David Pascual Arribas

Jesús María Aransay Azofra y Juan José Barrio Díez

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2014-2015

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

Aplicación informática para la previsión de costes deproducción de cultivos agrícolas

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2015

publicaciones.unirioja.esE-mail: publicaciones@unirioja.es

Aplicación informática para la previsión de costes de producción de cultivos agrícolas, trabajo fin de grado

de David Pascual Arribas, dirigido por Jesús María Aransay Azofra y Juan José Barrio Díez(publicado por la Universidad de La Rioja), se difunde bajo una Licencia

Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

 

 

 

 

 Facultad    Facultad  de  Ciencias,  Estudios  Agroalimentarios  e  Informática    

Titulación    Grado  en  Ingeniería  Informática    

Título    Aplicación  informática  para  la  previsión  

de  costes  de  producción  de  cultivos  agrícolas  

Autor    David  Pascual  Arribas  

Tutores    Jesús  María  Aransay  Azofra    Juan  José  Barrio  Díez    

Departamento    Departamento  de  Matemáticas  y  Computación    

Curso  académico    2014  /  2015      

 

 

   

   

AGRADECIMIENTOS    

Por  toda  la  ayuda  y  apoyo  recibidos  durante  la  realización  del  TFG  querría  agradecer  a:    

• Jesús  Aransay  por  estar  siempre  que  lo  he  necesitado,  por  todos  sus    buenos  consejos  y   la  cercanía  que  me  ha  prestado  en  todo  momento.  

• Juanjo   Barrio   por   sus   explicaciones   que   me   han   permitido   aprender   y     entender   de   una  materia   totalmente   desconocida   y   por   las   reuniones   que   hemos   tenido   que  me  han  servido  para  conocer  cómo  mantener  una  relación  con  un  cliente.  

• Familia  por  aguantarme  y  animarme  en  los  momentos  de  estancamiento  y  de  dificultad.  

   

   

RESUMEN    En  el  ámbito  agrícola  es  necesario  poder  prever  con  bastante  exactitud  los  costes  derivados  en  cada  explotación  agraria  durante  todo  su  proceso  de  producción.  Estos  costes  se  dividen  en  tres  grandes  bloques:  

• Costes  de  la  maquinaria.  

• Coste  de  la  mano  de  obra.  

• Coste  de  los  productos  fitosanitarios  empleados  en  la  tarea.  

Todos   estos   costes   dependen   directamente   de   la   explotación   agraria   en   la   cual   estamos  trabajando,  ya  que  en  ellos  influyen  la  dificultad  de  trabajo  de  la  parcela  y  sus  Hectáreas.  

En  este  proyecto   revisaremos   y   ampliaremos   las   funcionalidades  de  una   aplicación  web  que  permita   al   usuario   poder   prever   los   costes   de   las   tareas   agrícolas   en   explotaciones   agrarias  determinadas,  incluyendo  costes  de  maquinaria,  la  mano  de  obra  y  los  productos  fitosanitarios  necesarios.  

 

ABSTRACT    In   agriculture   it’s   necessary   to   predict   with   accuracy   the   costs   on   each   farm   throughout   its  production  process.      These  costs  are  divided  in  three  main  sections:    

•  Costs  of  machinery.  •  Cost  of  labor.    •  Cost  of  the  plant  protection  products  on  the  task.    

 All  these  costs  depend  directly  on  the  farm  on  which  we  are  working,  since  they  influence  the  difficulty  in  working  the  land  and  hectares.    This  project  will  review  and  extend  the  functionality  of  a  web  application  that  allows  the  user  to  predict   the  costs  of   farming   in  certain   farms   including  machine  costs,   labor  and  pesticides  needed.          

 

1    

INDICE    

INDICE  .......................................................................................................................................  1  

METODOLOGIA  E  ITERACIONES  ................................................................................................  5  

Desarrollo  de  la  memoria  ......................................................................................................  5  

PLANIFICACION  .........................................................................................................................  6  

ITERACION  0.  “ANALISIS  APLICACIÓN  EXISTENTE”  ....................................................................  7  

Descripción  de  la  aplicación  ..................................................................................................  7  

ITERACION   1.   Realización,   modificación,   búsquedas   y   cálculo   de   costes   de   las   tareas  asociadas  a  las  explotaciones  agrarias.  ..................................................................................  17  

ITERACION  2.  Creación  de  gráficos  para  mostrar  el  uso  de  la  maquinaria  .............................  32  

ITERACION  3.  Realización,  modificación,  búsquedas  y  cálculo  de  costes  de  la  mano  de  obra  y  productos  fitosanitarios  de  las  tareas.  ....................................................................................  38  

ITERACION   4.     Introducción   de   nuevos   parámetros   para   incrementar   la   precisión   de   los  cálculos  .  ..................................................................................................................................  47  

ITERACION  5.  Modificaciones  en  la  interfaz  de  la  aplicación.  .................................................  49  

ITERACION  6.  Implantación  de  la  aplicación  en  el  servidor.  ...................................................  53  

Conclusiones  ...........................................................................................................................  55  

Trabajo  futuro  .........................................................................................................................  56  

Bibliografía  ..............................................................................................................................  57  

 

 

2    

INTRODUCCION    

Antes  de  empezar  a  hablar  de  tareas  agrícolas  y  sus  costes  debemos  saber  qué  es  y  cómo  es  el  ámbito  en  el  que  se  aplican,  este  ámbito  es  la  agricultura  y  los  procesos  de  producción  agraria.  

La  agricultura  es  el  conjunto  de  técnicas  que  nos  permiten  cultivar  la  tierra.  Estas  técnicas  van  desde   la  preparación  del  terreno  para  el  cultivo,   la  siembra,   los  riegos,   los  tratamientos  para  evitar  las  enfermedades  y  la  recolección.  Todas  estas  técnicas  citadas  han  ido  evolucionando  y  mejorando  durante  toda  la  historia  del  hombre,  empezando  desde  la  época  de  los  faraones  en  el  Antiguo  Egipto  en  las  orillas  del  río  Nilo  pasando  también  por  los  árabes,  los  romanos,  edad  Media,  edad  Moderna,  edad  Contemporánea,  y  la  época  actual.    

Hasta   la   segunda  mitad   del   s.   XX   no   se   han   tenido   en   cuenta   los   costes   de   la  maquinarias,  básicamente  porque  la  herramientas  usadas  hasta  entonces  (carromatos,  arados)  eran  tiradas  por  animales  (bueyes,  burros).  En  la  época  actual  es  cuando  empiezan  a  relegarse  los  animales  a  un  segundo  plano  dando  paso  a  lo  que  hoy  conocemos  como  maquinaria  agrícola  movida  por  motores   de   combustión.   Este   nuevo   tipo   de   maquinaria   está   compuesta   por   maquinaria  autopropulsada  y  maquinaria  arrastrada.  

Las  máquinas  autopropulsadas   son  aquellas  que  pueden   realizar  las   tareas   agrícolas   de   forma   autónoma.   Este   tipo   de   máquinas  están   propulsadas   por   motores   de   combustión.   Un   ejemplo   de  máquina   autopropulsada   puede   ser   una   cosechadora,   una  vendimiadora  o  un  tractor.    

Las   máquinas   arrastradas   requieren   de   una   máquina  autopropulsada   para   poder   realizar   la   tarea,   principalmente  tractores.   Este   tipo   de   maquinaria   es   muy   variado,   incluye  maquinaria   para   preparar   la   tierra   para   los   cultivos   (arados),  remolques   para   llevar   las   cosechas   recogidas,     atomizadores  para  realizar  los  tratamientos  fitosanitarios  a  los  cultivos.  

Las   ventajas   que   otorgan   al   agricultor   en   sus   tareas   agrícolas   este   tipo   de  maquinarias   son  notables   principalmente   en   el   ahorro   de   tiempo   y   en   la   mayor   eficiencia   de   las   tareas   a  realizar,   pero   principalmente   un   gran   ventaja   que   otorga   es   el   ahorro   de   mano   de   obra  necesaria  para  realizar  dichas  tareas  (del  50%  al  5%  de  la  población).    

La  utilización  de  este  tipo  de  maquinaria  da  lugar  a  la  aparición  de  costes,  denominados  costes  de  maquinaria.  Esto  genera   la  necesidad  al  agricultor  de  prever   los  cotes  de  cada   tarea  y  es  aquí   donde   aparece   la   motivación   de   realizar   este   proyecto:   la   necesidad   que   tienen   los  agricultores  de  saber   los  costes  de  utilizar  una  máquina  para  una  determinada  tarea  en  cada  parcela.  

De  acuerdo  con  el  Instituto  para  la  Diversificación  y  Ahorro  de  la  Energía  (2007),  los  costes  de  maquinaria  y  operación  tienen  dos  componentes:  

 

3    

• Costes  fijos:  Estos  costes  son  los  que  no  cambian,  es  decir,  son  costes  constantes  a  lo  largo  del  año.  Dentro  de  estos  costes  podemos  encontrar:  

o Impuestos:  de  Circulación.  o Seguros.  o Costes  de  Adquisición  de  la  maquinaria  (Primer  año).  o Depreciación:  Pérdida  de  valor  por  el  uso  de  la  maquinaria.  o Costes  de  almacenamiento:  Lonjas.  

• Costes   variables:   Los   costes   variables   como   su   propio   nombre   indica   son   los   costes  que   van   variando   debido   a   las   labores   realizadas,   estos   componentes   son  combustibles,  mano  de  obra,  lubricantes,  reparaciones  y  mantenimiento.  

Con  todo  esto  se  establece  que  los  costes  totales  de  una  máquina  corresponden  a:  

Coste  Total  =  Costes  Fijos  +  Costes  Variables  

Hasta  aquí  corresponden  los  costes  de  la  máquina,  pero  también  deberemos  saber  que  no  nos  va  a  costar  siempre  lo  mismo  utilizarla,    dependiendo  de  diversos  factores  como  pueden  ser  la  parcela  (superficie,  dificultad,  pasadas),  tipo  de  cultivo  y  características  de  la  máquina  (ancho  de  trabajo,  velocidad  teórica)  que  se  va  emplear  en  realizar  las  labores,  este  coste  aumentará  o  disminuirá.  

Además  de  los  costes  ya  comentados  deberemos  añadir  el  coste  de  la  mano  de  obra.  En  este  último   influye   tanto   el   personal   encargado   de   manejar   la   maquinaria   autopropulsada  denominado   tractorista   como   las   personas   que   intervienen   en   la   tarea   denominados   otro  personal.    

 

 

 

 

Para  poder  prever  el  coste  total  de  la  tarea  deberemos  añadir  a  lo  anterior  los  costes  derivados  de  los  productos  fitosanitarios  empleados.  Estos  productos  son  medios  imprescindibles  para  la  producción   agrícola,   tanto   bajo   los   sistemas   convencionales   de   agricultura,   como  bajo   otros  sistemas  de  agricultura,  como  la  integrada  o  la  ecológica,  pues  los  estragos  potenciales  de  las  diferentes  clases  de  plagas,  determinarían  la  inviabilidad  de  muchos  cultivos.    

 

 

 

La  previsión  del  coste  total  de  la  tarea  quedaría  así:  

Coste  Total  =  Costes  Maquinaria  +  Coste  mano  de  obra  +  Coste  productos  fitosanitarios  

 

4    

 

   

 

5    

METODOLOGIA  E  ITERACIONES    

La   metodología   empleada   en   este   proyecto   será   de   tipo   iterativo.   Realizaré   las   máximas  posibles   dentro   del   plazo   marcado.   Cada   iteración   estará   basada   en   las   fases   de   Análisis,  Diseño  e  Implementación.  

Las  iteraciones  para  este  TFG  son  las  siguientes:  

• Iteración  0:  Análisis  de  la  aplicación  existente  y  realización  o  mejora  de  funcionalidades  de  la  aplicación.    

• Iteración   1:   Realización,   modificación,   búsquedas   y   cálculo   de   costes   de   las   tareas  asociadas  a  las  explotaciones  agrarias.    

• Iteración  2:  Creación  de  gráficos  para  mostrar  el  uso  de  la  maquinaria.    

• Iteración   3:  Realización,  modificación,   búsquedas   y   cálculo   de   costes   de   la  mano   de  obra  y  productos  fitosanitarios  de  las  tareas.    

• Iteración   4:   Introducción   de   nuevos   parámetros   para   incrementar   la   precisión   de   los  cálculos  .    

• Iteración  5:  Modificaciones  en  la  interfaz  de  la  aplicación.    

• Iteración  6:  Implantación  de  la  aplicación  en  el  servidor.    

Desarrollo  de  la  memoria    

Esta   memoria   se   redactará   desde   un   punto   de   vista   técnico   pues   se   espera   que   sirva   de  soporte   /   punto   de   partida   para   que   posibles   desarrolladores   futuros   de   esta   aplicación  aumenten  las  funcionalidades  creando  así  nuevas  versiones  más  completas.  Por  otra  parte,  la  aplicación   debe   ser   lo   suficientemente   intuitiva   y  manejable   como   para   que   un   usuario   sin  conocimientos  técnicos  pueda  usarla  con  facilidad.  

   

 

6    

PLANIFICACION    

Los  actores  implicados  en  este  Trabajo  Fin  de  Grado  somos  los  siguientes:    

• David  Pascual  Arribas  :  Alumno  de  Grado  en  Ingeniería  Informática  y  autor  del  TFG.    • Jesús  María  Aransay:  Director  del  TFG.  Profesor  del  Departamento  de  Matemáticas  y  

Computación  de  la  Universidad  de  La  Rioja.    • Juan  José  Barrio:  Cliente  y  director  del  TFG.  Profesor  del  Departamento  de  Agricultura  

y  Alimentación  de  la  Universidad  de  La  Rioja.    

A   continuación   se   muestra   una   tabla   con   las   horas   previstas   para   el   desarrollo   de   este  proyecto.  

Acciones   Horas  PREVISTAS  ITERACION  0   50    ITERACION  1   90    ITERACION  2   30      ITERACION  3   50    ITERACION  4   5  ITERACION  5   12  ITERACION  6   3  REUNIONES   10  

REVISIONES  Y  MEJORAS   10  MEMORIA   40  

  300    

Se  ha  establecido  un  horario   semanal  para   su   realización  del   TFG,   el   cual   queda  detallado  a  continuación:  

• De  lunes  a  miércoles  de  10:00  a  13:00  y  de  16:00  a  18:00.  • De  jueves  a  viernes  de  10:00  a  13:00  y  de  16:00  a  20:00.  

Decidí   establecer   de   esta   forma   el   horario   para   el   TFG  porque   eran   las   horas   en   las   que   no  tenía   clase   y   dejar   los   fines   de   semana   para   realizar   trabajos   o   utilizar   alguna   hora   prevista  para  el  TFG.  

   

 

7    

ITERACION  0.  “ANALISIS  APLICACIÓN  EXISTENTE”    Descripción  de  la  aplicación    En   esta   iteración   se   analizará   la   aplicación   sobre   cálculo   de   costes   de   maquinaria.   Esta  aplicación   tiene   como   objetivo   la   previsión   de   costes   de   maquinaria   en   el   ámbito   agrícola  basándose  en  alguno  de  los  métodos  de  cálculo  existentes(ASABE,COMBINADO)1.    La  aplicación  que  desarrollaré  en  este  TFG  se  corresponderá  con  la  cuarta  versión  de  la  misma.  A  continuación  citaré  y  expondré  algunos  detalles  de  cada  una  de  las  versiones  anteriores:    1ª  

Versión:   Aplicación   desarrollada   en   un   archivo  Excel     por   Juanjo  Barrio1

.   En   esta   versión   los  costes   de   maquinaria   son   obtenidos   mediante   los   métodos   ASABE   (Método   de   calculo   de  costes:   basado   en   la   metodología   propuesta   por   la   American   Society   of   Agricultural   and  

Biological  Engineers  )y  COMBINADO2

 que  explicaré  más  adelante.  

2ª  Versión:  Aplicación  web  desarrollada  en  php,  JavaScript  y  MySQL  para  la  gestión  de    la  base  

de    datos.    Esta    versión  fue  desarrollada  por  Gonzalo  Bastida3

.  En  esta  versión   los  costes  de  maquinaria  son  obtenidos  únicamente  mediante  el  método  COMBINADO.  

Esta  versión  corresponde  con  el  TFG  de  Gonzalo  Bastida  realizada  en  el  curso  12/13  y  se  puede  consultar  en:  http://biblioteca.unirioja.es/tfe_e/TFE000278.pdf  

Estas   dos   primeras   versiones   solo   prevén   los   costes   de   la   maquinaria   por   medio   de   los  métodos  de  cálculo  ya  comentados.  

3ª  Versión:  Aplicación  web  continuada  por  Andrés  Sáenz  Fernández4

.  Se  mantiene  la   interfaz  de   la   versión   anterior   pero   se   ha   implementado   el   patrón   de   diseño   Modelo   Vista    Controlador.   En   esta   versión   ya   se   permite   el   registro   de   usuarios,   la   gestión   de   las  explotaciones   agrarias   y   maquinarias.   Almacena   máquinas   y   fincas   para   cada   usuario   y   se  prevén  cálculo  de  costes  derivados  de  la  maquinaria  

En  esta  cuarta  versión  voy  a  continuar  con  los  lenguajes  elegidos  en  la  versión  anterior,  PHP  y  JavaScript.    Análisis  del  software  existente  e  implementación    Andrés   implantó   el   patrón  MVC5   desde   cero,   en   vez   de   utilizar   un   Framework   ya   existente.  Después  de  revisarlo    durante  el  análisis  de  esta  iteración,  he  decidido  continuar  con  lo  que  él  ha  creado  en  vez  de  utilizar  uno  existente,  ya  que  las  funcionalidades  que  yo  voy  a  realizar  son  bastantes  similares  a  las  actuales  y  puedo  basarme  en  el  trabajo  que  ha  realizado  él.  Considero  que   puede   venirme   bien   para   mi   formación   el   empezar   con   un   código   ya   existente   y  amoldarme  a  él,  cosa  que  me  parece  más  complicada  que  empezar  algo  de  cero.        1    Aplicación  de  Juanjo  Barrio:  http://www.unirioja.es/dptos/daa/docencia/1011013costes.xls      2  COMBINADO:  http://biblioteca.unirioja.es/tfe_e/TFE000278.pdf#page=16  3  Aplicación  de  Gonzalo  Bastida:  http://acmag.unirioja.es/  4  Aplicación  de  Andrés  Sáenz:  https://acmag.unirioja.es/acmag_v2/  5  MVC:  http://www.lab.inf.uc3m.es/~a0080802/RAI/mvc.html  

 

8    

En   las  siguientes   imágenes  veremos  el  esquema  que  utilizaba  Andrés  para   los  controladores,  modelos  y  vistas:                      Los  controladores  heredan  características  comunes  de   la  clase  “controller.php”  situado  en   la  carpeta  app.  Dentro  de  cada  controlador  particular  se  realizan  funciones  más  específicas  de  la  parte  de  la  aplicación  como  su  nombre  indican.    

agricolaController:   se   corresponde   con   la   lógica   de   usuarios,   maquinarias   y   fincas   de   la  aplicación   que   permite   su   administración.   A   continuación   voy   a   explicar   cada   uno   de   ellos  según  sus  funcionalidades:  

• Administración  de  máquinas  adminMaquina  adminIPC    

• Administración  de  usuarios  adminUsuario    

