App/Web responsive pel control d'accessos

(1)

App/Web responsive pel control d’accessos

Ana López Velasco

Resum— Aplicació/web responsive que permet als usuaris fer la reserva de sales i de material mostrant la disponibilitat diària i horària oferint a l'usuari les possibilitats restants. El procés de reserva de sales també permet indicar la quantitat de persones per les que es realitza la reserva dependent de l'aforament disponible a més d'oferir la possibilitat de, en el mateix procés fer la reserva de material. Això mateix també es podrà fer en un procés a part, ja que pot ser que hi hagi material que no estigui associat a cap sala. Per la part de l'administrador, ell podrà fer tota la gestió de les sales a més de poder extreure estadístiques dels moviments que s'hagin fet. El projecte, que s’ha implementat utilitzant el desenvolupament iteratiu incremental, consta d’un estudi de mercat previ on es va poder conèixer la competència i es va adaptar el producte basant-se en les conclusions extretes. L’eina, per tant, és simple, intuïtiva i portable per poder ser utilitzada per qualsevol usuari sigui experimentat o no, des de qualsevol dispositiu sent perfectament aplicable a qualsevol institució.

Paraules clau— App, material, sales, control, gestió, reserva, calendari, aforament.

Resumen— Aplicación/web responsive que permite a los usuarios hacer la reserva de salas i de materiales mostrando la disponibilidad diaria i horaria ofreciendo al usuario las posibilidades restantes. El proceso de reserva de salas también permitirá indicar la cantidad de personas para las que se realiza la reserva dependiendo del aforo disponible. Además se ofrece la posibilidad de, en el mismo proceso hacer la reserva de material. Esto mismo también se puede hacer en un proceso a parte, ya que puede ser que haya material que no esté asociado a ninguna sala. Por la parte del administrador él podrá hacer toda la gestión de las salas además de poder extraer estadísticas de los movimientos que se hayan hecho. El proyecto, que se ha implementado utilizando el desarrollo iterativo incremental, consta de un estudio de mercado previo donde se pudo conocer a la competencia y se adaptó el producto en base a conclusiones extraídas. La herramienta, por tanto, es simple, intuitiva y portable para poder ser utilizada por cualquier usuario sea experimentado o no, desde cualquier dispositivo y siendo perfectamente aplicable a cualquier institución.

Palabras clave— App, material, salas, control, gestión, reserva, calendario, aforo.

Abstract— A responsive application that allows users to make reservations of rooms and materials, which show the user daily and hourly availability to offer the remaining possibilities. The rooms reservation process also allows to indicate the amount of people to whom the reservation is made based on the capacity available, as well as to offer the possibility, in the same process, to reserve material. The same can be done in a different process, since there may be material that is not associated with any room. On the administrator part, he will be able to do all the management of the rooms, as well as to extract the movements statistics that have been made. The project, which has been implemented using incremental iterative development, consists of a previous market study where the competition could be known and the product was adapted based on conclusions drawn. The tool, therefore, is simple, intuitive and portable to be used by any user whether experienced or not, from any device and being perfectly applicable to any institution.

Index Terms— App, material, rooms, control, management, reservation, calendar, capacity.

——————————  ——————————

1 I

NTRODUCCIÓ

a realització d’una app/web responsive de control d’accessos es basa en la idea de poder generar una eina que permeti als usuaris fer reserves de sales i materi-als d'una forma còmoda. Gràcies a aquesta eina es podri-en substituir alguns dels mètodes actuals que hi ha a institucions públiques o a empreses petites que funcionen amb formularis de Google o de forma manual.

Actualment, les eines que hi ha al mercat estan més enca-rades a sistemes de hardware que permeten l'entrada dels usuaris i no tant a una correcta gestió i administració de les reserves en si. Per tant, es va decidir enfocar l'eina

amb l'objectiu de cobrir aquesta necessitat que permetrà extreure conclusions de les reserves que es realitzin. En les properes pàgines, s’explicarà amb més detall en què consisteix el seu desenvolupament i es tractaran els objectius que s’han volgut assolir en la realització del projecte. Per tal de poder marcar-los, s’ha fet una anàlisis del mercat actual que permetrà saber quines eines simi-lars hi ha a la competència. Fent aquest estudi s’han po-gut prendre decisions importants en els objectius que faran que l’eina sigui atractiva i distintiva pels consumi-dors.

S'exposarà la metodologia escollida i si aquesta, un cop posada en pràctica, ha donat bons resultats o bé ha neces-sitat modificacions o canvis.

També s'inclou un apartat on veure els recursos que s'han necessitat juntament amb els costos i els terminis

L

————————————————

 E-mail de contacte: [email protected]

 Menció realitzada: Enginyeria del Software

 Treball tutoritzat per: Marc Talló (Ciències de la computació)

 Curs 2018/19

(2)

establerts pel projecte.

Finalment, es mostrarà com s’ha plantejat el projecte i els resultats obtinguts que permetran verificar si s’han complert les metes establertes i com ha quedat el projecte. A partir d'aquests resultats es podran extraure conclusi-ons tant del procés seguit com del seu estat final.

2 O

BJECTIUS

Un objectiu és un resultat o una meta desitjada que s'espera aconseguir en la creació del projecte. En aquest cas s'han plantejat una sèrie d'objectius que es consideren que faran l'experiència de l'usuari el més completa possi-ble.

A causa de l'anàlisi constant, a mesura que es va anar avançant en el desenvolupament, es van afegir alguns més i d'altres es van modificar. Això és degut, per un costat, al fet que no van quedar ben reflectits des del principi i, per l'altre, a requeriments que, més tard, es van considerar importants.

Els objectius que es van modificar són els que es troben en negreta; només van afectar a la meta i no a la prioritat. Els afegits són el 14 i el 15, ambos referents a la gestió dels dies i hores.

Finalment, la taula d'objectius queda conformada de la següent manera:

TAULA 1

OBJECTIUS DEL PROJECTE AMB LES SEVES PRIORITATS

N. Objectiu Prioritat

1 Fer el disseny web de forma responsi-ve i intuïtiva tant per la part dels usua-ris com per la de l'administrador.

Molt alta

2 Crear la base de dades considerant que hi haurà un usuari estàndard, un usuari amb privilegis i un adminis-trador.

Molt alta

3 L'administrador ha de poder donar d'alta, els usuaris, les sales, els mate-rials i les categories d'una forma simple.

Alta

4 Poder fer la reserva de sales (procés base).

Alta 5 Poder reservar materials

indepen-dentment de la sala.

Alta 6 Els usuaris han de poder gestionar la

seva compta en quant a configuració.

Mitja 7 L'administrador ha de poder

gestio-nar les reserves, els usuaris i els ob-jectes a reservar.

Mitja

8 Els usuaris han de poder gestionar les seves reserves.

