Implementació d'una aplicació per la gestió logística d'entitats esportives sense ànim de lucre

Implementació d'una aplicació per la gestió logística d'entitats esportives sense ànim de lucre Autor: Ferran Martínez Martí Data: 27/05/2015 Director: Marc Alier Forment Departament del director: Enginyeria del Software i Sistemes d’Informació (ESSI) Titulació: Enginyeria Superior en Informàtica Centre: Facultat d'Informàtica de Barcelona (FIB) Universitat: Universitat Politècnica de Catalunya (UPC) BarcelonaTech 2 Agrair al Marc Alier per haver confiat en la proposta de projecte quan li vaig explicar per primer cop i pels seus consells, suport i orientacions durant tot el projecte. A la meva família per l’empenta, ajuda i ànims constants que m’han donat. Als membres de la junta del meu club, que em van fer adonar de la necessitat de crear una solució pel problema que teníem, per haver confiat en aquesta “bogeria” i per totes les seves crítiques i aportacions. Als jugadors/es i famílies per haver-se prestat a fer de “conillets d’índies”, per tot el feedbac rebut i també les seves aportacions. I a totes aquelles persones úniques que m’han patit però que sempre han estat allà. Elles ja saben qui són. 3 Índex Introducció ...................................................................................................................................5 Definició del projecte ...............................................................................................................5 Objectiu del projecte ................................................................................................................6 Abast ........................................................................................................................................7 Motivació personal ...................................................................................................................8 Beneficis .................................................................................................................................10 Perfils d’usuari ........................................................................................................................11 Target del projecte .................................................................................................................13 Viabilitat del projecte .............................................................................................................14 Alternatives ............................................................................................................................17 Planificació Inicial .......................................................................................................................18 Aspectes generals...................................................................................................................18 Descomposició inicial de les tasques a realitzar .....................................................................20 Diagrama de Gantt .................................................................................................................22 Disseny .......................................................................................................................................24 Anàlisi de requeriments .........................................................................................................24 Requeriments funcionals ....................................................................................................24 Requeriments no funcionals ...............................................................................................26 Casos d’ús ...............................................................................................................................27 Àrea d’usuaris.....................................................................................................................28 Àrea d’equips .....................................................................................................................32 Àrea de documentació pública ...........................................................................................38 Àrea de material esportiu...................................................................................................41 Àrea de quotes ...................................................................................................................48 Diagrama de clases .................................................................................................................53 Disseny .......................................................................................................................................54 Arquitectura ...........................................................................................................................54 El patró Model – Vista – Controlador (MVC) ..........................................................................56 Flux d’ús .................................................................................................................................58 Tecnologies ............................................................................................................................60 Servei d’allotjament web....................................................................................................60 Framework .........................................................................................................................62 Front-end framework .........................................................................................................63 4 Implementació ...........................................................................................................................64 Procés d’implementació .........................................................................................................64 Recorregut per l’aplicació.......................................................................................................76 Àrea d’usuaris.....................................................................................................................78 Àrea de documentació pública ...........................................................................................80 Àrea d’equips .....................................................................................................................81 Àrea de material esportiu...................................................................................................84 Àrea de quotes ...................................................................................................................88 Fase de testeig ...........................................................................................................................91 Generalitats ............................................................................................................................91 Planificació .............................................................................................................................92 Estadístiques d’ús ...................................................................................................................96 Aportacions dels usuaris ......................................................................................................105 Revisió dels requisits no funcionals ......................................................................................107 Model de negoci.......................................................................................................................112 Generalitats ..........................................................................................................................112 Despeses 1ª Fase ..................................................................................................................113 Despeses 2ª Fase ..................................................................................................................114 Modalitats del producte ofertades.......................................................................................116 Planificació Final .......................................................................................................................118 Conclusions ..............................................................................................................................119 Bibliografia ...............................................................................................................................120 Webs d’informació general ..................................................................................................120 Annexos....................................................................................................................................121 Annex 1: Estadístiques completes d’ús ................................................................................121 Annex 2: Presentació Juny’14 ...............................................................................................145 Annex 3: Manual d’usuari ....................................................................................................146 5 Introducció Definició del projecte Aquest Projecte Final de Carrera consisteix en la implementació d’una aplicació web per gestionar els processos logístics d’entitats esportives sense ànim de lucre. En concret l’aplicació estarà pensada per a totes aquelles entitats, ja siguin clubs esportius o seccions esportives d’escoles que s’organitzen en diferents categories (benjamí, aleví, infantil, cadet, juvenil, júnior, mini, etcètera) i dins d’aquestes categories diferents grups o equips. D’altra banda quan es parla de processos logístics ens referim a totes aquelles accions que una junta directiva o gestors de l’entitat han de dur a terme i que són imprescindibles pel correcte desenvolupament de l’activitat de l’entitat. Per tant l’objectiu serà facilitar la tasca dels gestors d’aquestes entitats i que en tractar-se d’entitats sense ànim de lucre no poden percebre una remuneració per aquestes tasques, però en canvi han de dur-les a terme sense excepcions. A més a més de tot això, s’haurà de buscar en tot moment la manera de minimitzar els costos per tal de fer una solució més atractiva i assequible pels clients potencials. 6 Objectiu del projecte L’objectiu és dissenyar i implementar un aplicació que permeti fer una gestió completa d’un club esportiu adaptant-se a les peculiaritats que presenta cada club. Per això, s’optarà per un portal web que cobreixi tots aquells tràmits que es duen a terme de forma repetitiva al llarg d’una temporada i on hi interactuen múltiples persones. Així de forma concreta ha de permetre:  Facilitar les comunicacions i processos per part de membres no directius del club en el moment que sigui, sense haver de dependre de la presència d’un membre de la directiva o persona que desenvolupi tasques administratives.  Simplificar i ajudar a controlar a la directiva del club totes les gestions que han de realitzar els seus membres. 7 Abast Definits els objectius l’aplicació final haurà de donar solució a:  Permetre el procés d’inscripció a l’entitat per part dels jugadors/es del club, així com l’entrega de tota la documentació que es necessiti.  Servir com a base de dades de tots els membres de l’entitat pels gestors.  Classificar i assignar els jugadors segons la categoria i l’equip que formin part.  Especificar les característiques de cada equip, ja sigui d’horaris, llocs d’entrenaments, com de la documentació en concret que es requereix.  Posar a disposició del jugador els documents i formularis que es necessiten en el procés d’inscripció.  Oferir una botiga de marxandatge perquè els usuaris puguin fer comandes de material esportiu del club i puguin seguir tot el procés de compra fins a la seva entrega.  Assignar quotes econòmiques als jugadors/es i que aquests puguin fer un seguiment dels terminis, l’estat i les quantitats. 8 Motivació personal Des de fa uns quants anys formo part del club de bàsquet del meu poble. Com la majoria de casos, primer hi entres a formar part com a jugador i després d’un temps si ets d’aquelles persones que van complint, arriba un moment que se t’ofereix entrenar un equip. En tractar-se d’una entitat d’un poble amb poc més de 8000 habitants, la majoria d’entrenadors sempre acaben sent els propis jugadors de l’entitat i així es va produint un relleu generacional. Farà unes tres temporades les persones que fins aquell moment formaven part de la junta directiva van comunicar que, després de 13 temporades, convocaven eleccions i que no tenien intenció de presentar-se a la reelecció. Aquesta situació va fer que entre un grup d’amics, tots vinculats a l’entitat, decidíssim presentar-nos-hi per agafar el relleu. En aquell moment la situació del club no era la millor de la seva història, del màxim de 20 equips que havia arribat a tenir, en tenia uns 10 i alguns d’aquests amb un risc elevat de desmembració. El perfil del grup d’amics que ens vam presentar a les eleccions, era el d’unes persones amb formació en l’àmbit esportiu (titulacions d’entrenadors, estudis d’educació física...) però també amb estudis d’economia, informàtica o d’altres que podien ser útils en el dia a dia de la gestió. Aquesta situació contrastava amb la de la junta sortint, ja que eren un grup de pares que s’havien fet càrrec de l’entitat més que res amb bona voluntat. Com acostuma a succeir en poblacions petites, només hi va haver una candidatura, la nostra, i vam ser escollits com a junta directiva. A partir d’aquell moment, se’ns obria una nova situació, on per una banda teníem llibertat per aplicar els criteris que millor consideréssim però a més a més, no teníem vinculació de parentesc amb cap jugador i per tant les decisions que prenguéssim podien anar completament encaminades a seguir els criteris que ens havíem marcat. Com que no hi ha uns estudis pròpiament dits per gestionar aquest tipus d’entitats, la situació requeria un replantejament de tot des de 0, que permetés per una banda capgirar la tendència negativa que duia l’entitat i per l’altra adaptar-la a temps més actuals. Ben aviat ens vam adonar que si bé el nostre objectiu era estar el màxim temps possible a les pistes duent a terme la pràctica esportiva, la gestió ens treia un volum de temps molt gran. En aquella primera temporada, jo ja havia estat buscant algun tipus d’aplicació que ens facilités aquesta tasca però sempre acabava topant amb aplicacions centrades en el recull de dades estadístiques, resultats esportius o entrenaments realitzats. 9 Al principi de la segona temporada es va produir un fet que va ser el detonant per plantejar-me fer aquest projecte. En aquell moment el procés d’inscripció dels jugadors es feia mitjançant un dossiers que es repartien i després s’havien de retornar emplenats i amb un seguit de documents necessaris. Sempre ens acabàvem trobant que s’havien de fer diferents models de dossiers segons les característiques de la categoria i a l’hora de la veritat cada família acabava portant els documents que volien o ho feien en tongades. Això en suposava una feina de revisió constant i tenint en compte que en aquell moment l’entitat la formaven unes 150 persones, la feina era considerable. Mentre realitzàvem aquesta tasca, un dels companys de la junta va llençar una pregunta, quasi més com a lamentació que com a proposta. La pregunta va ser si tot això no ho podia fer un ordinador. En aquell moment jo ja tenia la idea d’acabar fent aquest projecte, però aquesta pregunta em va fer adonar-me que no era l’únic que havia detectat aquesta necessitat. Tot això coincidia amb un procés endegat per la Federació Catalana de Bàsquet (FCBQ) on totes les llicències de tramitar-se de forma presencial a la seva seu es passaven a tramitar-se a través d’una aplicació web. Per tant tota aquella documentació que nosaltres teníem en dossiers s’havia d’acabar bolcant per una part a una base de dades en excel i per l’altra escanejar i enviar a la FCBQ. Sempre havia estat una persona que havia intentat unir les noves tecnologies amb l’esport, així que això era una nova oportunitat per donar solució a un problema però també per plantejar-me un repte personal i una manera de posar-me a prova. 16 Amb quina freqüència revises el teu correu electrònic? El primer punt a destacar és que totes les persones enquestades disposaven d’Internet a casa i un 95% deien disposar d’uns coneixements mitjans-alts. El punt que podia convertir-se en un petit problema era que més d’un 25% de les persones no disposaven d’escàner, cosa que feia que el club hagués d’assumir aquesta responsabilitat. De totes maneres, fins al moment els clubs ho feien pel seu compte per tant una reducció en el 70% del volum de feina no era gens menyspreable i aquest aspecte només afectava a la inscripció. Després de les proves amb usuaris reals, es va demostrar que aquesta xifra no era tant alta i que només un 7% dels usuaris havien requerit que el club escanegés tota la documentació. Finalment, els hàbits d’ús del correu electrònic eren molt alts cosa que permetia rebre notificacions via correu electrònic (per exemple de la disponibilitat d’una comanda) i la presència d’smartphone deixava oberta la porta, en un futur, a adaptar certes funcionalitats, si bé no és l’objectiu principal. Cada dia 32 80% 2-3 cops per setmana 7 18% Un cop per setmana 1 3% Un cop al mes 0 0% Mai 0 0% 17 Alternatives En el moment de l’inici del desenvolupament del projecte no s’havien detectat alternatives a aquest projecte que poguessin cobrir la problemàtica detectada. A finals de desembre de 2014, la Federació Catalana de Basquetbol va signar un conveni de col·laboració amb l’empresa danesa Holdsport per oferir el seu software (EquipSport.cat) en territori català. Si bé, degut al moment del projecte en que ens trobem no s’ha testejat les característiques que segons la seva plana web ofereixen són les següents:  Calendari online  Sistema avançat de gestió de cobraments de quotes  Compartir perfils entre membres del club  Estadístiques del club  Adquisició de material esportiu 18 Planificació Inicial Aspectes generals Pel desenvolupament del projecte s’han establert quatre parts diferenciades: Especificació, Disseny, Implementació i Proves. Donat que el club al qual pertanyo s’ha ofert a realitzar les proves amb els jugadors i membres, tota aquesta planificació vindrà determinada per unes dates de funcionament del club i que no poden ser modificades. S’entenia que de les tres grans àrees establertes a l’abast (inscripcions-equips, material esportiu i quotes) la més important era la d’inscripcions-equips. Així doncs en el moment de les proves aquesta part havia d’estat completament implementada i testejada en un alt grau per part dels desenvolupadors. Aquesta data era al voltant del 20 de juny, moment on es dona per acabada la temporada i s’inicia la preinscripció que pot durar fins a finals de juliol. Després ve l’etapa d’inscripcions que s’allarga fins a finals de setembre. La diferència entre les etapes d’inscripció i preinscripció no té cap efecte cara al desenvolupament del projecte, és simplement una diferenciació que fa el club per oferir un descompte a aquelles persones que confirmen que continuaran una temporada més i així faciliten la planificació de la temporada vinent. Per tant, en el moment que es comencessin a fer les reunions informatives de la temporada 2014-15 s’havia de disposar del nucli central de l’aplicació implementada. De totes maneres es va prendre la decisió que es treballaria perquè les tres grans àrees estiguessin disponibles des d’un moment inicial malgrat que la d’inscripcions era la que tenia un ús més centrat en una franja temporal i la resta tenen un ús al llarg de tota la temporada. Per tot això, es va decidir que l’etapa d’implementació i proves es dividiria en 5 parts quedant el conjunt de la planificació de la següent manera: Etapa Descripció Especificació En aquesta etapa s’ha de definir què és el que el sistema ha de realitzar i les funcionalitats que ha de tenir. Disseny Les funcionalitats s’han d’adaptar al sistema i generar models conceptuals, diagrames de seqüència i els casos d’ús corresponents. Implementació 1: Mòdul inscripcions En aquesta etapa s’ha d’implementar tot el que fa referència al registre d’usuaris, gestió de perfil i documentació que s’ha d’entregar per completar la inscripció. Proves 1: Mòdul inscripcions Testeig del correcte funcionament del mòdul en qüestió. 19 Implementació 2: Mòdul equips En aquesta etapa s’ha d’implementar el sistema de creació d’equips i personalització i l’assignació d’usuaris al diferents equips. Proves 2: Mòdul equips Testeig del correcte funcionament del mòdul en qüestió. Implementació 3: Mòdul quotes En aquesta etapa s’ha d’implementar el sistema de plantilles genèriques de quotes i l’assignació als usuaris. També tota la consulta segons diferents criteris i modificació de l’estat de la quota. Proves 3: Mòdul quotes Testeig del correcte funcionament del mòdul en qüestió. Implementació 4: Mòdul material esportiu En aquesta etapa s’ha d’implementar una botiga que permeti generar comandes de material esportiu segons uns productes que l’usuari ha creat i el posterior control de la comanda. Proves 4: Mòdul material esportiu Testeig del correcte funcionament del mòdul en qüestió. Proves 5: Fase de proves per a tots els usuaris Aquesta fase té com a objectiu analitzar la càrrega de l’aplicació amb un volum d’usuaris més alt i les proves exhaustives per part d’aquests. Feedbac Etapa on es rebrà un feedbac per part dels usuaris que empren l’aplicació (jugadors com gestors) i es determinaran quines millores d’usabilitat es poden fer. No es contemplen ampliacions de funcionalitats a no ser que siguin imprescindibles. Implementació 5: Millores a partir del feedbac Implementació de les millores definides al feedbac. Proves 6: Proves de les millores Testeig d’aquelles millores implementades a l’última fase. Segons la normativa l’estudiant ha de dedicar unes 20h per cada crèdit, donat que el projecte està valorat en 37.5 crèdits en surt un volum d’hores de 750 aproximadament. Donades les característiques de l’entitat no és possible repartir de forma equitativa aquest volum de feina ja que partim amb unes dates límit que hem de complir si volem poder realitzar la fase de testeig al propi club. Amb tot això s’ha repartit la càrrega entre les diferents tasques que s’havien identificat. 20 Descomposició inicial de les tasques a realitzar TASCA Tasques generals 85 Tasques administratives del projecte 5 Reunions amb el director del projecte 20 Elaboració planificació temporal 5 Elaboració de la memòria del projecte 50 Preparació diapositives del projecte 5 Estudi previ 11 Estudi de viabilitat 3 Reunions inicials amb el club 5 Elaboració i anàlisi enquesta inicial 3 Especificació 40 Casos d'ús 20 Diagrama de classes 20 Disseny 55 Decisió tecnologies a emprar 10 Aprenentatge de les tecnologies 25 Disseny base de dades 20 Implementació 400 Configuració entorn de treball 20 Disseny d'interfícies generals 20 Implementació registre d'usuaris 25 Implementació perfils d'usuaris 60 Implementació mòdul de documents públics 20 Implementació del mòdul d'equips 30 Implementació botiga 30 Implementació comandes de productes 50 Implementació plantilles de quotes 25 Implementació gestió de quotes 50 Implementació de millores d'usabilitats i altres funcionalitats no essencials rebudes del feedbac 70 Proves 101 Testeig de les funcionalitats implementades 40 Preparació manual de funcionament 5 Formació persona encarregada del club 3 Preparació reunió de presentació 2 Reunions informatives amb usuaris 5 Suport persona encarregada del club 10 Assistència tècnica a usuaris 25 Reunions seguiment amb el club 5 Elaboració enquesta satisfacció 3 21 Anàlisis resultats enquesta satisfacció 3 Altres tasques 60 Anàlisi ús de recursos del sistema 15 Optimització consum de recursos de l'aplicació 25 Elaboració del model de negoci 20 Hores totals 752 Com podem veure surt una càrrega de 752 hores aproximades que concorda amb el que es demana, aspecte que ja s’havia tingut en compte a l’hora de definir l’abast del projecte. 22 Diagrama de Gantt Una vegada fixat el repartiment de la càrrega de feina segons les tasques, s’elabora el següent diagrama de Gantt per fixar el moment temporal en que s’ha de realitzar cada tasca. 23 Es fixa la major part de la càrrega del projecte durant els primers mesos de 2014, deixant un marge suficient per poder arribar a la data del 20 de juny (aproximadament) amb el projecte implementat en gran part. A partir d’aquest moment la càrrega de feina serà fer un seguiment del funcionament i de suport a les dues part d’usuaris (club i jugadors). Aquesta etapa s’allargarà fins a mitjans d’octubre moment on el ritme d’inscripcions al club decreix i aleshores es farà el feedbac per part dels usuaris, l’última iteració de la implementació i l’elaboració del model de negoci. Arribat a aquest punt només quedarà la realització de la memòria. 24 Disseny Anàlisi de requeriments El primer pas en el procés de disseny del projecte és analitzar quin són els requeriments funcionals del projecte, o dit d’una altra manera, aquelles funcionalitats que disposaran els diferents usuaris actors de l’aplicació i per l’altra aquells no funcionals que fan referència a com ha de ser l’aplicació en sí mateixa. Requeriments funcionals Per definir els requeriments funcionals partirem de l’abast definit anteriorment. És important que aquests requisits quedin definits clarament, ja que un canvi posterior en qualsevol d’aquests requisits o simplement el fet d’afegir-ne un podria desencadenar tot un seguit de canvis que podrien generar incompatibilitats amb algunes funcionalitats o d’altres requeriments ja acceptats.  Crear una pàgina web que permeti a una entitat esportiva controlar els processos logístics que duu a terme en el seu dia a dia.  Permetre als gestors de l’aplicació donar d’alta usuaris amb nom d’usuari i contrasenya. Els gestors hauran de ser els únics que puguin donar d’alta els usuaris de manera que es generarà una contrasenya aleatòria i després serà l’usuari qui tindrà l’opció de modificar-la.  Tenir la possibilitat per part dels usuaris d’emplenar les dades referents al seu perfil, tal com són nom, cognoms, adreça, telèfons, correu electrònic, compte bancari, dni, targeta sanitària i que són les indispensables per poder tramitar una llicència esportiva.  Concedir al gestor la facultat per validar una inscripció.  Mostrar en tot moment l’estat de la inscripció entre els següents estats: sense equip, manca de documentació, pendent de revisió i validada.  Permetre als usuaris adjuntar documents escanejats tals com dni, targeta sanitària, drets d’imatge, llicència federativa, fotografia de carnet i certificat mèdic.  Oferir la possibilitat de crear equips on s’hi indiqui el lloc, les hores d’entrenament, la categoria i el nom.  Poder assignar els usuaris a equips.  Introduir arxius per a que aquests puguin ser descarregats per part dels seus usuaris. Aquests documents hauran de ser visibles o no, segons el gestor decideixi.  Permetre la creació de productes de material esportiu on s’hi indiqui el nom, una fotografia, descripció, mètode de pagament, si el producte està disponible o no i les talles que el conformen.  Mostrar tots els productes disponibles d’una forma clara i intuïtiva perquè l’usuari es faci una idea del que s’ofereix. 25  Facilitar l’adquisició dels productes esportius a partir del llistat que s’ofereix demanant només a l’usuari quina és la talla que desitja.  Donar la possibilitat al gestor de modificar l’estat de cada comanda per permetre a l’usuari fer-ne un seguiment, així com filtrar-les segons diferents criteris com pot ser producte o equip.  Mostrar un historial de totes les comandes que ha realitzat l’usuari i els seus estats.  Permetre la creació de plantilles de quotes on s’especifiqui per cada quota la data de cobrament, la quantitat i el concepte.  Poder assignar una plantilla de quotes a un usuari, de manera que es creï una quota per l’usuari per cada quota que formés part de la plantilla.  Poder modificar l’estat de cada quota d’entre els següents: pendent de cobrament, passada, error en el cobrament i cobrada sense problemes.  Permetre també al gestor crear, modificar i/o eliminar les quotes.  Facilitar la cerca de les quotes existents mitjançant filtres com pot ser l’estat, el mes on s’ha de cobrar o l’equip al qual es pertany.  Permetre accedir directament a un llistat on es mostrin totes les quotes d’un usuari en concret. 32 Àrea d’equips 33 Veure llistat d’equips de l’entitat Actors: Gestor Objectiu: Visualitzar tot el llistat d’equips de l’entitat Resum: El gestor visualitza la llista d’equips i escull una acció per dur a terme ja sigui creant un equip nou o una acció per a un equip existent. Curs típic d’esdeveniments: 1. El gestor prem el botó de veure el llistat d’equips. 2. El sistema li mostra una taula on s’indica el nom de cada equip, la seva categoria, la xifra de jugadors/es i els botons per dur a terme les següents accions: afegir equip, afegir entrenament, editar equip, eliminar equip i veure informació de l’equip 3. El gestor escull una de les accions mitjançant els botons. Curs alternatiu: Cap Veure informació d’un equip Actors: Gestor Objectiu: Visualitzar tota la informació relativa d’un equip en concret. Resum: El gestor veurà tota la informació relativa a l’equip, dies d’entrenament, documentació necessària i components de l’equip. Curs típic d’esdeveniments: 1. El gestor prem el botó de veure informació d’un equip en concret. 2. El sistema mostra una primera taula amb les dades bàsiques de l’equip: nom i categoria. A més a més mostra diferents taules addicionals: una indicant els dies d’entrenament, lloc i hores, una altra amb els documents que requereix la inscripció en aquell equip i una última amb el nom i cognoms dels membres que el conformen i un enllaç a la seva fitxa. Curs alternatiu: Cap 34 Afegir equip Actors: Gestor Objectiu: Donar d’alta un nou equip al sistema Resum: El gestor crearà un nou equip indicant-ne el nom, la categoria i la documentació necessària per la inscripció. Curs típic d’esdeveniments: 1. El gestor prem el botó de crear equip. 2. El sistema mostra un formulari amb dos camps de text per indicar-hi el nom i la categoria de l’equip. També es mostra una taula on s’indica si és necessària o no, per aquell equip, l’entrega de fotografia, dni, targeta sanitària, llicència, drets d’imatge i revisió mèdica. 3. El gestor introdueix la informació requerida i marca quins documents són necessaris. 4. El gestor prem el botó registrar. 5. El sistema crea l’equip Curs alternatiu: 5. Si ja existeix un equip amb aquell nom i categoria es retorna al pas 2. 5. Si al formulari hi falta el nom o la categoria es retorna al pas 2. Afegir entrenament Actors: Gestor Objectiu: Afegir un entrenament a un equip determinat Resum: El gestor emplenarà un formulari per afegir un nou entrenament indicant dia, lloc i hores. Curs típic d’esdeveniments: 1. El gestor prem el botó d’afegir entrenament ja sigui des del llistat d’equips o des de la vista d’informació de l’equip. 2. El sistema mostra un formulari on es requereixen 4 camps de text: dia, hora d’inici, hora de finalització i lloc. 3. El gestor introdueix la informació requerida i prem el botó registrar. 4. El sistema crea el nou entrenament. Curs alternatiu: 4. Si l’hora d’inici és posterior a l’hora de finalització, el sistema mostra un error i es retorna al pas 2. 4. Si al camp dia de la setmana s’introdueix un valor que no és un dia, el sistema mostra un error i es retorna al pas 2. 4. Si no s’introdueix una hora en el format hh:mm o hh:mm:ss, el sistema mostra un error i es retorna al pas 2. 4. Si no s’emplenen tots els camps, el sistema mostra un error i es retorna al pas 2. 35 Eliminar entrenament Actors: Gestor Objectiu: Eliminar un entrenament d’un equip determinat Resum: El gestor eliminarà un entrenament que estava associat a un equip del sistema. Curs típic d’esdeveniments: 1. El gestor prem el botó d’eliminar un entrenament en concret. 2. El sistema eliminarà l’entrenament indicat. Curs alternatiu: Cap Modificar equip Actors: Gestor Objectiu: Modificar la informació bàsica d’un equip Resum: El gestor podrà modificar el nom, la categoria i la documentació necessàries d’un equip. Curs típic d’esdeveniments: 1. El gestor prem el botó de modificar informació d’un equip en concret. 2. El sistema retorna un formulari on ens permet modificar el nom i la categoria de l’equip i una taula on amb tota la documentació possible per indicar si es requisit o no. 3. El gestor fa els canvis pertinents i prem el botó registrar. 4. El sistema guarda les modificacions. Curs alternatiu: 4. Si el nom de l’equip i la categoria ja coincideixen (els dos a la vegada) en un altre equip, es mostra un error i es torna al pas 2. 4. Si es deixa un camp en blanc, es mostra un error i es torna al pas 2. 36 Eliminar equip Actors: Gestor Objectiu: Eliminar un equip existent al sistema Resum: El gestor eliminarà un equip que existia al sistema i aquest es donarà de baixa, conjuntament amb tota la seva informació i entrenaments. Per poder eliminar l’equip ha de tenir 0 jugadors/es assignats. Curs típic d’esdeveniments: 1. El sistema mostra una llista d’equips existents al sistema. 2. El gestor prem el botó d’eliminar l’equip de la llista d’equips que es mostra. 3. El sistema elimina l’equip i tots els seus entrenaments que el conformaven. Curs alternatiu: 2. Si l’equip té jugadors assignats, es mostra un error i es torna al pas 1. Assignar usuari a un equip Actors: Gestor Objectiu: Assignar usuari un equip Resum: El gestor escollirà un conjunt d’usuaris del sistema i els reassignarà a un dels equips existents del sistema. Curs típic d’esdeveniments: 1. El sistema mostra per defecte un llistat dels usuaris que no tenen equip assignat. Mostrarà el seu nom, cognoms i l’estat de la seva inscripció. 2. El gestor, si ho desitja, pot escollir d’un desplegable un dels equips existents i prémer el botó de mostrar dels usuaris d’aquell equip. 3. El sistema actualitza la llista d’usuaris mostrats segons el filtre aplicat. 4. El gestor marca quins usuaris de la llista desitja assignar a un altre equip. 5. El gestor escull l’equip de destí del desplegable d’equips i prem el botó assignar. 6. El sistema reassigna els usuaris marcats a l’equip indicat pel gestor. Curs alternatiu: Cap 37 Veure informació del seu equip Actors: Usuari Objectiu: Visualitzar tota la informació relativa d’un equip en concret. Resum: L’usuari podrà veure part de la informació relativa al seu equip. Curs típic d’esdeveniments: 1. L’usuari prem el botó de veure informació del seu equip. 2. El sistema mostra una primera taula amb les dades bàsiques de l’equip: nom i categoria. A més a més mostra diferents taules addicionals: una indicant els dies d’entrenament, lloc i hores, una altra amb els documents que requereix la inscripció en aquell equip i una última amb el nom i cognoms dels membres que el conformen. Curs alternatiu: Cap 38 Àrea de documentació pública 39 Afegir document públic Actors: Gestor Objectiu: Afegir un document adjunt al sistema Resum: El gestor afegirà un document del seu sistema, li donarà un nom i marcarà si vol que en el moment de crear-lo sigui visible o no cara als usuaris Curs típic d’esdeveniments: 1. El sistema mostra un formulari on es demana el nom de l’arxiu, si vol que sigui visible o no per defecte i un botó per adjuntar un fitxer. 2. El gestor introdueix les dades sol·licitades i prem el botó afegir. 3. El sistema guarda el document. Curs alternatiu: 3. Si el formulari està incomplet es retorna un error. Eliminar document públic Actors: Gestor Objectiu: Eliminar un document públic dels existents al sistema Resum: El gestor eliminarà aquells documents donats d’alta al sistema que ja no necessiti. Curs típic d’esdeveniments: 1. El sistema mostra un llistat dels documents existents. 2. El gestor prem el botó d’eliminar que hi ha al costat del document que desitja eliminar. 3. El sistema elimina el document. Curs alternatiu: Cap Veure documents públics Actors: Gestor Objectiu: Veure tots els documents públics existents i visualitzar-ne un. Resum: El gestor escollirà aquell document d’entre tots els existents per visualitzar-lo. Curs típic d’esdeveniments: 1. El sistema mostra un llistat dels documents existents. 2. El gestor prem el botó de visualitzar que hi ha al costat del document que desitja veure. 3. El sistema mostra el document. Curs alternatiu: Cap 40 Modificar visibilitat d’un document públic Actors: Gestor Objectiu: Modificar la visibilitat d’un document existent al sistema. Resum: El gestor escollirà aquell document d’entre tots els existents per modificar-ne la visibilitat. Si el document no era públic passarà a ser-ho i a l’inrevés. Curs típic d’esdeveniments: 1. El sistema mostra un llistat dels documents existents amb la seva visibilitat. 2. El gestor prem el botó de modificar la visibilitat que hi ha al costat del document escollit. 3. El sistema modifica la visibilitat del document. Curs alternatiu: Cap Veure llistat de documents públics Actors: Usuari Objectiu: Veure tots els documents públics visibles al sistema. Resum: L’usuari podrà veure tots els documents disponibles per a la seva descàrrega Curs típic d’esdeveniments: 1. El sistema mostra un llistat dels documents existents indicant-ne el nom, mida i un botó per descarregar-lo. Curs alternatiu: Cap Visualitzar document públic Actors: Usuari Objectiu: Veure un document públic Resum: L’usuari es descarregarà un descarregarà un dels documents existents al sistema Curs típic d’esdeveniments: 1. L’usuari prem el botó descarregar del costat del document que li interessa del llistat de documents públics. 2. El sistema inicia la descarrega del document. Curs alternatiu: Cap 41 Àrea de material esportiu 48 Àrea de quotes 49 Crear plantilla de quotes Actors: Gestor Objectiu: Crear una plantilla genèrica de quotes Resum: El gestor crearà una plantilla genèrica que posteriorment serà emplenada amb diferents quotes i així poder ser aplicada a múltiples usuaris. Curs típic d’esdeveniments: 1. El sistema mostra un formulari on es demana el nom de la plantilla. 2. El gestor introdueix el nom de la plantilla i prem el botó d’afegir. 3. El sistema crea una plantilla nova sense cap quota. Curs alternatiu: Cap Afegir quota a plantilla Actors: Gestor Objectiu: Incorporar una quota a una plantilla ja existent. Resum: El gestor afegirà una nova quota genèrica a una plantilla creada amb anterioritat. Curs típic d’esdeveniments: 1. El sistema mostra un llistat amb totes les plantilles existents. 2. El gestor prem el botó d’afegir quota al costat de la plantilla desitjada. 3. El sistema mostra un formulari on es demana concepte, import i data de la quota. 4. El gestor introdueix totes les dades requerides. 5. El sistema crea una nova quota predefinida i la vincula a la plantilla indicada anteriorment. Curs alternatiu: Cap 50 Eliminar quota de plantilla Actors: Gestor Objectiu: Eliminar una quota d’una plantilla ja existent Resum: El gestor eliminarà una quota d’entre totes les que té assignades una plantilla de quotes predefinides. Curs típic d’esdeveniments: 1. El sistema mostra un llistat amb totes les plantilles existents. 2. El gestor prem el botó d’eliminar quota al costat de la plantilla desitjada. 3. El sistema mostra un llistat amb totes les quotes associades a la plantilla. 4. El gestor prem el botó d’eliminar al costat de la quota que vol eliminar. 5. El sistema elimina la quota. Curs alternatiu: Cap Eliminar plantilla de quotes Actors: Gestor Objectiu: Eliminar una plantilla de quotes predefinides Resum: El gestor eliminarà una plantilla sencera de quotes amb totes les quotes que contingui aquesta. Curs típic d’esdeveniments: 1. El sistema mostra un llistat amb totes les plantilles existents. 2. El gestor marca quines plantilles de quotes vol eliminar i prem el botó eliminar. 3. El sistema elimina les plantilles de quotes indicades. Curs alternatiu: Cap 51 Assignar plantilla de quotes a usuari Actors: Gestor Objectiu: Assignar una plantilla de quotes a un o varis usuaris Resum: El gestor crearà a cada usuari seleccionat una còpia de les quotes que contingui la plantilla de quotes predefinides. Curs típic d’esdeveniments: 1. El sistema mostra una taula amb el nom, cognoms, equip i estat de tots els usuaris existents. 2. El gestor marca tots els usuaris als quals vol aplicar una plantilla de quotes i escull una de les plantilles creades del desplegable. Finalment prem el botó aplicar. 3. El sistema crea una còpia de cada quota que conté la plantilla a tots els usuaris que s’han seleccionat i hi posa l’estat “Pendent de cobrament”. Curs alternatiu: 2. El gestor escull un equip del desplegable i prem el botó filtrar. 3. El sistema només mostra els usuaris d’aquell equip. Tornar al pas 2. Veure quotes dels usuaris Actors: Gestor Objectiu: Visualitzar les quotes d’un usuari en concret Resum: El gestor visualitzarà un resum de les quotes d’un usuari en concret. Curs típic d’esdeveniments: 1. El gestor prem el botó de veure quotes des del perfil d’un usuari en concret. 2. El sistema mostra una taula amb totes les quotes de l’usuari indicant-ne data, concepte, quantitat i estat de cobrament de la quota. Curs alternatiu: Cap 52 Modificar estat d’una quota Actors: Gestor Objectiu: Modificar l’estat d’una quota Resum: El gestor canviarà l’estat d’un conjunt de quotes d’entre els estats disponibles. Curs típic d’esdeveniments: 1. El sistema mostra una taula amb el nom, cognoms, equip i estat de tots els usuaris existents. 2. El gestor marca tots els usuaris als quals vol modificar l’estat i escull un dels estats del desplegable. Finalment prem el botó modificar. 3. El sistema modificarà l’estat de les quotes assignades assignant l’escollit del desplegable d’estats. Curs alternatiu: 2. El gestor pot escollir un equip, un mes o un estat i filtrar els resultats segons el criteri seleccionat prement el botó filtrar. 3. El sistema només mostra els usuaris que compleixin el criteri indicat. Tornar al pas 2. Veure quotes pròpies Actors: Usuari Objectiu: Visualitzar les quotes pròpies Resum: L’usuari visualitzarà un resum de les quotes seves. Curs típic d’esdeveniments: 1. El sistema mostra una taula amb totes les quotes de l’usuari indicant-ne data, concepte, quantitat i estat de cobrament de la quota. Curs alternatiu: Cap 53 Diagrama de clases El següent esquema mostra la primera versió del diagrama de classes. Aquest esquema ens serveix primer de tot per fer-nos una idea global de com serà la base de dades i per tenir un punt de partida sobre el qual començar a implementar el sistema. 54 Disseny En aquest apartat s’explicaran els diferents criteris que s’han tingut en compte a l’hora de desenvolupar el projecte. Cal recordar, que com a requisits no funcionals es va establir que l’aplicació hauria de complir almenys els següents:  Disponibilitat  Portabilitat  Cost  Escalabilitat  Facilitat d’ús Arquitectura Com ja s’ha comentat en anteriors apartats s’optarà per una aplicació web enfront d’una aplicació d’escriptori. En aquest tipus d’aplicacions, l’aplicació es troba allotjada en un servidor i els usuaris per accedir-hi només necessiten un navegador web. Aquest servidor rep totes les peticions per part dels usuaris i s’envia la resposta en forma de pàgina web a l’usuari que ha dut a terme la petició. Els avantatges que aquesta arquitectura ens dóna envers una aplicació d’escriptori són entre d’altres els següents:  Reducció dels requeriments de l’equip de l’usuari: L’arquitectura web no demana a l’usuari que instal·li cap programa addicional, es limita a demanar un navegador web, software que avui en dia tots els equips disposen.  Reducció dels problemes de configuració: Lligat al punt anterior, en no necessitar-se la instal·lació de cap software els típics problemes que alguns usuaris poden tenir a l’hora de configurar el sistema es redueixen considerablement.  Eliminació de la duplicitat de dades: Amb una aplicació d’escriptori es genera una dependència a l’hora de disposar de les dades de l’usuari. L’aplicació es pot fer servir sense disposar de connexió i a la llarga això pot generar incongruències o una falta d’unificació.  Facilitat d’actualitzar: Les actualitzacions de l’aplicació es duen a terme al costat del servidor de manera que sempre que l’usuari vulgui accedir-hi haurà de cursar una petició i per tant tindrem la certesa que s’està accedint a una versió actualitzada. Amb una aplicació d’escriptori pot donar-se el cas que un usuari estigui fent servir una versió anterior i això generi problemes. 55 La imatge superior ens mostra com quedaria l’arquitectura del sistema. Per una banda tenim el servidor i de l’altra els diferents usuaris del sistema (es representen amb icones diferents per remarcar que no cal una uniformitat de la banda de l’usuari, simplement accés a internet). El flux d’ús en aquest cas com s’ha comentat abans és el d’un usuari que envia una petició a través d’internet fins al servidor, aquest rep la petició, la processa i genera una resposta que també s’envia a través del servidor a l’usuari inicial. Servidor Internet Usuaris del sistema Recepció de peticions i enviament de respostes 56 El patró Model – Vista – Controlador (MVC) Una altra de les decisions preses en aquesta etapa de disseny és la d’emprar el model d’arquitectura de software Model – Vista – Controlador. L’ús d’un patró ens reporta diferents avantatges per exemple s’afavoreix el manteniment de l’aplicació i la reutilització de codi degut a que l’aplicació queda dividida en tres parts. A més a més, com que tot el codi queda ben organitzat i estructurat les possibilitats de cometre errors són més baixes, i en cas de cometre’n un, és més fàcil de localitzar. Com hem dit i el seu nom indica, aquest model divideix l’aplicació en 3 parts que són les següents:  Model: És la representació de la informació amb la que el sistema treballa. Per tant és l’encarregada de gestionar tots els accessos que s’hi fan, ja siguin consultes o actualitzacions.  Controlador: Aquesta capa és la que dona resposta als esdeveniments que es produeixen al sistema.  Vista: És la capa que presenta la informació del model en un format adequat perquè l’usuari hi interactuï. Model Vista Usuari Controlador 57 Com podem veure a l’esquema anterior, s’estableix un flux de treball entre les tres capes del model i l’usuari: L’usuari típicament interactua amb la interfície i les seves accions generen un esdeveniment que rep el controlador. Aquest, a través d’un gestor d’esdeveniment gestiona la notificació que acaba de rebre accedint al model i duent a terme l’acció que desencadena la decisió de l’usuari. Un cop fet això la vista rep per part del model la informació necessària per actualitzar el que s’està mostrant i que sigui intel·ligible per part de l’usuari. Si bé aquest flux explicat és el que típicament s’esdevé, també es poden establir altres relacions entre capes com per exemple que l’acció de l’usuari demani un canvi només en la forma en que es mostra la informació de manera que es produirà una acció del controlador cap a la vista, ometent el model. 64 Implementació Procés d’implementació En aquest apartat s’intentarà fer un recorregut per veure com les diferents tecnologies principals (Google App Engine, Django i Twitter Bootstrap) s’integren entre sí per acabar conformant l’aplicació plantejada en etapes anteriors. No és objecte d’aquesta secció fer-ne una explicació detallada donat que les fons d’informació són abundants, però sí donar unes una mirada en certa profunditat. Partirem de Django intentant veure com s’estructura i com Twitter Bootstrap s’integra en ell per complementar-lo. Finalment veurem com tot això s’acaba allotjant a Google App Engine. Assumim que ja s’ha fet una instal·lació de Python i creat el nostre projecte basat en Django, així que ens centrarem en explicar els seus arxius més importants i com aquests es relacionen entre ells. En aquesta imatge podem veure el nivell més alt de l’estructura de fitxers del nostre projecte. Les dues carpetes a les que més hi accedirem són portal (que és com hem anomenat la nostra aplicació i per tant variarà d’un projecte a un altre) i la carpeta templates. Destacar que ens podem trobar que no totes les carpetes ens apareguin 65 degut a que algunes són mòduls afegits posteriorment com PIL que és el Python Imaging Library. Centrem-nos però en la carpeta portal i mirem-ne el seu contingut. El primer arxiu a comentar és el models.py, aquest arxiu és on s’hi ha d’indicar les diferents classes que volem que la nostra aplicació tingui. Podem veure’n un exemple tot seguit, en concret de UserProfile. 66 Podem veure com els camps que vam definir s’han anat indicant fent ús de la classe models i indicant-ne les diferents opcions que se’n volen especificar com longitud màxima, si pot estar buit o ser nul o directori on s’allotjarà en el cas de l’arxiu. Com a curiositat destacar que no hi apareixen tots els camps definits (nom, cognoms o password per exemple) ja que s’ha aprofitat la classe user que ja ve implementada pel propi Django i per tant ens estalvia feina. El següent arxiu a comentar és l’arxiu forms.py. En aquest arxiu s’hi ha d’indicar tots els formularis vinculats als models que farà ús la nostra aplicació. Vegem-ne una imatge que serà més fàcil d’entendre. 67 En aquesta part del codi podem veure com es defineix primer un formulari basat en la classe usuari i s’especifica que s’hi haurà d’indicar username, email, first_name i last_name. Volem destacar que aquest formulari no indica que el password sigui necessari. Això és degut a que quan es dugui a terme el registre d’un usuari (moment en que fem servir aquest formulari) el password es genera automàticament per part de l’aplicació i per tant l’usuari no l’introdueix i no ens serà necessari quan fem la validació automàtica dels formularis. Posteriorment veiem un altre formulari anomenat UserEditForm on aquí ja no hi apareix username. Aquest fet agafa sentit si tenim en compte que el nom d’usuari és un element que no volem que es canviï per part de l’usuari. Tot seguit ens centrem en l’url.py. Aquest arxiu serveix per indicar-hi tots els patrons d’urls que volem que la nostra aplicació tingui. Quan s’escriu una url es revisen tots els patrons per veure si es pot fer match. En cas contrari es retornarà un error. Com podem veure se’ns mostra part de les urls de l’aplicació. El primer paràmetre de la funció url() és el patró en sí de l’url, és aquí on s’hi indica el format que volem que segueixi l’url o els paràmetres que s’hi passaran (id o pk a la imatge per exemple). Tot seguit es referencia una classe de l’arxiu views.py i finalment s’hi indica un nom que per facilitat és el mateix que la classe del views.py. 68 Seguim doncs analitzant l’arxiu que acabem de referenciar el views.py. En l’exemple podrem veure la implementació de la visa de login de l’aplicació i en comentarem algun aspecte destacat. Primer de tot veiem que abans de la definició de la vista s’hi indica @anonymous_required, això ens indica quins tipus de permisos cal per poder accedir a la pàgina, en aquesta cas un usuari que no ha fet login encara. Exemples d’altres permisos són @login_required o fer passar un test a l’usuari amb @user_passes_test(), passant el test com a paràmetre de la funció i que en serviria per exemple per comprovar si l’usuari és super usuari (útil per les vistes exclusives del rol gestor). Posteriorment es defineix un diccionari del context on s’hi incorporen tota la informació que posteriorment voldrem que la vista mostri procedent de la capa del Model (context_dict). A partir d’aquest moment mitjançant l’if comprovarem si la crida de la vista és post o no. Si no ho simplement indiquem quin és el template que farem servir (línia 46 de la imatge superior). En cas contrari intentem el login, si és satisfactori podem cridem una altra url (línia 37) i si incorporem al context_dict l’error que s’ha produït perquè es mostri posteriorment a l’usuari. La següent imatge ens mostra un aspecte no vist anteriorment del views.py que és fer una consulta de certa informació. Ho podem veure a les línies 331 i 333 on es crida respectivament a la classe User i UserProfile i es fa un get indicant la condició que l’objecte que se’ns retornarà ha de complir: username que prové del context ha de ser 69 igual a l’username guardat al model. En cas que el resultat fos un conjunt d’objectes s’hauria de fer un filtre en lloc d’un get. Finalment destacar del views.py que s’ha de d’incloure a les definicions tots els models, formularis o altres llibreries que anem a fer servir. Abans d’analitzar els templates que hem anomenat anteriorment és interessant comentar dos arxius més d’aquest directori: admin.py i dbindexes.py. El primer d’ells ens servirà per indicar tots els models que volem que apareguin des del panell d’administració que automàticament Django instal·la. Per fer-ho serà tant simple com especificar el model i quins camps han d’aparèixer tal i com mostra la imatge següent. 70 Com veiem s’especifica cada classe i amb list_display els valors que es mostraran. En cas de voler mostrar una clau externa al model ho femt mitjançant els def indicats al final de la classe. Per últim registrem cada classe definida en aquest document amb el model en qüestió perquè se’ns mostri a la pantalla d’administració. 71 El resultat obtingut seria el següent: I aquí un detall de com seria la visualització dels objectes que pertanyen a un model en concret. L’altre arxiu que calia esmentar és el dbindexes.py. Aquest arxiu és una conseqüència de fer servir Django NonRel i ens obliga a indicar-hi totes les claus externes als models si volem que es mantingui la consistència amb els models definits a l’etapa de disseny. 72 En aquest arxiu hi ha poca cosa a comentar, simplement es registra model a model els camps que són claus externes. Arribat aquest punt, és el moment d’analitzar com s’organitzen els templates a Django. En el nostre cas els tenim al directori templates/portal/ i hi trobarem un arxiu html per cada template indicat al views.py. 73 A més a més de tot això, s’ha creat un template que funciona com a base per la resta de templates i és el que ens servirà per estructura la interfície de tota l’aplicació. Des d’aquest arxiu també farem l’include de tots els arxius que pertanyen al Twitter Bootstrap: També aprofitarem per definir-hi la navbar que és comuna a tota l’aplicació: És interessant observar que aquí ja aprofitem per indicar quines parts del barra de navegació es mostraran a tots els usuaris i quines exclusivament als gestors. Per últim tenim una part on ja dividim l’estructura de 12 columnes del Twitter Bootstrap segons la distribució que ens interessi i hi definim uns blocs que seran emplenats a cada template segons pertoqui. Com es veu a la imatge següent hem tres blocs: un d’amplada de 12 columnes anomenat navigation i just a sota dos blocs més left_block d’amplada 2 i body_block d’amplada 10. Aquest fet no limita a que posteriorment cada template opti per subdividir els diferents blocs en d’altres subblocs però si que ens assegura que tots els templates que heretin del base.html mantindran aquesta estructura. 80 Àrea de documentació pública Aquesta àrea es divideix en dos parts, la primera de totes la que permet a qualsevol usuari accedir i des de la qual poden descarregar documents que s’han posat a la seva disposició. D’aquesta manera els usuaris poden obtenir aquells documents que se’ls requereixen en el procés d’inscripció i emplenar-los. A la part privada d’aquesta àrea el gestor pot dur a terme la gestió dels documents que posarà a la disposició dels usuaris. Se’ns mostra una taula amb tots els documents estiguin publicats o no, permetent-nos visualitzar-los, eliminar-los o modificar la seva visibilitat. Per últim la finestra per afegir un document on simplement se’ns demana un nom, l’arxiu a adjuntar i si volem que inicialment estigui visible o no. 81 Àrea d’equips L’àrea d’equips es basa en dos grans zones, la primera permet totes les accions relacionades amb els equips. Aquí podem observar el llistat de tots els equips amb la seva categoria, el seu nom i quants jugadors el conformen. Cada equip té 4 botons associats que permeten editar l’equip, visualitzar-lo en detall, afegir-hi entrenaments o eliminar-lo. En cas d’afegir un equip simplement cal indicar la seva categoria, el seu nom i marcar quins documents seran necessaris. 82 A la finestra del perfil de l’equip s’ha optat per mantenir l’estructura de caixes de la resta de l’aplicació i agrupar la informació per grups. Així, primer se’ns mostra les dades de l’equip, després els entrenaments amb l’opció d’eliminar-ne o afegir-ne i tot seguit un llistat dels jugadors amb accés als seus perfils. A la banda dreta s’ha optat per situar-hi el resum de la documentació que es requereix per aquest equip en concret. L’altra part important d’aquesta àrea és la gestió dels jugadors, o dit d’una altra manera com els jugadors s’assignen a un equip o un altre o se’ls hi valida la inscripció. 83 Això ho podem veure a la següent imatge: Des d’aquesta finestra disposem d’un desplegable amb tots els equips del sistema, aquest el farem servir per escollir quin equip volem mostrar tot prement el botó de filtrar. Un cop fet això podem escollir els usuaris que ens interessin clicant la casella al costat del seu nom i assignant-los a l’equip marcat al desplegable o bé validar la inscripció. També és interessant observar en aquesta imatge com els usuaris mostren els diferents estats d’inscripció, en aquesta cas “Falta documentació”, “Pendent de revisió” i “Validada”. 84 Àrea de material esportiu L’àrea del material esportiu pivota al voltant de dos grans eixos. Per part de l’usuari no deixa de ser més que una botiga on hi pot adquirir els productes que l’entitat posa a la seva disposició i per part del gestor apareixen dos subparts: la primera abans de la compra de l’usuari i que significa la gestió de tots els productes que es podran adquirir i per l’altra el post-compra i tot el procés de seguiment fins que s’entrega. En aquesta vista s’ha optat per donar prioritat a la imatge del producte per sobre de la resta. D’aquesta manera se’ns mostra una graella amb tots els productes existents, estiguin disponibles o no conjuntament amb el preu i el nom del producte. S’ha considerat que aquestes eren les dades essencials i que en cas que un usuari estigui interessat en el producte podrà visualitzar la resta des de la fitxa del producte. Malgrat que inicialment per accedir a la fitxa del producte es feia clicant al nom o al botó de “Més info” es va veure que una part dels usuaris tendien a intentar clicar a la imatge per tant es va optar per dotar d’un enllaç també a la imatge. 85 La fitxa del producte segueix una estructura similar a d’altres parts de l’aplicació com el perfil d’usuari: informació al bloc central i imatge al bloc de la dreta. Al contrari de la pàgina inicial de la botiga ara ja se’ns mostra la descripció completa del producte, mètode de pagament i informació addicional de pagament com també totes les talles disponibles del producte. Com que les talles del producte són objectes i no una simple cadena de text (a l’apartat de futures millores es justifica aquesta decisió) ha calgut un procés d’ordenació de totes les talles afegides segons l’ordenació habitual: 2-4-6-8-10-12-14-16-3XS-2XS-XS-S-M-L-XL-2XL-3XL-4XL-Única Si s’afegís qualsevol talla que no formés part d’aquesta opcions es mostraria al final. Un cop l’usuari es decideix a fer la compra se’ns mostrarà la pantalla per escollir la talla i finalitzar la compra. 86 Un cop adquirit ens retornarà a la pàgina inicial i s’haurà creat la comanda corresponent. Tots aquests productes que ens apareixen s’afegeixen, com hem dit per part del gestor: En aquesta pantalla se’ns mostra un llistat, amb els mateixos productes que a la botiga, però enfocat a la informació que necessita el gestor: la visualització atractiva dels productes via imatge perd pes per mostrar altres dades com l’inici de la descripció o el mètode de pagament. Des d’aquesta pantalla podrem accedir a les opcions per afegir un nou producte, una nova talla, editar o eliminar el producte. 87 Per afegir un producte com veiem simplement emplenem el formulari, escollim un mètode de pagament del desplegable (transferència, efectiu o domiciliació) i adjuntem una imatge que representi el producte. Per defecte el nou producte estarà disponible, en cas que no es volgués des de la finestra d’edició del producte es pot canviar aquesta opció. La pota del gestor que ens queda és les accions post-comanda. Tot això es pot dur a terme des de la vista de gestió de comandes. Des d’aquesta finestra bàsicament la feina a realitzar és modificar l’estat d’un producte o, excepcionalment, eliminar una comanda. Per facilitar aquesta tasca per defecte es mostren totes les comandes fetes fins al moment ordenades per data i s’ofereix l’opció de filtrar les comandes segons l’equip de l’usuari o el producte que s’ha encomanat. 88 Àrea de quotes Acabem el repàs a les diferents àrees fent una ullada a la zona per gestionar les quotes. Abans però de centrar-nos en les quotes pròpiament farem una breu explicació de en què consisteix el sistema de plantilles de quotes. En una entitat esportiva s’acostuma a establir quotes en funció de categories, és a dir la quota pot variar segons l’edat, els dies d’activitat, si es disputen o no partits, si es tenen germans, etc. Això fa que a cada usuari se li apliqui un conjunt de quotes diferent però que a l’hora de la veritat sigui compartida per més d’un usuari. Centremnos en l’exemple de l’entitat i ho entendrem més fàcilment. Categoria Quota Dies d’act. Equips Pagaments Psicomotricitat 200€ 2 1 3 Psicomotricitat 2n Germà 180€ 2 1 3 Premini i Escola 230€ 2 4 3 Premini i Escola 2n Germà 207€ 2 4 3 Mini-Cadet 270€ 3 7 3 Mini-Cadet 2n Germà 243€ 3 7 3 Sènior Femení 120€ 1 1 2 Sènior Masculí A 300€ 3 1 3 Sènior Masculí B 400€ 2 1 3 Veiem que en alguns casos la divisió de quotes que s’empra pertany exclusivament a un equip (Sèniors), en canvi hi ha d’altres on s’hi assignen fins a 7 equips de l’entitat. D’altra banda cada quota és duplicada donat que als germans se’ls hi fa un descompte del 10%. Per tot això s’ha optat per crear un sistema de plantilles de quotes de manera que un cop està creat només s’ha d’anar assignant (generar una còpia) als diferents usuaris segons les seves característiques. La creació d’una plantilla és simplement assignar-li un nom i la part important és totes les diferents quotes que s’assignen a cada plantilla. 89 Com podem veure en aquest exemple la plantilla de quotes del Sènior Masculí A la conformen 3 quotes per valor de 100€ cadascuna que es cobren a l’octubre, desembre i febrer. Totes aquestes plantilles s’assignen des d’una vista específica on filtrem els usuaris mostrats segons els equips, escollim aquells a qui volem aplicar una quota i des del desplegable amb les plantilles creades n’escollim una i premem aplicar. Finalment tots aquestes quotes es gestionen des d’una vista que té dos funcionalitats bàsiques: primer de tot servir com a eina de consulta i control de les quotes que s’han de domiciliar cada mes i segon per anar actualitzant els estats de cobrament i que l’usuari pugui fer-se una idea de la seva situació. 96 Estadístiques d’ús En aquest apartat s’analitzarà l’activitat dels 198 usuaris registrats a finals de desembre durant els aproximadament 6 mesos d’activitat (del 10 de juny al 28 de desembre de 2014). Després, i durant, el període de testeig un dels aspectes importants a tenir en compte és fer un anàlisi de les dades d’ús que disposem. En aquest aspecte Google App Engine ens ofereix 29 paràmetres (25 a l’inici de les proves) que ens permeten monitoritzar els recursos que es van consumint. Aquest anàlisi ens servirà més endavant per establir una proposta de model de negoci. Com recordarem cada paràmetre té una quota diària i en cas que s’excedeixi aquesta quota l’aplicació queda inaccessible fins a l’endemà. Abans de centrar-nos en l’anàlisi pròpiament dit, la intuïció ens diu que alguns d’ells seran rellevants i d’altres no ens n’haurem de preocupar. Amb una simple observació ens adonem que n’hi ha alguns d’ells que Google App Engine no ens ofereix quota gratuïta, per tant el seu ús sempre serà 0. Aquesta paràmetres els podem obviar completament de l’anàlisi i són el següents:  Discounted Instance Hour  Dedicated Memcache  PageSpeed Out Bandwidth  SSL VIPs  SSL SNI Certificates Després hi ha aquells paràmetres on l’aplicació no en fa ús:  Backend Instance Hours  Datastore Mobile Storage  Taskqueue Storage  Datastore Mobile Writes  Datastore Mobile Reads  Small Datastore Mobile Operations  XMPP Stanzas  Opened Channels  Logs Read Bandwidth  Other Search Ops  Search Document Indexing  Search Document Storage  Complex Searches  Simple Searches 97 Arribat a aquest punt només queden 10 de 29 paràmetres que són els que, en menor o major mesura ens serviran per fer-nos una idea de l’ús global de l’aplicació. Un dels aspectes a que més es fa referència quan es busca informació sobre les quotes gratuïtes de Google App Engine és el volum de Frontend Hours. Per defecte la quota gratuïta és de 28 hores, tenint en compte que el dia és de 24 sembla que aquest element no ens hauria de preocupar. De totes maneres analitzem-lo una mica més detingudament. La idea darrere el funcionament de les Frontend Hours és que cada vegada que arriba una petició a la nostra aplicació es consumiran com a mínim 0,15 hores. Durant aquest temps cada petició que arribi serà assignada a la mateixa instància i només en cas que la cua de la instància en execució superi un temps determinat (es pot escollir aquest temps) es crearà una segona instància i per tant un consum extra de 0,15h com a mínim. Aquest procés doncs si es va allargant en el temps pot fer que arribat un moment es consumeixin les 28hores disponibles en una fracció mol reduïda de temps. Ara bé, de manera que podem triar quin tipus de modalitat escollim (a més memòria i processador es multiplicarà el valor de 0,15), podem escollir el temps màxim que ha d’esperar una petició abans de crear una nova instància i, evidentment, el nombre màxim d’instàncies que volem “oferir”. Tot això és pot configurar des de l’opció de configuració del dashboard de Google App Engine. 98 Aquesta que veiem aquí és la configuració que s’ha escollit. En aquest cas de les 4 classes disponibles per les instàncies, s’ha escollit la primera:  F1 (600 MHz, 128MB)  F2 (1200MHz, 256MB)  F4 (2400MHz, 512MB)  F4_1G (2400MHz. 1024MB) Això s’ha fet perquè aquesta és l’única que ens garantia una disponibilitat ja que cada classe superior que s’agafa duplica per 2 el consum d’hores, de manera que agafar F2 ens reduiria de 28h a 14h en el pitjor dels casos la disponibilitat de l’aplicació. El segon i tercer paràmetres van lligats en certa manera. S’ha escollit com a màxim 1 instància sense funcionament, el motiu en aquest cas és el mateix que anteriorment s’ha comentat, assegurar una disponibilitat 24hores al dia mantenint-se dins la quota gratuïta. En el cas del tercer per la configuració escollida no afecta perquè ens permet escollir el temps a esperar abans d’activar la següent instància però tenim en compte que només en permetem 1 no val la pena. Amb aquesta configuració observem doncs, en el gràfic de la pàgina següent, quin ha estat el comportament al llarg dels sis primers mesos de funcionament de l’aplicació. Tot seguit detallem els valors i dades més rellevants, les dades completes es poden veure a l’annex final al document. Primer de tot es poden veure pics en l’ús de l’aplicació durant els últims dies de juny. En aquest cas això s’entèn ja que moltes famílies esperaven a l’últim divendres (27 de juny) en que el club feia el servei de secretaria per fer la inscripció i també per l’efecte novetat. D’altra banda cap als volts del 22 de juliol hi ha un segon augment d’activitat ja que aquesta data era la que inicialment s’havia establert per entregar tota la documentació amb la reducció de quota, si bé després es va prorrogar 7 dies més degut a que l’Ajuntament no havia lliurat els horaris de la temporada següent aspecte determinant per moltes famílies. Finalment s’observa un augment notable en l’ús durant tot el mes de setembre, moltes famílies esperen sempre a última hora i quan se’ls fa el recordatori indicant que sense documentació no hi ha ni activitat ni competició llavors formalitzen la inscripció. De totes maneres s’observa que el valor màxim d’hores consumit està en 13,73 durant el juny i el mes amb un ús més intensiu és el setembre amb una mitjana diaria de 7,84. En el global del període el consum d’hores és de 3,77. Per tant podem concloure que l’ús és bastant baix i que hi ha cert marge per activar més instàncies en moments de previsió d’alta demanda sense que això suposi un cost extra. 99 0,00 5,00 10,00 15,00 20,00 25,00 30,00 10/06 17/06 24/06 01/07 08/07 15/07 22/07 29/07 05/08 12/08 19/08 26/08 02/09 09/09 16/09 23/09 30/09 07/10 14/10 21/10 28/10 04/11 11/11 18/11 25/11 02/12 09/12 16/12 23/12 Hores Frontend Instance Hours Valor Mitjana Mitjana Mensual Màx Límit 100 Un altre dels paràmetres a tenir en compte és el volum de lectures que es fa del DataStore (Datastore Reads). Les lectures al Datastore inclouen per una banda totes les dades que emmagatzemem (noms d’usuaris, emails, adreces, etc.) com el Blobstore (Fitxers adjunts, fotografies). Com podrem veure tot seguit aquest aspecte és l’únic que va causar que l’aplicació excedís els límits gratuïts i per tant l’aplicació no estigués disponible durant unes hores. En concret se’ns permeten un total de 0.05 milions d’operacions diàries i a la següent taula s’indiquen els dies on s’ha assolit una xifra més alta: Dia Milions d’operacions 05/10 0.06 22/07 0.04 17/09 0.04 La resta de dies no s’ha superat en cap els 0.02 milions de lectures al Datastore. Per la pròpia experiència de l’ús i la naturalesa ens vam adonar amb l’entitat que aquestes tres dates no eren casuals si no que venien determinades per un ús intensiu per part dels gestors. En concret la primera data en ordre cronològic es tractava del 22 de juliol el dia després de la data límit per gaudir del descompte en la quota marcat pel club. Aquell dia es va fer una revisió dels documents que havien entregat els usuaris amb la inscripció en pendent de revisió per comprovar que eren els correctes. D’altra banda les dues altres dates coincidien amb dates on el club havia estat accedint a la documentació dels jugadors per guardar-la i tramitar la llicència a la federació. Per tant, amb un ús diari per part dels usuaris no s’intuïen problemes per superar el límit si bé s’havia de tenir en compte quan els gestors haguessin de dur a terme un gran volum d’activitat. D’altra banda si ens aturem a analitzar les escriptures enlloc de les lectures al Datastore, intuïtivament podem pensar que ha de suposar encara menys problemes. Primer de tot perquè la xifra límit es situa també en els 0.05 milions d’operacions i donat que la tendència general, i en aquesta aplicació també es compleix, és que es facin més lectures que escriptures observem que mai es supera aquesta xifra i que la mitjana d’escriptures es situa per sota de la de lectures. (17% del límit d’escriptures per 20% de lectures) 101 0,00 0,01 0,02 0,03 0,04 0,05 0,06 0,07 10/06 17/06 24/06 01/07 08/07 15/07 22/07 29/07 05/08 12/08 19/08 26/08 02/09 09/09 16/09 23/09 30/09 07/10 14/10 21/10 28/10 04/11 11/11 18/11 25/11 02/12 09/12 16/12 23/12 Milions d'operacions DataStore Reads Valor Mitjana Mitjana Mensual Màx Límit 0,00 0,01 0,02 0,03 0,04 0,05 0,06 10/06 17/06 24/06 01/07 08/07 15/07 22/07 29/07 05/08 12/08 19/08 26/08 02/09 09/09 16/09 23/09 30/09 07/10 14/10 21/10 28/10 04/11 11/11 18/11 25/11 02/12 09/12 16/12 23/12 Milions d'operacions DataStore Writes Valor Mitjana Mitjana Mensual Màx Límit 102 També s’ha de tenir en compte l’ample de banda enviat per l’aplicació per respondre les peticions dels usuaris. En aquest punt disposem d’1GB diari i com podem extreure de les estadístiques en el dia de més demanda es va fer ús d’uns 120MB xifra bastant allunyada del límit establert, situant-se la mitjana al voltant d’uns 17MB diaris. Un aspecte que s’ha de tenir molt en compte és la xifra de correus electrònics que l’aplicació envia. Aquesta xifra recordem que està fixada en un màxim de 100 diaris i que l’aplicació n’envia un cada vegada que es fa un registre d’un usuari i cada vegada que una comanda passa a estar en estat “pendent de recollir”. Això ja es va tenir en compte a l’hora, sobretot, de fer els registre si bé el màxim que es va assolir va ser de 51 en un dia i la mitjana és de 1,3 correus electrònics enviats al dia. Tot seguit ens centrarem en l’emmagatzematge tant del Datastore com del Blobstore. Se’ns ha assignat un total de 1GB i 5GB respectivament i l’ús que se’n farà d’aquests dos Store anirà augmentant al llarg de la temporada, sobretot a l’inici d’aquesta i quan arribi el final patirà un descens amb l’eliminació d’informació que s’ha de renovar cara a l’inici de la següent (especialment el Blobstore). En aquest punt no té sentit mirar quina és la mitjana d’ús, ja que com hem dit l’ús és creixent i per tant ens centrem exclusivament en la xifra màxima que evidentment es troba en l’últim dia on disposem d’estadístiques. En el cas del Datastore se’n fa ús en un 2%, per tant 20MB i del Blobstore un 6% per tant, uns 300MB. Ambdues xifres també estan molt allunyades del límit i no suposen una preocupació. Per acabar comentar molt per sobre el volum del codi de l’aplicació que ocupa al voltant d’uns 40MB del total d’1GB que disposem i els registres que genera el propi Google App Engine i que tant sols arriba a l’1% del 1GB que també disposem. 103 0,00 0,02 0,04 0,06 0,08 0,10 0,12 0,14 10/06 17/06 24/06 01/07 08/07 15/07 22/07 29/07 05/08 12/08 19/08 26/08 02/09 09/09 16/09 23/09 30/09 07/10 14/10 21/10 28/10 04/11 11/11 18/11 25/11 02/12 09/12 16/12 23/12 GB Bandwidth Out Valor Mitjana Mitjana Mensual Màx 0,00 0,20 0,40 0,60 0,80 1,00 1,20 10/06 17/06 24/06 01/07 08/07 15/07 22/07 29/07 05/08 12/08 19/08 26/08 02/09 09/09 16/09 23/09 30/09 07/10 14/10 21/10 28/10 04/11 11/11 18/11 25/11 02/12 09/12 16/12 23/12 Volum Emails enviats Valor Mitjana Mitjana Mensual Màx Límit 104 0,00 0,05 0,10 0,15 0,20 0,25 0,30 0,35 10/06 17/06 24/06 01/07 08/07 15/07 22/07 29/07 05/08 12/08 19/08 26/08 02/09 09/09 16/09 23/09 30/09 07/10 14/10 21/10 28/10 04/11 11/11 18/11 25/11 02/12 09/12 16/12 23/12 GB Blobstore Storage Valor Mitjana Mitjana Mensual Màx 0,000 0,005 0,010 0,015 0,020 0,025 10/06 17/06 24/06 01/07 08/07 15/07 22/07 29/07 05/08 12/08 19/08 26/08 02/09 09/09 16/09 23/09 30/09 07/10 14/10 21/10 28/10 04/11 11/11 18/11 25/11 02/12 09/12 16/12 23/12 GB Datastore Storage Valor Màx 105 Aportacions dels usuaris Un dels aspectes que es va tenir en compte durant tot el desenvolupament de la planificació va ser aprofitar les proves reals que es durien a terme per recollir i copsar opinions dels usuaris per millorar l’aplicació. És per això que es va preveure una iteració que es centraria exclusivament en aquest aspecte. Tot seguit detallem algunes de les demandes principals que van fer els usuaris (tant jugadors com gestors de l’entitat). Algunes d’elles es van considerar prioritàries i per tant es van implementar d’altres en tractar-se de funcionalitats majors s’ha decidit deixar-les per més endavant.  Canvi de la contrasenya: Inicialment no estava previst si bé durant el desenvolupament i per part dels membres de l’entitat es va suggerir que l’usuari pogués canviar la contrasenya generada inicialment per la pròpia aplicació.  Reinici de la contrasenya: Es va detectar també una demanda relativament alta d’usuaris que oblidaven la seva contrasenya. En aquest punt també es va optar per afegir la funcionalitat i evitar reinicis manuals i que després fos el propi usuari qui la modifiqués de nou.  Pantalla d’edició del perfil: Un altre aspecte a tenir en compte va ser que alguns usuaris no tenien clar quins documents calia entregar i quins no, per tot això es va modificar la taula on s’indicava exclusivament els documents que calia entregar. Per això es va ampliar la taula indicant els documents requerits i els ja entregats facilitant-ne per tant la comprensió.  Compra de múltiples articles: Es va rebre també alguna suggerència demanant que quan es fes la compra d’un producte es pogués adquirir més d’un article a la vegada. Es va valorar i no es va implementar degut a que cobria un volum molt minoritari de casos ja que la majoria d’usuaris només tenen un producte de cada.  Redisseny de vistes del gestor: Els gestors de l’entitat amb l’ús de l’aplicació van fer diferents suggerències per fer més usable l’aplicació. Per això es va dur a terme un redisseny d’algunes vistes en concrets a partir de les indicacions dels propis gestors.  Consulta de dades de l’equip: Es va demanar si seria poder veure la classificació o propers partits a la pròpia aplicació. Aquest aspecte és complicat degut a que les dades són propietat de la Federació i no es disposa de cap API o similars per accedir-hi. De totes maneres es deixa com a pendent incloure la possibilitat d’afegir un enllaç al calendari de partits i la classificació.  Funcionalitats per entrenadors: Membres de la junta de l’entitat van plantejar la possibilitat d’estudiar funcionalitats que els entrenadors necessitessin i donar-los accés a l’aplicació. Donat que aquest punt s’havia de plantejar a fons 112 Model de negoci Generalitats Un dels aspectes determinants a l’hora de plantejar un model de negoci serà tenir clares les prioritats de despeses inicials. Com recordem uns dels objectius és aconseguir reduir els costos al mínim per poder fer més assequible el producte donat les característiques de les entitats. Per tot això definirem dues grans etapes i determinarem el volum de negoci que s’ha d’assolir per passar de la primera a la segona. Ítem 1a Etapa 2a Etapa Treballadors 1 treballador autònom Més d’un treballador Seu física Espai habilitat al lloc de residència Local de lloguer Despeses de la seu Allotjament web Aigua Llum Allotjament web Internet i telèfon mòbil Mobiliari Espai de treball personal Taula i cadires per reunions Taules i cadires pels treballadors Estanteria Material fungible Paper, bolígrafs i similars Paper, bolígrafs i similars Hardware i software Actualment disponible Impressora 2 iMacs En aquesta taula només s’indiquen els elements que generaran un despesa. Per exemple en software no se’n preveu la utilització de cap ítem que suposi una despesa en termes de llicència. Amb aquesta divisió s’estableixen dues etapes en funció, bàsicament, del volum de treballadors. S’entén que fins al moment en que s’hagi de dur a terme la contractació d’una segona persona molts elements són prescindibles i per tant es poden obviar i així estalviar la despesa que generarien. Aquest fet és degut a que en una fase inicial del negoci s’ha de tenir en compte que la relació amb els clients (presentació del producte, reunions amb els gestors, formació, presentacions als usuaris...) es durà sempre a la seu de l’entitat i l’assessorament i atenció es farà a través de correu electrònic o trucades telefòniques. Evidentment tampoc cal un espai per dur a terme reunions ja que només treballarà una persona així doncs un local com a seu física no té sentit. Per tant les tasques de difusió del producte i cerca de clients, assessorament i desenvolupament de noves funcionalitats les durà a terme la mateixa persona i arribat el moment de requerir més persones per dur-les a terme serà quan es farà el salt a la següent fase. 113 Arribat a aquest punt l’objectiu és calcular les despeses d’ambdues fases i així establir les modalitats que s’oferiran del producte de manera que es faci viable el salt a la segon fase quan s’arribi al moment. Despeses 1ª Fase En aquesta fase els elements que s’han d’adquirir segons hem vist anteriorment i que encara no es disposen és un allotjament per la web i el material d’ús quotidià. Caldrà adquirir un allotjament web degut a que serà la plataforma mitjançant la qual el producte tindrà presència a Internet. En aquest aspecte es calcula que la despesa es pot situar al voltant dels 40€ anuals i per elaborar la plana web es faria servir un CMS gratuït. D’altra banda també es requereix la necessitat d’adquirir material d’oficina com pot ser paper, bolígrafs i similars. En aquest punt es valora en uns 60€ anuals. Finalment el gruix de les despeses és l’àmbit de personal. La persona que durà a terme les tasques es valora inicialment en uns 25000€ anuals bruts en qualitat d’autònom. D’altra banda s’ha de tenir en compte la quota d’autònom es situaria en uns 260€ mensuals fent un total de 3120€. Aquesta quota no té en compte possibles descomptes que el govern aplica actualment. Per tot això les despeses anuals es situarien en 28220€ anuals. 114 Despeses 2ª Fase En aquesta 2ª fase ja entren en joc les despeses d’un local on dur a terme l’activitat. Tots els càlculs es faran sobre 2 treballadors, que seria el mínim per iniciar aquesta fase. Es calcula que per començar un local d’uns 30m2 seria més que suficient. En aquest cas es poden trobar locals al voltant d’uns 8€/m2 al mes, si bé seria interessant establir un marge i arribar fins a un màxim de 10€/m2. D’aquesta manera no ens restringim tant. Per tant podem quantificar aquest punt sobre uns 300€/mes com a màxim (3600€ anuals). D’altra banda cal tenir en compte que a més a més del local hi ha una sèrie de despeses fixes que s’han de pagar mes a mes:  Llum  Aigua  Connexió a Internet i Telèfon  Allotjament de la pàgina web En termes d’aigua i llum es calcula que entre els dos la despesa seria de 75€ al mes. Per la connexió a Internet la despesa pujaria a uns 20€ mensuals sense línia fixa i pel telèfon s’optaria per telefonia mòbil fixant una despesa màxima d’uns 15€ al mes. Finalment l’allotjament de la pàgina web es mantindria en els 40€ anuals vists anteriorment. En aquest aspecte ascendiria doncs a 1360€ anuals. El mobiliari necessari per 2 treballadors és el següent:  Dos taules de treball: 250€  Dos cadires de despatx: 200€  Taula de reunions: 200€  Joc de 4 cadires per reunions: 240€  Estanteries: 100€ Aquests elements pugen a 990€ i el període d’amortització es calcula en 6 anys, quedant doncs una despesa de 165€ per any. D’altra banda en termes de hardware es necessiten 2 iMacs a un cost de 1129€ cadascun i una impressora làser d’uns 200€ que suma en total 2458€. Aquests ítems se’ls hi assigna un període d’amortització de 4 anys quedant una cost anual de 614,5€ anuals. 115 El material d’ús quotidià augmentaria fins a uns 100€ anuals aproximadament degut al major volum de negoci i finalment s’hauria de tenir en compte el sou del segon treballador que seria idèntic al calculat amb el primer. Per tant les despeses d’un any quedarien: Ítem Cost anual Treballadors 56240€ Seu física 3600€ Despeses de la seu 1360€ Mobiliari 165€ Material fungible 100€ Hardware i software 614.50€ Total 62079.50€ 116 Modalitats del producte ofertades Amb les despeses calculades amb els dos escenaris és el moment de plantejar-se les diferents modalitats del producte que s’oferiran i quins serien els preus. Primer de tot el que cal fer és analitzar quines despeses ens pot generar el producte per cada client. En aquest punt només existeix el consum que ens pugui generar el l’allotjament a Google App Engine. Per calcular-ho ens basarem ens els resultats obtinguts a la prova real amb una entitat de 16 equips i uns 200 usuaris i extrapolarem el seu consum per adaptar-lo a 4 tipus d’entitats. Donat que anteriorment vam detectar i analitzar tot un seguit de paràmetres d’ús, simplement ens fixarem en aquests. Agafarem els valors màxims i no els mitjans ja que aquest és el valor que fa que es bloquegi una aplicació a Google App Engine Ítem Fins a 5 grups Fins a 10 grups Fins a 20 grups Fins a 30 grups ~ Usuaris 65 130 260 390 Frontend Hours 4,46 8,92 17,85 24 Blobstore Storage 0,09 0,19 0,38 0,57 Code Storage 0,04 0,04 0,04 0,04 Datastore Writes 0,01 0,01 0,01 0,02 Datastore Reads 0,02 0,04 0,07 0,09 Bandwith Out 0,04 0,08 0,16 0,31 Emails 0,17 0,33 0,66 0,99 S’ha optat per marcar en groc aquelles xifres que estan properes al límit gratuït i en vermell aquelles que el superen. D’aquesta taula podem veure que cal emprar la modalitat de pagament amb entitats a partir dels 11 grups i en el cas d’entre 6 i 10 grups pot ser recomanable. No es plantegen entitats de més de 30 grups degut a que en aquests casos s’hauria d’analitzar detingudament els consums segons l’entitat en concret ja que podria donar-se els casos que calgués un consum de Frontend Hours més alt per evitar saturacions en moments d’alt ús. En cas d’entrar en la modalitat de pagament Google App Engine comença a cobrar a partir del moment en que s’excedeix la quota gratuïta, aquest és un punt a favor ja que es pot activar aquesta opció per totes les aplicacions i evitar bloquejos de l’aplicació inesperats. 117 A partir d’aquest moment l’únic que ens queda fer és quantificar el cost d’aquest excedent: Ítem Fins a 5 grups Fins a 10 grups Fins a 20 grups Fins a 30 grups Frontend Hours 0€ 0€ 0€ 0€ Blobstore Storage 0€ 0€ 0€ 0€ Code Storage 0€ 0€ 0€ 0€ Datastore Writes 0€ 0€ 0€ 0€ Datastore Reads 0€ 0€ 1,67€ 1,67€ Bandwith Out 0€ 0€ 0€ 0€ Emails 0€ 0€ 0€ 0€ Total 0€ 0€ 1,67€ 1,67€ Tots els costos s’expressen en cost mensual. L’únic cas que s’ha de tenir en compte és el dels emails que s’ha de sol·licitar a Google App Engine un augment i no té cost addicional. En aquest punt és el moment de recuperar la mida dels clubs explicada al principi del projecte. S’havia trobat que un 10% dels clubs tenen fins a 5 grups, un 71% entre 6 i 20 i un 19% més de 21. Per mantenir la filosofia de facilitar les tasques a unes entitats sense ànim de lucre s’ha d’optar per oferir un producte amb un cost simbòlic i amb un cost relativament reduït amb les entitats de fins a 10 grups. A partir d’aquest punt s’ha de tenir en compte que les entitats comencen a disposar de més recursos i és el bloc d’entitats que suposaran el gruix dels ingressos. Segmentem encara més les dades dels clubs de bàsquet segons mida i fixem el cost de l’aplicació: Mida Percentatge Preu anual Fins a 5 grups 10% 20€ 6-10 grups 12% 100€ 11-20 grups 59% 400€ 21-30 grups 14% 900€ Més de 30 grups 5% Sota estudi Amb aquests preus per fer viable la primera fase del negoci i suposant que les entitats de més de 30 grups paguessin també 900€ anuals, caldria disposar d’un total de 69 clients. Tenint en compte que l’aplicació és vàlida per entitats de múltiples modalitats esportives aquest fet és completament viable. En el cas de la segona fase seria viable assolint la xifra de 153 entitats, xifra que també es pot assolir. 118 Planificació Final En termes de seguiment de la planificació plantejada inicialment podem dir que les tasques identificades inicialment van ser les correctes i s’hi va assignar una càrrega d’hores adequades . De totes maneres finalment s’ha produït una desviació que ha fet que malgrat que estava previst que tot el projecte finalitzés al gener finalment hagi estat a l’abril. Aquest fet ha estat degut a temes personals i completament aliens al projecte que han fet que el projecte hagi quedat aparcat unes setmanes fins a estar en disposició d’acabar les parts de la memòria que faltaven, dur a terme l’anàlisi d’ús i una proposta de model de negoci. 119 Conclusions Personalment ha estat un projecte molt enriquidor i satisfactori. Primer de tot per la possibilitat de realitzar una proposta pròpia de projecte i més tenint en compte que el sector on es crea aquesta solució és un àmbit on t’hi sents identificat i desenvolupes tasques. Després perquè poder realitzar una prova real de l’envergadura de la que s’ha realitzat no sempre és una oportunitat fàcil d’aconseguir. Qualsevol persona que desenvolupa el projecte té molt clars els avantatges, degut al coneixement que té del que està fent, però les persones més allunyades són aquelles que n’han d’estar realment convençudes. Això no sempre és tasca trivial ja que s’ha de convèncer un gran volum de persones que es llencin a una nova manera de funcionar que no ha estat provada anteriorment i que per tant comporta els seus riscos. Un cop convençuts del canvi és quan comença el repte de debò, ja que s’ha de treballar amb un grup de persones (els usuaris) que en un principi no havien demanat la solució, si no, que ha vingut proposada pels gestors de l’entitat i això fa que l’exigència per part seva sigui més gran. En tots els projectes desenvolupats durant la carrera, quan es realitzaven proves sempre s’intentava adaptar-se a la màxima realitat possible però això mai s’assoleix, En aquest cas era la primera vegada que em trobava davant d’aquest escenari i realitzar sol el projecte crea la responsabilitat d’haver de donar resposta a qualsevol problema que pugui sorgir. Aquesta potser ha estat una de les parts més maques i gratificants de tots els mesos que ha durat el projecte. Per acabar, animar a totes aquelles persones que es trobin en situacions similars a atrevir-se a fer-ho i llençar-se cap a una aventura d’aquestes característiques. En finalitzar el creixement personal que s’aconsegueix compensa, i de llarg, tots el temps i esforç invertit. 120 Bibliografia Webs d’informació general  Tango with Django http://www.tangowithdjango.com/  Django Book http://www.djangobook.com/en/2.0/index.html  Django non-rel: http://django-nonrel.org/  Bootstrap: http://getbootstrap.com/components/  Google App Engine Docs: https://cloud.google.com/appengine/docs  Wikipedia: https://www.wikipedia.org/  Start Bootstrap: http://startbootstrap.com/template-categories/all/  Django AppEngine: http://django-appengine.com/  Django App Engine: http://djangoappengine.readthedocs.org/en/latest/index.html 121 Annexos Annex 1: Estadístiques completes d’ús Fronten d Instance Hours Discounted Instance Hour Backend Instance Hours Datastore Storage Logs Storage Taskqueue Storage Blobstore Storage Dedicated Memcache 10/06 2,35 0,00 0,00 0,01 0,01 0,00 0,01 0,00 11/06 1,29 0,00 0,00 0,01 0,01 0,00 0,01 0,00 12/06 1,28 0,00 0,00 0,01 0,01 0,00 0,01 0,00 13/06 3,07 0,00 0,00 0,01 0,01 0,00 0,01 0,00 14/06 2,41 0,00 0,00 0,01 0,01 0,00 0,01 0,00 15/06 2,50 0,00 0,00 0,01 0,01 0,00 0,01 0,00 16/06 1,51 0,00 0,00 0,01 0,01 0,00 0,01 0,00 17/06 6,87 0,00 0,00 0,01 0,01 0,00 0,01 0,00 18/06 4,14 0,00 0,00 0,01 0,01 0,00 0,01 0,00 19/06 3,70 0,00 0,00 0,01 0,01 0,00 0,01 0,00 20/06 5,23 0,00 0,00 0,01 0,01 0,00 0,01 0,00 21/06 4,23 0,00 0,00 0,01 0,01 0,00 0,02 0,00 22/06 7,68 0,00 0,00 0,01 0,01 0,00 0,02 0,00 23/06 3,81 0,00 0,00 0,01 0,01 0,00 0,02 0,00 24/06 1,82 0,00 0,00 0,01 0,01 0,00 0,02 0,00 25/06 5,76 0,00 0,00 0,01 0,01 0,00 0,02 0,00 26/06 9,59 0,00 0,00 0,01 0,01 0,00 0,03 0,00 27/06 13,73 0,00 0,00 0,01 0,01 0,00 0,03 0,00 28/06 6,55 0,00 0,00 0,01 0,01 0,00 0,04 0,00 128 06/12 0,32 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 07/12 0,00 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 08/12 0,52 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 09/12 3,72 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 10/12 3,15 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 11/12 2,33 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 12/12 4,80 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 13/12 2,18 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 14/12 0,82 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 15/12 6,19 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 16/12 2,35 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 17/12 3,70 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 18/12 2,53 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 19/12 5,89 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 20/12 1,89 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 21/12 1,14 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 22/12 1,54 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 23/12 0,64 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 24/12 0,26 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 25/12 1,54 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 26/12 2,03 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 27/12 0,26 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 MITJ 3,772 0,000 0,000 0,015 0,000 0,010 0,000 0,183 0,000 MAX 13,73 0,00 0,00 0,02 0,00 0,01 0,00 0,29 0,00 Límit 28 0 9 1 1 1 0,49 5 0 % MIG 13% 0% 0% 2% 0% 1% 0% 4% 0% % MAX 49% 0% 0% 2% 0% 1% 0% 6% 0% 129 Code and Static File Storage Datastor e Writes Mobile Datastore Writes Datastor e Reads Mobile Datastor e Reads Small Datastore Operations Mobile Datastore Small Ops Bandwidt h Out Email s XMPP Stanzas Opened Channels Logs Read Bandwidth 10/06 0,04 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 11/06 0,04 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 12/06 0,04 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 13/06 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 14/06 0,04 0,01 0,01 0,01 0,01 0,42 0,00 0,00 0,00 15/06 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 16/06 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 17/06 0,04 0,01 0,01 0,01 0,01 0,01 0,00 0,00 0,00 18/06 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 19/06 0,04 0,01 0,01 0,01 0,02 0,01 0,00 0,00 0,00 20/06 0,04 0,01 0,01 0,01 0,02 0,03 0,00 0,00 0,00 21/06 0,04 0,01 0,01 0,01 0,03 0,00 0,00 0,00 0,00 22/06 0,04 0,01 0,01 0,01 0,04 0,51 0,00 0,00 0,00 23/06 0,04 0,01 0,01 0,01 0,02 0,00 0,00 0,00 0,00 24/06 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 25/06 0,04 0,01 0,01 0,01 0,04 0,00 0,00 0,00 0,00 26/06 0,04 0,01 0,01 0,01 0,07 0,02 0,00 0,00 0,00 27/06 0,04 0,01 0,02 0,01 0,10 0,05 0,00 0,00 0,00 28/06 0,04 0,01 0,01 0,01 0,03 0,01 0,00 0,00 0,00 29/06 0,04 0,01 0,01 0,01 0,03 0,10 0,00 0,00 0,00 30/06 0,04 0,01 0,01 0,01 0,03 0,00 0,00 0,00 0,00 01/07 0,04 0,01 0,02 0,01 0,07 0,02 0,00 0,00 0,00 02/07 0,04 0,01 0,01 0,01 0,03 0,01 0,00 0,00 0,00 130 03/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 04/07 0,04 0,01 0,01 0,01 0,01 0,02 0,00 0,00 0,00 05/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 06/07 0,04 0,01 0,01 0,01 0,02 0,00 0,00 0,00 0,00 07/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 08/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 09/07 0,04 0,01 0,01 0,01 0,01 0,01 0,00 0,00 0,00 10/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 11/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 12/07 0,04 0,01 0,01 0,01 0,01 0,01 0,00 0,00 0,00 13/07 0,04 0,01 0,01 0,01 0,01 0,01 0,00 0,00 0,00 14/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 15/07 0,04 0,01 0,01 0,01 0,01 0,01 0,00 0,00 0,00 16/07 0,04 0,01 0,01 0,01 0,01 0,02 0,00 0,00 0,00 17/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 18/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 19/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 20/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 21/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 22/07 0,04 0,01 0,04 0,01 0,12 0,00 0,00 0,00 0,00 23/07 0,04 0,01 0,02 0,01 0,02 0,01 0,00 0,00 0,00 24/07 0,04 0,01 0,01 0,01 0,02 0,01 0,00 0,00 0,00 25/07 0,04 0,01 0,02 0,01 0,03 0,00 0,00 0,00 0,00 26/07 0,04 0,01 0,01 0,01 0,02 0,00 0,00 0,00 0,00 27/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 28/07 0,04 0,01 0,01 0,01 0,02 0,00 0,00 0,00 0,00 29/07 0,04 0,01 0,01 0,01 0,02 0,01 0,00 0,00 0,00 131 30/07 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 31/07 0,04 0,01 0,01 0,01 0,02 0,00 0,00 0,00 0,00 01/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 02/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 03/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 04/08 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 05/08 0,04 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 06/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 07/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 08/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 09/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 10/08 0,04 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 11/08 0,04 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 12/08 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 13/08 0,04 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 14/08 0,04 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 15/08 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 16/08 0,04 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 17/08 0,04 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 18/08 0,04 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 19/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 20/08 0,04 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 21/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 22/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 23/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 24/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 25/08 0,04 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 26/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 132 27/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 28/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 29/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 30/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 31/08 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 01/09 0,04 0,01 0,01 0,01 0,02 0,00 0,00 0,00 0,00 02/09 0,04 0,01 0,01 0,01 0,03 0,00 0,00 0,00 0,00 03/09 0,04 0,01 0,01 0,01 0,02 0,00 0,00 0,00 0,00 04/09 0,04 0,01 0,01 0,01 0,03 0,04 0,00 0,00 0,00 05/09 0,04 0,01 0,01 0,01 0,02 0,04 0,00 0,00 0,00 06/09 0,04 0,01 0,01 0,01 0,02 0,14 0,00 0,00 0,00 07/09 0,04 0,01 0,01 0,01 0,03 0,00 0,00 0,00 0,00 08/09 0,04 0,01 0,01 0,01 0,03 0,02 0,00 0,00 0,00 09/09 0,04 0,01 0,01 0,01 0,03 0,03 0,00 0,00 0,00 10/09 0,04 0,01 0,02 0,01 0,04 0,09 0,00 0,00 0,00 11/09 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 12/09 0,04 0,01 0,01 0,01 0,02 0,08 0,00 0,00 0,00 13/09 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 14/09 0,04 0,01 0,01 0,01 0,02 0,02 0,00 0,00 0,00 15/09 0,04 0,01 0,01 0,01 0,02 0,02 0,00 0,00 0,00 16/09 0,04 0,01 0,02 0,01 0,05 0,05 0,00 0,00 0,00 17/09 0,04 0,01 0,04 0,01 0,04 0,02 0,00 0,00 0,00 18/09 0,04 0,01 0,01 0,01 0,06 0,08 0,00 0,00 0,00 19/09 0,04 0,01 0,01 0,01 0,04 0,03 0,00 0,00 0,00 20/09 0,04 0,01 0,01 0,01 0,02 0,01 0,00 0,00 0,00 21/09 0,04 0,01 0,01 0,01 0,02 0,02 0,00 0,00 0,00 22/09 0,04 0,01 0,01 0,01 0,05 0,01 0,00 0,00 0,00 133 23/09 0,04 0,01 0,01 0,01 0,02 0,01 0,00 0,00 0,00 24/09 0,04 0,01 0,01 0,01 0,04 0,02 0,00 0,00 0,00 25/09 0,04 0,01 0,01 0,01 0,03 0,02 0,00 0,00 0,00 26/09 0,04 0,01 0,03 0,01 0,03 0,14 0,00 0,00 0,00 27/09 0,04 0,01 0,01 0,01 0,01 0,01 0,00 0,00 0,00 28/09 0,04 0,01 0,01 0,01 0,02 0,02 0,00 0,00 0,00 29/09 0,04 0,01 0,03 0,01 0,05 0,00 0,00 0,00 0,00 30/09 0,04 0,01 0,01 0,01 0,07 0,01 0,00 0,00 0,00 01/10 0,04 0,01 0,01 0,01 0,04 0,03 0,00 0,00 0,00 02/10 0,04 0,01 0,02 0,01 0,08 0,02 0,00 0,00 0,00 03/10 0,04 0,01 0,02 0,01 0,04 0,02 0,00 0,00 0,00 04/10 0,04 0,01 0,01 0,01 0,02 0,00 0,00 0,00 0,00 05/10 0,04 0,01 0,06 0,01 0,02 0,07 0,00 0,00 0,00 06/10 0,04 0,01 0,01 0,01 0,03 0,00 0,00 0,00 0,00 07/10 0,04 0,01 0,01 0,01 0,01 0,01 0,00 0,00 0,00 08/10 0,04 0,01 0,01 0,01 0,01 0,01 0,00 0,00 0,00 09/10 0,04 0,01 0,01 0,01 0,02 0,00 0,00 0,00 0,00 10/10 0,04 0,01 0,01 0,01 0,04 0,00 0,00 0,00 0,00 11/10 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 12/10 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 13/10 0,04 0,01 0,01 0,01 0,02 0,00 0,00 0,00 0,00 14/10 0,04 0,01 0,02 0,01 0,02 0,02 0,00 0,00 0,00 15/10 0,04 0,01 0,01 0,01 0,03 0,00 0,00 0,00 0,00 16/10 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 17/10 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 18/10 0,04 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 134 19/10 0,04 0,01 0,01 0,01 0,01 0,00 0,00 0,00 0,00 20/10 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,04 0,00 0,00 0,00 0,00 21/10 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 22/10 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 23/10 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 24/10 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,03 0,00 0,00 0,00 25/10 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 26/10 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 27/10 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 28/10 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 29/10 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,01 0,00 0,00 0,00 30/10 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 31/10 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 01/11 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 02/11 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 03/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 04/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,01 0,00 0,00 0,00 05/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 06/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 07/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,02 0,04 0,00 0,00 0,00 08/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 09/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 10/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,02 0,00 0,00 0,00 0,00 11/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,01 0,00 0,00 0,00 12/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,01 0,00 0,00 0,00 13/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 135 14/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,02 0,00 0,00 0,00 0,00 15/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 16/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 17/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 18/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 19/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 20/11 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 21/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,02 0,00 0,00 0,00 22/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 23/11 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 24/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,03 0,01 0,00 0,00 0,00 25/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 26/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 27/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 28/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 29/11 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 30/11 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 01/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 02/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 03/12 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 04/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,01 0,00 0,00 0,00 05/12 0,04 0,01 0,00 0,02 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 06/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 07/12 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 08/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 09/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,02 0,00 0,00 0,00 0,00 136 10/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 11/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 12/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,02 0,02 0,00 0,00 0,00 13/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 14/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 15/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 16/12 0,04 0,00 0,00 0,01 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 17/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 18/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 19/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,11 0,00 0,00 0,00 20/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,01 0,00 0,00 0,00 21/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 22/12 0,04 0,01 0,00 0,01 0,00 0,01 0,00 0,01 0,00 0,00 0,00 0,00 23/12 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 24/12 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 25/12 0,04 0,00 0,00 0,01 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 26/12 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 27/12 0,04 0,00 0,00 0,00 0,00 0,00 0,00 0,01 0,00 0,00 0,00 0,00 MITJ 0,040 0,009 0,000 0,010 0,000 0,009 0,000 0,017 0,013 0,000 0,000 0,000 MAX 0,04 0,01 0,00 0,06 0,00 0,01 0,00 0,12 0,51 0,00 0,00 0,00 Límit 1 0,05 0,05 0,05 0,05 0,05 0,05 1 1 0,1 1 0,1 % MIG 4% 17% 0% 20% 0% 17% 0% 2% 1% 0% 0% 0% % MAX 4% 20% 0% 120% 0% 20% 0% 12% 51% 0% 0% 0% 137 PageSpeed Out Bandwidth SSL VIPs SSL SNI Certificates Other Search Ops Search Document Indexing Search Document Storage Complex Searches Simple Searches 10/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 11/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 12/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 13/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 14/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 15/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 16/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 17/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 18/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 19/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 20/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 21/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 22/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 23/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 24/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 25/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 26/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 27/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 28/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 29/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 30/06 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 01/07 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 02/07 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 03/07 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 144 11/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 12/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 13/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 14/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 15/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 16/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 17/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 18/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 19/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 20/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 21/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 22/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 23/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 24/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 25/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 26/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 27/12 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 MITJ 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 MAX 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 ALL 0 0 0 0,1 0,01 0,25 0,01 0,1 % MIG 0% 0% 0% 0% 0% 0% 0% 0% % MAX 0% 0% 0% 0% 0% 0% 0% 0% 145 Annex 2: Presentació Juny’14 Mitjançant el següent enllaç es pot accedir a la presentació que es va mostrar a les famílies explicant l’aplicació i les novetats que comportava. https://dl.dropboxusercontent.com/u/13026989/Presentaci%C3%B3%20Juny%2014.ppsx 146 Annex 3: Manual d’usuari Mitjançant l’enllaç següent es pot accedir al manual d’usuari que es va crear per facilitar el procés als usuaris. https://dl.dropboxusercontent.com/u/13026989/Manual%20d%27Usuari%20ESecretaria.ppsx