• Administración  de  fincas  adminFinca    

• Controlador  de  vistas  private_admin:  Vista  de  administración  para  usuarios  registrados.  coste_laboreo:  Vista  del  coste  de  una  tarea.  public_admin:  Vista  de  administración  para  el  usuario  administrador  de  la  aplicación.      

ajaxController:   Los   métodos   de   este   controlador   serán   utilizados   por   los   métodos   de  costesFincas.js  y  costesMaquinaria.js.  

El   método   getFactorActualizacion   obtiene   el   IPC  acumulado   desde   el   año   de   adquisición   de   la  máquina   hasta   el   año   en   curso.   Este   valor   es  necesario   para   calcular   el   valor   actualizado   de   la  máquina.   Para   obtenerlo   llamará   al   método  getFactAct  del  modelo  ajaxModel.  

   

 errorController:  Controla  el  error  que  se  ha  producido  y  nos  redirige  a  la  vista  correspondiente  mandándole  el  mensaje  adecuado  al  error.  

Controladores    

Modelos  

Vistas  

Controlador  ajax

 

9    

idiomaController:  Gestiona  el  idioma  para  adaptarlo  al  escogido  en  la  aplicación.  Contiene  un  método  para  comprobar  el  idioma.   indexController:  nos  redirige  a  la  vista  index.   pdfController:  contiene  un  método  para  generar  una  página  PDF  que  contenga  los  datos  de  la  vista,  pero  dicho  método  se  quedó  sin  desarrollar  y  no  funciona.    userController:  contiene  la  lógica  necesaria  para  el  manejo  de  usuarios  dentro  de  la  aplicación.    • Métodos  para  iniciar/cerrar  la  Sesión:    

El  método  login  será  el  encargado  de  iniciar  la  sesión.  El  método  logout2  será  el  encargado  de  cerrar  sesión.    

• Métodos  para  el  registro  y  la  activación  de  cuenta:  El  método  openForm  se  encargará  de  abrir  las  vistas  asociadas  al  controlador  adecuado  en  el   formato   de   caja   FancyBox6.   En   este   caso   este   controlador   se   utilizará   para   cargar   las  vistas  formRegistro.phtml  y  formPerfil.phtml  encargadas  del  registro  de  usuarios  y  cambio  de  contraseña  del  usuario  respectivamente.    

• El   método   interno   del   controlador   “activacionCuenta”   se   encargará   de   enviar   al   correo  electrónico  del  usuario  el  código  de  activación  de  la  cuenta  usando  la  librería  phpmailer7.  

• El  método  “register”  se  encargará  de  realizar  el  registro  del  usuario,  previa  comprobación  del  CAPTCHA  enviado  desde  la  vista  formRegistro.phtml.  Si  el  código  es    válido  se  procederá  a  realizar  el  proceso  de  activación  de  la  cuenta.  

• El   método   “registered”   será   el   encargado   de   generar   la   vista   activacion.phtml,   con   el  mensaje   correspondiente   a   la   situación   del   registro   que   se   haya   realizado   en   el  método  anterior.  

• El  método  “activar”  será  el  encargado  de  activar  la  cuenta  del  usuario,  una  vez  que  el  mismo  pulse  el  enlace  en  el  correo.    

• Métodos  para  controlar  el  perfil  del  usuario:              El  método  “profile”  será  el  encargado  de  abrir  la  vista  del  perfil  de  usuario  (perfil.phtml).  

El  método   “modUser”   será   el   encargado  de   actualizar   los   cambios  producidos   en   la   vista    perfil.phtml.  

El  método    “changePass”  será  el  encargado  de  actualizar  los  cambios  realizados  en  la  vista  formPerfil.phtml.  

El  método  “dataChanges”  será  el  encargado  de  generar   la  vista  dataChanges.phtml  con  el  mensaje  correspondiente  a  la  situación  que  se  haya  producido  en  el  método  “changePass”.  

 

Los  modelos  son  las  clases  encargadas  de  acceder  a  la  base  de  datos.  Como  apreciamos  en  la  imagen  existen  3  modelos;  comentaré  a  continuación  lo  que  realiza  cada  uno  de  ellos.  

 

 

6  FancyBox:  http://www.usosweb.com/content/tutorial-­‐fancybox    7  phpmailer:  http://www.desarrolloweb.com/articulos/phpmailer.html    

 

10    

agricolaModel.php:   Es   el   encargado   de   realizar   en   la   base   de   datos   todas   las   funciones  relacionadas  con  usuarios,  máquinas  y  fincas. Entre  ellos  los  siguientes:  

     getUsuarios:   devolverá   todos   los   usuarios   de   la  aplicación.  insertUsuario:   añadirá   un   usuario   a   la   tabla   de  usuarios.  

modifyUsuario:   modificará   un   usuario   de   la   tabla  usuarios.  

deleteUsuario:   borrará   el   usuario   de   la   tabla  usuarios   así   como   también   de   la   tabla  maquinas_usuario  y  fincas_usuario   las  entradas  que  tenga  ese  usuario.  

 

ajaxModel.php:  Este  modelo  contiene  los  siguientes  métodos:  

• validarNick:  el  cual  comprueba  si  el  Nick  utilizado  por  el  usuario  está  disponible  en  la  base  de  datos  o  ya  está  usado.  

• getDificultad:  obtiene  la  descripción  de  la  dificultad  de  las  parcelas  de  cada  usuario.  • getFactAct:  obtiene  el  IPC  a  partir  del  año,  usado  en  el  cálculo  de  costes  de  máquinas  y  

en  explotaciones  agrícolas.  • getMaquinas:  filtrar  las  máquinas  públicas,  usado  por  el  administrador  en  el  portal  de  

administración  de  máquinas  públicas.  • gruposMaquinaria:  obtiene  los  grupos  de  las  máquinas  de  la  aplicación  en  los  distintos  

idiomas.  

• userModel.php:  contiene  todos  los  métodos  necesarios  para  realizar  las  acciones  de  la  clase  “userController.php”.  Los  explico  a  continuación  organizados  por  funciones:

• Funciones  de  obtención  de  usuarios  por  medio  de  distintos  parámetros. getUsuario_by_USERNAME  getUsuario_by_USERNAME_and_PASS  getUsuario_by_mail  getUsuario_by_id  getUsuario_by_ID_and_CODE  

Todas  estas  funciones  nos  devuelven  el  usuario  con  todos  sus  datos,  la  única  diferencia  entre  ellas  es  que  para  obtener  el  usuario  utilizamos  distintos  datos  pertenecientes  a  él.  

• Funciones  para  comprobar  si  existe  o  no  un  usuario:  o existeUsuario_by_ID  o existeUsuario_by_ID_and_PASS  

• Funciones  de  registro  y  activación  de  un  usuario:  

o registrarUsuario  o activarUsuario  

 • Funciones  para  modificar  datos  de  un  usuario:  

o modifyUser  o changePassUser  

Tablas:  fincas,  usuarios  y  máquinas  usuarios

 

11    

Vistas  

Vistas  agrícola  

Vistas  error  e  index  

• Andrés   generó   un   fichero   con   la   cabecera   y   otro   con   el   pie   de   todas   las   páginas,   siendo  necesario  importar  dichos  ficheros  en  cada  página.  

• Las   vistas   como   observamos   están   organizadas   en   carpetas,   cada   una   de   las   cuales   tiene  dentro   ficheros   PHP   encargados   de   unas   funciones   más   específicas   que   comentaré   a  continuación:  

• Layout:  Cabeceras  pertenecientes  al  usuario  cuando  éste  está  y  no  logueado  y  el  pie  serán  almacenadas  en  views/layout/agrario.    

 

La   carpeta   agrario   contiene   la   plantilla   específica   creada   para  esta   aplicación.   Además   de   las   cabeceras   y   pie   también   podrá  almacenar  hojas  de  estilo  (carpeta  css),   imágenes  (carpeta  img)  y  archivos  JavaScript  (carpeta  js). El  cuerpo  de  la  página  está  localizado  en  el  fichero  index.phtml,  almacenado  en  views/agricola  

La   carpeta  agrícola   contiene   las   vistas  asociadas  al   controlador  agrícola.  

La   vista   “private_admin.phtml”   es   la   que     mostrará   todos   los  elementos  susceptibles  de  creación,  modificación  y  borrado  en  la  aplicación  para  el  usuario  registrado,  en  este  caso  máquinas  privadas  y  fincas.  

La   vista   “public_admin.phtml”,   es   la   vista   que  mostrará   todos  los  elementos  susceptibles  de  creación,  modificación  y  borrado  en  la  aplicación  para  el  administrador  (en  este  caso  usuarios).  

Error:  Vistas  para  mostrar  los  errores.  Index.phtml:  Vista  que  nos  muestra  el  cuerpo  de  la  página.          

Carpeta  “User”:  Contiene  todas  las  vistas  referentes  a    usuarios  en  la  aplicación.    Carpeta   “forms”:   en   ella   están   las   vistas   para   los   formularios   de  registro  y  cambio  de  contraseña  del  usuario.  En  la  carpeta  raiz  observamos  las  siguientes  vistas:  

• perfil.phtml  :  vista  que  muestra  los  datos  del  usuario  a  modificar.  

• activacion.phtml:   vista   que   mostrará   el   estado   en   el   que   se  encuentra  el  registro.  

• data_changes.phtml:   vista   que   mostrará   el   estado   en   el   que   se   encuentra   el   cambio   de  contraseña.  

Las  vistas  que  se  observan  en  la  imagen  pero  que  no  he  comentado,  son  parte  de  este  TFG  y  serán  comentadas  más  adelante.  

 

Vistas  de  usuario  

 

12    

Análisis  del  diseño  

La   parte   gráfica   de   la   aplicación   referente   a   los   formularios   de   inserción   y  modificación     de  usuarios,  máquinas  y  de  fincas  está  desarrollada  mediante  fancybox.  

Cuando  se  comenzó  con  el  desarrollo  de  la  aplicación,  resultaban  interesantes  y  agradables  a  la  vista,  pero  ahora  mismo  comentando  con  el  tutor,  acordamos  reducir  los  fancybox  porque  la  aplicación  se  estaba  sobecargando  de  ellos  y  ya  no  resulta  tan  agradable  para  su  manejo.  Nos  parecio  más  cómodo  poder  introducir  los  datos  directamente  en  la  misma  ventana  que  tener  que  abrir  un  “pop-­‐up”  y  tener  que  rellernarlo.  Creo  que  es  más  comodo  trabajar  de  esta  última  manera   e   implementarlo   internamente   mediante   AJAX(elementos   dinámicos)   en   lugar   de  ventanas  emergentes  que  pueden  dificultar  el  uso  de  la  misma  a  los  usuarios.  

 

 

 

 

 

             

             

La  interfaz  general  de  la  página  considero  que  es  bantanste  usable  e  intuitiva  y  que  cualquier  usuario  sin  demasiados  conocimientos  de   informatica  podrá  manejar   la  aplicación  sin  ningún  problema.  Para  conseguir  esto  se  ha   tenido  que  hacer  un  uso  reducido  de  HTML5  y  de  CSS3  aunque  queda  la  posiblidad  de  que  más  adelante  dicha  interfaz  sea  objeto  de  modernizarse  y  actualizarse.              He   continuado   con   todas   las   funcionalidades   ya   desarrolladas.   Al   principio   voy   a   analizar   el  código  de  la  aplicación,  lo  cual  ayudará  a  ir  comprendiendo  como  está  realizada.    Una   vez   analizado   y   con   la   ayuda   y   opinión   del   tutor   vemos   que   algunas   funcionalidades  pueden  corregirse  o  mejorarse.      Al  comenzar  con  el  proyecto  me  ha  aparecido  la  primera  dificultad.  Andrés  no  había  utilizado  un  controlador  de  versiones  y  la  versión  que  me  pasó  de  la  aplicación  no  era  una  versión  final.  Este  problema   lo   solucionamos  en  breves  días  quedando  con  Andrés,   se  descargó   la   versión  que  estaba   instalada  en  el   servidor  de   la  Universidad  y  me   la  pasó.  Este  motivo  me  obligo  a  utilizar    un  controlador  de  versiones  como  durante  el  desarrollo  del  TFG.  El  controlador  elegido  es  GIT  ya  que   lo  hemos  utilizado  en   la  asignatura  de  desarrollo  de  aplicaciones  móviles  y  ya  conocía  su  funcionamiento.    Las  mejoras  de  las  funcionalidades  comentadas  anteriormente  son  las  siguientes:  

 § Funcionalidad  deshabilitada  del  botón  que  genera  el  PDF  con  los  costes.  § Opción  recordar  contraseña  a  los  usuarios  registrados.  § Dar  de  alta  usuarios  comprobando  su  correo  electrónico,  lo  cual  solo  permitirá  dar  

de  alta  un  usuario  si  su  correo  electrónico  no  está  almacenado  en  la  base  de  datos.  § Dar  la  opción  de  borrar  usuarios  registrados  en  la  aplicación.  § Modificar   el   nombre  de   “máquinas   arrastradas”   por  Aperos   en   todos   los   lugares  

que  aparece  ese  nombre  en  la  aplicación  ya  que  fue  un  exigido  por  el  cliente.  Esta  mejora  se  realizará  si  ninguna  complicación.      

Ejemplo  de  fancybox  

 

13    

Código  de  generación  PDFs  

Funcionalidad  deshabilitada  del  botón  que  genera  el  PDF  de  los  costes.    En  una  reunión  con  el  tutor  dedicada  a  mostrarme  el  funcionamiento  de  la  aplicación,  se  dio  cuenta   que   la   funcionalidad   para   generar   un   documento   con   los   datos   de   la  maquinaria   no  funcionaba.  Existía  un  botón  de  imprimir  pero  no  realizaba  su  función.    De  entre   las  opciones  que  disponía  para  dar   funcionalidad  a  este  botón,  me  decidí  por   la  de  pasarlo   a   PDF   ya   que   es  muy   cómodo   a   la   hora   de   imprimir   el   documento   y   no   permite   su  modificado.   Buscando   en   internet   encontré   dos   librerías   FPDF8   y   JSPDF9.   Analizándolas  más  detenidamente  vi  que  eran  bastante  similares  y  las  dos  servían  para  lo  que  necesitaba,  añadir  texto  y  insertar  imágenes.  Con  las  dos  opciones  disponibles  opté  por  elegir  JSPDF.      El  primer  problema  que  me  encontré  fue  a  la  hora  de  introducir  caracteres  no  ASCII,  como  los  acentos   y   los   símbolos   como   el   del   euro   (€).   Otro   problema   surgió   a   la   hora   de   insertar   las  imágenes   en   el   documento   PDF,   no   se   insertaban   de   manera   correcta   intentando   pasarlas  como  imagen  directamente.  Buscando  soluciones  en  internet  al  segundo  problema,  opté  por  la  siguiente  alternativa;  transfórmala  a  data  URI10  generada  en  Base64  por  medio  de  la  siguiente  web11.   El   proceso   para   ello   es   sencillo,   en   la   página   web   seleccionamos   la   imagen   que  queremos  transformar  y  la  misma  página  nos  la  transforma  a  Base64,  lo  cual  sí  nos  sirve  para  insertarla  en    nuestro  PDF  sin  problemas.        Como   observamos   en   la  imagen   a   la   hora   de   escribir  tenemos   que   indicar   la  posición  del  texto/imagen  que  añadimos.   El   primer   dígito   se  corresponde   con   el   margen  izquierdo   y   el   segundo   con   el  superior.  También  apreciamos  que  se  puede  cambiar  el  tipo  de  la  letra  y  su  tamaño.    No  me  he  encontrado  con  más  dificultades,  gracias  a  que  en  la  página  web  la  documentación    es   bastante   simple   y   completa,   salvo   los   acentos   y   símbolos   extraños   que   ni   utilizando   la  codificación  UNICODE    he  conseguido  solucionar  todos  los  problemas.    Finalmente  la  solución  al  anterior  problema  ha  sido  resuelta  mediante  el  siguiente  plugin:    

• jspdf.plugin.standard_fonts_metrics.    El   cual   puede   descargarse   desde   la   siguiente   web:   https://code.google.com/p/bdd-­‐biocomp/source/browse/trunk/js/jspdf/jspdf.plugin.standard_fonts_metrics.js?r=129  

 Con  este  plugin,  no  hace  falta  hacer  nada  para  que  se  corrijan  los  errores  de  acentos,  símbolos  especiales   etc.   Simplemente   se   le   pasan   los   datos   con   los   acentos   y   los   símbolos   ya  comentados  como  se  los  pasábamos  anteriormente  y  el  plugin  se  encarga  de  transformarlos  al  formato  adecuado  (con  los  símbolos  que  antes  no  reconocía).          8  FPDF:  http://www.fpdf.org  9  JSPDF:  https://parall.ax/products/jspdf  10  Página  para  transformar  imagen  a  data  URI:  http://www.greywyvern.com/code/php/binary2base64  11  data  URI:  http://es.wikipedia.org/wiki/Data:_URL  

 

14    

Emails  de  confirmación  

Opción  recordar  contraseña  a  los  usuarios  registrados    Si  un  usuario  no  recordara  su  contraseña  a  la  hora  de  acceder  a  la  página  se  tendría  que  volver  a  registrar  como  otro  usuario  para  poder  utilizarla,  lo  cual  perjudicaría  a  nuestra  base  de  datos  la   cual   incrementaría   el   número   de   usuarios   que   no   se   volverán   a   utilizar   nunca  más.   Otro  argumento  para  dar  dicha  funcionalidad  es  cumplir  con  la  ley  LOPD.  Podría  darse  el  caso  que  un  usuario   introdujese  datos  personales   en   la  base  de  datos   y   la   próxima   vez  que   intentase  acceder  a   la  aplicación  no  recuerde  su  contraseña.  Si  se  diese  este  caso  y  el  usuario  quisiera  borrar   sus   datos,   no   podría   eliminarlos   ya   que   no   tiene   acceso,   con   el   correspondiente  incumplimiento  por  nuestra  parte  de  la  LOPD.    Su  funcionamiento  es  el  siguiente:  Al  pulsar  sobre  “Olvido  contraseña”  nos  solicitará  el  correo  electrónico.   Debemos   escribirlo   en   el   campo   de   texto   y   pulsar   sobre   el   botón   enviar.   A   los  segundos   recibiremos   un   correo   con   un   enlace   el   cual   deberemos   pulsar;   a   continuación  accederemos   a   una   caja   de   texto   donde   escribir   la   nueva   contraseña   dos   veces   para   evitar  escribirla  mal.  Se  almacenará  la  nueva  contraseña  sobrescribiendo  la  que  había  anteriormente.  Una  vez  modificada  se  enviará  un  correo  al  usuario  para   informarle  de  que  su  contraseña  ha  sido  cambiada,  por  motivos  de  seguridad.      Para  la  realización  de  dicha  funcionalidad  intervienen:  

• El   controlador:   userController.php   y   los   métodos   recordarCuenta,   reMail   y  changePass.  

• El  modelo:  userModel.php.  • Las  vistas:  views/user  mailenviado.phtml,  views/user/form  formPerfil.phtml.  

                                   Como   vemos   en   las   imágenes   “Emails   de   confirmación”,   son   pruebas   realizadas   para  comprobar  que  su  funcionamiento  es  el  adecuado.                

 

15    

Registro  de  usuario  

Configuración  phpmailer  

