uoc. tfc. aplicacions web per treball...

UOC. TFC. APLICACIONS WEB

PER TREBALL COL·LABORATIU

Memòria de projecte

Alumne: Eduardo Márquez López

Consultor: Ferran Prados Carrasco

Juny de 2015

UOC. TFC. Aplicacions web per treball col laboratiu


Eduardo Márquez López 2

A la meva dona,

per la seva comprensió, paciència i recolzament

durant els darrers sis anys.

A la meva filla,

que té tants anys com els que ha durat l’enginyeria,

per la seva paciència i comprensió quan el seu papa

ha hagut de marxar a estudiar.

Agraïments a la UOC per la oportunitat que ens dona d’estudiar a tots els

que tenim ganes de continuar creixent i només ho podem fer a distancia.




Contingut Contingut .................................................................................................................................. 3

1 Introducció ........................................................................................................................ 6

1.1 Objectius del projecte ................................................................................................ 6

1.2 Motivació i justificació ............................................................................................... 6

1.3 Recursos en el desenvolupament ............................................................................... 7

2 Planificació i metodologia.................................................................................................. 8

2.1 La planificació ............................................................................................................ 8

3 Requisits del sistema ......................................................................................................... 9

3.1 Els requeriments no funcionals .................................................................................. 9

3.1.1 Usabilitat .................................................................................................. 9

3.1.2 Portabilitat ............................................................................................... 9

3.1.3 Rendiment ............................................................................................... 9

3.1.4 Manteniment .......................................................................................... 10

3.1.5 Seguretat ............................................................................................... 10

3.2 Els actors principals ................................................................................................. 10

3.2.1 Root ....................................................................................................... 10

3.2.2 Administrador ........................................................................................ 10

3.2.3 Encarregats d'àrea ................................................................................ 10

3.2.4 Tècnics .................................................................................................. 11

3.2.5 Usuaris clients ....................................................................................... 11

3.2.6 Usuari administratiu ............................................................................... 11

3.3 Els requeriments funcionals ..................................................................................... 11

3.3.1 Funcionalitats d’administració ................................................................ 12

3.3.2 Funcionalitats de gestió de flux d’incidències ......................................... 12

3.3.3 Llistat i estadístiques ............................................................................. 14

3.3.4 Login, consulta i modificació de perfil..................................................... 14

3.4 Casos d’us ................................................................................................................ 15

3.5 Fitxes de casos d’ús ................................................................................................. 16

3.5.1 Login...................................................................................................... 16

3.5.2 Obrir incidència ...................................................................................... 17

3.5.3 Modificar detall d'incidència ................................................................... 17

3.5.4 Llistar incidències .................................................................................. 18




3.5.5 Consultar detall incidència ..................................................................... 19

3.5.6 Visualitzar el perfil.................................................................................. 19

3.5.7 Modificar dades de contacte .................................................................. 20

3.5.8 Estadístiques ......................................................................................... 20

3.5.9 Modificar progrés d’incidència................................................................ 21

3.5.10 Modificar estat d’incidència .................................................................... 22

3.5.11 Consultar càrrega de treball ................................................................... 23

3.5.12 Assignar incidència ................................................................................ 23

3.5.13 Canviar àrea d’incidència....................................................................... 24

3.5.14 Administració d’usuaris .......................................................................... 24

3.5.15 Enviar e-mail .......................................................................................... 25

4 Anàlisi i disseny del sistema ............................................................................................. 25

4.1 Diagrama de classes................................................................................................. 25

4.2 Model E/R, Model relacional de la base de dades .................................................... 26

4.3 Diagrames d’activitat. .............................................................................................. 28

4.3.1 Login...................................................................................................... 28

4.3.2 Obrir/Crear incidència. ........................................................................... 28

4.3.3 Modificar detall incidència. Modificar progrés d’incidència. Modificar estat

d’incidència. Assignar incidència. Canviar àrea d’incidència. ............................... 29

4.3.4 Llistar incidències. ................................................................................. 29

4.3.5 Consultar incidència (veure detall d’incidència). .................................... 30

4.3.6 Modificar dades de contacte .................................................................. 30

4.4 Diagrames de seqüència .......................................................................................... 31

4.4.1 Login...................................................................................................... 31

4.4.2 Obrir/Crear incidència. ........................................................................... 31

4.4.3 Llistar o cercar incidències. .................................................................... 32

4.4.4 Veure detall incidència. .......................................................................... 32

4.4.5 Modificar detall incidència (Modificar estat, modificar progrés, assignar i

canvi d’àrea). ....................................................................................................... 33

4.5 Prototipus de principals pantalles ............................................................................ 34

4.5.1 Login...................................................................................................... 34

4.5.2 Pantalla perfil d’usuari ........................................................................... 34

4.5.3 Pantalles Panel principal........................................................................ 35

4.5.4 Pantalla incidència ................................................................................. 37

4.5.5 Pantalla llistat d’incidències ................................................................... 39




5 Estudis i decisions ........................................................................................................... 41

5.1 Sobre tecnologia ...................................................................................................... 41

5.1.1 Python i Django. .................................................................................... 41

5.1.2 Postgresql ............................................................................................. 42

5.1.3 Apache + wsgi ....................................................................................... 43

5.1.4 Zurb Foundation .................................................................................... 43

5.1.5 Javascript, JQuery, Ajax i json ............................................................... 45

5.1.6 Llibreries javascript basades en JQuery per la representació

d’estadístiques i taules de dades ......................................................................... 48

5.2 Decisions en quant a funcionament ......................................................................... 49

5.2.1 Notificacions i màquina d’estats ............................................................. 49

5.2.2 Nou usuari root i limitacions en la edició d’incidències ........................... 50

6 Implantació i resultats ..................................................................................................... 51

6.1 Entorns virtuals, desenvolupament i producció ........................................................ 51

6.1.1 Entorn virtual i posada en marxa del desenvolupament del projecte ...... 51

6.1.2 Entorn de producció ............................................................................... 52

6.1.3 Connectar i configurar la base de dades ................................................ 52

6.2 Estructura del projecte ............................................................................................ 53

6.3 Càrrega de dades inicials a la base de dades ............................................................ 54

6.4 Captures de pantalla mes significatives .................................................................... 56

6.4.1 Panel principal, en aquest cas el d’administrador: ................................. 56

6.4.2 Pantalla de llistat d’incidències. ............................................................. 57

6.4.3 Pantalla de creació d’incidència. ............................................................ 58

7 Conclusions i futur de WinciGo ........................................................................................ 59

8 Bibliografia ...................................................................................................................... 60

8.1 Llibres consultats: .................................................................................................... 60

8.2 Recursos consultats online:...................................................................................... 60

9 ANNEX – Dades per la realització de proves ..................................................................... 61

1 Introducció

1.1 Objectius del projecte

Amb la realització d’aquest projecte es pretén assolir l’objectiu de la creació d’un gestor

d’incidències o tickets per web, un sistema sòlid i estable en la seva primera versió. Per assolir

amb satisfacció l’objectiu general, s’han d’aconseguir els objectius següents:

Planificar i seguir la planificació de les diferents fases i tasques de les fases en que es

separa la realització del projecte.

Consolidar els coneixements adquirits a la resta d’assignatures sobre documentació,

anàlisis i disseny.

Assolir coneixements en Python suficients per aconseguir l’objectiu general.

Assolir coneixements de programació web, comprendre el funcionament de les

peticions, respostes entre client i servidor, sessions i seguretat.

Ser capaç de traspassar l’anàlisi i el disseny a l’aplicació, aprenent a fer servir

frameworks (frontend o backend) i llibreries útils per aconseguir la fita i intentant ser

fidel als prototips i la idea de que l’aplicació sigui intuïtiva i amb un entorn amigable.

Que l’aplicació sigui instal·lable en un servidor web i continuar amb procés de millora

continua.

1.2 Motivació i justificació

La meva experiència com a estudiant i com a treballador dintre del mon de les TIC m’ha

permès aprendre a programar en entorn d’escriptori, siguin sistemes distribuïts o no. El mon

de la programació web ha estat sempre un mon interessant sota el meu punt de vista i del que

sempre he volgut aprendre, així doncs quina millor oportunitat?.

L’elecció del tema, tot i les propostes de la llista que es facilita a l’assignatura ha estat una

aposta personal per realitzar un gestor d’incidències tal i com a mi m’agradaria que funcionés

un gestor d’incidències en la meva empresa. I es que estàvem fent servir un gestor

d’incidències poc amigable i amb tecnologia desfasada. No havia pensat el nom, ni el disseny,

però si que tenia clars els següents punts:

Que l’aplicació es pogués fer servir en una empresa jerarquitzada on hi hagin àrees

definides amb tècnics que donen suport i que necessiten instancies superiors per

verificar la qualitat del servei.

Que les accions estiguin limitades segons el tipus d’usuari que faci servir l’aplicació.

Que mantinguin l’usuari, tant tècnics com clients, informats amb una simple visita al

sistema.




Que s’enviïn notificacions en els canvis d’estat.

La frase “Un dia faré un gestor de tickets web intuïtiu”, que havia dit als meus companys quan

encara em faltaven semestres per arribar al TFC, ha tornat i aquest dia ha arribat. La meva

motivació queda explicada i en aquest projecte, amb les limitacions del temps i l’ajuda del

consultor, intentaré assolir l’objectiu principal i satisfer els meus desitjos de fer una primera

versió d’un producte útil i adquirir un nivell acceptable de programació web.