Mitja

9 Fer que el calendari de reserva sigui més visual amb l'ajuda d'alguna API.

Mitja 10 Poder fer reserves periòdiques. Mitja

11 Generar la versió app. Mitja

12 Crear notificacions i, si ho facilita, sincronitzar-ho amb alguna eina com Google.

Mitja

13 Fer que un usuari amb privilegis pugui cancel·lar qualsevol reserva.

Baixa 14 S'han de poder modificar les franges

horàries de reserva de cada sala.

Baixa 15 S'ha de poder indicar els dies festius

o exempts de reserva.

Baixa 16 Poder reservar materials associats a

una sala en el mateix procés de reser-va de la sala.

Baixa

17 Afegir funcionalitats a la reserva de les sales com ara posició a la sala o cost.

Baixa

18 En el procés de reserva poder convi-dar a altres usuaris i que aquests puguin acceptar la invitació.

Baixa

19 L'administrador ha de poder extreure estadístiques.

Baixa

Segons la TAULA 1, que acabem de veure, es genera un diagrama de casos d'ús que podem veure a la pàgina següent (Il·lustració 1); un mètode que ens permet especi-ficar més gràficament el comportament del sistema mit-jançant la interacció dels usuaris.

Aquest diagrama inclou totes les accions que podrà re-alitzar cadascun dels usuaris. A part de les modificacions que van en relació a la taula d’objectius, es va eliminar l’opció d’editar la imatge de perfil, ja que es va considerar que pel tipus d’eina no és una característica necessària.

3 E

STAT DE L

’

ART

Actualment ja hi ha sistemes que permeten gestionar la reserva d'espais, alguns d'ells permeten fins i tot gestio-nar el càtering i els recursos audiovisuals a utilitzar du-rant una reunió. D'altres, informen els seus usuaris de les reserves realitzant una sincronització amb Outlook o Google, enviant SMS o enviant correus. Com es pot donar el cas que hi hagi reunions o esdeveniments que es realit-zin de forma recurrent es contempla la possibilitat de la realització de la reserva de forma periòdica.

També és interessant, sobretot de cara a oficines o a executius, la funcionalitat que ofereixen alguns softwares de poder convidar a més usuaris a una reserva, sigui una presencial o de tipus conferència. En aquestes últimes, fins i tot, es contempla que aquesta altra persona pot estar

(3)

a l'altre punta del món.

N'hi ha que combinen Outlook i terminals tàctils per-metent als usuaris que, si una reunió finalitza abans de l’hora final prevista, aquesta es pugui comunicar perquè passi a estar disponible i poder ser reservada de nou. Gràcies a aquests terminals s'augmenta la seguretat de la sala i dels materials que conté, ja que només podran acce-dir les persones amb les credencials correctes. En aquesta mateixa línia, hi ha eines que tenen una detecció automà-tica de l'ocupació per tant d'alliberar una sala si detecta que ningú ha acudit a fer ús d'aquesta.

El hardware és molt ofert per altres empreses, oferint la col·locació de pantalles a les entrades de les sales on poder consultar la seva disponibilitat i, si es vol, poder fer des d’allà mateix la reserva. Gràcies a aquests tipus de pantalles que també es col·loquen a dins de les sales, és possible fer altres gestions com controlar l'aire condicio-nat o obrir una incidència. Altres obvien les pantalles i es centren en els lectors d'empremta de cara a millorar la seguretat de l'accés.

Les últimes opcions, on s'inclouen elements externs, tot i que podrien semblar les més completes, estan més enfo-cades en la part de seguretat i deixen de costat altres ges-tions com la reserva de materials o la periodicitat. En canvi, es centren més en els informes que pot extreure l'administrador.

En definitiva, el que tenen en comú la majoria d'aques-tes eines és que permeten fer la gestió des de qualsevol dispositiu incloent sistemes iOS, a més que es pot fer la gestió en pocs clics i de forma molt visual gràcies a grae-lles o calendaris i a l'ajuda de múltiples filtres.

Per una altra banda, he trobat empreses o organitzaci-ons que en comptes de tenir un sistema especialitzat uti-litzen els formularis de Google o formularis propis per enviar les peticions de reserva. Fins i tot m'he trobat grans empreses que fan la gestió de forma manual.

Existeixen empreses amb eines que es dediquen a re-servar espais per coworking i, per tant, aquesta reserva implica un cost sigui setmanal o mensual. D'igual mane-ra, aquests tipus de serveis impliquen funcionalitats per poder crear esdeveniments i poder vendre entrades, un sistema de CRM per fer un seguiment dels clients, etc. doncs està més enfocat de cara a vendre un servei i seria un ús diferent de les altres eines anteriors.

En canvi, el que més m'ha costat trobar són eines que venguin la part de l'administració com podria ser la fun-cionalitat de poder fer estadístiques segons les reserves o les més bàsiques com ara poder fer reserves autogestio-nades. Alhora, tot i que n'hi ha que ofereixen reserva de materials, càtering o recursos, no he vist cap que permeti

fer aquesta reserva més enfocada als materials que pot contenir la sala. Tampoc hi ha que ofereixin l'opció de fer-ho tant en el procés de reserva de la sala com fora d'a-quest. Per normal, les eines trobades eren molt tancades i amb funcionalitats molt marcades.

D’acord amb tots els softwares trobats, he vist una mancança en el que seria la gestió de sales des de la part administrativa. Per exemple, podem veure com bibliote-ques o universitats o bé, directament no tenen reserva de sales informatitzada per falta de facilitats, o bé, en el sis-tema que tenen sempre hi ha terceres persones que han de confirmant aquestes gestions. Un cas molt proper seria el del meu lloc de treball, on és la recepcionista qui s'en-carrega de rebre les peticions de reserves, sigui de forma oral o per correu, i de confirmar-les posteriorment.

Observem que podem trobar una eina que s'apropi a cobrir totes les nostres necessitats però que no conté una de les qualitats que considerem primordials sinó que aquesta la trobem en una altra. És a dir, cap d'aquests softwares és complet i sempre acaben faltant petites co-moditats o necessitats que has d'acabar complementant de forma alternativa. En canvi, s'ofereixen eines que van acompanyades d'un hardware específic que fa que la instal·lació sigui més costosa i que, a més, conté menys funcionalitats fent que els clients es facin enrere i optin per buscar una altra solució.

Per tant, la idea és desenvolupar una eina que integri tot aquest ventall de possibilitats de gestió de sales, de materials i altres configuracions que la facin el més com-plet possible i que pugui estar a l'abast de qualsevol em-presa evitant l'ús de hardware. Es farà accessible des de qualsevol dispositiu per tal d'estar a l'altura de la resta de la competència. A la pàgina següent es pot veure una taula comparativa de les funcionalitats de les eines exis-tents.