Configuración  de  la  librería  phpmailer    Para   que   la   librería   phpmailer   funcione   correctamente   deberemos   configurar   los   siguientes  parámetros:  

• Host  • Secure  • Port  • Username  • Password  

               Dar  de  alta  usuarios  comprobando  su  correo  electrónico    En  una  reunión  con  el  tutor  observamos  que  cuando  das  de  alta  un  a  usuario  en  la  aplicación,  solo  se  comprobaba  que  no  exista  el  Nick  en  la  base  de  datos.  Esto  no  es  del  todo  correcto  ya  que  solo  se  debería  permitir  dar  de  alta  a  un  usuario  comprobando  que  su  correo  electrónico  no  esté  registrado.  Para  solucionar  esto  pensé  en  comprobar  además  del  nombre  de  usuario  el  correo  en  la  base  de  datos,  pudiendo  solo  almacenar  un  usuario  por  cada  correo  electrónico.      

Como   observamos   en   la   imagen,   ya   hay   un   usuario   registrado  con   ese   correo   electrónico   y   no   nos   permitirá   continuar   el  proceso  sin  introducir  un  correo  inexistente.  Esta  comprobación  se  realiza  instantáneamente  mediante  JavaScript  en  el  servidor.    Para  la  realización  de  dicha  funcionalidad  intervienen:  

• El  controlador:  userController.  • El  modelo:  userModel.  • Las  vista:  views/user/form  formRegistro.phtml.  

       En  la  foto  “Registro  de  usuario”  observamos  que  su  funcionamiento  es  el  correcto,  ya  que  nos  avisa  que  el  correo  que  se  está  utilizando  para  dar  de  alta  un  nuevo  usuario  ya  está  registrado  y  nos  avisa  sin  permitir  su  registro.    Dar  la  opción  de  borrar  usuarios  registrados  en  la  aplicación    Veo  importante  añadir  la  funcionalidad  de  dar  la  opción  a  los  usuarios  de  poder  darse  de  baja  ellos  mismos  de  la  aplicación  web.  Como  no  está  implementada,  he  decidido  realizarla.    Su   funcionamiento  es   simple,  un  usuario   logueado  accede  a   su  perfil   y  ahí  pulsa  en  eliminar  usuario.  Antes  de  eliminar  completamente  los  datos  de  los  usuarios  de  la  base  de  datos,  hablé  con   el   tutor   sobre   la   opción   de   almacenar   al   usuario   en   un   estado   similar   a   cuando   nos  registramos  por  primera  vez  pero  aun  no  hemos  confirmado  nuestra  cuenta.    Enseguida  desechamos  esta  opción  ya  que  pensando  un  poco  más,  nos  dimos  cuenta  que  el  usuario  estando  en  el  estado  previo  a  su  eliminación  completa,  no  podría  el  volver  al  estado  de  

 

16    

confirmar   su   cuenta.   Por   esto   decidí   borrar   los   datos   directamente   cuando   dicho   usuario  elimina  su  cuenta.  Si  quisiese  volver  a  usar  la  aplicación,  tendrá  qué  volver  a  registrarse.    Para  la  realización  de  dicha  funcionalidad  intervienen:  

• El  controlador:  userController  y  el  método  deleteUser  .  • El  modelo:  userModel.  • Las  vista:  views/user/form  formDelUser.phtml.  

             

         Justificación  de  las  horas  descompensadas  en  la  planificación      Esta  primera  iteración  se  ha  desviado  5  horas  de  lo  planificado  debido  a  varios  factores:  

• He   invertido   3   horas   más   de   las   previstas   en   conocer   cómo   estaba   desarrollada   la  aplicación  de  Andrés  y  adaptarme  al  lenguaje  utilizado  PHP.  

• He  invertido  1  hora  más  de  las  previstas  en  la  corrección  del  PDF  que  generaba  con  los  datos  de  la  maquinaria,  debido  a  las  exigencias  por  parte  del  cliente.  

• La  última  hora  descompensada   se  ha  debido  a   la   inversión  de  minutos  extra   con   los  que  no  contaba  entre  las  nuevas  funcionalidades  a  desarrollar  y  a  la  realización  de  las  pruebas  para  comprobar  el  correcto  funcionamiento  de  las  modificaciones.  

   Valoración  por  parte  del  cliente    El  cliente  después  de  mostrarle   los  avances  en   la  aplicación  dio  su  visto  bueno  a   las  mejoras  desarrolladas  y  sugirió  algunos  cambios  en  el  PDF  generado.  En  el  PDF  exigió  que  se  añadiera  un   pie   de   página   indicando   en   él   que   la   aplicación   no   se   hace   responsable   del   uso   que   los  usuarios   puedan   realizar   de   ella,   simplemente   es   una   aplicación   para   prever   los   costes  agrícolas.   También   recalcó   que   los   campos   más   importantes   del   PDF   como   son   los   totales  debían  estar  en  negrita.    Conclusiones  de  la  iteración    Esta   iteración   me   ha   resultado   bastante   beneficiosa   para   poder   conocer   más   a   fondo   la  aplicación,   ver   como   está   desarrollada   por   el   anterior   alumno   e   ir   conociendo   parte   de   su  código.  Observando  el  nuevo  patrón  MVC  he  preferido  amoldarme  a  él  y  proporcionar  nuevas  funcionalidades  a  la  aplicación  que  invertir  tiempo  en  adaptarlo  a  un  Framework  ya  existente  y  continuar  desde  ese  punto.  No  me  ha  llevado  excesivo  tiempo  en  comprender  el  patrón  MVC  creado   por   Andrés   debido   al   conocimiento   previo   de   dicho   patrón   y   realizando   las  funcionalidades  que  he  comentado  anteriormente  en  esta  iteración  de  manera  similar  a  lo  ya  desarrollado  por  él,  el  proceso  de  adaptación  ha  sido  sencillo.  

Perfil  de  usuario  

 

17    

Base  de  datos  

ITERACION  1.  Realización,  modificación,   búsquedas   y   cálculo   de   costes  de  las  tareas  asociadas  a  las  explotaciones  agrarias.    

Objetivos  

Esta   iteración   tiene   como   objetivo   la   realización   de   “tareas”   agrarias.   Una   tarea   agrícola   la  entendemos   como   los   trabajos  que   realiza  un  agricultor   con  ayuda  de  maquinaria,  mano  de  obra   y   los   productos   fitosanitarios   para   su  mantenimiento.   Siguiendo   los   requisitos   exigidos  por  parte  del  cliente  una  tarea  está  formada  por  una  Finca,  0  ó  1  Máquina  Autopropulsadas    y  por  0..5  Aperos  (Máquinas  arrastradas).  (en  posteriores  iteraciones  se  añadirá  la  mano  de  obra  y  los  productos  fitosanitarios)  

 

Base  de  datos    

Entre  las  posibles  opciones  que  he  barajado  a  la  hora  de  realizar  el  diseño  de  la  base  de  datos  están  las  siguientes:  

• Crear  una  tabla  “tareas”,  compuesta  de  1  campo  para  las  máquinas  autopropulsadas  y  5  campos  más  para  los  aperos.  

• Crear  una  tabla  intermedia  entre  “tareas”  y  “maquinas”,  las  cuales  estarían  relacionadas  por  medio  de  la  idTarea  e  idMaquina,  en  la  cual  cada  fila  formaría  parte  de  una  tarea  con  una  máquina.  

Presentándole  las  dos  alternativas  al  tutor,  llegamos  a  la  conclusión  de  que  la  opción  más  interesante  era  la  segunda  aunque  conllevase  mayor  complejidad.  Esta  solución  permitirá  realizar  modificaciones  o  mejoras  más  adelante  de  una  manera  más  simple  para  la  persona  que  continúe  el  proyecto.  

 

Descripción  de  las  nuevas  tablas  creadas    

La  nueva  tabla  “tareas”,  almacena  registros  de  tareas  realizadas  por  el  usuario  en  una  finca,  de  la   cual   es   propietario   y   con   sus   propias   máquinas   (autopropulsadas   y   aperos).   Cuando   se  nombra  “sus  propias  máquinas”  se  hace  referencia  a  las  máquinas  creadas  por  el  usuario  en  la  aplicación,  ya  que  dentro  de  ésta  se  dividen  en  públicas  y  privadas.  Las  máquinas  privadas  son  las   que   el   usuario   da   de   alta   y   solo   él   puede   utilizarlas,  mientras   que   las   públicas   ya   están  dadas   de   alta   en   la   base   de   datos   y   están   disponibles   para   cualquier   usuario   que   utilice   la  aplicación.  

Los  campos  de  esta  tabla  son:  

• idTarea:  identificador  de  la  tarea  de  tipo  entero.  • idFinca:  identificador  de  la  finca  de  tipo  entero.  •  descripción:  nombre  que  el  usuario  da  a  la  tarea  de  tipo  string.  •  anch_trabajo:   capacidad  de   trabajo  que   tiene   la  máquina   autopropulsada   calculada  

en  metros  para  trabajar  una  explotación  agrícola.  •  vel_trabajo:   velocidad  media   en   km/h   a   la   que   una  máquina   trabaja   la   explotación  

agrícola.  •  numPases:   número   de   pasadas   necesarias   de   la   maquinaria   para   la   correcta  

realización  de  la  tarea  en  la  explotación  agraria.  

 

18    

•  coste_trabajo:   sumatorio   de   todos   los   costes   implicados   en   la   tarea   (Maquinaria,  mano  de  obra,  productos  fitosanitarios).    

Como  se  puede  observar  en  la  imagen  “Base  de  datos”,  está  relacionada  con  “fincas”  y  “tareas_maquinas”.  

Esta  tabla  tiene  la  siguiente  restricción:  

• Una  tarea  está  formada  por  0  ó  1  máquinas  autopropulsadas  y  por  0..5  aperos.    

Dicha  restricción  se  va  a  controlar  mediante  programación  de  la  aplicación,  utilizando  las  consultas  adecuadas  a  la  base  de  datos  y  obteniendo  así  el  numero  de  filas  con  un  count.  Este  numero  de  filas  devuelto  será  controlado  para  evitar  violar  la  restricción.    La  relación  entre  las  tablas  “tareas”  y  “maquinas”  es  de  tipo  “n”  a  “n”,   la  cual  da  lugar  a  una  tabla   intermedia   llamada   “tareasMaquina”,   dicha   tabla   estará   formada   por   los   siguientes  campos:  idTarea,  idMaquina  y  num_campo.    Diseño    Una  vez  definidos  los  requisitos  por  parte  del  cliente,  surgieron  varias  alternativas  que  podrían  satisfacer   todos   ellos,   de   entre   las   cuales   habría   que   elegir   la   interfaz  más   intuitiva   para   el  usuario.    En  una  reunión  con  el  tutor  se  acordó  eliminar  el  estilo  utilizado  anteriormente,  el  cual  estaba  basado  en  fancybox.  Para  nuestro  punto  de  vista  los  fancybox  complicaban  la  usabilidad  de  la  aplicación  al   usuario   como  ya  he   comentado  anteriormente.  Como  alternativa   a  esto,   decidí  realizar   una   tabla   mostrando   únicamente   los   campos   más   relevantes   para   el   usuario.   Esta  solución   tenía   un   problema;   la   tabla   quedaba   muy   bien   con   8   columnas   pero   faltaban   de  añadir  las  máquinas,  lo  que  implicaba  añadir  5  columnas  más.  La  tabla  empezaba  a  crecer  de  manera   desmesurada,   lo   cual   quedaba   estéticamente  poco   visible   y   ya   no   imaginemos   para  dispositivos   como   tablets   o  móviles,   no   se   llegarían   a   percibir   de  manera   correcta   todos   los  campos.  Si  seguimos  añadiendo  más  columnas  hacia  la  derecha  habría  que  añadir  una  barra  de  scroll  para  desplazarnos  y  poder  visualizarla  de  manera  completa.      Con   la   ayuda   del   tutor   llegamos   a   la   conclusión   de   dividir   la   tarea   en   categorías   como   son:  máquinas,  mano  de  obra  y  productos  fitosanitarios  e  ir  mostrando  en  cada  fila  una  categoría.  Por  ejemplo:  la  primera  fila  para  las  características  de  la  tarea,  la  siguiente  para  las  maquinas  …etc.  De  esta  manera  se  pueden  añadir  mas  categorías  a  la  tarea  de  manera  sencilla  y  visible.      Esta   solución   se   consideró   como   la  mejor   con   vistas   al   futuro.   Es   la   que  mejor   se   adapta   a  posibles   funcionalidades   que   se   le   añadirán   a   la   aplicación   y   sobre   todo   a   las   siguientes  iteraciones  en  las  cuales  añadiremos  las  categorías  mano  de  obra  y  productos  fitosanitarios.    Una   vez   diseñada   la   tabla   y   después   de   realizar   varias   pruebas,   añadiendo   varias   tareas,  percibimos  que  aun  se  podría  mejorar  un  poco  más  el  apartado  de  visibilidad  para  el  usuario.  El  tutor  sugirió  la  idea  de  dar  la  opción  de  ocultar  las  filas  secundarias  de  la  tarea  con  un  botón  y  con  otro  volver  a  mostrarlas,  para  conseguir  de  esta  manera  reducir  el  numero  de  filas  de  la  tabla.        

 

19    

Tabla  tareas  1  

Tabla  tareas  2  

             Como  se  observa  en  la   imagen  “Tabla  tareas  1”,   la  primera  fila  de  cada  tarea  se  corresponde  con  datos  generales  de  ella  y  la  segunda  con  la  maquinaria  empleada  en  dicha  tarea.  De  esta  forma  apreciamos  de  manera  rápida  qué  fila  corresponde  a  cada  tarea.  En   la  segunda  fila  de  cada  tarea,  el  primer  campo  contiene  un  texto  que  indica  qué  categoría  de  elementos  hay  en  las  siguientes  casillas  de  la  fila.    Junto  a  la  descripción  de  la  tarea  vemos  estos  dos  botones  :     El   botón   verde   con   el   +  indica  que  se  han  ocultado   las   filas  de   la   tarea  y  pulsando  sobre  él   volveríamos  a  ver  dichas  filas  que  están  ocultas.  El  botón  azul  con  el  menos  hace  lo  contrario,  oculta  las  filas  de  la  tarea  dejando  solo  visible  la  primera  fila  de  la  tarea.  Al  pulsar  sobre  uno  de  ellos,  realizará  su  función  y  desparecerá  dejando  sitio  a  su  contrario.    La   última   fila   en   blanco   la   utilizaremos   para   añadir   tareas   nuevas.   Los   botones   de   la   parte  derecha  dan  la  funcionalidad  de  editar,  eliminar  y  guardar  tarea.    Comentando   con   el   tutor   cómo   podríamos  mejorar   la   interfaz,   surgió   la   idea   de   solo   dejar  habilitados  los  combos  de  las  maquinas  autopropulsadas,  que  se  corresponden  con  el  primer  combo  de   cada   tarea   situado   el   primer   campo  de   la   fila  máquinas   y   una   vez   que   el   usuario  haya   seleccionado   una   de   ellas,   se   vayan   habilitando   los   combos   de   los   aperos   uno   a   uno.  Cuando   seleccione   un   apero,   que   pueda   añadirle   otro,   pero   no   todos   disponibles   desde   el  comienzo.                                      

 

20    

Filtros  1  

Filtros  2  

Cuadro  de  costes  

Costes  tarea  

Como  alternativa  a  este  diseño,  se  consideró  la  posibilidad  de  generar  la  tabla  de  manera  más  dinámica.   La   idea   me   pareció   bastante   interesante,   ya   que   permitía   poder   modificar   o   dar  mayor  funcionalidad  a  la  aplicación  para  futuros  cambios.  Al  final  he  decidido  ceñirme  a  lo  que  el  cliente  me  dijo,  ya  que  especificó  de  manera  muy  clara  que  en  una  tarea  podían  intervenir  0  ó  1  máquinas  autopropulsadas  y  en  caso  de  haber  una,  0  ó  5  aperos.    Durante   la   realización  de   las  pruebas  de   funcionamiento,   el   tutor   y   yo  nos  dimos   cuenta  de  que  se  podrían   insertar  unos  filtros  que  permitiesen  realizar  búsquedas  en   la  aplicación.  Esta  funcionalidad  puede  resultar  muy  útil  para  un  usuario  que  tenga  almacenadas  bastantes  tareas  y  necesite  encontrar  de  manera  rápida  una  de  ellas,  conociendo  algún  campo  de  ella.  A  la  hora  de  plantear  su  diseño,  decidí  situarlos  en  la  parte  superior  de  la  tabla  ya  que  pensé  que  es  la  parte  más  adecuada  para  que  la  interfaz  sea  lo  más  simple  al  usuario.  Como  vamos  a  ver  en  las  siguientes  imágenes,  nada  más  cargar  la  pagina  nos  aparecería  el  siguiente  filtro.            A  la  derecha  de  la  imagen  observamos  dos  iconos,  uno  en  rojo  con  un  menos  y  uno  azul  con  un  más.   Estos   iconos   sirven   para   añadir   un   filtro   de   búsqueda  más   o   eliminarlo   si   ya   lo   hemos  añadido  anteriormente.            Si  buscamos  por  medio  de   los  dos  filtros,   lo  que   la  aplicación  realizará  es  una  búsqueda  más  estricta.  Buscará  las  concordancias  en  la  tareas  con  lo  que  indiquemos  en  los  dos  filtros,  si  solo  encontrase  concordancia  con  uno  de  ellos,  no  mostrará  nada.    Los  costes  de  cada  tarea  se  mostrarán  en  un  nuevo  campo  situado  en  la  parte  de  la  derecha  de  cada  fila.    La  primera  fila  que  contiene   los  datos  generales  de   la  tarea  nos   informará  también  del  coste  global   de   la   tarea,   así   cuando   minimizamos   las   líneas,   veremos   además   de   dichos   datos   el  coste   total,  ya  que  es  un  dato   fundamental  para  el  usuario.  En   las  demás   filas  de   la   tarea  se  mostrarán  los  costes  desglosados  (maquinaria,  mano  de  obra  y  fitosanitarios).    En   la   primera   imagen   “Cuadro   de   costes”   podemos   observar   cómo   queda   la   interfaz  permitiendo  ver  los  costes  de  la  tarea  cuando  esta  está  minimizada.          En   esta   segunda   imagen   observamos   cómo   se   desglosan   los   costes   por   categorías   que  conforman  la  tarea,  en  este  ejemplo:  la  maquinaria.  

 Debido  a  los  problemas  con  el  cálculo  de  los  costes  de  las  tareas  que  comentaré  un  poco  más  adelante  me  he  visto  obligado  a  realizar  modificaciones  en  el  formulario  de  insertar  máquina  “formMaquina.php”.      

 

21    

Priavte_admin.js  

Función  pintaTabaTareas  

 Variables  globales  