1.3 Recursos en el desenvolupament

L’equip que s’ha fet servir durant la realització del projecte ha sigut una tablet Microsoft

Surface Pro amb Windows 8.1. Intel(R) Core(TM) i5-3317U amb 4 GB de RAM.

Tecnologia per al desenvolupament:

Per la codificació de la part del servidor es farà servir Python 3.4 amb el framework

Django versió 1.8. Amb aquest framework es realitzarà el disseny seguint el patró MVC

(Model View Controller), que en aquest cas s’anomena MVT (Model View Template) i

també es fa servir el seu ORM per la gestió de les dades al SGDB utilitzat.

Pel la persistència de les dades es fa servir el SGDB Postgresql.

De la banda del client es realitzarà codificació en Javascript, JQuery fent servir

frameworks com Zurb Foundation i llibreries com Chart-js i Datatables.net.

El software IDE triat per la codificació es Visual Studio 2013 amb els paquets necessaris per

treballar amb Python, Django i Javascript. La raó no era altre que la familiaritat que tinc amb

l’entorn per circumstancies laborals. Finalment, però, he escollit Sublime text 3 amb plugins

per treballar amb Django y Python com Djaneiro i Anaconda.

Per al control de versions i per motius de seguretat he triat Git i com a servidor de suport

Bitbucket.org.

En quant a software de gestió i documentació es faran servir les següents eines:

Paquet ofimàtic de Microsoft Office.

Disseny UML amb MagicDraw i disseny de la resta d diagrames amb Visio Studio 2013.




Diagrames de planificació i seguiment amb el software Gant Project.

Ajuda i recordatori de tasques OneNote 2013 en la versió escriptori i en la versió

Android per facilitar la inserció d’idees en moments en els que no disposi d’ordinador.

2 Planificació i metodologia

2.1 La planificació

Una planificació mes detallada i desglossada sempre ajuda a aconseguir els objectius.

La taula següent mostra la descomposició en tasques de les tasques principals, els lliuraments.

A cada lliurament se l’ha assignat un nom “P” seguit del nombre del lliurament. Cada tasca que

forma part d’aquest lliurament te el nom del lliurament seguit d’un punt i el nombre de tasca

indicant l’ordre de realització.

Degut a la falta d'experiència en la programació web i el desconeixement de la tecnologia

emprada en la resolució del projecte era difícil mantenir l’objectivitat, sobretot en la fase de

codificació. Un cop realitzat el projecte es pot dir que totes les fases menys la última s’han

complert a la perfecció. Degut a l’alta corba d’aprenentatge del framework Django, la fase P4.1

s’ha allargat mes del que està indicat a la programació actual comprimint les fases següents

fins a la data límit en un període de quinze dies.

Nom Descripció Dies Inici Finalització

P1 13 25/02/2015 09/03/2015

P1.1 Definició del projecte. Descomposició en activitats. Planificació.

12 25/02/2015 08/03/2015

P1.2 Revisió i lliurament. 1 09/03/2015 09/03/2015

P2 14 10/03/2015 23/03/2015

P2.1 Límits del problema. Anàlisis de requeriments no funcionals. Actors Implicats.

2 10/03/2015 11/03/2015

P2.2 Anàlisis de requeriments funcionals. 1 12/03/2015 12/03/2015

P2.3 Diagrames de classes. 4 13/03/2015 16/03/2015

P2.4 Model E/R. Model relacional de BD.

2 17/03/2015 18/03/2015

P2.5 Casos d'us. Fitxes de casos d'us.

4 19/03/2015 22/03/2015





P3 18 24/03/2015 10/04/2015

P3.1 Diagrames d'activitat. 5 24/03/2015 28/03/2015

P3.2 Diagrames de seqüència. 5 29/03/2015 02/04/2015

P3.3 Prototipatge de les principals interfícies. 7 03/04/2015 09/04/2015


P4 64 11/04/2015 14/06/2015

P4.1 Implementació. 37 11/04/2015 18/05/2015

P4.2 Posada en funcionament. 5 19/05/2015 23/05/2015

P4.3 Memòria. 7 24/05/2015 30/05/2015

P4.4 Presentació virtual. 3 31/05/2015 02/06/2015

P4.5 Vídeo explicatiu. 7 03/06/2015 09/06/2015


La metodologia amb la que s’ha treballat ha sigut metodologia en cascada seguint cadascuna

de les fases proposades a l’assignatura, amb l’ajut de la planificació presentada i un diagrama

de Gant.

3 Requisits del sistema

3.1 Els requeriments no funcionals

Aquesta secció detalla els requeriments no funcionals del sistema.

3.1.1 Usabilitat

S’ha de tenir en compte que l’usuari pot no estar acostumat a software de gestió d’incidències.

Per tant un repte important de l’aplicació es aconseguir un entorn intuïtiu i amigable per

l’usuari. L’aplicació haurà de tindre elements d’ajuda en la navegació, com tooltips, validació

de dades en la seva entrada al sistema, gestió d’errors i missatges clars sense ambigüitats.

L’aplicació haurà de permetre l’elecció de l’ idioma que desitgi l’usuari. En les primeres

versions de l’aplicació es presentaran alguns idiomes per triar, però el sistema es deixarà

preparat per afegir més traduccions.

3.1.2 Portabilitat

Es pretén que l’aplicació es pugui instal·lar en qualsevol de les plataformes en les que es pugui

instal·lar un servidor Apache 2.*. També es objectiu de l’equip de desenvolupament que la

web sigui accessible des de qualsevol dels principals navegadors actuals.

3.1.3 Rendiment

La resposta del sistema ha de ser ràpida en la gestió d’incidències i en l’execució de consultes a

la base de dades. En quant al software l’aplicació haurà de ser robusta, controlant i gestionant

els errors que es puguin produir, evitant errors incontrolats que converteixin en una mala




experiència l’ús de l’aplicació per part dels usuaris. Tot i que l’entorn de proves de l’aplicació

es limitat i que s’assegura un bon funcionament per aquestes limitacions, els aspectes

referents al hardware s’hauran de tenir en compte segons les característiques dels client on es

faci la implantació final.

3.1.4 Manteniment

El manteniment del lloc web serà senzill per part de l’administrador del sistema degudament

format i indicant-li, mitjançant la documentació necessària els requeriments per el correcte

funcionament del lloc. Si les accions de manteniment va mes enllà de les funcions del personal

de l’empresa client s’hauran de comunicar a l’equip de desenvolupament de l’aplicació.

En quant al manteniment del software el patró MVC (model vista controlador) i la possible

reutilització del codi permetrà ampliar i modificar les funcionalitats requerides pel client,

reduint el temps de treball.

3.1.5 Seguretat

Es basa la seguretat en la autenticació dels usuaris en la aplicació. Els usuaris de l’aplicació

hauran de disposar d’un usuari i contrasenya que només podrà crear l’usuari administrador.

Per tant a l’aplicació ha d’existir un usuari administrador des de la seva implantació.

3.2 Els actors principals

Els actors principals son els següents:

3.2.1 Root

Es l’encarregat d’administrar l’aplicació. Només aquest actor tindrà accés total a l’aplicació, a

més de tindre els permisos i funcionalitats de la resta d’usuaris i només el root podrà accedir a

l’entorn d’administració proporcionat per el framework Django per administrar l’aplicació i

modificar passwords. Junt amb l’administrador serà l’encarregat de crear els nous usuaris.

Aquest rol no estava definit en la primera proposta, però s’ha introduït per que l’administrador

pugui realitzar la resta e tasques de forma segura per la integració de les dades.

3.2.2 Administrador

Com el seu nom indica, es l’encarregat d’administrar l’aplicació. Només aquest actor tindrà

accés al menú de gestió de l’aplicació i de canviar les incidències de departament quan ho

sol·liciti un encarregat d’àrea, a més de tindre els permisos i funcionalitats de la resta

d’usuaris.

3.2.3 Encarregats d'àrea

Son els encarregats de l'àrea al que s’assigna la incidència, per tant son els encarregats

d’assignar la incidència a un dels tècnics d’aquest àrea. Poden consultar les incidències del seu

departament i la càrrega de treball dels seus tècnics. Poden obrir i modificar l’estat o qualsevol

altre aspecte de les incidències. Son els únics que poden sol·licitar al administrador la

reassignació d’una incidència a un altre area. I també seran els únics en establir una incidència




tancada com a visible per tots els usuaris del sistema, aspecte útil per consultes simples que es

considerin d’interès general. Aquesta última funcionalitat no s’implementa en la primera

versió.

3.2.4 Tècnics

Encarregats de resoldre les incidències assignades. Pot, per tant, modificar les incidències,

només aquells camps que depenguin de les accions correctores. Poden consultar les

incidències que tingui o hagi tingut assignades, així com la seva càrrega de treball i el seu

històric. També podrà consultar les incidències resoltes de la seva area per tal de trobar

solucions semblants. Pot sol·licitar el tancament d’una incidència per part dels encarregats del

seu àrea.

3.2.5 Usuaris clients

Son els clients finals que reporten una incidència mitjançant l’aplicació. Poden crear

incidències i rebran notificacions per part del sistema quan la incidència hagi estat

solucionada, desestimada o estigui pendent de la seva atenció. Poden consultar el seu històric

i poden consultar les seves incidències.

3.2.6 Usuari administratiu

Son usuaris encarregats d’introduir al sistema les incidències rebudes per altres canals

d’entrada, com telèfon o e-mail. Poden introduir la incidència, però no poden consultar