4 METODOLOGIA

4.1 Metodologia escollida

La metodologia escollida ha estat el desenvolupament iteratiu i creixent que permet desenvolupar l'eina de forma incremental creant versions funcionals en cada iteració.

Aquest mètode el que fa és retroalimentar el procés iniciant en una implementació simple i iterant agregant funcionalitats/requeriments fins a completar tots els re-queriments del sistema. És a dir, divideix el projecte en blocs que va completant i incrementant en cada iteració proporcionant en cadascuna d'aquestes una versió funci-onal del sistema però incompleta.

(4)

TAULA 2

COMPARATIVA DE ELS FUNCIONALITATS DE LES EINES EXISTENTS

El procés que es realitza en aquesta metodologia co-mençar per determinar els requeriments centrals del sis-tema a partir dels quals es pugui començar a retroalimen-tar l'eina. Alhora s'estableixen quins seran els increments i s'assignen a cada iteració contemplant les prioritats de cada requisit en funció del valor que aporta al client. Es fa la definició en detall de cada iteració tenint en compte que cadascuna haurà de superar l'anterior.

A continuació, passaríem a realitzar les iteracions on faríem el desenvolupament de l'increment, les proves, la documentació i la integració del desenvolupament que s'acaba de realitzar amb la versió ja existent.

Es valida el sistema en cada iteració, ja que es genera un lliurament funcional que permet als clients posar-lo en funcionament i experimentar amb l'eina. Fet que permet que clients que no tenen clars els requisits puguin acabar de definir-los. Un cop s'han realitzat totes les iteracions, es valida el sistema resultant i es realitza l'entrega final.

Aquesta metodologia té beneficis que analitzarem per a aquest projecte en concret. El principal benefici és que, des d’un principi, tenim una versió funcional que el client pot començar a utilitzar i que es va actualitzant amb noves funcionalitat a mesura que avança l'estat del projecte.

Això també ens permet saber si anem ben encaminats i de no ser així poder redirigir el projecte. A més, per la forma en la qual es vol realitzar el sistema on es podrien contemplar els requisits com a mòduls independents, és molt interessant el concepte de poder tenir cadascun d'ells desenvolupats, documentats i testejats. D'igual manera, com els tracta de forma independent es facilita la gestió de canvis que puguin sortir en el procés. També es pot veure l'estat del projecte i si serà possible finalitzar-ho en la data prevista permetent l'opció de reajustar el

Eina Accessibilitat Sincronització Recordatoris Administradors HW

inclòs Extres Condeco Qualsevol

dis-positiu

MS Outlook Correu

elec-trònic i notifi-cacions

No Registre de visitants i reco-manació de sala. Reserva de càtering i audiovisuals. PlanningPME Qualsevol

dis-positiu

No Periodicitat

Richo Correu

elec-trònic

Gestió de reserves en espera.

No Gestió de serveis associats a la reserva i de visitants.

Bodet Ordinador o

tableta situada a les sales.

Outlook i Kelio Notificació per Outlook

Si Permet alliberar una sala si detecta una sortida abans de l'hora. RoomWizard Ordinador o panells Microsoft® Outlo-ok® y Office 265, IBM® Notes®, Google Calendar® Els propis de les eines inte-grades. Mesura la utilització i genera informes de patrons de reserva. Si RoomMana-ger Adaptable a qualsevol panta-lla Google Works, Microsoft Exchange i Lotus Notes Els propis de les eines inte-grades.

No

AMX Panells Microsoft Exchange,

Office 365 y Google Calendar

Els propis de les eines inte-grades.

Mitjançant RMS es poden tenir informes d'ús.

Si Detecció d'ocupació, sugge-riment de sales, allargar l'horari, informar d'incidèn-cia i sol·licitar càtering.

Simplybook Qualsevol dis-positiu

Correu elec-trònic i sms.

No Les reserves tenen un cost i es pot pagar en línia.

(5)

projecte.

4.2 La seva aplicació

No hi ha hagut gaires problemes a l'hora d'aplicar la metodologia escollida més enllà de la mateixa inexperièn-cia. De forma ideal realitzaríem cada iteració i no modifi-caríem cap anterior, però s'ha de tenir en compte que hi han hagut modificacions del client durant el procés, fet que ha provocat modificacions en iteracions posteriors. Aquest és un fet completament comú i, en certa manera, inevitable.

Tot i això, sí que hi va haver petits errors en el plante-jament que va provocar la modificació d'iteracions passa-des; es podrien haver evitat si aquest s'hagués fet més exhaustivament.

El projecte es va dividir en la planificació, 6 iteracions i l'entrega final. La planificació va incloure una investigació de mercat per poder adaptar l'eina a la competència, el recull de requisits i la planificació de les tasques. Aquesta part es va desenvolupar sense cap problema, tot i que crec que manca dedicar temps en aquesta fase a dissenyar el format de les pantalles perquè quedin totes integrades des del principi.

A la primera iteració es va fer tota la part visual de la web, que va consistir a escollir una plantilla de Boostrap i adaptar-la al format MVC. També es va crear la base de dades i les funcionalitats d'alta i baixes d'usuaris per a l'administrador. La base de dades, s'hauria d'haver fet més amplia pensant en les pròximes implementacions per tal de no dedicar temps extra més endavant.

A la segona iteració, es van crear les pantalles de re-serva de sales i la de materials i es va fer la gestió de la configuració dels usuaris. Tot i que no estava previst, també es va fer la pantalla de consulta de les reserves dels usuaris. En aquest punt van haver-hi modificacions per afegir tasques que no estaven contemplades a la planifi-cació: modificar l'horari de les reserves i poder gestionar la categoria de les sales. També es va eliminar de la itera-ció 3 la consulta de reserves dels usuaris per haver-se realitzat abans i es va afegir la gestió de les reserves.

Amb tots aquests canvis la iteració 3 va incloure per un costat, l'informe de progrés (I), la possibilitat de l'admi-nistrador de modificar un usuari, la de l'usuari d'eliminar reserves i la gestió de les reserves i de les categories de l'administrador.

Es va arribar a la quarta iteració sense cap altre com-plicació, i aquí es va fer la implementació de reserves periòdiques, d'un calendari visual i la possibilitat de re-serva materials alhora que es reserven sales.

A la cinquena iteració es va generar una versió An-droid de l'eina i es van generar els correus que notifiquen

als usuaris de les reserves que acaben de realit-zar/eliminar i de les reserves que tenen l'endemà. També es va crear un usuari amb privilegis que té capacitat per cancel·lar reserves d'altres usuaris i la possibilitat de l'administrador d'establir franges horàries i dies restrin-gits.

A la sisena i última iteració es va realitzar l'informe de progrés (II), es van afegir funcionalitats, es va implemen-tar la possibilitat d'afegir usuaris a la reserva i es van crear les estadístiques de l'administrador.