Implementación    La   tabla   HTML   donde   aparecen   de  manera   visual   las   tareas,   está   desarrollada   en   el   fichero  private_admin.phtml.  Dentro  de  este  hay   llamadas  a  métodos  situados  en  private_admin.js  y  entre  ellos    los  que  vemos  en  la  siguiente  figura.                        Nos  vamos  a  centrar  en  la  función  “pintaTablaTareas”  situada  en  dibujar_tablas.js  que    permite  plasmar  las  tablas  y  los  datos  en  la  tabla  mediante  JavaScript.                                    Dicha  función  recibe  el  parámetro  “data”  que  son  todas  las  tareas  almacenadas  en  la  base  de  datos  del  usuario  logado,  para  poder  “pintar  ”  la  tabla  con  todos  los  datos  necesarios.    Como  he  comentado  anteriormente,  desde  esta   tabla   se  da   la  opción  de  añadir,  modificar   y  editar   tareas.  Para  controlar  en  qué   tarea  está   interactuando  el  usuario  he  añadido   ids  a   las  filas  de  la  tabla  y  a  sus  columnas.  Por  medio  de  DOM12  he  ido  controlando  en  qué  parte  de  la  tabla  está  el  usuario.        El   controlador   encargado   de   todos   estos   cambios   es   “agricolaController.php”,   el   cual   se  comunica  con  “agricolaModel.php”  para  modificar  la  base  de  datos  con  los  nuevos  cambios  de  la  tarea.    A   la  hora  de   llevarme   los  datos  del   fichero   JavaScript  y  almacenarlos  en   la  base  de  datos,  el    controlador  encargado  de  esta  tarea  es  el   “ajaxController.php”.  Mediante  Ajax,  se  envían   los  datos  a  este  controlador.  Gracias  al  fichero  var_globales,  lo  que  hago  es  definir  a  qué  método  de  los  siguientes  deben  de  ir  los  datos  almacenados  en  el  fichero  Json  para  la  realización  de  su  tarea  correspondiente.                        12  DOM:  http://krook.org/jsdom/HTMLTableCellElement.html  

 

22    

Controlador  de  tareas  

Desplegable  maquinaria  

Filtros  3  

Una   vez   que   la   ruta   llega   al   fichero,   éste   nos   redirige   al   método   correspondiente,   como  podemos  ver  en  las  siguientes  imágenes.                Como  indican  los  nombres  de  los  métodos,  sus  funcionalidades  son:  actualizar  las  tareas  si  se  ha  modificado  alguno  de  sus  campos,  añadir  nuevas  y  eliminar  tareas  existentes.    Para  rellenar  los  menús  desplegables  con  los  datos  de  las  maquinarias,  lo  realizo  con  los  datos  de  estas  pertenecientes  al  usuario.  Por  medio  del  “agricolaController.php”  las  almaceno  en  un  array,  el  cual  lo  transfiero  a  la  vista  y  mediante  JavaScript  relleno  los  campos  selects  utilizando  para   ello   la   propiedad   name   de   cada   select.   Cada  máquina   será   almacenada   en   una   option  distinta.                    Como   he   explicado   antes   solo   están   habilitados   ciertos  menús   desplegables,   primeramente  solo  dejo  introducir  una  maquina  autopropulsada.  Una  vez  guardada  esta,  permito  que  pueda  escoger  un  apero  y  así  sucesivamente  hasta  completar  los  5  aperos  como  máximo  o  cualquier  numero  inferior  a  ese.    Filtros  de  búsqueda        En  el  primer  campo  desplegable  podemos  elegir  el   tipo  de   filtrado,  ya  sea  por  nombre  de   la  tarea,  producto  fitosanitario  utilizado  o  maquinaria  empleada  en  la  tarea  (funcionalidades  que  añadiremos  en  futuras  iteraciones).  En  la  caja  de  texto  situada  a  continuación  introduciremos  la  cadena  de  texto  que  queremos  buscar.  Especifico  claramente  que  el  filtrado  de  búsqueda  es  por  palabras  exactas,  sin  distinción  de  mayúsculas  o  minúsculas.  Por  ejemplo  si  quiero  buscar  “Cosecha”  como  descripción  de  una  tarea,  debo  escribir  “Cosecha”  o  ”cosecha”.      Los   filtros   de   búsqueda   están   situados   en   el   fichero   private_admin.phtml  mientras   que   sus  funcionalidades   están   en   el   dibujar_tablas.js.   A   la   hora   de   recoger   el   valor   que   el   usuario  introduce,  lo  primero  que  hace  la  aplicación  es  transformarlo  a  minúsculas  y  comparar  con  el  valor   de   las   tareas   también   en  minúsculas   para   evitar   que   no   encuentre   una   tarea   si   no   la  escribe  como  está  almacenada.  Esto  se  podrá  mejorar  en  un  futuro,  de  tal  manera  que  cuando  introduzcas  una  letra  el  te  sugiera  opciones  ya  almacenadas.    En   caso   de   que   intente   buscar   algo   vacío,   se   informará   al   usuario   mediante   JavaScript  indicándole  que  está  realizando  una  búsqueda  con  un  filtro  vacío.      

 

23    

Para   anidar   una   búsqueda   con   dos   filtros,   lo   que   he   hecho   es   una   función   específica   en  JavaScript  para  que  cuando  elijas  en  el  primer   filtro  una  opción  en  el  menú  desplegable,  esa  opción   no   esté   disponible   en   el   segundo   menú   desplegable,   ya   que   realizar   un   filtro   más  exhaustivo  eligiendo  el  mismo  campo  no  sirve  de  nada.    Antes  de  comenzar  con  la   implementación  pensé  en  dos  maneras  distintas  de  realizarlo.  Una  posibilidad   consiste   en   ir   a   la   base   de   datos   con   el   valor   a   buscar   y   realizar   la   consulta  adecuada  para   recoger   los  datos  y   recargar   la   tabla.   La   segunda  opción  y   la  que  he  decidido  implementar   es   la   siguiente:   recoger   el   valor   a   buscar   y   mediante   JavaScript   recorrer   los  valores  que  tengo  almacenados  en  la  tabla  HTML,  me  quedo  con  los  que  coinciden  y  vuelvo  a  pintar   la   tabla  solo  con  dichos  valores.  Con  esto  se  evita  tener  que  realizar  una  consulta  a   la  base  de  datos  por  cada  búsqueda  y  recoger   los  valores  para  pintar   la   tabla  con  ellos.  Esto   lo  hago  posible  gracias  a  estas  dos  funciones:    

   Decidí  que  era  mejor  crear  dos  funciones,  “filtros”  para  cuando  se  realice  una  búsqueda  por  un  parámetro  y  “filtros2”  para  cuando  la  búsqueda  sea  exhaustiva  y  se  busque  mediante  los  dos  parámetros.  De  esta  forma  creo  que  es  mas  simple  para  otra  persona  que  desee  modificar  los  filtros  en  una  posible  mejora  (por  ejemplo:  permitiendo  realizar  búsquedas  no  exactas).    Se   permite   realizar   búsquedas   consecutivas,   por   ejemplo   buscar   “Cosecha”,   que   nos   la  muestre  y  desde  ahí  volver  a  realizar  una  búsqueda  sin  tener  que  volver  a   la  página  anterior  donde  se  mostraban  todas   las   tareas.  Lo  he  realizado  de  esta   forma  ya  que  creo  que  es  útil,  por  si  el  usuario  se  ha  equivocado  en  buscar  una  tarea  y  realiza  una  búsqueda  consecutiva,  sin  la  necesidad  de  tener  que  regresar  a  la  página  anterior.    Ocultación  de  filas    Los  métodos  de  ocultación  y  des  ocultación  de   la   fila  de   las  máquinas  de  una   tarea  al  hacer  click  en  su  botón,  están   implementados  mediante   JavaScript  en  estas  dos   funciones  alojadas  en  el  fichero  dibujar_tabla.js.            Internamente  en  dichas  funciones  lo  que  hago  es  situarme  en  la  fila  en  la  cual  se  ha  hecho  click  en   su  botón  de  ocultar/mostrar   y  ocultarla  o  mostrarla   según   sea  el  estado  anterior  a  dicho  click.      Ordenación  de  las  tareas    Es  posible  también  la  ordenación  de  las  tareas  por  el  nombre  de  la  finca  en  la  cual  se  realizan.  Es   una   opción   bastante   interesante   para   el   usuario   si   tiene   varias   fincas   y   realiza   tareas   en  ellas,  ya  que  es  posible  realizar  más  de  una  tarea  en  una  misma  finca.    Como  podemos  observar  en  la  imagen,  vemos  los  iconos  de  una    flecha  los  cuales  sirven  para  la   ordenación   de   las   tareas.   Si   pulsamos   sobre   ella   ordena   las   tareas   en   orden   alfabético   y  dicha   flecha   cambia   de   sentido.   Si   la   pulsamos   cuando   está   en   el   otra   posición   ordena   las  tareas  de  manera  inversa  y  vuelve  a  estar  el  icono  en  la  posición  inicial.    

Métodos  de  ocultación  

 

24    

   Esta   implementación   está   desarrollada   en   dos   métodos   localizados   en   el   fichero  dibujar_tablas.js.  La  ordenación  se  realiza  utilizando  los  datos  guardados  en  la  tabla  HTML  sin  la  necesidad  de  acceder  a   la  base  de  datos  a  realizar  una  nueva  consulta  y  recoger   los  datos  que  nos  devuelve.  Para  la  ordenación  utilizo  los  métodos  sort()  y  reverse()  que  nos  devuelven  el   array  de  datos  que   le  mandamos,  ordenado  alfabéticamente  o  al   revés  por  el   campo  que  deseamos.      Costes  de  las  tareas    Llegado  al  punto  de  calcular   los  costes  de  cada  tarea,  en  una  reunión  con  el  tutor  nos  dimos  cuenta  que  había  que  realizar  cambios  en  la  versión  realizada  por  Andrés.  Dichos  cambios  en  la  parte  de  implementación  son  los  siguientes:    

• Almacenar   en   la   base   de   datos   los   costes   horarios   y   anuales   de   las   máquinas   para  luego   poder   realizar   los   cálculos   en   las   tareas.   Esto   conlleva   modificar   la   tabla   de  maquinas,  añadiéndole  dos  campos  más.      En   la   versión   anterior,   Andrés   trabajaba   con   estos   datos   sin   necesidad   de  almacenarlos;  debido  a  esto  yo  me  he  visto  obligado  a  modificar  su  implementación.      

                       

 Como  apreciamos  en  las  imágenes  anteriores,  los  campos  tasa  de  interés,  alojamiento,  carga  motor,  precio  combustible,  coste  anual  y  coste  horario  son  los  que  he  añadido  ya  que  sin  ellos  almacenados  no  puedo  ir  realizando  los  cálculos  del  coste  de  maquinaria  y  con  ello  el  coste  por  tarea.  Esto  es  debido  a  que  en  la  versión  anterior  nos  aparecía  un  pop-­‐up  en  el  cual  rellenábamos  los  datos  necesarios  para  realizar  los  cálculos  cada  vez  que  queríamos  calcular  el  coste  de  una  maquinaria  pero  no  se  almacenaban,  en  la  base  de  datos.    Surgió  un  problema  a  la  hora  de  almacenar  el  campo  coste  horario  de  cada  máquina.  Pensé  en  dos  posibilidades,  la  primera  consistía  en  almacenarlo  en  la  tabla  intermedia  entre   tareas   y   máquinas,   “tareas_maquinas”   y   la   segunda   almacenarlo   en   la   tabla  máquinas.  Me  decanté  por  esta  ultima  opción  ya  que  comentándolo  con  el  tutor,  nos  parece   más   interesante   tener   los   costes   anuales   y   coste   horarios   de   cada   maquina  junto   a   todos   sus   datos   en   la  misma   tabla   (la   otra   opción   exige   replicar   el   valor   de  coste  en  cada  tarea  qué  esté  involucrada  la  máquina).    

Tabla  anterior  

Tabla  nueva  

 

25    

• Modificar  el   formulario  de   la  creación  de  maquinas.  Debo  añadir  4  nuevos  campos  a  dicho  formulario  que  son:  Tasa  de  interés,  Alojamiento,  Carga  motor  y  Precio.  Estos  4  campos  y  alguno  más  deben  ser  rellenados  de  manera  obligatoria  por  el  usuario  para  que   los   cálculos   de   los   costes   sean   realizados   de   manera   correcta,   sino   su   coste  resultante  sería  de  0.  Todo  esto  lo  voy  a  llevar  a  cabo  deshabilitando  la  funcionalidad  de  crear  la  máquina  si  alguno  de  esos  campos  están  vacíos.  

               

   En  las  versiones  anteriores  de  la  aplicación  el  cálculo  de  los  costes  estaba  pensado  únicamente  para  los  datos  que  se  introducían  en  un  formulario,  se  recogían  en  un  fichero  js  de  costes  y  se  devolvía  el  coste  de  la  máquina  sin  distinguir  costes  fijos  como  por  ejemplo  la  amortización,  de  costes   variables   como   por   ejemplo   el   combustible.   Solo   se   calculaban   dichos   costes   de   una  máquina.   En   esta   ultima   versión   que   estoy   desarrollando   he   decidido   crear   otro   fichero  costesTarea.js  más  especifico  que  el  que  estaba  hecho.                  He   rediseñado   el   método   de   cálculo   del   tiempo   de   operación   real   de   la   tarea   en   una  explotación   agraria   entre   otros   y   he   generado   métodos   separados   para   el   cálculo   de   cada  coste  como  son:  Amortización,  Interés,    ASI  (Alojamiento,  Seguros  e  Impuestos),  Combustibles,  Reparación  y  Mantenimiento.    De   esta   forma   queda   más   sencillo   el   proceso   de   cálculo   distribuido   en   cada   uno   de   sus   7  partes.                            Para   simplificar   la   manera   de   entender   los   costes,   en   una   reunión   con   el   tutor   acordamos  dividir   los   costes   en   dos   grupos:   fijos   y   variables.   Los   costes   fijos   afectan   a   máquinas  autopropulsadas   y   a   los   aperos.   En   esta   categoría   se   engloban   los   costes   de   amortización,  

   Campos  maquinaria  

   Fichero  de  costes  

Metodos  de  cálculo  

 

26    

intereses  y  ASI.  Los  costes  variables  solo  afectan  a  la  maquinaria  autopropulsada  y  se  engloban  en   combustibles   y   reparaciones   y   mantenimiento   ya   que   en   los   aperos   estos   costes   se  desprecian.  En  el  fichero  js  “costeTareas”  sumo  los  costes  variables  y  fijos  de  cada  una  de  las  máquinas   involucradas  en   la  tarea  y  el   total   lo  almaceno  en   la  tabla  de   las  tareas.  Dentro  de  costesTareas.js   realizo   de   manera   independiente   los   cálculos   de   las   máquinas   y   a   su   vez  almaceno   el   coste   de   cada   maquinaria   en   dicha   tarea   guardándolo   en   la   tabla  “tareas_maquina”  de   la  base  de  datos  en  el  campo  “coste_maquina”.  Estos  datos  se  pueden  utilizar  más  adelante  para  la  creación  de  gráficos  y  que  el  usuario  pueda  ver  los  costes  de  cada  una  de  sus  máquinas.  Esta  última  parte  intentaré  realizarla  o  dejarla  si  no  me  da  tiempo  para  trabajo  futuro  o    futuras  mejoras.    

Como   observamos   en   la   imagen   “Tabla   tareas”,   almaceno   en   la   tabla  tareas,  el  coste  de  total  de  la  tarea  (coste_trab).  Debajo  de  este  campo  he   creado   otro   llamado   coste_maquinas   que   almacena   la   suma   de   los  costes   de   todas   las   máquinas   que   intervienen   en   la   tarea.   En   las  siguientes  iteraciones  crearé  nuevos  campos,   los  cuales  almacenarán  la  suma  de  los  costes  de  mano  de  obra  y  productos  fitosanitarios.    En   la   tabla   “tareas_maquina”   como   he   contado   anteriormente,   he  añadido   el   campo   “coste_maquina”   el   cual   solo   almacena   el   coste  individual  de  cada  maquinaria  que  interviene  en  alguna  tarea.    Estos   campos   servirán   más   adelante   para   la   creación   de   gráficos   que  pueden   ser   de   gran   utilidad   al   usuario   y   poder   apreciar   de   manera  rápida  datos  que  tendría  que  ir  desglosando  uno  a  uno.    

 El  campo  costes_maquinas  es  un  campo  derivado  o  calculable  a  partir  de  otros.  Esto  hace  que  la  Base  de  datos  no  esté  normalizada.  Si  utilizamos  la  aplicación  como  un  usuario  normal  (sin  modificar   la   base   de   datos   desde   phpmyadmin)   no   tendremos   este   problema   ya   que   más  adelante   realizaré   la   funcionalidad  para  que   se  actualicen   los   costes   cada  vez  que  el  usuario  acceda  a  una  tarea.    Estudiaré   también   la   posibilidad   de   insertar   disparadores   o   algún  método   programado   para  recalcular   los   costes   si   se   cambia   algún   campo   de   la   tabla   “maquinas”   o   de   la   explotación  agrícola,  ya  que  actualmente  si  se  realizase  algún  cambio  en  ellas  el  usuario  tendría  que  pulsar  el  botón  de  “recalcular”  los  costes  de  la  tarea  asociada  a  esa  máquina  o  explotación.    Dificultades  en  la  implementación    En   la   implementación  apareció  un  problema  a   la  hora  de  enviar  el   array   con   los  datos  de   la  tarea  que  el  usuario  ha  modificado  y/o  insertado  como  nuevos.  La  dificultad  consistía  en  como  enviar  el  array  con  todos  los  datos  desde  un  fichero  JavaScript  a  un  controlador  en  PHP.  Como  solución  he  utilizado  AJAX13  y  JSON14.  Los  pasos  para  su  resolución  son  los  siguientes:  crear  un  objeto  de  tipo  JSON  en  el  que  almaceno  todos  los  datos  a  enviar  al  controlador  mediante  AJAX,  en  dicho  controlador  capturo  el  objeto  JSON,  el  cual  lo  transformo  en  un  tipo  array  en  el  que    tengo  todos  los  datos  de  manera  accesible  y  con  ellos  los  envío  al  modelo  correspondiente  para  almacenarlos  en  la  base  de  datos.  Gracias  a  AJAX  me  permite  poder  enviar  el  objeto  JSON  desde  el  fichero  JavaScript  al  controlador  que  le  indique  en  la  ruta.    13  Ejemplo  de  AJAX:  http://stackoverflow.com/questions/19462649/trying-­‐to-­‐pass-­‐variable-­‐values-­‐from-­‐javascript-­‐to-­‐php-­‐using-­‐ajax  14  JSON:  http://www.w3schools.com/json/  

Tabla  tareas  

 

27    