estadístiques del client. Poden consultar i modificar les incidències introduïdes per ells, però

no la informació referent al progrés. Poden sol·licitar el tancament d’una incidència encara

que no hagi estat solucionada si el client així ho demana.

S’han produït canvis respecte a la PAC corresponent a la fase d’especificació. Durant el procés

de codificació s’ha detectat un problema de consistència dels estats de les incidències

introduïdes al sistema i s’ha decidit la introducció d’una nova figura “El Root” que es l’únic

actor amb poder de canviar el flux normal de les incidències.

3.3 Els requeriments funcionals

Els requeriments funcionals de l’aplicació es poden dividir en cinc grups: funcionalitats

d’administració, gestió de flux d’incidències, llistat i estadístiques, i per últim, login, consulta i

modificació del perfil personal.

Dintre d’aquests grups es pot parlar de varies funcionalitats obligatòries o requeriments

funcionals i es detallen en llenguatge natural indicant també els usuaris que tindran accés a les

funcionalitats. Es tornarà amb mes detall a les fitxes dels casos d’ús.




3.3.1 Funcionalitats d’administració

Les funcionalitats d’administració únicament seran accessibles per l’usuari administrador.

Dintre d’aquest grup tenim les següents funcionalitats i una descripció d’elles:

3.3.1.1 Administració d’usuaris:

Els usuaris s’han de donar d’alta, modificar i eliminar per l’administrador o el root de

l’aplicació.

Els usuaris no s’eliminaran, passaran a estar desactivats. D’aquesta manera es manté

l’històric per les consultes de les incidències resoltes des de les àrees corresponents.

A part del nom d’usuari i password, serà obligatori una adreça de correu electrònic.

3.3.1.2 Administració d’Empreses:

Els clients que obren incidències seran usuaris d’una empresa i aquestes empreses

seran donades d’alta per l’administrador o el root del sistema.

Les empreses no s’eliminaren del sistema, es marcaran com inactives. D’aquesta

manera es pot mantenir l’històric per futures consultes.

3.3.1.3 Assignació d’àrea un usuari tècnic o encarregat

El personal de l’empresa s’ha d’assignar a les àrees definides en la base de dades.

3.3.2 Funcionalitats de gestió de flux d’incidències

En aquest grup es situen totes les funcionalitats referents al recorregut d’una incidència des de

que s’obre fins a que es dona per finalitzada.

3.3.2.1 Creació d’incidència

Actors: Tots els usuaris de l’aplicació.

Descripció: Qualsevol usuari ha de poder obrir una incidència. En obrir la incidència

s’haurà d’indicar per l’empresa que es registra la incidència. En el cas del personal de

l’empresa (Administrador, Encarregat d’àrea, tècnic o administratiu) el sistema

permetrà escollir l’empresa i l’usuari a l que s’ha notificar. En el cas d’un client no es

permetrà triar empresa, serà la seva. El sistema sempre ha de guardar l’usuari que ha

obert la incidència. La creació d’una incidència ha de notificar al encarregat de l’àrea

que consideri la persona que obre la incidència de que s’ha produït una nova entrada.

3.3.2.2 Modificació d’incidència

Les incidències es podran modificar per tots els usuaris del sistema, encara que segons el grup

d’usuari al que pertanyi podrà realitzar unes accions o altres. Per modificar una incidència

l’usuari haurà d’accedir a la incidència primer, però dintre de les modificacions que es podran

fer cal definir tres grups. Aquests grups es mantindran en les fitxes de casos d’us, mantenint

aquesta separació ja que inclouen accions diferents en cada cas. En aquesta secció s’han

produït canvis dintre dels grups definits respecte a la PAC d’especificació i anàlisi, ja que a part




de la introducció al sistema d’un nou actor, el root, en el moment de la codificació i la

realització de proves s’ha vist mes coherent la modificació de les zones de la incidència a les

que es pot accedir per part de cada actor com s’explica a continuació.

3.3.2.2.1 Modificar part descriptiva de les incidències

Actors: Només clients, administratius i root.

Descripció: L’usuari podrà modificar la part descriptiva de la incidència, es a dir, la

descripció del problema, les dades de contacte, l’àrea definida. Amb les següents

restriccions:

Un usuari client no podrà modificar la descripció si la incidència ja ha

començat a tractar-se.

Un tècnic o un encarregat no podran tocar la descripció si la incidència no

l’han creada ells.

3.3.2.2.2 Modificar part tècnica de les incidències

Actors: Usuaris tècnics, encarregats d’àrea, administrador i root.

Descripció: Qualsevol dels actors esmentats podran modificar la informació de la

incidència que considerin necessària per seguir el procés de resolució. També el

progrés de resolució per poder visualitzar-lo per part dels clients. Els tècnics nomes

podran modificar les incidències que tinguin assignades i els encarregats les de la seva

area. Els administradors podran modificar l’àrea si aquesta estigués mal definida.

3.3.2.2.3 Modificar estat de les incidències

Actors: Usuaris tècnics, encarregats d’àrea, administradors i root.

Descripció: Els usuaris tècnics podran modificar l’estat de les incidències i el canvi

d’estat han de provocar notificacions. Aquestes notificacions en els canvis d’estat es

descriuen amb mes detall a la fitxa de cas d’ús “Modificar estat d’incidència”.

3.3.2.2.4 Visualització de les incidències

Actors: Tots els usuaris del sistema.

Descripció: Els usuaris hauran de poder visualitzar les incidències a les que tinguin

accés per grup o area de la següent manera:

Administratius i clients: De les incidències de la seva empresa o les creades per

ells en el cas dels administratius, podran visualitzar una barra de progrés, la

part descriptiva de la incidència i l’estat.

Tècnics, encarregats i Administrador: Podran visualitzar tots els detalls de la

incidència. Els tècnics i encarregats només si pertany al seu àrea.




3.3.3 Llistat i estadístiques

El sistema ha de permetre llistar les incidències i les carregues de treball dels tècnics.

3.3.3.1 Llistar incidències

Actors: Tots els usuaris del sistema.

Descripció: Els usuaris podran veure el llistat de les incidències o creades per ells en el

cas dels clients, o de l’àrea corresponent en el cas del personal de l’empresa.

L’administrador ho pot llistar tot. S’han de permetre filtres per reduir el nombre de

resultats de la cerca.

3.3.3.2 Llistar càrrega de treball

Actors: Encarregats d’àrea.

Descripció: Els encarregats d’àrea han de poder veure la càrrega de treball dels seus

tècnics per una millor assignació de les tasques.

Aquesta funcionalitat no està implementada explícitament per falta de temps, encara que

es possible consultar la càrrega de treball dels seus tècnics mitjançant el llistat

d’incidències i filtrant i reordenant les columnes corresponents.

3.3.3.3 Estadístiques

Actors: Tots els actors.

Descripció: En funció de l’usuari que hagi accedit a l’aplicació l’usuari ha de poder

visualitzar estadístiques de les incidències. Seria requisit desitjable que poguessin ser

gràfiques que presentessin resums estadístics.

3.3.4 Login, consulta i modificació de perfil

3.3.4.1 Login

Actors: Tots els usuaris amb usuari i contrasenya del sistema.

Descripció: Un usuari ha d’entrar a l’aplicació mitjançant l’entrada i verificació de les

seves credencials.

3.3.4.2 Consulta i modificació del perfil:

Actors: Tots els usuaris del sistema menys el root.

Descripció: Els usuaris podran visualitzar les seves dades de contacte i modificar-les si

es produeix un canvi, ja que d’això depèn que rebi les notificacions de canvi d’estat en

cas que el procediment ho requereixi.




3.4 Casos d’us




Modificació respecte a la proposta inicial:

L’usuari root podrà realitzar els mateixos casos d’ús que l’administrador a més d’accedir al

menú d’administració proporcionat per Django, on accedirà a funcionalitats especifiques com

canvi de contrasenya o eliminació de registres de la base de dades.

En la fase de codificació s’ha decidit que els usuaris administratius podran visualitzar i

modificar el seu perfil, així com visualitzar estadístiques dintre del seu nivell de privilegis.

3.5 Fitxes de casos d’ús

3.5.1 Login

Objectiu Entrar a l'aplicació

Estén

Inclou

Casos d'ús relacionats

Actors Usuari administratiu, Client, Tècnic, Encarregat d’àrea, Administrador, Root

Actor primari Usuari administratiu, Client, Tècnic, Encarregat d’àrea, Administrador, Root

Precondició Usuari donat d'alta

Postcondició Login d’usuari

Alternatives de procés i excepcions

Usuari no present al sistema. Credencials no vàlides.

Descripció L'usuari accedeix a la pàgina de login on haurà d'escriure les seves credencials d’accés. El sistema validarà si pot entrar a l'aplicació.

Canvis respecte a la proposta inicial

Introducció de l’usuari root.




3.5.2 Obrir incidència

Objectiu Omplir un formulari amb la descripció del problema o dubte de l'usuari que l'omple o d'un tercer en cas de no ser un client.

Estén

Inclou Enviar e-mail

Casos d'ús relacionats Enviar e-mail.



Precondició Usuari ha fet login amb èxit.

Postcondició Nova incidència a la base de dades.


Excepcions en la validació en l'entrada de dades al formulari d’incidència.

Descripció Qualsevol usuari pot obrir una incidència. Un client es el principal interessat en obrir una incidència, però el personal de l'empresa, tingui el rol que tingui, pot obrir una incidència que hagi rebut d'un client per un canal de comunicació diferent. Al formulari de la incidència es podran omplir els camps referents a la descripció i origen de la incidència. Els encarregats de l’àrea de la incidència han de rebre notificació.