Finalment ara ens trobaríem a la part final de la meto-dologia que consisteix a fer els retocs finals, la proposta de l'informe i l'entrega de l'eina al client.

5 G

ESTIÓ DEL PROJECTE

5.1 Terminis

Tot i que hi ha hagut imprevistos durant el projecte, ha estat possible complir el termini final amb totes les funci-onalitats esperades pel sistema.

Per contra, els terminis que hi ha hagut entremig no s’han pogut complir en la seva totalitat. Això es deu a que hi van haver tasques que es van subestimar i van trigar una mica més en completar-se i alhora que hi van haver a anomalies a causa de moure, afegir o modificar tasques.

Encara que hi han hagut alguns terminis que no s’han complert en la data establerta, si se que s’ha complert la data final d’entrega del projecte.

Per tant, considero positiva la planificació dels termi-nis en relació a les tasques tenint en compte que hi han hagut modificacions demandades pel client que han pro-vocat adaptacions en la programació.

5.2 Recursos

En un principi es va estimar que es necessitarien els se-güents recursos:

 Recursos humans: una persona.

 Recursos físics: un ordinador i un smartphone

 Eines: PhpStorm, phpMyAdmin i Xampp.

 Eines de consulta: principalment documentació web que es podrà trobar a l'apartat de bibliogra-fia.

A mesura que es va anar avançant el projecte, va ser necessari afegir més recursos dels que s’havien pensat. El primer va ser la plantilla de Boostrap, que no es va consi-derar en el llistat, juntament amb les llibreries fullCalen-dar i Chart.

També es va afegir l’eina d’Android Studio i, final-ment, per generar l’enviament automàtic, va ser necessari el Visual Studio.

Tots els recursos mencionats es van poder utilitzar de forma gratuïta així que no van incrementar el cost del

(6)

projecte. 5.3 Cost

Avaluarem els costos que s'han generat des de l'inici fins al final del projecte, contemplant per cada iteració les hores que s'han invertit i el cost total que això suposa pel client.

Els costos que es veuen a continuació engloben tots els factors que es poden veure involucrats des de l’inici fins al final del projecte; el primer valor fa referència a les hores reals realitzades i el segon al planificat . S’ha consi-derat un únic valor de cost perquè només hi ha una per-sona desenvolupant el sistema, tot i això, aquesta perper-sona fa tasques de desenvolupament, de disseny, de test...

 Plantejament inicial : 42h/64h

o Deliberacions per la captació de requisits

 Temps: 20h/36h

o Creació del document del plantejament inici-al

 Temps: 10h/12h

o Modificacions del document de l’anàlisi del problema

 Temps: 5h/5h o Planificació de les tasques:

 Temps: 7h/11h

 Iteració 1: 32h/48h

o Anàlisis dels requisits: 3h/8h o Implementació: 25h/33h o Proba: 2h/5h

o Avaluació: 2h/2h

o Informe de progrés (I): 18h/28h

o Avaluació: 2h/2h

o Avaluació: 3h/3h

o Anàlisis dels requisits: 4h/7h o Implementació: 28h/38h

o Proba: 5h/5h o Avaluació: 2h/2h

o Informe de progrés (II): 15h/28h

 Entrega final: 71h/104h

o Proposta informe final: 21h/28h o Retard/extres: 50h/76h

 Temps dedicat: 384h/444h

 Cost per al client: 30 x 384h = 11520€/13320€

 Realitzada la totalitat del projecte 5.4 Riscos o imprevistos

En la planificació s'ha tingut en compte que si hi ha exàmens o dies prevists en els que no es podrà fer la tasca indicada, aquesta s'allarga i s'augmenta la duració. Igualment, aquestes planificacions no són perfectes doncs sempre hi ha certs riscos que poden succeir en un projecte a part de la mateixa inexperiència tecnològica en el seu desenvolupament.

Alguns dels riscos que poden succeir i endarrerir el desenvolupament i que són impossibles de predir podri-en ser, des dels més greus com ara operacions, malalties o problemes climàtics fins a les dificultats trobades durant una tasca del projecte.

D'altres, podrien ser els errors o la carència d'algun ti-pus de recurs requerit en el projecte o bé la realització d'una mala planificació; això podria desembocar en el fracàs de la data d'entrega.

Alhora, pel que fa a la planificació, també s'ha de con-templar la possibilitat que hi hagi canvis en les prioritats causades, per exemple, per un canvi en el mercat.

Una vegada iniciat el projecte, va haver-hi una sèrie de riscos que es van complir, com ara l’operació que, acom-panyada de sessions de rehabilitació va restar temps dis-ponible. No hi va haver cap mena de carència en els re-cursos que impedís el correcte funcionament de la planifi-cació, però sí que van haver algunes dificultats trobades durant el projecte i modificacions en els requisits que van fer modificar lleugerament la programació de les tasques. 5.5 Lliurables

El desenvolupament iteratiu i incremental implica que per cada iteració hi haurà una versió estable per entregar al client, de forma que per tot el projecte s’han generat un total de 6 lliurables.

A part dels mateixos lliurables de la metodologia, te-nim també l'entrega dels informes que han quedat encai-xats en les iteracions.

Per últim, tenim l'entrega final que coincideix tant en la distribució de la versió definitiva cap al client, com amb el dossier.

(7)

5.6 Relació entre l’estimació i la realitat

A l'inici del projecte es va fer una estimació de costos on es contemplaven el temps que es necessitaria per com-pletar el projecte i el cost que implicaria pel client.

Aquesta estimació va ser de 444h de temps dedicat a desenvolupar el projecte en la seva totalitat i 13320€ de cost pel client.

Un cop desenvolupat ens trobem que les hores que s'han necessitat han estat 384 i que el cost ha arribat fins 11520€. Es pot comprovar que hi ha hagut una reducció en les hores necessitades que ha implicat una disminució del cost que es va calcular.

Si ens aturem a analitzar-ho, podem veure que les fa-ses on menys recursos temporals s'han necessitat és a la fase del plantejament inicial i a la de l'entrega final. En el primer cas, la tasca que té una major diferencia sobre l'estimació és la deliberació per la captació de requisits. En el segon cas, s'ha reduït a la tasca de la implementació d’extres o de tasques endarrerides.

Les hores que no s'han invertit en aquestes tasques, per tal de poder millorar el projecte, es podrien haver invertit, per un costat, al plantejament inicial del disseny visual i de la base de dades i per l'altre a fer millores (o extres) a la implementació.

6. A

NÀLISIS

S'ha considerat que hi ha 3 tipus d'usuaris: usuari co-mú, usuari amb privilegis i administrador. Al diagrama que es troba en aquesta mateixa pàgina es pot veure cla-rament la funcionalitat de cadascun d'ells.