Otra   dificultad   apareció   a   la   hora   de   implementar   los   combo-­‐box   de   los   aperos.   La   idea   de  implementación   de   estos   menús   desplegables   era   la   siguiente:   como   he   comentado  anteriormente  en  primer  lugar  solo  estaría  habilitado  el  menú  desplegable  de  la  maquina  auto  propulsada.   Una   vez   elegida   una   se   habilitará   el   primer   desplegable   de   los   aperos   y   así  sucesivamente.  Una  vez  seleccionado  un  apero,  en  el  siguiente  menú  desplegable  ese  apero  ya  no   debe   aparecer   en   la   lista   de   ese   menú,   hasta   aquí   todo   bien.   A   continuación   detallo   el  problema  que  me  surgió:                  Como  podemos  apreciar  en  la  fotografía  “Desplegable  aperos  1”,  una  vez  almacenada  la  tarea,  si  pulsamos  sobre  un  menú  desplegable  que  no  sea  el  primero  de  los  aperos,  se  nos  volverá  a  mostrar  toda  la  lista  de  aperos.  Como  solución  a  este  problema  he  decidido  solo  rellenar  con  datos   los  menús  desplegables  de   la  autopropulsada  y  del  primer  apero,  en  vez  de  todos  a   la  vez,  y  así   ir  rellenando  los  siguientes  desplegables  con  los  aperos  restantes  y  de  esta  manera  no  permitir    escoger  otro  valor  repetido.  He  desarrollado  una  función  a  la  par  que  se  encarga  de  recorrer  los  menús  de  los  aperos  ya  seleccionados  y  guardando  solo  los  disponibles  para  los  siguientes  menús,  de  esta   forma  no  hay  posibilidad  de   introducir  un  apero  dos  veces  en  una  misma  tarea.    La   característica   de   esta   aplicación   una   vez   el   usuario   tenga   la   tarea   almacenada   y   desee  modificar   algún  apero,   deberá   seleccionar  desde  el   primer  menú  despegable   los   aperos  que  quiere  incluir.    Para   evitar   posibles   errores   en   la   duplicación   de   los   aperos,   la   base   de   datos   no   permite  almacenar  dos  aperos  iguales  en  una  misma  tarea.      En  la  siguiente  imagen  podemos  ver  como  quedaría  dicha  dificultad  solventada.              La   siguiente   dificultad   está   relacionada   con   modificar   aperos   de   una   tarea.   Como   ya   he  comentado   la   tarea   está   formada   por   0..5   aperos.   Si   yo   en   la   tabla   que   tenía   en   la   base   de  datos   quería   modificarlos,   me   encontraba   con   el   problema   de   cómo   saber   qué   apero  realmente  quería  modificar.  Los  campos  de  la  tabla  eran:  idTarea  e  idMaquina,  en  el  que  este  último  id  servía  para  almacenar  el  correspondiente  apero.  Una  vez  que  yo  cambiaba  un  apero  por   el   nuevo,   recogía   el   id   de   este   último   pero   no   sabía   cuál   era   el   id   del   apero   anterior   a  sobrescribir  en  la  base  de  datos.    Como  solución  a  este  problema,  comentándolo  con  el  tutor  se  tomó  la  decisión  de  añadir  un  campo  de  tipo  entero  más  a  la  tabla  “tareas_maquina”,  el  cual  servirá  para  localizar  de  manera  rápida  qué  campo  debía  ser  modificado  en  la  tabla.          

Desplegable  apreros  1  

Desplegable  aperos  2  

Tabla  tareas_maquina  

 

28    

A   la   hora   de   actualizar   los   nuevos   valores   de   una   tarea,   lo   que   realmente   hago   es   ir  actualizando  todos   los  campos  de  esa   tarea  y   recorrer   los  options  de  cada  select   recogiendo  sus  valores  y  llevándomelos  al  controlador.  En  este  ultimo  compruebo  si  el  apero  que  le  llega  es  vacío  o  no,  si  el  que  existía  es  vacío  o  no,  para  saber  qué  tipo  de  consulta  realizar.  En  caso  de  que  el  apero  nuevo  no  sea  vacío  y  no  exista  un  apero  en  esa  posición,  realizará  un  insert,  si  por  el  contrario  había  un  apero  y  ahora  el  que  le  llega  es  vacío,  realizará  un  delete  o  por  último  si  había  un  apero  y  lo  modifica,  la  consulta  será  de  tipo  update.      Otro  cambio  que  he  considerado  oportuno  realizar    ha  sido  eliminar   la   tabla   “rendimientos_operación”   de   la   base   de  datos   y   almacenar   esos   campos   en   la   tabla   “maquinas”.  Según   mi   punto   de   vista   esa   tabla   sobraba   y   es   mejor  almacenar  dichos   campos   simplemente  en   la  misma   tabla  con  los  demás  campos  de  las  máquinas.  Mi  opinión   se   fundamenta  en  que  es  una   tabla  de   la   cual  podemos  prescindir,  pero  sus  campos  sí  que  son  necesarios  para  realizar  los  cálculos  del  coste  de  la  maquinaria  ya  que  hacen   referencia   al   rendimiento   que   puede   ejercer   una  máquina  según  las  características  de  la  explotación  agrícola  en   la  que  se  utiliza.  El  posible  origen  de   la  misma  está  en  que   Andrés   (el   desarrollador   de   la   versión   anterior),  cuando  tuvo  que  incorporar  esta  información  no  quiso  modificar  la  tabla  “maquinas”  existente  y  generó  una  nueva  tabla.    Este  cambio  me  obliga  a  cambiar  el  controlador  y  el  modelo  agrícola  encargado  de  almacenar  esos  datos  en  la  base  de  datos  por  el  motivo  comentado  anteriormente.  Me  surgió  otra  duda  cuando  pensé  en  si  fusionar  o  no,  las  tablas   “máquinas_extra”  y   la   tabla   “maq_combinado”  con  la   tabla   “máquinas”.   Pensándolo   más   detenidamente,   la  tabla   “máquinas_extra”   sí   que   tiene   la   necesidad   de    fusionarse   con   la   tabla   “máquinas”,   ya   que   no   hay  necesidad   de   tener   esos   tres   campos   (horas_vida,  anos_vida  y  factorRyM)  en  otra  tabla  cuando  pueden  estar  en  la  tabla  “máquinas”.  Pero  al  contrario  pasa  con  la  tabla  “maq_combinado”;  esta  tabla  puede  dejarse  como  está  ya  que   sus   campos   se   utilizan   para   calcular   los   costes   por  medio  del  método  combinado  y  si  en  un  futuro  se  quisiese  poder  calcularlos  por  el  método  ASABE,  no  hará  falta  tener  que  introducir  los  datos  para  ello  en  la  tabla  máquinas.  En  mi   opinión   sería   interesante   tener   las   dos   tablas   para  distinguir   los   distintos   tipos   de   métodos   de   cálculo   de  costes  y  elegir  el  que  más  convenga  utilizar.        Así  es  como  queda  la  tabla  “maquinas”  al  fusionar  las  dos  tablas  anteriores  en  ella.              

 Fusión  tabla  maquinas  1  

 Fusión  tabla  maquinas  2  

 

29    

Vistas  agricola  

                               Estos  nuevos  cambios  obligan  a  realizar  otros  cambios  en  la  implementación  de  la  aplicación.  Entre   otros   cambios,   ahora   necesitamos   almacenar   los   nuevos   campos   recogidos   de   los  formularios  y  para  ello  habrá  que  modificar  el  modelo.    Ha   habido   que   adaptar   cambios   en   la   vista   que   permite   al   usuario   dar   de   alta   máquinas  nuevas,  ya  que  ahora  sí  es  necesario  introducir  esos  nuevos  valores  anteriormente  inexistentes  en  el  formulario,  por  parte  del  usuario  para  poder  trabajar  más  adelante  con  ellos.  

 El   fichero  modificado  es  el  “formMaquina.phtml”.  En   la  versión  anterior  se  controlaba  que  los  tipos  de  datos  introducidos  en  los  campos   sean  del   tipo   correcto   y   si   se  dejaba  alguno  vacío,  nos  avisaba  de  ello  y  nos  pedía   confirmación  para  almacenar  algún  campo  vacío  o  para  rellenarlo.  Esta  ultima  versión  va  a  ser  más  restrictiva  con  el  usuario,  solo  pudiendo  crear  máquinas  con  los  datos  necesarios  para  realizar  sus  cálculos,  obligando  al  usuario  a  introducirlos  o  no  se  le  permitirá  crear  una  nueva  máquina.    

Con  esto  me  garantizo  que  los  datos  mínimos  para  calcular  los  costes  de  la  maquinaria  en  una  tarea   sean   almacenados.   Todas   estas   comprobaciones   las   realizo   mediante   JavaScript   en  tiempo  real  y  trabajando  con  las  propiedades  de  los  elementos  HTML.    Una  vez  que  tenemos  todos   los  datos  necesarios  para  calcular   los  costes,  hay  que  pensar  en  como  podemos  mostrarlos  al  usuario.  Surgieron  varias  posibilidades,  pero   la  que  me  pareció  más  interesante  fue  poder  ir  desglosando  dichos  costes  en  sub-­‐apartados.  Estos  serían:  costes  de  maquinaria,  mano  de  obra  y  productos  fitosanitarios      Como  podemos  apreciar   en   la   siguiente   imagen,   he  añadido  un  botón  más  en  Acciones  que  sirve  para  calcular  los  costes  de  la  tarea.  El  porqué  de  realizarlo  de  esta  manera  y  no  que  sea  dinámico,  que  cada  vez  que  se  modifique  una  máquina  se  vaya  actualizando  es  el  siguiente.  Si  cada   vez   que   se   seleccionase   o  modificase   una  máquina   nueva   en   los  menús   desplegables,  tuviera   que   actualizarse   el   coste   de   la   tarea,   estaríamos   enviando   consultas   al   servidor   de  manera   continua,   solicitando   el   coste   de   cada   maquinaria,   pero   si   lo   que   hago   es   realizar  únicamente  las  consultas  cuando  se  pulsa  el  botón,  solo  se  realizarán  las  mínimas  consultas,  ya  que   los   valores   de   los   menús   desplegables   ya   están   fijados   con   los   valores   que   el   usuario  desea.        

 Tabla  final  maquinas  

 

30    

Boton  de  calcular  costes  

           Pruebas  realizadas    Para  comprobar  el  correcto  funcionamiento  de  las  tareas  mis  pruebas  han  sido  las  siguientes:    

• Crear  una  nueva  tarea  y  almacenarla.  • Comprobar  que  se  almacena  correctamente  en  la  base  de  datos.  • Incluir  en  la  tarea  una  máquina  autopropulsada  y  varios  aperos.  • Comprobar   que   se   almacenan   correctamente   en   la   base   de   datos   y   así   de   paso  

comprobar  las  relaciones  de  las  tablas.  • Ver   que   la   tabla   se   rellena   con   las   tareas   de   un   usuario   almacenadas   en   la   base   de  

datos.  • Actualizar  tareas.  • Eliminar  tareas.  • Comprobar  los  campos  de  los  menús  desplegables.  • Intentar  guardar  dos  aperos  repetidos  (modificando  el  código  para  que  lo  permitiese)  y  

ver  que  no  se  permitía  en  la  base  de  datos.  Volver  a  dejar  el  código  como  estaba  para  evitar  esa  acción.  

• Comprobar  que  se  ordenan  las  tareas  de  manera  creciente  y  decreciente  por  el  campo  descripción  de  la  finca.  

• Realizar   búsquedas   simples   y   anidadas,   comprobando   que   los   valores   devueltos   son  los  correctos.  

   Valoración  por  parte  del  cliente    Una  vez  que  tengo  el  prototipo  completado  hasta  esta   iteración,  nos  reunimos  con  el  cliente  para  que  nos  dé  su  opinión  acerca  del  trabajo  realizado.    El  cliente  quedó  gratamente  sorprendido  con  la  interfaz,  ya  que  no  se  imaginaba  cómo  se  iba  a  realizar  ya  que  nos  dejo  libertad  de  elección  en  este  aspecto.  Se  sorprendió  al  ver  la  fila  de  la  maquinaria,   pero   cuando   le   explicamos  que  de  esa   forma   será  más   simple  para  el   usuario   y  que   se   reducirán   el   número   de   filas   de   la   tabla,   su   valoración   fue   bastante   buena.   Le  propusimos   continuar   con   esa   idea   para   la  mano   de   obra   y   los   productos   fitosanitarios   y   él  mismo  fue  imaginando  la  interfaz  y  llegamos  a  una  idea  general  para  las  siguientes  iteraciones.  Siguiendo   con   el   tema   de   la   interfaz   pidió   modificar   el   orden   la   columna   de   la   finca   a   la  segunda  posición  y  solicitó  insertar  un  nuevo  parámetro  más  adelante  relativo  al  rendimiento  de  la  maquinaria  en  la  parcela.  Estuvo  de  acuerdo  en  los  cambios  realizados  en  los  formularios  relativos  a  dar  de  alta  una  máquina  nueva  con  la  explicación  que  le  dimos  acerca  de  ello.    Con   todo   lo   comentado   dio   el   visto   bueno   y   nos   permitió   continuar   con   las   siguientes  iteraciones.                    

 

31    

Justificación  de  las  horas  descompensadas  en  la  planificación      En  la  planificación  de  esta  tarea  no  calculé  el  tiempo  invertido  a  la  modificación  de  las  fórmulas  referentes   al   cálculo   de   los   costes   de   la   tarea.   Cuando   planifiqué   la   tarea   pensé   que   dichas  fórmulas   y   que   los   datos   necesarios   para   ellas   estaban   almacenados   en   la   base   de   datos   y  podría  utilizarlos.  Esto  no  resultó  ser  así  y  me  he  visto  obligado  a  realizar  cambios  en  la  base  de  datos,  en  formularios  y  en  el  cálculo  de  los  costes  para  poder  terminar  la   iteración.  Todo  ese  tiempo  invertido  no  fue  planificado  al  principio  y  de  ahí  la  desviación  horaria  resultante.    Esta   iteración   me   ha   llevado   10   horas   más   de   las   previstas   debido   a   las   siguientes  circunstancias:  

• Dificultades   que   tuve   en   el  momento   de  manejar   JSON   y   AJAX,   lo   cual  me   llevó   2,5  horas  más  de  las  previstas.  

• El   problema   que   tuve   con   los   menús   desplegables   de   los   aperos   en   los   cuales   solo  debían   aparecer   los   aperos   restantes   y   el   actualizar   los   aperos   en   la   base   de   datos,  esto  me  demoró  otra  3,5  horas  más.  

• Las   unificaciones   de   las   tablas   “rendimientos_op”   y   “maq_extra”   en   la   tabla  “maquinas”,  esto  me  demoró  otra  hora.  

• Adaptar  el   formulario  de  creación  de  máquinas  para  añadir   los  elementos  necesarios  para  el  cálculo  de  los  costes.  Esto  me  llevó  1  hora  más.  

• Y  las  dos  horas  restantes  fueron  invertidas  en  pensar  la  interfaz,  realizar  pruebas  para  comprobar   su   funcionamiento   de   cada   funcionalidad   de   la   interfaz   y   sus   debidas  correcciones.  

       

 

32    

Barra  de  menús  

 Gráficos  

ITERACION  2.  Creación  de  gráficos  para  mostrar  el  uso  de  la  maquinaria    

Objetivos  

En  esta   iteración  quiero  mostrar   al   usuario  el   uso   y   los   costes  horarios  de   su  maquinaria  de  manera  gráfica.  Considero  que  es  una  buena  opción  el  ver  de  manera  gráfica  estos  datos  ya  que  de  un  vistazo  rápido  se  puede  observar  cuáles  son  las  máquinas  que  más  usa  y    que  más  gastos  le  ocasionan  al  usuario.  

La   idea   con   que   realizo   esta   iteración   es   que   el   usuario   solo   pueda   conocer   el   uso   de   sus  propias  máquinas.    En  los  gráficos  solo  aparecerán  las  máquinas  que  tienen  costes  y  horas  de  uso  distintas  de  0.  

Esta   idea  de  generar   los   gráficos   se  me  ocurrió   y  decidí  planteársela   al   cliente  para   ver   si   le  resultaba   interesante  para   la  aplicación.  El  cliente  se  sorprendió  con   la   idea  y   le  pareció  muy  buena;  comentó  que  esto  podría  ser  de  gran  ayuda  para  un  agricultor.    

 

Análisis  del  diseño  

Después   de   observar   los   distintos   tipos   de   gráficos   disponibles   que   puedo   incrustar   en   la  aplicación,  he  decidido  insertar  gráficos  circulares.  He  elegido  este  tipo  sobre  todo  porque  son  más   visuales   y   se   entienden   de   manera   muy   simple.   Para   los   costes   también   he   pensado  colocar   un   gráfico   en   modo   de   tabla,   es   mas   típico   pero   a   su   vez   le   da   un   toque   menos  moderno  y  más  adecuado  al  estilo  del  resto  de  la  aplicación.  

Para   poder   acceder   a   los   gráficos   he   añadido   una   pestaña   más   al   menú   general.   Pulsando  sobre   ella   se   nos   generarán   los   gráficos   adecuados   a   la   maquinaria   de   cada   usuario.   En   la  siguiente  imagen  “Barra  de  menús”  podemos  apreciar  donde  está  situado.  

 

   

Si  pinchamos  en  él,  nos  aparecerán  los  gráficos  de  la  siguiente  manera.                                  Como  observamos  en  el  grafico  de  la  parte  izquierda  apreciamos  la  suma  de  los  costes  horarios  de  todas  las  máquinas  que   tiene  el  usuario  y  que   intervienen  en   las   tareas,  mientras  que  el  gráfico  de   la  parte  derecha  se  corresponde  con  las  hora  de  uso  de  la  maquinaria  anuales.        

 

33    

Una   ventaja   de   este   tipo   de   gráficos   es   que   si   pasamos   el   ratón   por   encima   de   cualquier   parte   del  gráfico,  nos  detalla  sus  cifras  y  porcentajes  de  ese  sector  del  gráfico.                              En  este  ejemplo  vemos  que   la  máquina  es  una  “Cosechadora”  y  también  observamos  que  su  coste  horario  es  de  489,27€.        Como  inconveniente  de  estos  gráficos  puede  considerarse  que  si  el  usuario  tiene  máquinas  con  coste  0,  no  saldrá  reflejada  en  el  gráfico  y  puede  dar  la  sensación  que  el  usuario  no  dispone  de  esa  máquina.  Esto  no   influye  a   la  hora  de  poder  escoger   la  máquina  en   las  tareas,  el  usuario  podrá  elegirla   sin  ningún  problema  y  en  el  momento  que  ya  quede  almacenada  en   la   tarea,  tendrá  coste  y  por  tanto  aparecerá  en  los  gráficos.    El  segundo  tipo  de  gráficos  que  he  escogido  para  la  aplicación  es  el  siguiente:            

Google  Charts  àPorque  he  escogido  esa  herramienta.        Esta  tabla  se  genera  como  un  gráfico  más,  tiene  la  característica  de  ser  más  acorde  al  estilo  de  la  aplicación,  es  menos  visible  que  los  anteriores  pero  es  bastante  intuitivo.  Sigue  apareciendo  el  mismo  inconveniente  que  he  comentado  anteriormente,  que  si  la  máquina  tiene  de  costes  0  no  aparecerá  plasmada  en  la  tabla  hasta  que  ese  coste  sea  superior.    Como   se   aprecia   en   las   imágenes   “Leyenda   gráficos”   y   “Gráficos   de   tabla”,  muestra  los  costes  con  bastantes  decimales,  esto  es  debido  a  que  internamente  en   la   aplicación   trabajo   con  ellos  para   ser  más  exacto  en   los   cálculos.   Cuando  muestro  el  coste  en  la  tabla  de  las  tareas,  solo  muestro  dos  decimales  para  que  sea  más  simple  para  el  usuario,  pero  en  los  gráficos  he  decidido  mostrar  todos  los  decimales  ya  que  para  verlos  hay  que  pasar  el  ratón  por  encima  de  cada  máquina,  si  no  solo  se  aprecia  su  porcentaje.    Una   vez   tengamos   los   gráficos   insertados,   podemos   personalizarlos   de   manera   bastante  sencilla.  Podemos  modificar  su   tamaño  y   la  gama  de  colores  que  queremos  que  ponga  a  sus  elementos.   El   tamaño   lo  modificamos   cambiando   las  medidas   del   contenedor   div   en   el   que  esta  incrustado  el  gráfico.        

 Leyenda  gráficos  

 Gráfico  de  tabla  

 Coste  

 