La introducció de l’usuari root.

3.5.3 Modificar detall d'incidència

Objectiu Accedir a una incidència per modificar el seu contingut.

Estén Consultar incidència.

Inclou

Casos d'ús relacionats Consultar incidència.



Precondició Usuari ha fet login amb èxit. La incidència existeix. La incidència no s'ha tancat. El nivell de privilegis permet accedir a la incidència.

Postcondició Incidència modificada.


Excepcions en la validació en l'entrada de dades al formulari d’incidència. Segons el rol de l’usuari:

- Administratiu i client: Nomes quan la incidència no s’hagi començat a tractar per un tècnic, podran modificar les dades




referents a la descripció de la incidència, no podran modificar les dades referents al procés de resolució.

- Tècnic: Podrà modificar tots els camps de la part tècnica de la incidència si la té assignada.

- Encarregat: Podrà modificar tots els camps de la part tècnica de la incidència si la incidència es del seu àrea.

- Administrador: Podrà modificar part tècnica de la incidència si la incidència està pendent de canvi d’àrea.

- Root: Pot modificar qualsevol camp de qualsevol incidència.

Descripció Un usuari pot accedir a la incidència, si te permisos necessaris per accedir, per modificar el detall de la incidència sempre que aquesta no s'hagi tancat. Si l’usuari es Root no té limitacions en la modificació.


La introducció de l’usuari Root i la limitació en l’accés a les parts de la incidència que pot accedir cada actor.

3.5.4 Llistar incidències

Objectiu Treure un històric d'incidències llistades que es puguin filtrar per diferents conceptes.

Estén

Inclou

Casos d'ús relacionats Consultar detall d’incidència.

Actors Usuari administratiu, Client, Tècnic, Encarregat d’àrea, Administrador

Actor primari Usuari administratiu, Client, Tècnic, Encarregat d’àrea, Administrador

Precondició Usuari ha fet login amb èxit. Incidències visibles per l'usuari al sistema.

Postcondició Visualització de llistat d'incidències segons criteri.


L'usuari no pot visualitzar cap incidència perquè no te accessibles per ell. Segons el tipus d’usuari:

- Administratiu: Podrà llistar totes les incidències dels client. - Client: Podrà llistar les seves incidències. - Tècnic i encarregat: Podrà llistar les incidències del seu

departament o àrea. - Administrador: Podrà llistar totes les incidències. - Root: Podrà llistar totes les incidències.

Descripció L'usuari vol accedir a un llistat d'incidències filtrades o no pels criteris que permeti l'aplicació segons els seus permisos, es a dir, depenent del tipus d'usuari.


Introducció de l’usuari Root.




3.5.5 Consultar detall incidència

Objectiu L’usuari vol conèixer la situació d'una incidència.

Estén Llistar incidències.

Inclou

Casos d'ús relacionats Llistar incidències, Modificar detall d’incidència, Modificar progrés d’incidència, Modificar estat d’incidència, Canviar àrea d’incidència.

Actors Usuari administratiu, Client, Tècnic, Encarregat d’àrea, Administrador

Actor primari Usuari administratiu, Client, Tècnic, Encarregat d’àrea, Administrador

Precondició Usuari ha fet login amb èxit. L'usuari pot accedir a la incidència.

Postcondició Es visualitza la situació de la incidència.


Segons el rol d’usuari: - Administratiu: Podran visualitzar el progrés, la descripció,

però no el detall del progrés. Podran visualitzar les incidències dels clients.

- Clients: Podran visualitzar el progrés i la descripció, però no el detall del progrés. Podran visualitzar les seves incidències.

- Tècnics i encarregats: Si la incidència es de la seva area, podran visualitzar tota la incidència.

- Administrador: Pot visualitzar qualsevol incidència. - Root: Pot visualitzar qualsevol incidència.

Descripció L'usuari vol conèixer l'estat d'una incidència. En funció del nivell d'accés podrà visualitzar unes dades o altres. Per exemple, un usuari administratiu o client no tindran accés a la part de la incidència que indica les accions que s'estan prenent, a menys que li estigui permès. Per obrir la incidència haurà de seleccionar-la d'un llistat d'incidències.


La introducció de l’usuari Root. Els clients i els administratius no poden visualitzar l’estat de la incidència, això es informació per a la part tècnica.

3.5.6 Visualitzar el perfil

Objectiu L'usuari pot visualitzar les seves dades del perfil.

Estén

Inclou

Casos d'ús relacionats Modificació dades de contacte.

Actors Administratiu, Client, Tècnic, Encarregat d’àrea, Administrador

Actor primari Administratiu, Client, Tècnic, Encarregat d’àrea, Administrador


Postcondició Visualització del seu perfil d'usuari.





Descripció L'usuari pot visualitzar les seves dades del perfil. Si es tracta d'un usuari que sigui notificable per alguna de les operacions de l'aplicació, tindrà interès en verificar si les dades de contacte estan actualitzades.


Introducció al cas d’ús de l’usuari administratiu.

3.5.7 Modificar dades de contacte

Objectiu L’usuari pot modificar les seves dades del perfil.

Estén Visualitzar el perfil.

Inclou

Casos d'ús relacionats Visualitzar el perfil.

Actors Administratiu, Client, Tècnic, Encarregat d’àrea, Administrador

Actor primari Administratiu, Client, Tècnic, Encarregat d’àrea, Administrador


Postcondició Les dades de contacte de l'usuari han estat modificades.


Excepcions en l'entrada de dades al formulari de modificació.

Descripció Un usuari que hagi de ser notificat per l'aplicació haurà de poder modificar les dades de contacte al formulari. Per exemple, en cas que un client canviï la seva adreça de correu electrònic i vulgui rebre les notificacions corresponents.


Introducció al cas d’ús de l’usuari administratiu.

3.5.8 Estadístiques

Objectiu Visualitzar estadístiques que presenta l'aplicació.

Estén

Inclou


Actors Administratiu, Client, Tècnic, Encarregat d’àrea, Administrador, Root

Actor primari Administratiu, Client, Tècnic, Encarregat d’àrea, Administrador Root


Postcondició L’usuari visualitza les estadístiques oferides pel seu nivell


En funció del rol de l’usuari es presentaran estadístiques d’incidències:

- Client: Les estadístiques seran de les seves incidències. - Administratiu: Les estadístiques d’incidències obertes per ell i

altres de l’empresa.




- Tècnic: Les estadístiques seran de les incidències que té assignades.

- Encarregat: Les estadístiques seran referents al seu area. - Administrador: Les estadístiques seran de totes les

incidències. - Root: Les estadístiques seran de totes les incidències.

Descripció L'aplicació presenta una sèrie d’estadístiques. Les estadístiques ja estan predefinides pel nivell/grup de l'usuari.


3.5.9 Modificar progrés d’incidència

Objectiu Modificar la barra de progrés i accions de resolució d'incidència.

Estén Consultar detall incidència.

Inclou

Casos d'ús relacionats Consultar detall incidència.

Actors Tècnic, Encarregat d’àrea, Administrador

Actor primari Tècnic, Encarregat d’àrea, Administrador

Precondició Usuari ha fet login amb èxit. La incidència existeix i l'usuari te accés. La incidència no està tancada.

Postcondició El progrés correctiu ha estat modificat.


Error de validació en l'entrada de dades. - Els tècnics poden modificar el progrés de les seves incidències. - Els encarregats poden modificar el progrés de les incidències

de la seva area. - Els administradors poden modificar el progrés de qualsevol

incidència.

Descripció Un usuari de nivell tècnic accedeix a una incidència per modificar informació referent a la resolució del problema. Si cal, podrà modificar el progrés de la resolució perquè l'usuari de nivell no tècnic (clients i administratius) puguin veure el progrés de la resolució en una barra de progrés, per exemple.




3.5.10 Modificar estat d’incidència

Objectiu Modificar l'estat de la incidència.


Inclou Enviar e-mail.

Casos d'ús relacionats Consultar incidència. Enviar e-mail. Assignar incidència. Canvi àrea d’incidència.

Actors Tècnic, Encarregat d’àrea, Administrador

Actor primari Tècnic, Encarregat d’àrea, Administrador

Precondició Usuari ha fet login amb èxit. La incidència existeix i l'usuari te accés. La incidència no està tancada.

Postcondició L'estat de la incidència es modifica.


Segons l’usuari es mostraran diferents estats per aplicar a la incidència:

- Els tècnics tindran els següents estats per establir : Quan comenci a resoldre una incidència: EN_EXECUCIO. Quan necessitin intervenció de tercers: PENDENT_TERCERS. Quan necessitin informació del client: PENDENT_CLIENT. Quan es finalitza: PENDENT_VERIFICACIÓ.

- Els encarregats tindran els següents estats per establir: EN_EXECUCIO, PENDENT_TERCERS, PENDENT_CLIENT. Quan creu que l’àrea no es la corresponent: PENDENT_AREA. Quan assigna un tècnic TECNIC_ASSIGNAT. Quan verifica la incidència sol·licitada pel tècnic: FINALITZADA.

- L’administrador tindrà els següents estats per establir: EN_EXECUCIO, PENDENT_TERCERS, PENDENT_CLIENT, FINALITZADA. Quan es torna a establir l’àrea a la que correspon la incidència: AREA_ASSIGNADA. Quan una incidència no s’ha de tenir en compte: DESESTIMADA.

