Aplicación informática para la previsión de costes de ... ·...
Transcript of Aplicación informática para la previsión de costes de ... ·...
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: [email protected]
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