34    

           Implementación    Antes  de  comenzar  con  la  implementación  estudié  las  alternativas  posibles  sobre  la  realización  de   los   gráficos.   De   las   herramientas   disponibles   escogí   las   siguientes   para   realizar   dicho  estudio:  

• Google  Charts  15  • pChart16  • JpGraph17  

 Una   vez   evaluadas   estas   tres   opciones,   pronto   me   decanté   por   Google   Charts   y   JpGraph  debido   a   que   disponen   de   una   amplia   documentación   y   sus   gráficos   me   parecieron   más  vistosos   para   el   usuario.   Entre   estas   dos,   escogí     como   opción   la   de   Google   Charts   ya   que  dentro  de   las  posibilidades  que  nos  proporcionan  dispone  de  más   tipos  distintos  de  gráficos  con   sus   respectivos   ejemplos.   La   única   pega   que   le   veo   es   que   tienen   menos   opciones   de  modificación  que  la  opción  de  JpGraph,  la  cual  permite  modificar  hasta  las  opciones  de  diseño  como  márgenes  y  situación  del  gráfico  en  la  etiqueta  <img>  (te  permite  modificar  las  CSS).  Por  contra   Google   Charts   solo   permite   modificar   los   colores   y   el   tamaño   del   gráfico.   Según   mi  criterio  no   considero   tan   importante  esta   limitación   como  para  escoger  otra   librería,   ya  que  como  hemos  visto  en  el  diseño  quedan  bastante  bien  los  gráficos.  Como  ventajas  destacables  a  la  opción  escogida   tenemos:   la   simplicidad  de   creación  de  gráficos,   los  ejemplos  que  hay  de  cada   uno   de   ellos,   las   variedad   de   gráficos   y   la   amplia   documentación.   Estos   gráficos   se  adaptan  de  manera   correcta  para  poder   ser   visualizados   en  dispositivos  móviles   gracias   a   la  tecnología   HTML5   y   SVG   que   proporcionan   compatibilidad   completa   con   los   distintos  navegadores  de  los  dispositivos  móviles.    Debe   conocerse   también   que   no   es   necesario   insertar   en   el   proyecto   la   librería   para   su  funcionamiento.  Cada  vez  que  solicitamos  dibujar  los  gráficos  se  conecta  a  Google  para  recibir  la   información  que  necesita  para   su   creación.   Esto  puede   ser  una  pega   ya  que   siempre   será  necesario  disponer  de  conexión  a  internet  para  su  correcto  funcionamiento,  pero  como  para  el  uso  de  la  aplicación  ya  es  necesario  tener  esa  conexión  a  internet,  no  es  algo  que  limite  a  los  usuarios  para  su  uso  y  no  la  he  descartado  por  ello.  El  problema  podría  surgir  en  un  futuro,  si  Google  decidiese  modificar  la  API  (la  librería)  y  esto  generase  algún  problema  en  la  generación  de  los  gráficos.  Como  trabajo  futuro  dejo  pendiente  si  el  próximo  desarrollador  decide  cambiar  la  librería  o  sigue  manteniéndola.      Tenemos  la  posibilidad    de  crear  gráficos  de  las  siguientes  maneras:  

• Mediante  un  objeto  JSON.  • Mediante  un  array.  • Mediante  un  fichero  de  texto.  • Escribiendo  los  datos  a  mano.  • Directamente  desde  la  base  de  datos.  

   15  Google  Charts:  https://developers.google.com/chart/  16  pchart:  http://www.pchart.net/  17  JpGraph:  http://jpgraph.net/  

 Creación  de  gráficos  

 

35    

             Generación  gráfico  mediante  JSON  1  

             Generación  gráfico  mediante  JSON  2    

Dificultades  en  la  implementación    En  la  documentación  de  la  página  oficial  de  Google  Charts  acerca  de  la  creación  de  los  gráficos,  explican   que   se   pueden   realizar   los   gráficos  mediante   un   objeto   JSON,   cosa   que   no   he   sido  capaz   de   realizar.   Desde   el   modelo   “agricolaModel.php”   recojo   los   valores   que   devuelve   la  base  de  datos  con  la  consulta  adecuada,  los  transformo  en  un  objeto  de  tipo  JSON  que  recojo  en  el  controlador  y  desde  este  lo  envió  a  la  vista  “graphics.phtml”  de  los  gráficos.  Aquí  inserto  el   código  de  generación  del  grafico  pasándole  el  objeto   JSON  como   indica   la  documentación  pero  no  se   inserta  el  gráfico  en   la  página.   Intenté  crearlo  también  por  medio  de  un  array  de  manera   automática   pero   seguía   sin   mostrar   el   gráfico.   Por   último   y   para   asegurarme   que  funcionara  decidí  insertar  los  elementos  uno  a  uno,    insertando  código  PHP  en  el  JavaScript  de  la  creación  del  gráfico.  Esto  no  fue  fácil  ya  que  la  realización  de  las  primeras  pruebas,  intenté  generar   el   gráfico   mediante   JavaScript   pero   en   la   función   de   creación   del   gráfico   no   me  permitía  insertar  un  bucle  dentro  de  ella.  La  solución  fue  introducir  código  PHP  e  ir  realizando  pruebas  hasta  que  quedase  perfecto.      El  objeto  que  envío  del  controlador  a  la  vista  es  un  JSON  y  en  ella  lo  transformo  a  cadena  de  tipo   string,   esta   cadena   la   almaceno   a   un   array   para   poder   trabajar   con   ella   en   un   bucle   y  poder  recorrer  los  datos  de  manera  más  sencilla  mediante  PHP.                                                                  Como  curiosidad  a  la  hora  de  implementar  los  gráficos  circulares  fue  descubrir  que  había  que  insertar  de  manera  obligatoria  campos   textuales   justo  antes  de   los  datos  que  conforman   los  sectores  del  gráfico,  en  el  método  de  dibujar  dicho  gráfico.  

 

36    

             Campos  gráfico  

             Gráficos  globales  

     

Estos   campo   de   tipo   string   se   corresponden   con   los   datos   que   nosotros   vamos   a   introducir.   En   mi  ejemplo,  las  máquinas  van  a  ser  el  nombre  de  las  máquinas  y  el  coste  los  valores  horarios/anuales  de  las  mismas.  

Si  intentamos  generar  un  gráfico  sin  insertar  algo  en  dicho  recuadro  remarcado  en  la  imagen  “Campos  gráfico”,  solamente  insertando  los  datos  que  queremos  mostrar,  no  dibujará  el  gráfico  y  no  dará  ningún  error.  Esto  no  está  detallado  en  la  documentación  oficial  pero  me  di  cuenta  realizando    las  pruebas.  

Dentro  de  ese  método  es  donde  tuve  el  problema  comentado  anteriormente,  en  el  cual  solo  se  permitía  introducir  datos  de  tipo  string  y  no  permitía  insertar  bucles  en  código  JavaScript.  

 

Valoración  por  parte  del  cliente    En   una   reunión   con   el   cliente,   se   le   mostraron   unos   prototipos   de   los   gráficos   en   el   cual  aparecían   gráficos   de   sectores   y   de   barras.   Los   gráficos   de   sectores   fueron   de   su   agrado  inmediatamente,  pero  enseguida  también  desestimó  los  de  tablas.  Los  gráficos  que  le  mostré  estaban  realizados  con  el  coste  anual  de   la  maquinaria  y  con   las  horas  de  uso  anuales  de   las  mismas.  El  cliente  decidió  realizar  un  cambio  en  cuanto  a  los  costes,  consideró  mas  interesante  conocer  los  costes  horarios  de  cada  máquina  junto  a  sus  horas  de  uso  anuales.    

El   prototipo   presentado   solamente   disponía   de   los   gráficos   de   la   unión   entre   máquinas  autopropulsadas   y   aperos,   cosa   que   al   cliente   le   pareció  mas   útil   dividirlos   en     gráficos   por  separado  para  cada  tipo  de  máquina  y  otro  dos  con  la  unión  de  todas  las  máquinas.  

Los  gráficos  finales  son  los  siguientes:  

Gráficos  globales    

 

 

 

 

 

 

 

 

 

 

 

 

37    

             Gráficos  autopropulsadas  

             Gráficos  aperos  

Gráficos  de  maquinaria  autopropulsada  

 

 

 

 

 

 

 

Gráficos  de  los  aperos    

 

 

 

 

 

 

 

Justificación  de  las  horas  descompensadas  en  la  planificación      Esta   iteración   me   ha   llevado   realizarla   10   horas   menos   de   las   previstas.   Pensé   que   me   iba   a   costar  bastante  más  tiempo  el  encontrar  librerías  que  se  adaptasen  a  los  gráficos  a  la  idea  que  tenía  pensada  para   ello.   Dediqué   menos   tiempo   del   que   consideré   en   la   planificación   que   me   costaría   aprender   a  manejar   dicha   librería,   pero   con   los   ejemplos   que   había   en   la   documentación   me   ahorra   bastante  tiempo.  Y  por  ultimo  pensé  que  debería  adaptar  más  cambios  de  los  que  tuve  que  realizar  al  prototipo  una  vez  enseñado  al  cliente.    Los  cambios  que  el  cliente  solicitó  que  se  realizasen  en  la  ultima  reunión  con  él  no  estaban  planificados  en  la  gestión  del  tiempo,  pero  como  había  planificado  más  tiempo  del  que  realmente  me  costo,  al  final  la  iteración  no  se  ha  visto  descompensado  en  el  tiempo.  Todos  estos  cambios  agradaron  al  cliente  que  quedó  muy  satisfecho  con  el  trabajo  realizado.    

     

 

38    

ITERACION  3.  Realización,  modificación,   búsquedas   y   cálculo   de   costes  de  la  mano  de  obra  y  productos  fitosanitarios  de  las  tareas.    

Objetivos  

En  esta  iteración  lo  que  se  quiere  conseguir  es  dar  la  posibilidad  al  usuario  de  poder  añadir  la  mano  de  obra  y  los  productos  fitosanitarios  que  el  agricultor  debe  utilizar  para  poder  realizar  la   tarea.  También  se  pretende  prever   los  costes  derivados  de  ello  y  añadirlos  a   los  costes  ya  previstos  de  la  tarea.  

En   la  mano   de   obra   deben   aparecer   dos   campos   nuevos   que   son:   el   tractorista   (la   persona  encargada   de   manejar   la   maquina   autopropulsada)   y   otro   personal.   Estos   últimos   son   las  demás  personas  que   intervienen  en   la   realización  de   la   tarea  pero  que  no  manejan  ninguna  máquina,  sino  que  hacen  labores  manuales;  se  asumirá    que  todos  ellos  tienen  el  mismo  coste  horario,  y  por  tanto  prestaremos  atención  al  número  de  integrantes  para  realizar  su  cálculo.  

Análisis  del  diseño  

Continuando  con  el  diseño  anterior,  añado  una  fila  a  cada  tarea  indicando  en  la  columna  más  a  la  izquierda  el  nombre  de  la  sección  correspondiente  de  la  tarea.  A  continuación  añado  una  etiqueta  para  especificar  a  qué  tipo  de  persona  nos  estamos  refiriendo,  ya  sea  tractorista  u  otro  personal.  El  cuadro  de  texto  sirve  para  que  se  introduzca  el  número  de  personas  de  ese  tipo  y  el  siguiente  campo  de  texto  el  precio  por  hora  que  percibirá  esa  o  esas  personas.  El  cliente  especificó  que  habitualmente  solía  haber  un  tractorista  por  lo  que  dejé  como  predeterminado  un  1,  pero  para  determinadas  tareas  podía  no  intervenir,  así  que  se  da  la  posibilidad  al  usuario  de  modificar  ese  número.  Se  recalcó  que  había  que  especificar  que  el  precio  del  personal  era  €  por  hora,  por  ello  lo  he  dejado  especificado  en  un  campo  justo  a  su  lado  para  que  introduzcan  el  precio  de  las  horas  de  trabajo.  Por  si  el  usuario  tiene  alguna  duda  a  que  se  refiere  cada  campo  de  texto  les  he  añadido  unas  etiquetas  qué  aparecen  al  pasar  el  ratón  por  encima  de  dichos  campos.  

 

 

 

 

 

 

Pa  

Para  los  productos  fitosanitarios,  abonos  y  otros,  el  diseño  no  ha  sido  fácil  ya  que  ahí  el  cliente  solicitó  introducir  los  siguientes  datos:  Nombre  del  producto,  cantidad  y  precio  del  mismo.  En  la   reunión   dejó   claro   que   como  máximo  un   agricultor   utilizaría   en   una  misma   tarea   hasta   5  productos  pero  en  ningún  caso  más,  así  que  yo  he  decidido  en  la  interfaz  darle  la  posibilidad  de  introducir  hasta  5  productos.  

 

 

 

             Mano  de  obra  

 

39    

Para  poder  cumplir  todas  sus  necesidades  la  interfaz  se  va  realizar  de  la  siguiente  manera.  

 

 

 

 

 

Como  observamos   la  primera  columna  es  el   indicador  de   la  sección  de   la   tarea  que  vamos  a  introducir,   en   este   caso   fitosanitarios.   Ahí   le   indico   al   usuario   los   5   productos   que   puede  introducir.  En  la  siguiente  fila  el  usuario  deberá  introducir  el  nombre  del  producto.  En  esta  fila  surgió   la   idea  de  poder  crear  una  tabla  con  los  nombres  de  todos   los  productos  agrícolas  del  mercado  y  que  el  usuario  pudiera  seleccionarlos  mediante  un  combo  box,  pero  en  la  reunión  el  cliente  desechó  esta  opción  al   comentar  que   sería  mas   cómodo  para   cada  agricultor  dejarle  libertad   para   que   él   escriba   el   nombre   que   considere   adecuado   para   su   entendimiento.   La  tercera  fila  se  corresponde  con  la  cantidad  de  producto  que  el  agricultor  va  a  emplear  en  esa  actividad,   la   cual   se  medirá   en   litros   de   producto   pudiendo   introducirlos  mediante   números  decimales.  Y  la  última  fila  hace  referencia  al  precio  de  determinado  producto  utilizado.    

Mientras  estaba   realizando  esta   tabla  pensé  en   ir   habilitando  producto  a  producto,   como   lo  había  utilizado  en   las  maquinarias  anteriormente,  pero  al   final  decidí  dejar   todos   los  campos  habilitados  y  que  el  usuario  introduzca  el  numero  de  productos  fitosanitarios  que  él  considere  necesarios  para  dicha  tarea.  

Como  hemos  observado  en  la  imagen  cada  columna  se  corresponde  con  todos  los  datos  de  un  determinado  producto.  De  esta  forma  creo  que  la  interfaz  es  más  intuitiva  para  el  agricultor.  

En   la   siguiente   imagen   voy   a   juntar   todas   las   partes   anteriores   para   mostrar   de   manera  completa  cómo  quedaría  la  interfaz  de  una  tarea  completa.  

 

 

 

 

 

 

 

La  interfaz  de  cada  tarea  queda  bastante  compacta,  pero  es  difícilmente  escalable  si  el  usuario  especifica   varias   tareas.   Intentaremos   resolver   esta   situación   en   futuras   iteraciones   con   una  interfaz  más  simple.  

   

Implementación    Después  de   intentar  continuar   la   implementación  desarrollada  anteriormente,  he  tenido  que  cambiar   la   forma   en   la   que   trabajaba   para   representar   los   datos   en   la   tabla.   En   el   modelo  agrícola  en  el   cual  obtenía  de   la  base  de  datos   las   tareas  y   las  máquinas  de   los  usuarios,  he  creado  dos  métodos  nuevos  para  recuperar   los  datos  de   la  mano  de  obra  y  de   los  productos  fitosanitarios      

Productos  fitosanitarios  

Interfaz  tareas  

 

40    

                   Estos  métodos   proporcionan   todos   los   datos   necesarios   para   representar   las   tareas   de   cada  usuario   en   la   tabla.   El   controlador   “agricolaController.php”   es   el   encargado   de   hacer   llegar  estos  datos   a   la   vista   “privateAdmin.phtml”,   la   cual  mediante   JavaScript   dibuja   la   tabla  para  que  el  usuario  pueda  ver  sus  tareas.                                      Una   vez   tengamos   los   datos   en   la   vista,   lo   que  hago   es   ir   comparando  mediante   el   id   de   la  tarea  para  representar  en  cada  línea  los  datos  adecuados  y  no  mezclar  datos  de  una  tarea  con  otras.    La  base  de  datos  ha  sido  modificada,  se  han  añadido  las  tablas  de  productos  y  mano  de  obra.  También   se   han   añadido   campos   de   costes   en   la   tabla   de   tareas.   En   la   tabla   productos  almaceno  todas  las  características  de  los  productos  que  el  usuario  añade  en  la  tabla,  como  son  el   nombre   del   producto,   la   cantidad   y   precio   del  mismo.   En   la   tabla   de   tareas   almaceno   el  coste  total  del  producto  y  mediante  la  clave  ”idTarea”  muestro  en  la  tabla  de  manera  correcta  todos  sus  datos.    Solo  se  almacenarán  los  productos  que  el  usuario  ha  introducido  en  la  tabla,  si  por  el  contrario  deja  en  blanco  los  campos,  estos  no  se  almacenarán.                  

AgricolaModel.php  

AgricolaModel.php  

 

41    

                               Lo  mismo  pasa  con  la  mano  de  obra,  en  ella  se  almacena  el  número  de  tractoristas  que  son  los  encargados  de  manejar  la  maquinaria  autopropulsada.  Como  he  comentado  anteriormente  el  cliente  comentó  en  la  reunión  que  suele  ser  siempre  1,  por  eso  dejo  ese  1  por  defecto  a  la  hora  de  crear  una  tarea  nueva,  en  ese  campo.  Se  almacena  también  el  salario  en  €/h  que  cobra  el  tractorista,   el   número   de   personas   que   intervienen   en   la   tarea   pero   que   no   manejan   esa  maquinaria,  llamados  otro  personal  y  el  salario  en  €/h  que  perciben.    En  esta  iteración  he  implementado  la  parte  de  los  filtros  que  realizan  la  búsqueda  por  nombre  de   productos   fitosanitarios   en   las   tareas   y   muestra   las   tareas   que   contienen   ese   producto.  Como   podemos   ver   en   la   imagen   “Filtro   fitosanitarios”,   buscamos   el   producto   llamado  “veneno”  y  nos  muestra  la  “tarea  1”  que  es  la  única  tarea  que  contiene  ese  producto.      

   Los   costes   de   la   mano   de   obra   y   de   los   productos   fitosanitarios   los   almaceno   en   sus  correspondientes  tablas  a  la  vez  que  se  guarda  la  tarea,  sin  la  necesidad  de  pulsar  el  botón  de  calcular   costes,   que   solo   calcula   los   generales   y   los   de   la   maquinaria.   Los   costes   de   los  productos   y  de   la  mano  de  obra   los   envío  desde   la   vista   al   controlador   “ajaxController.php”  mediante   Ajax   en   un   formato   JSON   y   el   modelo   “ajaxModel.php”   es   el   encargado   de  almacenarlo  en  la  base  de  datos      En   la   imagen   “Uso   de  AJAX   y   JSON”   observamos   cómo   se   envían  mediante  Ajax   los   objetos  JSON  a  sus  correspondientes  métodos.  