Es notificarà només en els casos de canvi d’estat següents: - Nova incidència i AREA_ASSIGNADA: S’ha obert una nova

incidència i s’ha de notificar al responsable d’àrea seleccionada per l’usuari al crear la incidència.

- PENDENT_AREA a AREA_ASSIGNADA: Es notifica al encarregat de la nova rea assignada.

- AREA_ASIGNADA a PENDENT_AREA: Es notificarà a l’administrador per que torni a assignar l’àrea.

- AREA_ASSIGNADA a TECNIC_ASSIGNAT es notifica al tècnic assignat per que comenci la resolució de la incidència.

- EN_EXECUCIO a PENDENT_VERIFICACIO: es notifica a l’encarregat d'àrea per que verifiqui i tanqui la incidència si cal o torni a TECNIC_ASSIGNAT si creu que no està finalitzada.

- PENDENT_VERIFICACIO a FINALITZADA: es notifica al client. - PENDENT_AREA a DESESTIMADA: Un encarregat creu que no

correspon al seu area i l’administrador la desestima per el motiu que sigui. Es notifica al client.




Descripció L'usuari tècnic vol modificar l'estat de la incidència per que consti quan es visualitzi o per notificar a instancies superiors perquè es prengui alguna decisió.

3.5.11 Consultar càrrega de treball

Objectiu Visualitzar informació respecte a la càrrega de treball que tenen els usuaris que es té a càrrec.

Estén

Inclou


Actors Encarregat d’àrea, administrador.

Actor primari Encarregat d’àrea, administrador.


Postcondició Es visualitza la informació.


Descripció L'usuari vol veure informació respecte a la càrrega de treball que tenen els usuaris que té a càrrec.

3.5.12 Assignar incidència

Objectiu Assignar incidència a un tècnic


Inclou Modificar estat d’incidència.

Casos d'ús relacionats Consultar incidència. Enviar e-mail.

Actors Encarregat d’àrea, administrador.

Actor primari Encarregat d’àrea, administrador.

Precondició Usuari ha fet login amb èxit. La incidència existeix i l'usuari te accés. L’àrea té tècnics.

Postcondició Incidència assignada a un tècnic





Descripció Una incidència introduïda per un usuari ha de ser assignada per un encarregat d’àrea a un tècnic perquè comenci el seu tractament. Es notificarà al tècnic de que té una nova incidència a la cua de treball. Els usuaris a escollir han de sortir ordenats per càrrega de treball en el moment de l’assignació. Un cop assignat un tècnic es produirà automàticament un canvi d’estat a TECNIC_ASSIGNAT.

3.5.13 Canviar àrea d’incidència

Objectiu Modificar l’àrea de la incidència quan s'ha obert la incidència.


Inclou Modificar estat d’incidència.

Casos d'ús relacionats Consultar incidència. Enviar e-mail.

Actors Administrador

Actor primari Administrador

Precondició L’usuari s’ha logejat amb èxit. La incidència existeix i no està tancada.

Postcondició La incidència canvia d’àrea.


Descripció L’administrador ha rebut notificació de que una incidència no correspon a l’àrea escollida per l'usuari que ha obert la incidència i realitza el canvi d’àrea. Un cop assignada l’àrea es produeix un canvi d’estat de la incidència a AREA_ASSIGNADA..

3.5.14 Administració d’usuaris

Objectiu Administrar usuaris. Crear, modificar i esborrar usuaris i els seus grups i permisos.

Estén

Inclou


Actors Administrador.

Actor primari Administrador.

Precondició L’usuari s’ha logejat amb èxit.

Postcondició


Crear usuaris. Modificar usuaris . Esborrar usuaris: si un usuari es esborrat del sistema s’haurà de mantindre el seu històric d’incidències. Assignar àrea als usuaris.

Descripció Tasques d’administració del sistema relacionades amb la gestió d’usuaris.




3.5.15 Enviar e-mail

Objectiu Notificar als usuaris d’un canvi d’estat.

Estén

Inclou

Casos d'ús relacionats Modificar estat d’incidència. Obrir incidència.

Actors

Actor primari Sistema.

Precondició El sistema ha de disposar de compte de correu. Els usuaris que vulguin ser notificats han de tindre comte de correu.

Postcondició Notificació enviada.


Si l’usuari que vol ser notificat no te compte de correu l’estat no ha de canviar i s’ha de notificar per pantalla.

Descripció Els usuaris han d’estar informats d’alguns canvis d’estat importants en el procés de resolució d’una incidència.

4 Anàlisi i disseny del sistema

4.1 Diagrama de classes

Abans de mostrar el diagrama de classes de l’aplicació s’ha d’aclarir que no es representaran

totes les classes de l’aplicació degut a que la utilització del framework Django encapsula

classes i entrar en el disseny del framework no es objecte d’aquest document. No obstant, al

disseny de les classes corresponents al model de dades es mostra la taula d’usuaris, ja que les

classes model si es poden extreure un cop generada la base de dades amb la api de Django.

Degut al patró MVT (Model View Template) que es fa servir amb el framework Django i el seu

funcionament el diagrama de classes correspon a les classes model:




4.2 Model E/R, Model relacional de la base de dades

Per tal d’aprofitar les funcionalitats que ofereix el Framework Django e quant a control de

sessions i registre d’activitat s’ha dissenyat el model relacional de base de dades s’ha realitzat

adjuntant al model de dades que el framework Django fa servir les taules noves. També s’han

introduït els camps necessaris per tal d’incorporar la informació necessària a les taules ja

existents.




A continuació es presenta una imatge amb un menor nivell de zoom on es poden apreciar els

camps de les taules:

El diagrama del model relacional ha sofert variacions significatives respecte a la proposta

inicial que es va fer durant el semestre. La substitució dels enumeradors d’estat, de canal

d’entrada i de tipus d’incidència per taules de la base de dades es un dels canvis introduïts. La

desaparició de les relacions de tècnics directament amb la taula incidències o de clients amb la

mateixa taula ha estat la conseqüència de la introducció de una nova taula, app_role, per

definir el rol de cada usuari del sistema i definir aquest rol a les taules que hereten

directament d’usuari (auth_user) amb una relació 1..1.




4.3 Diagrames d’activitat.

4.3.1 Login.

4.3.2 Obrir/Crear incidència.

4.3.3 Modificar detall incidència. Modificar progrés d’incidència. Modificar estat

d’incidència. Assignar incidència. Canviar àrea d’incidència.

4.3.4 Llistar incidències.




4.3.5 Consultar incidència (veure detall d’incidència).

4.3.6 Modificar dades de contacte




4.4 Diagrames de seqüència

4.4.1 Login.

4.4.2 Obrir/Crear incidència.




4.4.3 Llistar o cercar incidències.

4.4.4 Veure detall incidència.




4.4.5 Modificar detall incidència (Modificar estat, modificar progrés, assignar i canvi

d’àrea).




4.5 Prototipus de principals pantalles

4.5.1 Login

4.5.2 Pantalla perfil d’usuari




4.5.3 Pantalles Panel principal

4.5.3.1 Usuaris Client

4.5.3.2 Usuaris tècnics




4.5.3.3 Usuaris encarregats d’àrea

4.5.3.4 Usuari administrador




4.5.4 Pantalla incidència

4.5.4.1 Usuaris sense accés a detall d’accions tècniques




4.5.4.2 Usuaris amb accés a detall d’accions tècniques




4.5.5 Pantalla llistat d’incidències

4.5.5.1 Llistat per clients

4.5.5.2 Llistat per tècnics




4.5.5.3 Llistat per encarregats

4.5.5.4 Llistat per Administrador




5 Estudis i decisions

5.1 Sobre tecnologia

5.1.1 Python i Django.

Com he comentat en l’apartat de motivació, la raó de triar aquest area es convertia en un

repte per la falta d’experiència en programació web. Per tal de disminuir “l’impacte” d’un nou

paradigma de programació per a mi, en un principi havia decidit realitzar la codificació en

ASP.NET, degut a la meva experiència en C# i el coneixement de l’entorn de desenvolupament,

però parlant del hosting amb el consultor i veient les característiques del servidor del que

disposàvem a la UOC, vaig pensar que seria una bona opció triar una tecnologia compatible per

la seva naturalesa multiplataforma. Posats a triar un nou llenguatge, i assumint que això

tornaria a restar-me, volia apostar per un llenguatge proper al llenguatge natural i que fos net i

simple en la seva sintaxi, d’això m’havia informat fa temps per simple curiositat. I no només

això, també necessitaria una comunitat amplia per que segur que necessitaria moltes

respostes i trobar-les ràpidament davant dels milers de preguntes que em sorgirien. Per

aquests motius vaig pensa que el millor candidat era Python, i així li vaig comentar al meu

consultor del projecte.

Durant la tria del llenguatge havia d’investigar: Com es Python? Com es fa per crear aplicacions

Web en Python? Ja havia sentit parlar de Django, com un framework molt potent per la creació

de aplicacions web, però també havia sentit parlar de Ruby on Rails com a potencia en el

desenvolupament web i de Node.js, a part de php. Tocava centrar-se en una i formar-se per

començar a donar forma al projecte. Vaig triar Python amb Django perquè consultant la seva

comunitat vaig trobar força documentació i exemples de llocs desenvolupats amb Django que

van despertar la meva curiositat, entre ells bitbucket.org, servidor Git que jo ja havia fet servir

en una altre assignatura.