Un usuari comú, podrà realitzar reserves de sales i de materials, consultar el seu historial de reserves, modificar les dades del seu perfil i veure el seu calendari de reser-ves.

Dins de les finestres de reserves de sales i de materials l'usuari podrà veure un calendari ajustat de reserves per poder ajustar millor la seva. En el procés es pot seleccio-nar si es desitja periodicitat o si es farà una reserva pun-tual. Les opcions de periodicitat són:

 Cada dia: en el rang establert farà la reserva cada dia.

 Cada setmana: en el rang que s'hagi seleccionat es farà la reserva en el mateix dia de la setmana de la data inicial.

 Cada mes mantenint el dia: en el rang que s'in-diqui es farà una reserva mensual reservant ela mateix dia de la data inicial.

Totes les reserves les faran considerant si el dia està restringit, si ja hi ha una reserva o si es cap de setmana.

D'igual manera, a la reserva mensual comprovarà si el dia existeix per controlar mesos com febrer o els dies 30 i 31.

En aquest mateix tràmit es podrà afegir un material i també afegir usuaris a la reserva. El fet d'afegir persones implicarà que aquests passaran a veure que a la seva compta hi ha una nova reserva. És a dir, s'afegirà la data o dates seleccionades al calendari dels usuaris convidats.

Els usuaris que s’afegeixen a una reserva, se seleccio-nen mitjançant un desplegable que els va mostrant gràfi-cament i que permet rectificar i eliminar-los. En el procés s’indiquen la quantitat de persones independentment dels usuaris afegits, així que hi ha un control que vigila que aquest valor sigui igual o més gran que el sumatori de les persones convidades.

Les hores que es mostren al formulari dependran de l'horari de la sala i de si ja hi ha alguna reserva. En el

(8)

moment en que s'indiqui l'hora d'inici es carregaran les hores finals suprimint les hores prèvies i les hores ja ocu-pades. En el cas dels materials, el formulari carregarà els horaris d’acord amb l'horari de l'empresa i la disponibili-tat segons la quantidisponibili-tat que no ha esdisponibili-tat reservada.

Un cop finalitzat el tràmit, tant l’usuari que ho realitza com els convidats rebran un correu informatiu de la ges-tió que s’acaba de realitzar. Alhora, tant si s'ha realitzat el tràmit per a una reserva, com per a un material, els usua-ris rebran el dia abans un recordatori amb tota la infor-mació (dia, hora, sala o material). S’ha de considerar que aquests correus s’enviaran sempre que l’usuari tingui activades les notificacions. Per defecte, en crear l’usuari quedaran actives però es pot modificar des de la configu-ració.

L'usuari amb privilegis, en essència, pot realitzar les mateixes accions que un usuari comú però simulant un alt càrrec que li permet eliminar les reserves d'altres usua-ris.

L'administrador, podrà veure les estadístiques d'ús de l'eina, l'historial de totes les reserves, podrà fer altes, bai-xes i modificacions d'usuaris, sales, categories, materials i dies restringits.

A l'hora de crear usuaris es verifica que no hi hagi un altre amb el mateix nom i que les contrasenyes coincidei-xin. A la creació de sales, es permet delimitar l’horari d'accés el qual serà carregat a l’hora de realitzar la reser-va; es permet crear dos rangs horaris.

En el cas que es vulgui eliminar una categoria, aquesta preguntarà si es volen eliminar les sales assignades, en cas afirmatiu s’eliminarà el conjunt. Si una categoria, una sala o un material s’elimina, apareixerà, a la vista de l’administrador, una creu vermella al costat indicant que no està disponible. D’aquesta manera, els usuaris no po-dran seleccionar l’element per fer la reserva però l’administrador podrà portar un registre.

En el cas de les altes de sales, es verifica que els dos rangs horaris que s’han de definir tinguin una coherència entre ells per evitar, per exemple, que l’hora inicial sigui posterior a la final.

Finalment, a l’hora de crear dies exempts de reserves, s’evita que es pugui inserir dues vegades la mateixa data. En aquesta mateixa pantalla es podrà modificar l’horari de l’empresa. Això funcionarà essencialment per poder delimitar les hores de reserva dels materials, ja que s’entén que aquestes es podran reservar únicament men-tre el cenmen-tre sigui obert.

7 I

MPLEMENTACIÓ

7.1 Necessitats tècniques

Algunes de les eines requerides ja les tenia instal·lades

a l'ordinador, tot i això, per tal de preparar una màquina per desenvolupar un projecte com aquest s'ha de comen-çar realitzant la instal·lació de Xampp amb tots els com-ponents.

Es realitza l'enviament de mails de forma periòdica pe-rò també de forma puntal cada vegada que es realitza o s’elimina una reserva. Per aquest últim punt, s'haurà de configurar Xampp; perquè pugui fer aquest enviament. A l'arxiu php.ini s'hauran de buscar les variables i col·locar la següent informació:

SMTP=smtp.gmail.com smtp_port=587

sendmail_from = direcció[email protected] sendmail_path = "C:\xampp\sendmail\sendmail.exe -t" Després, a l'arxiu sendmail s'haurà de completar la configuració indicant la resta d'informació com seria el correu d'origen amb la contrasenya. Important activar a la compta l'opció "Permitir que aplicaciones menos seguras accedan a tu cuenta", ja que si no Gmail rebutjarà la con-nexió.

Un cop estigui llest Xampp s'haurà d'instal·lar Android Studio, Visual Studio i PhpStorm; o qualsevol altra eina que ens permeti modificar el codi. Aquesta última eina, ens pot donar problemes amb les llibreries de sql, si no hi ha cap problema, s'instal·larà Install-Package MySql.Data -Version 8.0.14. Si igualment no ho agafa; la solució que vaig trobar és eliminar el paquet i les dependències per tornar-ho a posar. Una bona guia per fer aquesta part del projecte és l’enllaç que trobem a la referència [47].

S'hauran de descarregar i posar al projecte, a la carpeta de Xampp, les llibreries de fullCalendar i Chart. Per úl-tim, per poder instal·lar l'aplicació directament al smartphone, s'haurà de configurar per posar-lo en mode desenvolupador.

Un cop estigui tot realitzat, ja no hi haurà cap proble-ma per realitzar tot el desenvolupament.

7.2 Desenvolupament

La programació es va iniciar agafant la plantilla i do-nant-li el format MVC, patró que es basa en el reaprofi-tament del codi i en la separació de conceptes. Es van començar a implementar les funcionalitats utilitzant els llenguatges HTML5, CSS3, JavaScript, PHP i SQL.

Un fonament de l’eina és l’obtenció de la informació de la base de dades, aquesta es fa mitjançant consultes SQL fent la connexió amb PDO.