Productos  y  mano  de  obra  

Filtro  fitosanitarios  

 

42    

                           En  esta  imagen  “Rutas  redirección  AJAX”  apreciamos    la  ruta  de  los  métodos  a  los  cuales  debe  redirigirse  cada  objeto  Ajax  dentro  del  controlador  adecuado.                  Una   vez   nos   ha   redirigido   al   “ajaxController.php”,   estos   son   los   métodos   encargados   de  recoger   todos   los  campos  del  objeto   JSON  y   llamar  al  método  adecuado  del  modelo  con  sus  parámetros                    En  el  último  paso,  hacemos  uso  de  los  métodos  encargados  de  almacenar  en  la  base  de  datos  los  campos  que  le  hemos  pasado  anteriormente                    Y  directamente  desde  el  modelo,  almacenamos  los  objetos  en  sus  correspondientes  tablas.            

Uso  de  AJAX  y  JSON  

Rutas  redirección  AJAX  

Métodos  ajaxController  

Métodos  ajaxModel  

Tabla  productos   Tabla  mano  de  oba  

 

43    

Justificación  de  las  horas  descompensadas  en  la  planificación      El  cliente  quedó  bastante  conforme  con  el  prototipo,  pero  pensó  que  entre  otros  cambios  si  podríamos  cambiar  el  orden  de  algún  campo  en  la  tabla  HTML  está  sería  más  intuitiva  para  los  usuarios  finales.  Después  de  realizar  dicho  cambio  la  tabla  quedó  de  la  siguiente  manera:    

   Como  podemos  apreciar  se  han  cambiado  el  orden  de   las  columnas  “Fincas”  y  “Vel.Trabajo”,  ya  que  de  esta   forma  es  más   intuitivo  para  un  agricultor  el  escoger  primero   la   finca  sobre   la  cual  va  a  trabajar  y  después  añadir  los  datos  referentes  a  ella.    También   he   tenido   que   realizar   cambios   en   los   formularios   de   creación   de   máquinas   para  facilitar   el   uso   a   los   agricultores,   incluyendo   en   ellos   un   campo   calculado   que   es   el   de  alojamiento,  el   cual   se   calcula  multiplicando  por  el   coeficiente  0,02  el   valor  de  adquisición  y  sumándole  120€.    En  la  siguiente  imagen  se  puede  apreciar  que  el  diseño  tuvo  que  ser  retocado  varias  veces,  los  últimos  cambios  exigidos  por  el  cliente  debido  a  que  se  solicitó  mostrar  los  costes  totales,  los  costes  horarios  y  los  costes  por  hectárea  de  cada  tarea.    

     Todas   estas   cosas   no   estaban   en   mi   planificación   inicial   (las   cuales   han   hecho   que   se   me  descuadren  bastante  las  iteraciones  que  yo  había  planeado).    Nuevos  cambios  en  los  cálculos  de  costes    Después   de   realizar   las   pruebas   pertinentes   y   ver   que   los   costes   estaban   divididos   en   coste  maquinaria   y   coste   finca   en   ficheros   diversos   decidí   unificarlos   en   uno   nuevo   con   todos   los  cálculos  necesarios  para   realizar  de  manera   correcta  previsión  del   coste   total  de   cada   tarea.  Los   ficheros   realizados   por   Gonzalo   estaban   diseñados   para   recoger   los   datos   de   una   vista  concreta  mediante   JQUERY,   calcular   los   costes  y  plasmarlos  en   sus   campos  de  costes.  Por  el  contrario  yo  he  decidido  crear  unas  funciones  más  generales  que  comentaré  a  continuación  y  que  pueden  ser  reutilizadas  en  un  futuro.  

Interfaz  tareas  

Costes  desglosados  

 

44    

El  fichero  desarrollado  en  esta  versión  es  el  siguiente:  costesTareas.js    

 

 

 

Dentro  de  este  fichero  nos  encontramos  los  siguientes  métodos:  

 

 

 

 

 

 

 

 

Estas  funciones  son  las  que  calculan  los  costes  horarios  de  la  tarea.    

La  función  “eficiencia”  nos  calcula  el  rendimiento  de  una  máquina  en  una  operación  agrícola.  Le  pasamos  como  parámetros  la  finca  y  la  máquina  autopropulsada  y  en  la  función  se  calcula  el  rendimiento   mediante   la   dificultad   de   la   finca   y   el   rendimiento   máximo   y   mínimo   de   la  máquina  insertados  por  el  usuario  al  generar  la  finca  y  la  máquina.      

La   función   “calcular_tiempo_op_real”   internamente   calcula   el   número   de   horas   necesarias  para   poder   realizar   una   determinada   tarea   en   una   explotación   agraria   y     con   una  máquina  autopropulsada.   Estos   dos   últimos   parámetros   son   los   que   le   pasamos   a   la   función.   Por   lo  tanto  el  número  de  horas  necesarias  se  obtiene  de  la  máquina  autopropulsada.  

La  función  “costesTareas”  es  la  encargada  de  realizar  los  cálculos  de  los  costes  fijos  y  variables  de  la  máquina  autopropulsada  y  los  costes  fijos  de  los  aperos  incluyendo  además  los  costes  de  personal  y  de  los  productos  fitosanitarios.  Para  realizar  estos  cálculos  interviene  el  tiempo  de  operación  real  y  la  eficiencia.  

La  función  “costesTareasMaquinas”  es  la  encargada  de  almacenar  los  costes  de  la  maquinaria  en  la  base  de  datos.  Ella  se  encarga  de  enviar  un  objeto  JSON  al  “ajaxModel.php”  para  que  este  lo  almacene  en  las  tablas  de  la  base  de  datos.  

En   las   siguientes   funciones   vemos   que   se   calculan   los   costes   fijos   y   variables   por   separado  como   he   comentado   anteriormente.   Los   costes   fijos   se   consideran   los   costes   derivados   de  intereses,   amortización   y   ASI   (Alojamiento,   Seguros   e   Impuestos)  mientras   que   los   variables  son  los  derivados  de  gastos  de  combustible  y  reparación  y  mantenimiento.  

Fichero  de  costes  

Métodos  de  cálculo  de  costes  

 

45    

En  cada  una  de  las  funciones  que  vemos  en  la  imagen  “Métodos  de  calculo”,  observamos  que  se  van  calculando  los  costes  horarios  de  cada  sub  apartado  como  indica  cada  una  de  ellas  en  su  nombre.  Decidí  realizar  cada  apartado  por  separado  para  que  se  comprendiesen  mejor  y  si  en  un  futuro  se  decidiesen  modificarlas,  dichas  modificaciones  se  realizan  de  manera  más  simple.    

 

 

 

 

 

En  la  siguiente  imagen  observamos  los  métodos  que  calculan  los  costes  anuales,  similares  a  los  vistos  anteriormente  que  calculaban  los  horarios:  

 

 

 

 

 

 

 

 

También  observamos  los  métodos  que  calculan  los  costes  de  cada  apartado  pero  esta  vez  de  manera   anual.   El   coste   anual   se   calcula   de   la   siguiente   forma:   “coste/h”   x   “t_op_real”   x  “numero  de  Ha”  x  “numero  de  pases”.  Y  el  coste  anual  por  hectárea:  “coste/h”  x  “t_op_real”  x  “numero  de  pases”.  

En   el   cálculo   de   los   costes   anuales   he  modificado   la   forma   de   calcular   el   tiempo   real   de   la  operación.  Los  cálculos  modificados  son  los  siguientes:    

• La   distancia   recorrida   es   la   distancia   que   tiene   que   recorrer   la  maquina   autopropulsada  para  realizar  la  tarea  en  toda  la  finca  completa  y  su  media  son  metros.  

o distancia_recorrida=(finca.superficie*10000)/anchura  • El   tiempo   de   operación   teórico     se   calcula   como   la   distancia   recorrida   en   kilómetros  

dividido   entre   la   velocidad   a   la   que   la  máquina   puede   trabajar   en   km/h   con   lo   que   sus  unidades  son  horas.  

o t_op_teorico  =  (distancia_recorrida/1000)/velocidad  • El   tiempo   de   operación   real,   es   el   tiempo   anterior   multiplicado   por   la   eficiencia   de   la  

máquina  en  dicha  finca.  Sus  unidades  también  son  horas.  o t_op_real=t_op_teorico*eficiencia(fin,maq)  

Métodos  de  calculo    

Métodos  de  calculo  anuales  

 

46    

Desviaciones  horarias  Nada  que  resaltar.    Pruebas  realizadas    Para   la   comprobación  de   todas   estas   funciones  he   introducido  nuevas   tareas,   comprobando  que  se  recogían  en  la  tabla  y  se  almacenaban  correctamente  todos  los  campos  en  la  base  de  datos.  Una  vez  almacenados,  he  calculado   los  costes  de  cada  tarea.  Para  esta  comprobación,  he  realizado  un  ejemplo  en  papel,  calculando  las  horas  que  harían  falta  trabajar  esa  finca  con  una  determinada  máquina  y  después  comprobar  que   los  cálculos  eran   los  correctos.  Una  vez  que  el   tiempo  era  correcto,  comprobé  que   los  costes  de   la  maquinaria  se  correspondían  con  los  que  Gonzalo  tenía  realizados  en  su  aplicación,  ya  que  se  podían  comprobar  introduciendo  una  máquina  y  todos  sus  campos  necesarios.  

He  realizado  pruebas  en  papel  para  comprobar  que  el  cálculo  del  tiempo  de  operación  de  cada  tarea  está  bien   realizado  y   comparándolo   con  el   que  me  devolvía   la   aplicación,  he  obtenido  resultados    satisfactorios.  

Valoración  por  parte  del  cliente    Durante   la   reunión   con   el   cliente   para   mostrarle   los   avances   del   TFG,   realizamos   pruebas  insertando  tareas  y  comprobando  sus  funcionalidades.  El  cliente  quedó  bastante  satisfecho  ya  que  veía  que  se  cumplían  todos  los  requisitos  que  él  había  exigido  y  los  cálculos  funcionaban  correctamente.   El   cliente   decidió   realizar   un   caso   de   uso   real,   sacó   de   un   libro   agrícola   los  datos  de  unas  determinadas  tareas  las  cuales  ya  estaban  calculados  sus  costes  y  lo  insertamos  en   la   aplicación   para   comprobar   que   su   funcionamiento   era   al   correcto.   La   prueba   resultó  satisfactoria  dándonos  su  visto  bueno  a  la  previsión  de  costes.    A  continuación  sugirió  introducir  un  parámetro  más  a  la  tabla,  el  cual  diese  mayor  control  del  rendimiento  de  una  tarea.  Este  parámetro  es  el  rendimiento  de  una  máquina  autopropulsada  en   una   explotación   agraria.   Anteriormente   este   parámetro   se   calculaba   en   la   función  eficiencia,  pero  ahora  le  vamos  a  permitir  al  usuario  que  lo  determine  él  y  conseguir  con  ello  unos  cálculos  más  exactos  y  dar  mayor  control  al  usuario  (agricultor).    Los   gráficos   fueron   del   agrado   del   cliente   ya   que   vio   plasmado   lo   que   él   consideraba  fundamental   que   conociese  un  agricultor   y   se   correspondía   con   la   idea  que  él   se  hizo  en   su  cabeza  al  mostrarle  los  prototipos.    

 

47    

ITERACION  4.    Introducción  de  nuevos  parámetros  para  incrementar  la  precisión  de  los  cálculos  .    

Objetivos  

Como  he  comentado  en  la  iteración  anterior,  vamos  a  insertar  un  nuevo  parámetro  en  la  tabla  de  las  tareas.  Este  nuevo  parámetro  es  el  rendimiento  de  la  operación  agrícola.  Anteriormente  se  calculaba  como   la  eficiencia  en  parcela.  Ahora  en  esta   iteración   se  pretende  poder  dar   la  opción  al  usuario  de  introducir  ese  parámetro  a  mano  para  darle  mayor  control  y  precisión  en  las  previsiones  de  costes.    

Análisis  del  diseño  

Teniendo   clara   la   función   que   va   a   desempeñar   este   parámetro,   es   hora   de   pensar   cómo  introducirlo  a  la  interfaz  ya  desarrollada.    

La  idea  principal  es  mostrar  este  parámetro  en  todo  momento  para  que  el  usuario  lo  conozca  ya   que   el   cliente   recalcó   en   la   reunión   que   dicho   parámetro   es   muy   importante   para   el  agricultor.  Sabiendo  todo  esto  se  pensó  en  la  siguiente  interfaz:  

 

 

 

Como  observamos  en  el  recuadro  resaltado  en  rojo  de  la  imagen  “Rendimiento  agrícola  1”,  se  cumple  el  requisito  exigido  por  el  cliente.  Se  ha  añadido  dicho  parámetro  en  la  tabla  HTML  en  el  lugar  especificado  por  el  cliente.  Igualmente,  permanece  visible  cuando  pulsamos  sobre  el  botón  de  ”ver  más  detalles”  de  la  tarea,  quedando  el  diseño  de  la  siguiente  manera:    

 

 

 

         Implementación    Internamente  también  me  he  visto  obligado  a  realizar  cambios.  Primeramente  se  han  tenido  que  modificar  las  funciones  que  pintan  la  tabla  de  tareas  ya  que  ahora  se  muestra  un  input  y  un   título  más  en   la   tabla.  A   la  hora  de  almacenar  una  nueva   tarea  se  ha   tenido  que   recoger  dicho  valor  nuevo  y  añadirlo  a  las  funciones  que  lo  almacenan  en  la  base  de  datos.  Esto  último  obliga  a  realizar  cambios  en  la  vista,  en  el  controlador  y  en  el  modelo.    El   nuevo   rendimiento   es   recogido   como   parámetro   introducido   por   el   usuario.   Comentar  también  que  se   realiza  de  manera  automática  dicho  calculo  para  usuarios  qué  no  sepan  que  

Rendimiento  agrícola  1    

Rendimiento  agrícola  2    

 

48    

rendimiento   poner,   se   calcula   en   función   a   la  máquina   y   la   dificultad   de   la   finca   que   él   ha  escogido  gracias  a  la  función  eficiencia  del  fichero  “costesTareas.js”.  Esto  se  acordó  realizarlo  de   esa  manera   en   una   reunión   con   el   tutor,   sirviendo   como   apoyo   para   las   usuarios.   Dicho  usuario  tendrá  la  posibilidad  de  modificar  ese  valor  generado  automáticamente  por  el  que  el  crea  conveniente  en  cualquier  momento.    La  función  que  ahora  calcula  el  tiempo  de  operación  real  de  una  tarea  se  simplifica,  debido  a  que   se   le   pasa   como  parámetro   el   valor   del   rendimiento   y   se   evita   el   tener   que   llamar   a   la  función  “eficiencia”  que  ya  existía  anteriormente  para  el  cálculo  de  ese  valor.      Con   respecto  a   la  base  de  datos,   se  ha  añadido  un  campo  nuevo  a   la   tabla  “tareas”,   el   cual   sirve   para   almacenar   el   rendimiento   de   la   operación  agrícola.  A  este  campo  le  he  denominado  “eficiencia”  y  de  tipo  entero.  Lo  he  almacenado   en   esta   tabla   ya   que   es   el   mejor   sitio   debido   a   que   hace  referencia  con  maquinaria  y  finca  y  ambas  forman  una  tarea.    

 

 

 

Pruebas  realizadas    

Las  pruebas  realizadas  en  esta  iteración  son  simples:  

• Con  las  tareas  ya  generadas,  insertar  el  nuevo  parámetro  y  calcular  de  nuevo  los  costes  de  las  tareas  modificando  ese  porcentaje.    

Estas   pruebas   han   resultado   satisfactorias   ya   que   si   ese   porcentaje   disminuye,   aumenta   el  número   de   horas   empleadas   por   Ha   y   si   aumenta,   el   caso   contario   y   con   ello   los   costes  también  varían  adecuadamente.  

Valoración  por  parte  del  cliente    El  cliente  quedó  gratamente  satisfecho  al  comprobar  el  funcionamiento  de  la  aplicación  con  el  nuevo  parámetro  integrado  en  ella.  Le  gustó  mucho  la  idea  de  que  si  el  agricultor  no  sabe  qué  porcentaje  utilizar  en  el  rendimiento,  la  propia  aplicación  le  realice  un  calculo  estimado  según  los  parámetros  de  la  máquina  y  de  la  explotación  agraria.  Consideró  que  esto  puede  ser  de  gran  ayuda  a  los  agricultores  que  duden  entre  qué  rango  de  valores  asignar  a  dicho  parámetro.  También  le  agradó  ver  que  dicho  parámetro  podía  ser  modificado  en  cualquier  momento.  

 

 

 

 

Tabla  tareas  

 

49    

ITERACION  5.  Modificaciones  en  la  interfaz  de  la  aplicación.    

Objetivos  

En   esta   iteración   lo   que   se   pretende   conseguir   es  mejorar   la   interfaz   para   que   el   usuario   al  verla  sea  capaz  de  comprenderla  de  manera  rápida  y  simple.  Hasta  ahora   la   interfaz  que  nos  muestra   las   tareas  es  demasiado  pesada,   siete   filas  por   cada   tarea  es  excesivo  y   solo   lleva  a  confusiones.    Se  va  a  intentar  unificar  el  estilo  de  la  interfaz  ya  existente  en  la  versión  anterior  de  la  aplicación  en  los  apartados  maquinaria  y  fincas  con  la  nueva  creada  para  las  tareas.  

En  una  reunión  con  el  tutor,  pensamos  de  qué  manera  simplificar  la  interfaz  y  observando    la  página  de  cuaderno  de  campo  de  explotaciones  agrícolas16  conseguimos  llegar  a  una  solución  adecuada.   Avanzando   por   dicha  web,   apreciamos   unas   tablas   similares   a   la   desarrollada   en  tareas  y  vimos  que  por  cada  fila  mostraban  solo  los  datos  mínimos  y  tenían  un  botón  para  ver  mas  detalles  de  cada  fila.  El  objetivo  final  a  conseguir  es  el  siguiente:  

Tabla  Máquinas    

 

 

Tabla  Fincas  

 

 

Tabla  Tareas  

 

 

 

Además   se  pretende   insertar  en   la   interfaz  el  número  de  horas  empleadas  en   cada   tarea  ya  que  en   la   última   reunión   con  el   tutor   consideramos  que  puede   ser   un  dato   interesante  que  debería  conocer  el  agricultor.  

 

 

 

 

 

16  Cuaderno  de  campo.  http://www.micuadernodecampo.es  

Interfaz  tabla  máquinas    

Interfaz  tabla  fincas    

Interfaz  tabla  tareas    

 

50    

Análisis  del  diseño  

En  la  siguiente  imagen  se  aprecia  como  está  diseñada  la  ultima  interfaz  de  las  tareas:  

 

Como   apreciamos   en   la   imagen   “Diseño   interfaz”,   son   demasiados   campos   los   que   se  muestran  en  cada  tarea.  

Si   nos   imaginamos   esta   misma   interfaz   con   6   o   7   tareas   distintas,   nos   damos   cuenta   que  necesitamos   realizar   scroll   vertical  para  poder  acceder  a   las  últimas   tareas.   Se   intentó  evitar  esto  mediante  el  botón  de  reducir  los  productos  de  la  tarea  a  una  fila  y/o  reducir  la  tarea  a  una  solo  fila,  pero  la  mejor  solución  es  rediseñar  dicha  interfaz.    