Encara que la corba d’aprenentatge es molt alta, l’experiència i coneixements adquirits en la

realització d’aquest projecte es força gratificant com per recomanar aquest procés

d’aprenentatge amb Django.

Django està dissenyat seguint el patró MVC (Model-View-Controller), però s’ha de tindre en

compte que no es del tot aquest patró, potser per això el nom que els seus creadors han posat

al patró es MVT (Model-View-Template). El seu funcionament molt esquematitzat es el

següent:

Un cop llegits manuals i documentació una de les característiques mes rellevants es la potencia

del seu ORM (Object Relacional Mapping) que permet una abstracció total de la base de dades.

D’aquesta manera el programador només ha de definir el model i les relacions entre les classes

definides i sincronitzar mitjançant python amb la base de dades, de la resta se’n ocupa Django.

EL seu panel d’administració i API de control d’autenticació i control de sessions em van acabar

de convèncer. La gestió per part d’un usuari de les tasques de manteniment, tot i que per

temes de seguretat he optat per crear un administrador amb menys privilegis, es una

característica que no es pot desestimar en una aplicació com la que es pretén desenvolupar.

5.1.2 Postgresql

PostgreSQL es l’elecció en quant a servidor de bases de dades i les raons son:

Àmpliament popular - Ideal per tecnologies Web.

Facilitat en l’administració. Per la seva administració i veure els resultats de les proves

de manera ràpida s’ha fet servir pgAdmin III.

La seva sintaxis SQL es estàndard, tot i que l’ORM de Django se’n ocupa d’això.

Multiplataforma.

Molta documentació i gran comunitat.




I per últim la mes important, un cop es triats varis candidats, es la recomanació de PostgreSQL

com a sistema gestor de bases de dades en la documentació de Django.

5.1.3 Apache + wsgi

La meva elecció per la publicació de l’aplicació web WinciGO es el servidor Apache. La meva

elecció ha estat condicionada per la popularitat d’aquest servidor i la gran comunitat que dona

suport. En converses amb el consultor em va comentar que el servidor a la nostra disposició

tenia instal·lat Apache amb el mòdul mod-wsgi.

El mòdul wsgi es un mòdul necessari per que Apache pugui córrer aplicacions en Python,

trobar informació de com configurar Apache amb mod-wsgi no porta mes d’uns minuts degut

a la ja comentada gran comunitat.

Tot i que, finalment no he instal·lat l’aplicació al servidor de la UOC i l’he pujat a un hosting ,

també es fa servir Apache amb el mòdul wsgi. La seva configuració no ha sigut necessària ja

que es tracta d’un hosting amb espai preconfigurat per aplicacions realitzades en Django.

5.1.4 Zurb Foundation

Cada cop son més els usuaris que fan servir els seus smartphones i tablets per fer servir les

seves aplicacions i visitar les seves webs preferides. Els consumidors de WinciGo son persones

actuals, persones que realitzen moltes de les seves operacions des de dispositius mòbils, ser

capaç de preparar l’aplicació perquè es pugui adaptar als diferents dispositius es un repte que

es pot assolir amb la tècnica de Responsive design.

Les avantatges del responsive design son les següents:




Càrrega rapida del lloc web als dispositius portàtils.

Millor lectura, amb el tamany de lletra adequada.

Millor experiència en la navegació: botons adaptats per l’ús tàctil del dispositiu.

Per assolir el disseny de les plantilles s’ha fet servir Zurb Foundation, que junt amb Twitter

Bootstrap, es un framework per la creació de plantilles amb estructura responsiva.

La base del disseny del framework CSS Zurb Foundation es la divisió de la pantalla en un grid

de 12 columnes dividit en 3 tamanys base: small (layout per smartphones), medium (tablets) y

large (desktops). Tots els components excepte el menú principal, per decisió pròpia, no han

hagut de ser re-codificats per als diferents tamanys.

Un exemple en la codificació responsive del menú principal:

Per les pantalles grans el menú es:

Es pot apreciar la classe “hide-for-small” que s’encarrega d’ocultar aquest menú de navegació.

En canvi la codificació per al mateix menú en dispositius petits te una classe es :




5.1.5 Javascript, JQuery, Ajax i json

Per millorar l’experiència de l’usuari i controlar la interacció d’aquest amb el sistema s’ha fet

servir javascript i JQuery.

A part de les llibreries necessàries per al framework Zurb Foundation s’han fet servir funcions

en Javascript per interactuar amb l’usuari, com per exemple per mostrar les notificacions un

cop realitzades les operacions, o per deshabilitar l’entrada de dades en les incidències si el seu

estat no permet la seva modificació.

Un dels problemes que m’he trobat es la de comunicar al client el resultat de les operacions,

tot i que els formularis de Django mostren els errors, jo volia redireccionar a una altre pàgina

quan l’operació realitzada a un formulari tingues èxit. Llavors vaig optar per enviar un missatge

d’èxit i recollir-lo a la pàgina redireccionada. Un cop carrega la nova pàgina, si te missatge

d’èxit afegeixo un input ocult amb un id=”exito”. Quan carrega la pàgina executa un codi

javascript que treu del DOM l’objecte ocult si existeix i afegeix codi javascript per llançar un

modal quan la pàgina hagi carregat.




5.1.5.1 Cas d’ús de JQuery sense Ajax per mostrar notificacions:

A la plantilla html:

Al carregar la pàgina:

Quan ha carregat la pàgina:

Modal que es mostra per mostrar l’èxit en la operació realitzada:

5.1.5.2 Exemple d’ús d’ Ajax per carregar una gràfica del panel principal.

Amb la mateixa finalitat de la millora de l’experiència de l’usuari s’ha fet servir Ajax de la

llibreria JQuery amb json per a carrega de dades del servidor al client de manera asíncrona.

Exemples clars d’ús es la càrrega de les dades al panel principal dintre dels gràfics. Cal

comentar que pyhton disposa de llibreries per serialitzar les dades en json i facilitar el pas de

dades entre servidor i client.




L’esquema de peticions i respostes mitjançant Ajax a Django es el següent:

Prenem com a exemple la funció Ajax que es crida quan carrega la pantalla i que s’encarrega

d’anar a buscar les dades al servidor cridant a la vista de Django que es troba al fitxer views.py.

Funció Ajax:

Funció al fitxer views.py:

Aquesta última funció crida a una altra que s’ha tret del fitxer views.py per tal de reduir el seu

tamany i començar amb la modulació del codi.




5.1.6 Llibreries javascript basades en JQuery per la representació d’estadístiques i taules

de dades

5.1.6.1 Chart.js

La presentació d’estadístiques s’ha realitzat al panel principal i es tracta de dos gràfiques de la

llibreria chart.js carregades mitjançant Ajax. Cada usuari càrrega les dades mes representatives

o més interessants segons el rol al que pertany. A través d’aquestes crides Ajax s’obtenen fins i

tot els tooltips personalitzats i es prepara la implementació futura de canvis d’idioma.

5.1.6.2 Datatables.net

Degut a que la quantitat d’informació obtinguda del servidor pels usuaris mes freqüents del

sistema es pot carregar en memòria del client vaig decidir fer servir una llibreria per

representar les dades en taules que funciona sobre JQuery en la seva versió sense Ajax.

Aquesta llibreria forma part del projecte Datatables.net. A més de proporcionar la

representació de les dades, te una sèrie de característiques que em van resultar atractives,

com son la possibilitat de cerca, de paginació i de disseny responsive.

Aquestes taules son la base de qualsevol objecte modificable per l’usuari, es a dir per les

incidències en cas de tots els usuaris i pels objectes modificables per par de l’administrador.




A part de l’ús descrit, també s’ha fet servir aquest component en el panel principal per tal de

mostrar fins a les deu ultimes incidències que requereixen l’atenció de l’usuari logejat a

l’aplicació. En aquestes pantalles de panel principal s’ha fet servir Ajax per personalitzar les

capçaleres i no haver de crear una plantilla html nova o diferents plantilles parcials per cada

usuari.

Per la edició de cada registre he creat codi javascript que fent servir el DOM envia el id del

registre que es vol modificar. A continuació es pot veure una mostra del codi encarregat de

realitzar aquesta acció al fer “click” a qualsevol dels botons que també s’han introduït a cada

registre de la taula.

Cal mencionar que el suport que he trobat per aquesta llibreria ha sigut elevat i que existeix la

possibilitat de fer córrer la versió Ajax si el volum de dades arribés a ser molt elevat.

5.2 Decisions en quant a funcionament

5.2.1 Notificacions i màquina d’estats

Per tal de simplificar i unificar l’enviament de notificacions segons els diferents canvis d’estat

es va codificar una màquina d’estats al fitxer functions.py que es crida des de view.py amb el

nom de funció:

send_wincigo_email(old_state, issue, iamroot)

En Python no he trobat l’estructura switch...case a la que estem acostumats els programadors

que em fet servir Java o .Net, però he implementat la solució amb l’estructura if...elif...

Aquesta funció rep un estat del que ve la incidència, un estat nou de la incidència modificada i

si l’usuari es root o no es root. En funció de cada valor d’estat si es troba la opció s’envia un e-

mail amb les característiques i missatges definits. Un cas especial es el de l’usuari Root, que

pot variar el flux natural d’una incidència en qualsevol moment, per tant perd pes el valor de

l’estat antic de la incidència modificada.

Per aclarir l’explicació, a continuació es mostra gràficament, de manera simplificada, en quins

canvis d’estat es notifica i en quins no.