La connexió amb PDO ens proporcionarà una major seguretat de cara a evitar la inserció de codi. A part, es va realitzar una funció utilitzant htmlspecialchars, trim i stripslashes que validava les dades introduïdes per evitar

(9)

també aquests tipus d’atacs. La imatge següent representa l'estructura de la base de dades.

També s’han realitzat moltes funcions de JavaScript per fer comprovacions en les dades proporcionades per l’usuari i per generar una sensació de dinamisme en la navegació. Una de les comprovacions que es va fer va ser la dels dies restringits:

$.ajax({

type: 'POST',

url: './model/dbManager.php', data: {func: 'comprobarDia', dia: dia}, success: function (response) { if (response == 'true') {

alert("No se pueden realizar reservas el dia seleccionado"); document.reservaSala.dia.value = null;

document.reservaSala.dia.focus(); }

} });

Per oferir dinamisme tenim l’exemple dels calendaris que es mostren a les pantalles de creació de reserves o fins i tot de les icones que indiquen que s’ha afegit un convi-dat a la reserva:

function getUsuarioToList(user){ var usuario = $(user).val();

var div = document.createElement('div'); var nombreId = "usuario"+usuario;

var valores = $('#contentConjuntoUsuariosIN').val(); if (valores == ""){

var valores = new Array(); valores.push(usuario); }else{ valores = JSON.parse(valores); valores.push(usuario); } div.className = 'usuario'; div.id = nombreId;

div.innerHTML='<div href="#" class="listUsu">'

+usuario+'  ' +'<button type="button" class="close btn btn-primary" aria-label="Close" ' + 'onclick="removeRow('+nombreId+')" >×</button></div>'

document.getElementById('contentConjuntoUsuarios'). appen-dChild(div);

//eliminamos la option de la list

$("select").find("option[value='"+usuario+"']"). prop("disabled",true);

$('#contentConjuntoUsuariosIN').val(JSON.stringify(valores)); }

Sobretot van sorgir problemes al voler mantenir oculta visualment certa informació, com ara el calendari. Els mètodes que es van utilitzar al principi eren display i visibility; en el cas del display no es reservava el lloc que ocupava però a l’hora de fer-lo visible perdia el format. En canvi, el de visibility sí que ocupava espai però man-tenia el format. Utilitzar un dels dos de forma única per fer aquests tipus de processos va ser impossible així que es va haver de buscar una forma alternativa com va ser la que hi ha a l’exemple anterior.

De cara a l’enviament de correus de creació i d’eliminació de reserves simplement es va configurar Xampp i es va fer la crida quan va correspondre:

mail($correo,$subject,$message);

L’enviament automàtic va ser més complicat donat que passava de ser un cas puntual a una execució periòdica havent de programar un procés extern que no només envies el correu sinó que també generés el cos del missat-ge. En el cos s’inclouen totes les reserves que tingui l’usuari per l'endemà evitant la redundància d’enviar més d’un correu.

Per tal de poder tenir una eina multiplataforma s'ha creat una app d'Android. Aquesta, lluny de ser una apli-cació nativa, el que s'ha fet ha estat crear-la de forma que funcionarà com un navegador obrint la web des de la Il·lustració 3 Diagrama de classes

(10)

mateixa app del smartphone.

protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

webView=(WebView) findViewById(R.id.webView); webView.setWebViewClient(new WebViewClient()); WebSettings settings = webView.getSettings(); settings.setJavaScriptEnabled(true);

webView.loadUrl(url); }

8. R

ESULTATS

8.1 Resultats

La navegació s'ha fet la més intuïtiva i fàcil possible; també és responsive per facilitar el seu ús des de qualse-vol dispositiu. Per aquesta raó, s’ha aprofitat per realitzar una aplicació Android que el que fa és cridar la pàgina web obrint-la en la mateixa app.

Gràcies a enfocar-ho al fet que fos responsive s'ha aconseguit també, afegir valor a l'eina amb un baix esforç i cost.

S'han pogut crear els tres tipus d'usuari que permetran marcar els privilegis y funcions de cadascú, i realitzar les seves respectives transaccions.

D'igual forma, s'ha generat un procés de reserva de sa-les ple de personalitzacions que permeten acorar al mà-xim possible les reserva de l'usuari.

Per mantenir l'estructura de tota aquesta informació s'ha hagut de jugar amb la base de dades per tal que ho englobés tot i alhora permetés, en la mesura del possible, poder-la ampliar en un futur. A continuació podem ob-servar el diagrama de la base de dades:

Mitjançant la llibreria FullCalendar, es va poder gene-rar una sèrie de calendaris que mostren les reserves que s’han realitzat. La vista del calendari que es va escollir és la que agrupa l'espai visible segons els tipus de recurs. Segons el cas, mostra les sales que hi ha creades, afegint, a l'última línia, la informació dels materials, mentre que en altres mostra únicament com a recurs el material. Això permet veure d'una forma més ordenada la gestió de l'espai.

Com s’ha comentat, hi ha dos sistemes d’enviament de correus. El primer s’executa justament després de realit-zar una reserva o d'eliminar una d'elles. En el primer cas, després de finalitzar el formulari, enviarà tant a l'usuari creador com als convidats un correu informatiu. De la mateixa manera succeeix quan s'elimina una reserva.

El segon cas serveix com a recordatori per a l’usuari; s’envia el dia abans incloent totes les reserves que tingui aquella persona a l’endemà evitant redundàncies en els correus. Aquesta funcionalitat està implementada en C# com un service de Windows.

8.2 Proves

De cara a les proves s’han realitzat i documentat les proves funcionals i les proves d’usuari, ambdós docu-ments els podem trobar a l’annex.

Les funcionals són aquelles específiques, concretes i exhaustives que serveixen per validar que el software fa el que s’ha especificat als requeriments.

Les proves d’usuari o user testing és una tècnica que s’utilitza per avaluar un producte, característica o proto-tip amb usuaris reals. S’han utilitzat quatre proto-tipus de per-sones; la primera una persona amb coneixements infor-màtics, la segona amb coneixements bàsics, la tercera sense cap mena de coneixement i la quarta un usuari que fa actualment aquests tràmits a mà.

En essència, els usuaris es queixen que el calendari és poc intuïtiu i no facilita la seva comprensió i que els hi agradaria poder reservar més d'un material en el procés de reserva de sales. Totes les impressions que es van reco-llir durant aquestes proves es poden trobar al document.

Tant les proves funcionals com les dels usuaris, van permetre detectar errors, incongruències i factors a millo-rar. Els errors detectats anaven més enfocats a modifica-cions que s’havien realitzat però no s’havien aplicat a tots els llocs necessaris.

Les millores que van suggerir van consistir tant en mi-llores visuals com en funcionals. Com a millora visual podríem extreure el cas anteriorment mencionat del ca-lendar, i com a funcional una suggerència pel que fa a les Il·lustració 5 Pantalla d'inici