La  solución  que  nos  resulto  interesante  fue  dejar  una  solo  fila  para  cada  tarea  y  seguir  con  el  estilo   realizado   en   las   pestañas   de   maquinaria   y   fincas,   en   las   cuales   una   sola   fila   hace  referencia  a  una  maquina  y  a  una  finca.  

Si   queremos   que   solo   se   muestre   una   tarea   en   cada   fila   y   así   mantener   una   interfaz   muy  similar  a  la  de  las  tareas  y  las  fincas,  el  nuevo  diseño    mostrará  en  ella  los  datos  referentes  al  nombre  de  la  tarea,  la  finca,  el  numero  de  pases  al  año,  la  anchura  de  trabajo,  la  velocidad  de    trabajo  y   los  costes  horarios,  anuales  y  por  hectárea.  Como  novedad  se  añade  un  botón  “ver  más”  el  cual  si  hacemos  click  sobre  el  nos  desplegará  en  la  tabla  solo  los  campos  de  esa  tarea  con  un  botón  “volver  ”en  la  parte  inferior  para  poder  volver  a  ver  todas  las  tareas.  

En  las  siguientes  imágenes  se  observa  mejor  lo  que  acabo  de  comentar.  

 

 

 

 

 

 

 

 

La  imagen  “Ver  detalles”  se  corresponde  con  la  interfaz  en  la  que  aparecen  todas  las  tareas  y  en   la   cual   podemos   añadir   nuevas.   En   el   recuadro   rojo   observamos   los   botones   que   nos  

Diseño  interfaz    

Ver  detalles    

 

51    

mostrarán  todos  los  detalles  ocultos  de  dicha  tarea.  Si  pulsamos  sobre  el  botón  nos  aparecerá  la  siguiente  tabla  con  todos  los  datos.  

 

 

 

 

 

 

Una   vez   realizada   esta   modificación,   en   una   reunión   con   el   tutor   acordamos   bloquear   los  campos  de  la  tarea  en  la  vista  general  de  todas  ellas,  en  la  cual  no  se  podrá  modificar  ningún  campo.  Si  se  quisiera  realizar  cambios  en  alguna  tarea  se  deberá  acceder  a  sus  detalles  y  allí  sí  que  se  permitirá  cambiar  los  datos  que  deseemos.  

 

 

 

 

 

 

 

Con  este  cambio  en  la  interfaz  conseguimos  continuar  con  el  estilo  de  la  aplicación  y  evitar  que  el  usuario  modifique  algún  dato  por  error.   La  única  opción  permitida  en  esta  vista  es  añadir  una  nueva  tarea  y  acceder  a  los  detalles  de  una  determinada  tarea.  

Como  aún  queda  un  campo  vacío  en  la  primera  fila  de  la  tabla,  la  que  hace  referencia  a  la  finca,  he  pensado  que  puede  ser  el  sitio  adecuado  para  mostrar  el  numero  de  horas  previstas  para  la  realización  de  la  tarea.  

He  pensado  que   al   hacer   click   sobre   “ver  más”   se   recalcule   automáticamente   el   coste   de   la  tarea  por  si  se  ha  modificado  algún  campo  de  la  tabla  finca  o  de  la  maquinaria.  

Implementación    

Conociendo  el  diseño  de  la  nueva  interfaz,  lo  primero  que  he  hecho  ha  sido  cambiar  la  forma  en  la  que  se  dibujaba  la  tabla  de  tareas.  Ahora  solo  se  muestra  la  primera  fila  de  cada  tarea  en  el  método  “pintaTablaTareas”.  He  eliminado  las  opciones  de  calcular  costes,  editar  y  eliminar  tarea  en  este  método.  Solo  permitiendo  almacenar  la  nueva  tarea  y  añadiendo  la  opción  de  los  detalles  de  la  tarea.  Esta  ultima  opción  llama  al  método  que  veremos  a  continuación.  

 

Tarea  detallada    

Tareas    

 

52    

Esta  función  carga  todos  los  datos  de  la  tarea  y  con  ellos  llama  a  la  función  pintaTablaTareas3  para  plasmar  la  tabla  en  la  página.  

 

Esta   función   como  he   comentado  es   la   encargada  de  pintar   la   tabla   con   la/las   tareas  que   le  mandamos  como  parámetro,  realiza  la  misma  función  cuando  el  usuario  realiza  una  búsqueda  con  los  filtros  o  al  pulsar  en  “ver  mas”.  Una  vez  pintada  la  tabla,  ahora  sí  que  se  permite  utilizar  las  funciones  de  editar,  eliminar  la/las  tareas  y  calcular  sus  costes.  

También  me  he  visto  obligado  a  pulir  detalles  en  las  funciones  de  ordenación  alfabética  de  las  tareas,   ya   que   al   modificar   los   datos   que  muestro   en   la   tabla,   he   tenido   que  modificar   las  funciones  encargadas  de  ello.  

La   integración   del   número   de   horas   que   necesitamos   invertir   para   completar   la   tarea,   la   he  realizado  en  el  mismo  método  en  el  cual  se  pinta  la  tabla  de  tareas.  He  añadido  un  campo  para  insertar   este   dato   y   como   el   numero   de   horas   ya   estaba   calculado   en   el   fichero   de  “costesTareas.js”,  lo  que  he  hecho  ha  sido  recogerlo  de  la  función  “calculaTiempo_op_real”  e  insertarlo  en  el  nuevo   campo.  Este   campo   se  muestra   también  en   la   vista  general   en   la  que  vemos  todas  las  tareas  como  vemos  en  la  siguiente  imagen.  

 

Resultado  Final    Como  hemos  podido  observar,  se  ha  conseguido  mantener  el  estilo  de  la  interfaz  desarrollada  anteriormente  por  Andrés,  de  esta  forma  se  facilitará  al  usuario  su  manejo.    

También  he  añadido  la  funcionalidad  al  botón  “ver  más”  en  la  cual  se  haga  automáticamente  una  llamada  a  calcular  costes  por  lo  comentado  en  los  objetivos  de  la  iteración.  De  esta  forma  si   se   han   realizado   cambios   en   alguna   máquina   o   finca   utilizadas,   dichos   costes   totales   se  actualizarán  inmediatamente  al  pulsar  sobre  el  botón  y  acceder  a  los  detalles  de  la  tarea.      

Valoración  por  parte  del  cliente    El  cliente  no  había  exigido  que  se  mostrase  el  numero  de  horas  previstas  en   la  tabla,  pero  al  ver   el   resultado   final   se   quedó   sorprendido   y   comentó   que   viéndolo   en   ella   el   agricultor   ya  conoce  todos  los  datos  necesarios  para  la  correcta  previsión  de  los  costes  con  lo  que  su  trabajo  se  facilita  muchísimo.  También  nos  comentó  que  con  la  aplicación  en  el  estado  actual  podría  ayudar   mucho   a   sus   alumnos,   ahorrándoles   tiempo   en   la   previsión   de   costes,   cosa   que  anteriormente   les  ocupaba  un  gran  porcentaje  de   tiempo  en   los   trabajos  que   les  obligaba  a  realizar  en  su  asignatura.  También  es  de  gran  ayuda  para  él  ya  que  puede  corregirles  los  costes  de  manera  mas   rápida   con   un   simple   vistazo   y   no   tener   que   revisar   hojas   de   cálculo   como  seguía  revisando  actualmente.    En  definitiva  quedó  satisfecho  ya  que  se  han  cumplido  todos  sus  objetivos  y  se  han  realizado  alguno  más  con  el  que  no  contaba  en  el  comienzo.  

Tareas  detalladas  

 

53    

ITERACION  6.  Implantación  de  la  aplicación  en  el  servidor.    Preparación  previa  

Antes  de  subir  la  aplicación  al  servidor  he  tenido  que  realizar  varios  cambios:  

• Dentro  del  fichero  “views  /  layout  /  agrario  /  var_globals.js”  deberemos  modificar  la  variable  base_url  e  indicar  la  url  que  utilizará  la  aplicación  web:  https://acmag.unirioja.es/acmag_v2/

• Hay  que  modificar  el  fichero  config.php  el  cual  almacena  numerosas  constantes  necesarias  para  el  correcto  funcionamiento    de  la  aplicación  entre  ellas:  

o Base_url  en  la  que  debemos  indicar  la  url  utilizada  por  la  aplicación  web.  o Deberemos  configurar  también  la  base  de  datos  utilizada  por  la  aplicación.  

Este  fichero  está  alojado  en  la  carpeta  app.                  

Implantación  

La  aplicación  web  será  implantada  en  un  servidor  web  alojado  en  la  UR  (acmag.unirioja.es).  

Esta  implantación  consistirá  en  sobrescribir  la  versión  de  Andrés  y  dejar  la  versión  de  Gonzalo.  Se  realizará  de  esta  forma  ya  que   la  nueva  versión   incluye  toda   la  funcionalidad  desarrollada  por   Andrés   incorporando   lo   desarrollado   por   mi,   por   lo   tanto   no   hay   necesidad   de   seguir  manteniendo   dicha   versión,   con   la   ultima   seguimos   manteniendo   las   funcionalidades  anteriores   y   añadimos   las   nuevas.   Por   el   contrario   seguimos   manteniendo   la   versión   de  Gonzalo   ya   que   su   aplicación   es   completamente   distinta   a   la   actual   y   por   ello   resulta  interesante  que  siga  disponible.  

 

Conexión  al  Servidor  “acmag.unirioja.es”  

Para  poder  conectarnos  al  servidor  necesitaremos  configurar  una  conexión  VPN,  es  decir  un  canal  seguro  de  comunicación  que  nos  permita  gestionar  la  aplicación  desde  cualquier  lugar.  El  programa  que  vamos  a  necesitar  para  establecer  dicha  VPN  es:  forticlient.    

En  las  siguientes  imágenes  vamos  a  ver  el  proceso  de  conexión  a  la  VPN:  

 

 

 

 

 

 

 

 

 Creación  de  la  conexión     Conexión  establecida  

Fichero  var_globals.js  

Fichero  config.php  

 

54    

En  la  foto  ”Creación  de  la  conexión”  observamos  cómo  se  rellenan  los  campos  obligatorios  para  su  creación:  

• Server:  boo.unirioja.es  • Puerto:  10443  • User  y  password:  la  quasi  de  la  UR.  

Una  vez  que  tenemos  esto  ya  rellenado  pulsamos  en  conectar  y  nos  aparecerá  algo  similar  a  la  imagen  “Conexión  establecida”,  esto  significa  que  la  VPN  ya  esta  establecida.  

Una  vez  establecida  la  conexión  VPN  necesitamos  conectarnos  al  servidor  en  el  cual  desplegaremos  la  aplicación  web.  Para  ellos  utilizaremos  una  conexión  mediante  escritorio  remoto  como  veremos  en  las  siguientes  imágenes:  

   

 

 

 

 

 

 

 

 

 

Una  vez  abierto  el  escritorio  remoto,  indicaremos  el  servidor  al  que  queremos  conectarnos,  el  usuario   y   la   contraseña   de   acceso.   Las   credenciales   necesarias   para   poder   conectarnos   a  “acmag”  deberemos  solicitarlas  en  este  caso  al  tutor  del  proyecto.  

 

Implementación  de  la  aplicación  en  el  servidor  “acmag”  

La  implementación  en  el  servidor  ha  resultado  bastante  simple  debido  a  que  la  configuración  de   XAMP   y   todas   las   configuraciones   pertinentes   para   que   la   aplicación   funcione  correctamente  ya  estaban  realizadas  por  Andrés.  

Para  implementarla  deberemos    acceder  a  la  carpeta  de  XAMP  alojada  en  la  raíz  del  disco  duro  local,  abrir  la  carpeta  htdocs  y  dentro  de  ella  hay  creada  una  carpeta  llamada  “tfg”  en  la  cual  deberemos  copiar  la  carpeta  completa  de  nuestro  proyecto  sustituyéndola  por  la  ya  existente.  Una  vez  realizado  esto  y  para  que  los  cambios  surtan  efecto  deberemos  reiniciar  los  servicios  de  Apache  y  MySQL    de  XAMP.  Como  también  la  base  de  datos  ha  sido  modificada  deberemos  sustituir   la   existente   por   la   nuestra,   para   ello   deberemos   exportarla   en   formato   SQL   e  importarla   en   el   servidor.   Una   vez   tengamos   el   fichero   con   formato   sql   en   el   servidor,  deberemos  crear  una  base  de  datos  vacía  con  el  nombre  que  utilicemos  en  el  proyecto,  una  vez  generada   la  nueva  base  de  datos  deberemos   importar  el   fichero   sql  desde  el  navegador  web.  Abriremos  phpmyadmin  ya  que  es  la  herramienta  utilizada  para  el  mantenimiento  de  la  base  de  datos,  pulsar  sobre  importación  y  buscar  el  fichero  sql  a  importar.  Él  solo  nos  generará  la  base  de  datos  con  todas  las  tablas  y  campos  nuevos  que  hemos  desarrollado  durante  todo  el  proyecto.  

 

 

Escritorio  remoto  

Configurar  conexión  

 

55    

Conclusiones    

El  trabajo  desarrollado  me  ha  permitido  adquirir  nuevas  rutinas  de  trabajo  en  cuanto  a  planificación  y  desarrollo  de  tareas.  

Respecto  al  tema  agrícola  previamente  al  proyecto  mi  conocimiento  sobre  ese  tema  era  muy  escaso,  me  ha  aportado  conocimientos    acerca  de  los  distintos  tipos  de  maquinarias  existentes  y  sobre  los  costes  implicados  en  la  tareas.  

En  cuanto  al  punto  de  vista  informático  me  ha  permitido  aprender  el  uso  de  nuevas  tecnologías  de  programación.  También  me  ha  enseñado  a  adaptarme  a  un  proyecto  ya  comenzado  y  poder  continuarlo.  Esto  puede  servirme  de  bastante  ayuda  para  mi  vida  laboral.  

 

Revisión  del  tiempo    

A  la  conclusión  de  todas  las  tareas  planificadas  en  este  TFG,  los  tiempos  quedan  de  la  siguiente  manera:  

Acciones   Horas  PREVISTAS   Horas  EMPLEADAS  ITERACION  0   50   55  ITERACION  1   90     100  ITERACION  2   30     20    ITERACION  3   50     50  ITERACION  4   5   5  ITERACION  5   12   12  ITERACION  6   3   2  REUNIONES   10   10  

REVISIONES  Y  MEJORAS   10   10  MEMORIA   40   40  

  300   304    

He  cumplido  con  la  planificación  semanal  especificada  al  comienzo  del  TFG,  salvo  semanas  en  las   que   tenia   menos   tiempo   debido   a   la   acumulación   de   trabajos   de   las   asignaturas   y  exámenes.  He  logrado  terminarlo  en  el  tiempo  fijado  exceptuando  las  4  horas  que  me  he  visto  obligado  a  trabajar  de  más  para  completar  todos  los  objetivos.  

Objetivos  logrados  

Del  trabajo  futuro  que  dejó  pendiente  Andrés  se  han  logrado  alcanzar  los  siguientes  objetivos:  

• Permitir  a  la  aplicación  el  borrado  de  usuarios.  • Permitir  añadirle  a  una  máquina  autopropulsada  uno  o  varios  aperos.  • Establecer  un  sistema  de  recuperación  de  contraseñas  para  los  usuarios.  • Calcular  una  previsión  de  los  costes  de  las  tareas  agrícolas.  • Prever  los  costes  de  la  mano  de  obra  y  de  los  productos  fitosanitarios.  • Permitir  a  los  usuarios  dar  de  alta  nuevas  tareas.  

Además  de  estos  objetivos  se  han  cumplido  otros:  

• Controlar  los  usuarios  que  se  registran  en  la  aplicación  por  su  correo  electrónico.  • Generar  PDFs  con  los  costes  de  la  maquinaria.  

 

56    

• Visualizar  los  costes  agrícolas  mediante  gráficos  de  sectores.  • Detallar  los  costes  de  las  tareas  de  manera  intuitiva  para  el  usuario.  • Filtrar  mediante  búsquedas  las  tareas.  • Ordenar  las  tareas  alfabéticamente.  

 

Trabajo  futuro      

Como  tareas  pendientes  para  futuras  versiones  pueden  ser  las  siguientes:  

o Disparadores  que  actualicen  los  costes  de  las  tareas  en  el  momento  que  algún  valor  de  la  maquinaria  o  de  la  finca  sea  modificado,  sin  necesidad  de  entrar  a  cada  tarea  para  que  se  actualice.  

o Se  puede  modificar  toda  la  interfaz  de  la  aplicación,  para  darle  un  toque  mas  moderno.  Por  ejemplo  utilizando  plantillas  o  realizándolo  desde  cero.  

o Desarrollar  una  aplicación  móvil  en   la  cual  se  permita  al  usuario  poder  realizar   todas  las  funcionalidades  disponibles  en  la  web.  

o Dar  de  alta  fincas  con  los  datos  obtenidos  desde  el  catastro.  o Generar  un  PDF  con  todas  las  previsiones  de  costes  de  las  tareas.  o Realizar  filtros  de  búsquedas  que  te  sugieran  palabras  a  la  vez  que  estás  escribiendo.  

   

 

57    

Bibliografía    

• Temática  agrícola:  o Aplicación  informática  para  la  previsión  de  costes  de  producción  de  cultivos  

agrícolas  (2013)  de  Gonzalo  Bastida  Rodríguez.  § http://biblioteca.unirioja.es/tfe_e/TFE000278.pdf  

• Hoja  de  calculo  para  la  previsión  de  costes  horarios  y  anuales  de  la  maquinaria  agrícola.  Departamento  de  Agrícola  y  Alimentación  de  la  Universidad  de  La  Rioja  de  Juanjo  Barrio  Díez  y  Rebate  Aguirre  (2010).  

• Costes  de  maquinaria  agrícola,  Departamento  de  Agricultura  y  Alimentación  de  la  Universidad  de  La  Rioja  de  Juanjo  Barrio  Díez  (2012).  

• Estimación  de  costes  horarios  de  la  maquinaria  agrícola  S.ASABE  Hoja  de  Cálculo  del  Departamento  de  Agricultura  y  Alimentación  de  la  Universidad  de  La  Rioja  creada  por  Juanjo  Barrio  Díez  (2012).  

• MVC  o http://www.lab.inf.uc3m.es/~a0080802/RAI/mvc.html  

• FancyBox  o http://www.usosweb.com/content/tutorial-­‐fancybox  

• PHP  Mailer  o http://www.desarrolloweb.com/articulos/phpmailer.html  

• FPDF  o http://www.fpdf.org  

• JSPDF  o https://parall.ax/products/jspdf  

• Página  para  transformar  una  imagen  a  data  URI    o http://www.greywyvern.com/code/php/binary2base64  

• Data  URI  o http://es.wikipedia.org/wiki/Data:_URL  

• DOM  o http://krook.org/jsdom/HTMLTableCellElement.html  

• AJAX  o http://stackoverflow.com/questions/19462649/trying-­‐to-­‐pass-­‐variable-­‐values-­‐

from-­‐javascript-­‐to-­‐php-­‐using-­‐ajax  • JSON  

o http://www.w3schools.com/json/  • Google  Charts  

o https://developers.google.com/chart/  •  Cuaderno  de  campo  

o http://www.micuadernodecampo.es