5.2.2 Nou usuari root i limitacions en la edició d’incidències

La presencia d’una entitat amb poder per realitzar modificacions en qualsevol moment en una

incidència es un fet que em semblava important, més important si cal fer-ho de manera

controlada. I la manera de fer-ho controlat era proporcionant els mecanismes per programa i

no modificant els registres directament des de base de dades.

Per altre banda no em semblava coherent deixar modificar l’estat d’una incidència a un altre

estat per un usuari que no te res a veure amb el nou estat o amb el vell estat. Es a dir, durant

el procés de codificació i proves cada cop prenia mes força la idea de fer un sistema consistent

i coherent amb la informació que es manipulava.

Per exemple, no te sentit que un usuari tècnic pugui establir una incidència a l’estat pendent

d’àrea, si aquest no te poder de decisió sobre aquest fet. O que una incidència que s’ha

començat a tractar es pugui modificar per un client. O més important encara, que una

incidència tancada es pugui reobrir per error per un tècnic.

Controlar això amb tant detall no estava planificat com una tasca important en la planificació,

però considero que es una irresponsabilitat desenvolupar un sistema tant inestable. I encara

que a aquesta casuística s’han dedicat mes recursos dels esperats, sacrificant funcionalitats

com canvi d’idioma o modulació del fitxer functions.py per mancança de temps, s’ha

aconseguit una primera versió de producte força estable i coherent amb les dades.




6 Implantació i resultats

6.1 Entorns virtuals, desenvolupament i producció

6.1.1 Entorn virtual i posada en marxa del desenvolupament del projecte

En el meu primer contacte amb Python fent servir el visual studio 2013 amb les eines de

python instal·lades em vaig adonar que l’IDE instal·lava un entorn aïllat del sistema operatiu on

em podria instal·lar els components que necessites pel meu projecte. La decisió de fer servir

Git i Zurb Foundation en comptes de Bootsrap em va fer prendre la decisió deixar aquest IDE.

Però la idea de fer proves en diferents entorns i la recerca d’un entorn senzill per realitzar el

canvi de plataforma sense dificultats em va portar a instal·lar virtualenv. Aquesta eina permet

al programador cremar-se entorns independents de python. En el meu cas amb virtualenv em

vaig crear l’entorn python3.4 on amb l’ajuda de pip nomes em vaig instal·lar el Django versió

1.8 i el controlador per la base de dades PostgreSQL un cop descarregat de

http://initd.org/psycopg/

Per activar l’entorn virtual s’ha de cridar a l’script activate dintre de la carpeta scripts on s’ha

creat el directori de l’entorn virtual. Per exemple en el meu cas:

C:\WIG\venv\Scripts\activate

Un cop instal·lat Django es crea un projecte de la següent manera:

django-admin startproject wincigo

Analitzarem breument l’estructura creada dintre de la carpeta generada al crear el projecte:

__init__.py: Un arxiu per que Python tracti aquest directori com un paquet.

manage.py: Una utilitat de línea de comandes per interactuar amb el projecte de

Django.

settings.py: Configuracions pel projecte de Django.

urls.py: La declaració de les URL pel projecte de Django. Una taula de continguts del

lloc Django.

Un cop creat el projecte el següent pas es crear l’aplicació amb manage.py:

manage.py startapp app

Per desenvolupar el meu projecte i fer les proves executo el servidor de desenvolupament de

Django amb manage.py, situat dintre de la carpeta del projecte, de la següent manera:

manage.py runserver

http://initd.org/psycopg/




Des del moment que executo el meu servidor de desenvolupament puc comprovar que la

instal·lació s’ha realitzat amb normalitat quan puc accedir al meu lloc Django amb l’adreça que

m’indica l’execució del servidor 127.0.0.1:8000.

6.1.2 Entorn de producció

En aquet punt, cal comentar que a part dels canvis que s’hagin de fer en el fitxer de

configuracions settings.py, establint el mode DEBUG = False i els hosts permesos en

ALLOWED_HOSTS, es molt probable que la utilització dels fitxers estàtics, com són els fitxers

.css i .js o recursos media, no es publiquin de manera que l’aplicació mostri un aspecte i un

comportament molt diferent al que s’ha creat a l’entorn de desenvolupament.

Per solucionar aquest fet, els fitxers estàtics s’han de col·locar en una carpeta “publica” al

servidor mitjançant la comanda:

manage.py collectstatic

En el cas del hosting triat pel projecte WinciGo la manera de procedir es creant una aplicació

amb una carpeta static, definir aquesta ruta al fitxer settings.py i executar la comanda descrita.

6.1.3 Connectar i configurar la base de dades

Tant en entorn de desenvolupament, com en producció, un cop creat el projecte i la aplicació

principal del projecte WinciGo, s’han de realitzar les següents pases per connectar amb la base

de dades i sincronitzar-la amb l’aplicació.

Primer s’ha de crear la base de dades wincigodb al nostre sistema gestor de bases de dades.

Un cop configurats els paràmetres de connexió a la base de dades dintre del fitxer settings.py i

habilitat el mòdul d’autenticació a les INSTALLED_APPS d’aquest mateix fitxer, s’ha d’executar

la següent comanda:

manage.py syncdb

D’aquesta manera es sincronitzen la base de dades i l’aplicació. Durant el procés de

sincronització el sistema preguntarà si es vol crear un supersusuari per l’administració de

django, la resposta ha de ser si i el nom que posarem serà root, com es pot intuir aquest serà

el nostre usuari root de l’aplicació, i el password serà el que desitgi el client.

Una vegada sincronitzada la base de dades, necessitem guardar les migracions pels models en

un arxiu de control, per que Django pugui trobar-les al sincronitzar l’esquema de la base de

dades. Això es fa amb la comanda:




manage.py makemigrations

Després, cal carregar l’estructura del nostre model de l’aplicació principal app en la base de

dades, per tal que es creïn les taules necessàries pel correcte funcionament de l’aplicació.

manage.py migrate

Considero que només aquesta part que correspon a la instal·lació del producte es la part

tècnica de Django que s’ha d’explicar en aquest punt.

6.2 Estructura del projecte

L’estructura del projecte te dos parts diferenciades, una la carpeta del projecte principal, amb

l’estructura comentada en el apartat anterior, i una carpeta per l’aplicació principal del

projecte. A continuació es detalla com s’estructura l’aplicació principal amb ajuda d’una

captura de pantalla de l’entorn de desenvolupament:

La carpeta o paquet migrations per la migració de les

modificacions al model.

La carpeta static conté els fitxers static que es fan servir a les

plantilles. Fitxers css, fitxers javascript i fitxers .svg en el cas

del projecte WinciGo. S’han separat les els components de

tercers en diferents carpetes per tal de tindre localitzats els

fitxers amb les seves versions, pensant que es una bona

pràctica per afavorir el manteniment, encara que hi ha

programadors que es desmarquen d’això situant tots els

fitxers dintre d’una carpeta vendors que es situa dintre de la

carpeta static. Els fitxers estàtics propis es situen dintre de la

subcarpeta app.

La carpeta templates conté una subcarpeta amb totes les

plantilles que es fan servir a l’aplicació.

A l’arrel de la carpeta de l’aplicació principal es troben els

fitxers views.py, models.py, admin.py, forms.py,

functions.py i tests.py.

El fitxer views.py: Conté tota la lògica de l’aplicació.

El fitxer forms.py: Conté els formularis de l’aplicació amb les regles de validació.




El fitxer models.py: Conté el model de base de dades. Aquesta estructura es la que es copia a

la base de dades quan s’executen les comandes de migració comentades amb anterioritat.

El fitxer admin.py: Conté la informació dels camps que s’han decidit incorporar al sistema

d’administració de Django.

El fitxer functions.py: Conté funcions que es fan servir als fitxers views.py i forms.py i que

s’han separat per una millor comprensió del codi i un millor manteniment. Tot i que soc

conscient que en un futur s’ha de treballar en aquest aspecte.

6.3 Càrrega de dades inicials a la base de dades

WinciGo necessita un mínim de dades pre-carregades a la base de dades wincigodb pel seu

correcte funcionament.

Es necessari un usuari administrador ja que aquest no es podrà crear des de dintre de

l’aplicació i encara que l’usuari root el podria crear utilitzant l’aplicació d’administració de

Django, trobo una millor opció crear-lo d’aquesta manera. També son necessaris taules amb

els tipus d’incidències, els rols dels usuaris i els estats de les incidències, que han de tenir un

ordre i claus primàries determinades per la correcta sincronització amb les constants definides

a l’aplicació.

Abans de fer servir l’aplicació cal executar el següent codi SQL:

-- Creació de l’àrea local pels usuaris administratius i administrador

INSERT INTO app_area (id, name, description) VALUES (1, 'Local', 'Area de administracion');

--Creació del scanals d’entrada

INSERT INTO app_channel (id, channel) VALUES (1, 'Web');

INSERT INTO app_channel (id, channel) VALUES (2, 'Telefono');

--Creació d’estats

INSERT INTO app_issuestateenum (id, state) VALUES (1, 'Área Asignada');

INSERT INTO app_issuestateenum (id, state) VALUES (2, 'Técnico asignado');

INSERT INTO app_issuestateenum (id, state) VALUES (3, 'En ejecución');

INSERT INTO app_issuestateenum (id, state) VALUES (4, 'Pendiente terceros');




INSERT INTO app_issuestateenum (id, state) VALUES (5, 'Pendiente cliente');