(11)

invitacions a altres usuaris. Aquesta, consistia a poder reclinar o acceptar aquesta petició des de la mateixa plata-forma.

9 C

ONCLUSIÓ

Un cop finalitzat el projecte podem afirmar que s’han aconseguit complir tots els objectius i requeriments espe-cificats pel client.

El projecte va ser capaç d’adaptar-se als canvis tant del client com de la mateixa planificació sense afectar a la seva data d’entrega final.

La trajectòria de desenvolupament ha estat favorable gràcies a la metodologia utilitzada que permetia aprofitar els coneixements adquirits i reduir el temps d’implementació.

Ara, amb una mica més de perspectiva, hi ha coses que es podrien haver fet de diferent manera per aprofitar millor el temps. Per exemple, es podria haver fet tot el disseny de la base de dades des d’un principi.

De la mateixa manera, crec que una plantilla de Boos-trap més plana/uniforme podria anar més acord amb el tipus d’eina que és.

Tot i això, crec que el sistema està ben enfocat perquè compleix una carència que hi ha al mercat actual. Alhora, és completament apta per continuar ampliant-se i afegir funcionalitats que permetin que sigui més completa i s’ampliïn les seves aplicacions.

El projecte té múltiples ampliacions però a continuació, s’explicaran les que considero més interessants enumera-des de major a menor criticitat.

El primer que s'hauria d'avaluar és si es deixa de con-siderar el material com un element crític i s'agrega la funcionalitat que permeti reservar més d'un material en el tràmit de reserva de sales i en el de materials.

A continuació, vincular el calendari amb Google Ca-lendar perquè cada usuari pugui veure les seves reserves a les dues plataformes. També, trobar una solució per poder veure en el calendari tota la setmana i tot el mes d'una sola ullada.

Seria important, que tant l’usuari amb privilegis como l'administrador poguessin no només eliminar reserves sinó també crear-les per altres usuaris.

Fer reserves que no siguin úniques per a una persona sinó es que permeti realitzar diverses reserves en una sala el mateix dia a la mateixa hora sempre que ho permetés l’aforament. Aquesta part seria interessant si s’enfoca a sales d’estudi o amb ordinadors.

En vista de donar més utilitat a les invitacions d'usua-ris, implementar que aquestes invitacions poguessin ser acceptades o rebutjades dins de la mateixa plataforma.

Per últim, donar la possibilitats de crear una vinculació

amb un hardware de detecció d’empremta dactilar que permetés l’accés a aquells usuaris que, efectivament, te-nen guardada la sala.

B

IBLIOGRAFIA [1] https://themewagon.com/themes/free-html5-admin-dashboard-template/ [2] http://www.forosdelweb.com/f4/pop-up-que-cierre-automaticamente-html-983495/ [3] https://www.lawebdelprogramador.com/foros/HTML/14927 26-Ventana-emergente-o-Pop-Up.html [4] https://www.w3schools.com/php/php_mysql_insert.asp [5] http://php.net/manual/es/pdostatement.rowcount.php [6] https://librosweb.es/libro/bootstrap_3/capitulo_6/mensajes_ de_alerta.html [7] http://www.forosdelweb.com/f4/evento-cambiar-contenido-del-input-text-1059425/ [8] https://desarrolloweb.com/articulos/880.php [9] http://www.forosdelweb.com/f4/posicionar-cursor-formulario-html-427143/ [10] http://www.forosdelweb.com/f13/validar-existencia-usuario-sin-salir-pagina-1062601/ [11] https://blog.reaccionestudio.com/comprobar-si-el-nombre-de-usuario-existe-con-jquery-y-php/ [12] https://soporte.miarroba.com/152498/2636164-mostrar-una-varible-por-pantalla/ [13] http://danielcarrllojara.blogspot.com/2013/09/eliminacion-de-registros-multiples.html [14] https://stips.wordpress.com/2014/03/13/eliminar-multiples-datos-con-checkbox-php-y-mysql/ [15] https://www.youtube.com/watch?v=yl_VCP1ca9U [16] http://php.net/manual/es/function.isset.php [17] http://php.net/manual/es/function.header.php [18] https://www.jose-aguilar.com/blog/paginacion-resultados-con-php/ [19] https://programacion.net/codigo/paginar_registros_de_una_c onsulta_34 [20] https://www.jose-aguilar.com/blog/paginacion-resultados-con-php/ [21] https://desarrolloweb.com/articulos/1035.php [22] http://www.lisenme.com/dynamic-dependent-select-box-using-jquery-ajax-php/ [23] https://www.anerbarrena.com/php-unset-4808/ [24] https://www.w3schools.com/howto/howto_css_switch.asp [25] https://programacion.net/articulo/boton_switch_estilo_ios_ut ilizando_css3_y_jquery_1479 [26] https://cybmeta.com/comprobar-sin-un-checkbox-esta-seleccionado-con-jquery [27] https://cursoprogramador.wordpress.com/2014/02/19/progr amando-en-php-un-boton-para-cerrar-sesion/ [28] http://www.itmplatform.com/es/blog/todo-lo-que-debes-incluir-en-un-reporte-de-estado-de-proyecto/ [29] https://fontawesome.com/icons?d=gallery [30] http://php.net/manual/es/datetime.format.php [31] https://devtroce.com/2010/10/13/traer-al-frente-un-div-con-css/ [32] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time [33] https://www.jose-aguilar.com/blog/seleccionar-una-opcion-por-defecto-de-un-select-con-jquery/

(12)