INSERT INTO app_issuestateenum (id, state) VALUES (6, 'Pendiente verificar');

INSERT INTO app_issuestateenum (id, state) VALUES (7, 'Pendiente area');

INSERT INTO app_issuestateenum (id, state) VALUES (8, 'Finalizado');

INSERT INTO app_issuestateenum (id, state) VALUES (9, 'Desestimado');

--Creació de tipus d’incidencia

INSERT INTO app_issuetypeenum (id, "issueType") VALUES (1, 'Incidencia');

INSERT INTO app_issuetypeenum (id, "issueType") VALUES (2, 'Consulta');

INSERT INTO app_issuetypeenum (id, "issueType") VALUES (3, 'Formacion');

--Creació de rols

INSERT INTO app_role (id, name) VALUES (1, 'Cliente');

INSERT INTO app_role (id, name) VALUES (2, 'Administrativo');

INSERT INTO app_role (id, name) VALUES (3, 'Tecnico');

INSERT INTO app_role (id, name) VALUES (4, 'Encargado');

INSERT INTO app_role (id, name) VALUES (5, 'Administrador');

--Creació de l’suari administrador (admin)

INSERT INTO app_staff (user_ptr_id, email_for_ads, role_id, user_area_id_id) VALUES (2,

'[email protected]', 5, 1);

INSERT INTO auth_user (id, password, last_login, is_superuser, username, first_name, last_name, email,

is_staff, is_active, date_joined) VALUES (2,

'pbkdf2_sha256$20000$g7zTuMoKHevm$pF8AL3pRARirLVez3chngSDrWrswYmzjLErwj46TpPg=', '2015-

06-06 08:45:59.63506+02', false, 'admin', 'Administrador', '', '', false, true, '2015-06-06 08:34:50+02');




6.4 Captures de pantalla mes significatives

6.4.1 Panel principal, en aquest cas el d’administrador:

En el panel principal es pot veure un canvi significatiu respecte a la distribució dels panels de

les gràfiques de representació de dades. Aquest canvi ha estat motivat per millorar la

visualització de les dades a la taula, ja que la posició inicial d’aquesta taula dificultava la lectura

d’aquells registres que contenen cadenes de text molt llargues.

La mateixa pantalla amb les mides d’ smatphone




6.4.2 Pantalla de llistat d’incidències.

El canvi mes important referent al prototip es la desaparició de la zona de filtre a sobre de les

capçaleres, ara es situen sota de cada capçalera de columna i l’aparició d’un paginador. Aquest

canvi s’ha fet aprofitant les possibilitats de personalització del component de Datatables.net i

la personalització que s’ha fet amb codificació javascript per millorar l’experiència de l’usuari.

Totes les taules de l’aplicació presenten les mateixes funcions i es poden ordenar descendent o

ascendent per qualsevol columna si es clicka en la seva capçalera. Tots els objectes

modificables dintre de l’aplicació es presenten en una taula per triar l’objecte que es vol

modificar, cada objecte el representa una fila.




6.4.3 Pantalla de creació d’incidència.

La creació d’àrea va lligada a la creació d’un encarregat, per tant el formulari de creació d’àrea

validarà dos formularis en la mateixa plantilla.




7 Conclusions i futur de WinciGo

Partint de la base del meu desconeixement total de la programació web i dels llenguatges de

programació i tecnologies emprades la meva avaluació de la experiència en global es positiva.

Estaria enganyant al lector si no digués que per moments m’he trobat perdut i m’ha costat

molt fer l’exercici d’abstracció i començar a pensar de manera diferent a com ho faig

normalment quan programo per entorn escriptori.

La corba d’aprenentatge de Django es molt elevada i tenint en compte la duració del projecte

he acabat amb la sensació de que he aprés conceptes importants i maneres millors o diferents

de resoldre situacions quan s’apropava el final del projecte. Però el petit sentiment de

frustració es veu recompensat amb l’experiència molt positiva d’aprendre un llenguatge del

que sempre he volgut conèixer, com es Python i el coneixement de tecnologies com JQuery i

Ajax del que segurament trec profit a la meva carrera professional.

El treball de recerca i documentació per recolzar la presa de decisions justificada durant el

quadrimestre es una de les facetes mes importants segons el meu criteri i la manera

estructurada de treballar em fa valorar molt més el que representa l’Enginyeria de Programari.

En quant al futur de WinciGo. Lògicament es una versió molt novell i que està per madurar en

molts aspectes, però continuaré la seva evolució no pública per continuar aprenent i arreglar

tot el que considero que per falta de temps no he pogut fer, com es:

Realització de multi idioma.(I18N)

Ajax en les peticions que triguin temps per mostrar un “Loading”

Aprofitar la potencia de Django. (Memòria cau, ...)

D’altre banda m’agradaria introduir noves funcionalitats d’administració fins aconseguir poder

fer tota l’administració sense necessitat de fer servir el menú d’administració de Django.

Des del començament WinciGo no ha sigut un producte per estar en una adreça pública, de

moment es troba a www.wincigo.com, però es un producte pensat per la gestió d’incidències a

l’entorn empresarial i amb una implantació que potser requereix algun tipus de personalització

i seguiré treballant en aquesta línea.

http://www.wincigo.com/




8 Bibliografia

8.1 Llibres consultats:

Curso Django para perfeccionistas deadlines. Un projecte de Maestros del web.

http://www.maestrosdelweb.com/guias/#guias-django

El libro de Django, traducció de The Definitive Guide to Django: Web Development

Done Right. Editorial Apress.

La guía definitiva de Django: Desarrolla aplicaciones web de forma rápida y sencilla.

De Django software corporation, autor Saul García M.

8.2 Recursos consultats online:

http://stackoverflow.com: Citant la seva pròpia definició “Es un lloc de preguntes i

respostes per als programadors professionals i entusiastes. Es 100% lliure, sense

necessitat de registre.

https://docs.djangoproject.com/en/1.8/: Site oficial de django on es pot trobar tota la

seva documentació i exemples de configuració i codificació.

http://grokbase.com/s/django: un arxiu de mailing list que facilita descobriment de les

discussions d’usuaris dintre de grups. En concret s’ha llegit informació dintre del grup

django.

http://librosweb.es/libros/: Lloc de referència sobre disseny i programació web des de

2006. Publiquen llibres, tutorials, vídeos y presentacions y altres recursos per

dissenyadors i programadors.

http://www.codecademy.com: Codecademy és una plataforma interactiva en línea

que ofreixe classes gratuïtes de codificació en llenguatges de programació com Python,

PHP, JavaScript, y Ruby, així como llenguatges de marcat incloent HTML i CSS.

http://foundation.zurb.com/docs/: Lloc on es pot trobar tota la documentació referent

al framework CSS Zurb Foundation.

http://www.chartjs.org: Lloc on es pot descarregar i consultar documentació i

exemples dels components de representació gràfica.

http://datatables.net: Lloc o es pot descarregar i trobar informació i exemples de les

taules de representació de dades.

https://www.webfaction.com: Hosting que s’ha fet servir per la instal·lació del

projecte.

S’han consultat molts més recursos online dels que no s’ha guardat el link, però no voldria

finalitzar la memòria sense agrair totes les aportacions que la comunitat de programadors

fan desinteressament.

http://www.maestrosdelweb.com/guias/#guias-django

http://stackoverflow.com/

https://docs.djangoproject.com/en/1.8/

http://grokbase.com/s/django

http://librosweb.es/libros/

http://www.codecademy.com/

http://foundation.zurb.com/docs/

http://www.chartjs.org/

http://datatables.net/

https://www.webfaction.com/




9 ANNEX – Dades per la realització de proves

L’aplicació web es troba allotjada en un hosting web i per accedir a l’aplicació s’ha d’accedir a

la següent url: www.wincigo.com

Per la realització de proves s’han donat d’alta els següents usuaris amb els seus passwords:

Usuaris clients:

Usuari Password Nom y Cognom Empresa

cliente1a sadaba Maite Márquez Empresa A

cliente2a sadaba Alonso Alfonso Empresa A

cliente1b sadaba Fernando Royo Empresa B

cliente2b sadaba Mercedes López Empresa B

Usuaris membre de la plantilla separats per rols:

Usuari Password Nom y Cognom Area

root sadaba1234

admin sadaba12

secretario1 sadaba Gema Romero

encargado_h sadaba Claudia Márquez Hardware

encargado_s sadaba Laura Rodríguez Software

tecnico1s sadaba Marcos Lora Software

tecnico2s sadaba Rafa Gracia Software

tecnico1h sadaba Albert Canales Hardware

tecnico2h sadaba David Llovera Hardware

El codi font està preparat per que cada usuari tingui una adreça de correu diferent, però

aquesta validació ha estat comentada en el codi font per facilitar les proves. Així tots els

usuaris han de tindre la mateixa adreça de correu [email protected]. Si es vol crear establir

una altra adreça al modificar o crear un usuari ha de ser una adreça valida si es vol veure el

resultat de les notificacions.

AVIS: No s’ha implementat el sistema per esborrar objectes, si s’esborra una empresa, àrea o

usuari des del menú d’administració de Django el sistema pot tornar-se inestable en quant a

integració de les dades. Hi ha objectes que no estan lligats per la seva clau primària i la relació

s’ha fet controlada pel codi, així no es produiran avisos d’esborrar en cascada si s’intenta

esborrar des del gestor de bases de dades.

http://www.wincigo.com/

mailto:[email protected]

uoc. tfc. aplicacions web per treball...

Documents