[34] http://php.net/manual/es/function.strftime.php [35] https://lachabela.wordpress.com/2012/02/24/fechas-en-espanol-con-php-y-setlocale/ [36] http://www.forosdelweb.com/f18/como-dar-formato-datetime-458385/ [37] https://www.fernandezsansalvador.es/blog/recorrer-rango-de-fechas-en-php [38] https://www.baulphp.com/sumar-y-restar-horas-y-minutos-con-php/#Sumar_horas_en_PHP_4 [39] http://php.net/manual/es/function.array-unique.php [40] https://fullcalendar.io/ [41] https://fullcalendar.io/scheduler [42] https://www.youtube.com/watch?v=ByyXkD25RfM&index=8 &list=PLSuKjujFoGJ3xqSJHnZUR-INEO71t1znq [43] https://developer.android.com/guide/webapps/webview [44] https://www.youtube.com/watch?v=sr5dr9A2De8 [45] https://www.youtube.com/watch?v=TUXui5ItBkM [46] https://stackoverflow.com/questions/47239251/install-failed-user-restricted-android-studio-using-redmi-4-device [47] https://www.youtube.com/watch?v=S0Q6LYGLeYo&t=981s [48] https://es.stackoverflow.com/questions/20438/c%C3%B3mo-acortar-la-paginaci%C3%B3n-en-php [49] https://es.stackoverflow.com/questions/20438/c%C3%B3mo-acortar-la-paginaci%C3%B3n-en-php [50] http://www.forosdelweb.com/f18/sumar-dentro-rango-horas-717330/ [51] https://www.lawebdelprogramador.com/foros/PHP/1586494 -Sumar-Horas.html [52] https://bannysolano.wordpress.com/2008/12/28/eliminar-parametros-en-el-navegador/ [53] https://getbootstrap.com/docs/4.2/components/ [54] https://es.slideshare.net/angienikyvasquez/agregar-espacios-en-html [55] https://getbootstrap.com/docs/4.2/utilities/close-icon/ [56] https://www.w3schools.com/jsref/prop_html_classname.asp [57] https://stackoverflow.com/questions/17650776/add-remove-html-inside-div-using-javascript [58] https://developer.mozilla.org/en-US/docs/Web/API/Node/removeChild [59] https://www.w3schools.com/js/js_arrays.asp [60] https://stackoverflow.com/questions/29076219/javascript-storing-array-of-objects-in-hidden-field [61] https://es.stackoverflow.com/questions/45780/c%C3%B3mo-eliminar-un-elemento-de-un-array-en-javascript [62] https://geekytheory.com/json-iii-gestionar-json-en-php [63] https://desarrolloweb.com/articulos/997.php

ÍNDEX

DE

FIGURES

Il·lustració 1 Desenvolupament iteratiu i creixent... 4

Il·lustració 2 Diagrama de casos d'us ... 5

Il·lustració 3 Diagrama de classes ... 5

Il·lustració 4 Calendari de reserves ... 5

Il·lustració 5 Pantalla d'inici ... 5

TAULA 1 OBJECTIUS DEL PROJECTE ... 2

TAULA 2COMPARATIVA DE LES FUNCIONALITATS ... 4

ANNEX

Només entrar a la plataforma el primer que veiem és la petició d’inici de sessió. Segons les credencials i el rol de la persona carregarà una vista o una altra.

En el cas de l’usuari comú, la seva pantalla d’inici car-regarà el calendari amb totes les seves reserves. En els calendaris veiem una columna dels recursos, on es carre-ga el llistat de les sales i, en els casos necessaris, s’afegeix una altra fila dels materials.

Si l’usuari opta per realitzar la reserva d’una sala, se li obrirà el següent formulari on podrà personalitzar la seva reserva. També té accés a un botó que mostrarà un calen-dari amb totes les reserves del sistema.

Si es marca que es desitja periodicitat, un material o convidar usuaris, s’afegiran més opcions a completar. Totes elles són opcions que es poden tornar a desmarcar.

En el cas de convidar usuaris, només s'haurà de selec-cionar en el desplegable i apareixeran en forma de bom-bolla just a sota. Porten inclosa una creu que permet eli-minar-los si és necessari i es controlarà que tingui cohe-rència amb la quantitat de persones que s'indica, evitant que es reservi per a menys persones.

(13)

Una vegada s'hagi tramitat la reserva, si s'ha seleccio-nat periodicitat, apareixeran al costat els possibles pro-blemes que pugui haver hagut durant el procés. Això pot ser, per exemple, que en una reserva mensual hi hagi dies que no existeixin, que caiguin en cap de setmana o sim-plement que ja estigui reservat.

Si es tracta d'una reserva sense periodicitat, simple-ment es notificarà si el tràmit s'ha finalitzat correctasimple-ment o no.

Quan s'hagi finalitzat s'enviarà un correu a l'usuari in-formant del tràmit que acaba de realitzar; de la mateixa manera s'avisarà als convidats si és que s'han indicat.

La pantalla de la reserva de materials és molt més sim-ple, la variància més gran que hi ha és que al fer clic per veure el calendari, en aquests només veurem els materials i no les sales.

Si l'usuari decideix consultar les seves reserves, es tro-barà amb una finestra que li permet veure-les separades per sales o per materials.

Alhora, cadascuna d'elles té l'opció d'eliminar sempre que la reserva no hagi succeït encara. En els casos dels llistats, si hi ha molts elements a mostrar, s'habilita una paginació a la part baixa de la vista.

Finalment, l'usuari pot modificar les seves dades per-sonals, com podria ser el seu nom, el correu electrònic o si desitja o no rebre notificacions. A la part esquerra podrà veure el recull de la seva informació i a la dreta podrà realitzar les modificacions emplenant els camps que ne-cessiti.

L'usuari amb privilegis té les mateixes opcions que un usuari normal però afegint la possibilitat de cancel·lar o modificar les reserves de les sales d'altres usuaris. Tot i això té el mateix límit a l'hora d'eliminar o modificar les reserves; han de ser posteriors a la data actual.

L'administrador carrega la seva pàgina d'inici tenint una visió global de totes les reserves dels usuaris. De la mateixa manera, les estadístiques han estat generades d'acord amb totes les dades del sistema.

Si es desitja realitzar l'alta d'un usuari, es podrà accedir des de dos llocs diferents, el primer des de l'opció Alta de usuarios del menú i el segon dins del d'usuaris.

En ambos casos es carregarà un formulari que ens de-manarà emplenar la informació de l'alta, comprovant que el nom de l'usuari no existeixi i que les contrasenyes si-guin coincidents. Les altes, per defecte posen les notifica-cions com a actives.

(14)

Per tal de gestionar tots els elements a la plataforma tenim l'opció de Gestionar elementos; des d'aquí podrem crear, modificar i eliminar categories, sales i materials.

S'obrirà una pantalla que, mostrarà un llistat de l'ele-ment en qüestió indicant amb una icona verda aquells elements actius i modificables i amb una creu roja els elements inactius.

Es disposa d'un menú secundari per moure's entre els tres tipus d'elements. Tant per la creació com per la modi-ficació, s'obrirà un pop-up on es podran introduir les dades. En el cas d'un nou element el formulari vindrà buit però, en el cas de modificar, apareixeran les dades actuals de l'element seleccionat.

Si es desitja fer una modificació s'haurà de fer click a l'opció verda de la fila que desitgem i s'obrirà una finestra com la següent.

El cas de l'eliminació és més complex; no eliminarà l'e-lement sinó que el mostrarà amb una creu per indicar que ja no està disponible. A més, en el cas de les categories, un cop seleccionada l'opció d'eliminar es preguntarà si es desitja eliminar també les sales.

L'administrador també podrà llistar les reserves de sa-les i de materials i sa-les podrà modificar i editar sempre que la data sigui posterior.

Per finalitzar, a l'opció de Días restringidos es podran

afegir i eliminar els dies en els quals ningú podrà fer cap mena de reserva. També es pot modificar l'horari de l'empresa, el qual va lligat a l'hora de reserva dels materi-als.