TRABAJO FIN DE GRADO. Módulo viñedos

(1)

Iván Godoy San José

Jesús Cervantes

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2013-2014 Título Director/es Facultad Titulación Departamento Curso Académico

Módulo viñedos

Autor/es

(2)

E-mail: [email protected]

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

(3)

Proyecto:

Módulo

Viñedos

Director: Responsable:

Jesús Cervantes

Iván Godoy San José

TFG

_Finalizado:

_25/06/14

(4)

Índice

1. Resumen

1.1 Castellano

1.2 Inglés

2. Introducción

2.1 Logic Soluciones Software

2.2 Sage Murano

3. Introducción al proyecto

4. Proyecto

4.1 Preanálisis

4.2 Gestión del proyecto

4.3 Análisis

4.4 Diseño

4.5 Implementación

4.6 Plan de pruebas

4.7 Control y Cierre del proyecto

(5)

1. Resumen

1.1 Castellano

El presente documento se redacta con carácter de Trabajo de Fin de Grado (TFG). El proyecto lo desarrolla Iván Godoy San José junto a la empresa Logic Soluciones Software. El programa utilizado para desarrollar la aplicación es Sage Murano, ERP utilizado normalmente por la empresa para proyectos o trabajos cotidianos.

El proyecto consiste en realizar una aplicación que controle la traza de la uva, desde que se planta hasta que se obtiene el vino como resultado final de un laborioso proceso.

1.2 Inglés

This document is drawn up by way of Final Project Grade (TFG). The project is developed by Iván Godoy San José with the company Logic Soluciones Software. The program used to develop the application is Sage Murano, ERP usually used by the company for prohects or daily tasks.

The project consists in an application that controls the trace grapes, from planting until the wine is obteined as a final result of painstaking process.

2. Introducción

Antes de comenzar a describir el proyecto, situamos la empresa que lo propone, así como la herramienta que se utilizará para su desarrollo, ya que su aprendizaje es uno de los objetivos del TFG.

2.1 Logic Soluciones Software

El proyecto es propuesto por la empresa Logic Soluciones Software. Esta empresa se dedica a la consultoría, distribución, desarrollo, implantación y servicio postventa de soluciones de software de gestión.

Las empresas que contratan los servicios de Logic son pequeñas o medianas. Los negocios de estas empresas son variados, desde agricultores hasta mecánicos.

(6)

Logic forma parte del Grupo Pancorbo, especialista en nuevas tecnologías de la información y de la comunicación.

2.2 Sage Murano

Desde 1983, Logic es distribuidor global de soluciones SAGE. Sage Murano es un ERP que resuelve las necesidades más exigentes de una empresa de la forma más eficiente posible. Es decir, es un software que da una solución completa para la gestión de empresas. Los módulos de Sage son los siguientes:

 Contabilidad  Compras  Ventas  Almacén  Fabricación  CRM  Gestión Laboral  Recursos Humanos  Gestión Documental  Tesorería

Una de las mayores ventajas de Sage Murano es la sencilla adaptación a cualquier tipo de empresa ó comercio. Utilizando varios módulos de este programa y añadiendo los necesarios vamos a crear nuestra aplicación.

3. Introducción al proyecto

Este proyecto toma vida a raíz de la propuesta de un cliente que se dedica a la gestión de bodegas. El cliente nos plantea una serie de necesidades relacionadas con la gestión de empresas del Sector de Bodegas, de las cuales extraemos la idea principal: la conveniencia de llevar la traza de la uva.

El gestor quiere controlar el proceso completo, desde que la uva es tratada en los viñedos hasta que se obtiene el vino embotellado como resultado final de este proceso.

(7)

La intención del consultor es utilizar las funciones de Sage Murano, con las modificaciones necesarias para que el resultado sea el esperado. Es decir, a la funcionalidad básica de Sage Murano, se le añadirá la funcionalidad propia del tratamiento de viñedos, depósitos de uva y barricas de vino. La aplicación dará la posibilidad de registrar varias empresas.

(8)

4. Proyecto

4.1 Pre-Análisis

Antes de comenzar el proyecto, el director del mismo, compañero de la empresa del alumno, es el encargado de realizar el análisis previo. Se reúne con el cliente, gestor de bodegas, para marcar objetivos, funcionalidad y requisitos.

Como resultado de este primer análisis se obtiene un documento poco concreto con las ideas generales del proyecto. A raíz de estudiar exhaustivamente este documento se cree conveniente dividir el proyecto en 3 partes/módulos: viñedos, bodegas y barricas.

Se decide desarrollarlos en ese orden debido a que es el orden lógico del proceso para obtener el vino a partir de la uva y, posiblemente, las dependencias entre módulos van a seguir mayoritariamente esa misma dirección.

También se proponen otros módulos secundarios para los que se recabará información adicional para nuestra aplicación.

A partir de este momento, comienza la labor del desarrollador de este proyecto, siendo la primera tarea la comprensión del problema y análisis del mismo.

4.2 Gestión del proyecto

Antes de comenzar con el desarrollo, se realiza la planificación de tareas y la estimación del tiempo. El tiempo "máximo" de duración del proyecto son 300 horas, por tanto, para que el proyecto sea admisible, la estimación de tiempo total debería aproximarse a esa cifra.

Para representar las tareas he decidido dibujar un diagrama que estructure la descomposición de las tareas (EDT) junto a su diccionario. También se muestra la gestión temporal del proyecto y un diagrama de Gantt, ya que considero que es la mejor forma de mostrar el progreso del proyecto según avanzan las semanas.

(9)

4.2.1. EDT del proyecto.

(10)

Junto al diagrama anterior se encuentra el diccionario EDT que describe brevemente cada una de las tareas:

101 Análisis: Conjunto de procesos y técnicas que se llevarán a cabo para extraer los requisitos funcionales y no funcionales de la información proporcionada por el cliente. 102 Diseño: Conjunto de procesos y técnicas a través de los cuales se obtienen diagramas y tablas a partir del análisis.

103 Implementación: Puesta en marcha del diseño sobre la interfaz de Sage Murano, utilizando tanto sus técnicas como su estilo.

104 Plan de pruebas: Puesta en marcha de la aplicación con el fin de encontrar fallos o problemas que el usuario se pueda encontrar y poder corregirlos.

201 Planificación: Consiste en estimar el tiempo que emplearemos para desarrollar cada tarea del entregable, así como de controlar cuándo han sido desarrolladas y el tiempo utilizado para su ejecución.

202 Control: Durante la ejecución de las actividades y al terminar las mismas, se comprobará que cumple con lo planificado inicialmente. En cada caso se explicará las razones de retraso o avance. Se incluirán aspectos de calidad.

300 Demostración: Puesta en escena del proyecto y de la aplicación mediante una presentación y un vídeo formal. El vídeo presentará la aplicación y hará un uso detallado de la misma. Se mostrarán todas las áreas de este módulo.

400 Memoria: Documento que reúne todos los entregables del proyecto. Incluye una descripción, análisis, diseño, implementación, plan de pruebas y gestión.

(11)

4.2.2. Gestión del tiempo.

La siguiente tabla muestra el tiempo estimado inicialmente para desarrollar cada tarea. El proyecto es suficientemente grande por ello se considera conveniente estimar tiempos más holgados en las tareas que se realizarán en último lugar para asegurarse de que no nos desviaremos en los plazos establecidos.

ID Tarea Estimado Dedicado

101 Análisis 10 h 102 Diseño 20 h 103 Implementación 200 h 104 Plan de pruebas 20 h 201 Planificación 10 h 202 Control 15 h 300 Demostración 25 h 400 Memoria 25 h Total 325 h

Tabla 1. Tabla que muestra la estimación inicial del tiempo.

Como se observa, se plantea que el desarrollo completo del proyecto llevará unas 325 horas. Se considera apropiado para lo que se supone un TFG. Por ello se desestima la posibilidad de entrar en el desarrollo de los otros dos módulos.

Diagrama de Gantt.

La siguiente tabla muestra cuándo se realizará cada tarea. Se puede observar que el proyecto abarca de Febrero a Mayo (4 meses) en los que se deben repartir las 325 horas estimadas anteriormente.

(12)

ID Tarea Febrero Marzo Abril Mayo S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 S14 S15 S16 101 Análisis 102 Diseño 103 Implementación 104 Plan de pruebas 201 Planificación 202 Control 300 Demostración

Tabla 2. Diagrama de Gantt.

4.3 Análisis

Como se ha comentado anteriormente, tras un primer preanálisis se decidió separar el diseño de la aplicación en tres módulos:

 Viñedos: Se trata de recoger los datos de las viñas, las distintas variedades y su división en parcelas. Interesan sus tratamientos, cualquier operación o labor realizada y tener un control de maduración de la uva.

 Bodegas: A las bodegas llega la uva recién vendimiada. Se almacena en unas salas que tienen grandes depósitos, donde comienza el proceso de fermentación. Interesan sus tratamientos y cualquier operación realizada sobre los depósitos. Cabe recalcar la importancia de las partidas. Hay tres formas de comenzar a considerar una partida:

1. Entrada de la uva.

2. Entrada de vino procedente de compras.

3. Creación de nuevos coupages (mezclas) de dos o más partidas de un depósito.

 Barricas: De los depósitos, el vino pasa a las barricas, formando varias pilas de barricas. Interesa controlar los movimientos de vino y qué operaciones se realizan sobre el vino.

(13)

Hacemos hincapié en que este TFG se centrará única y exclusivamente en diseñar e implementar el primer módulo, ya que la realización del proyecto completo se cree que excede con creces los objetivos del TFG, tanto en tiempo como en materia.

Respecto a la funcionalidad de la aplicación a desarrollar. La parte que desarrolla el alumno en este TFG comprende:

 Se recogerán datos de los viñedos y se podrán modificar en cualquier momento. Se almacenarán datos de variedades, cartillas, parcelas y tratamientos.

 Se almacenarán datos de las vendimias y se podrán modificar en cualquier momento.

 “DiarioViñedo” se guarda automáticamente por el sistema, registrando así cada operación realizada sobre un viñedo.

 Es necesario llevar un control de maduración previo a las labores de vendimia.

 Dentro de las bodegas se forman datos que se recogen a través de ciertas operaciones. Por ejemplo se recogerán datos de los tratamientos de los depósitos de las bodegas.

Para enmarcar lo anterior, se describe también la funcionalidad que no será desarrollada en este TFG:

 “DiarioBodega” y “MovimientosBarrica” se guardan automáticamente por el sistema, registrando así cada operación realizada sobre una bodega o barrica.

 Se recogerán datos de las bodegas y se podrán modificar en cualquier momento. Se almacenarán datos de salas y depósitos.

 Se podrán asignar partidas y se podrán modificar en cualquier momento.

 Identificamos las partidas de una forma interna inequívoca. El usuario podrá acceder al código de la partida según su propio concepto de partida.

 Se recogerán datos de las barricas y se podrán modificar en cualquier momento. El programa funcionará integrado sobre la interfaz de Sage Murano, con toda su funcionalidad básica, además de la recientemente mencionada.

NO se podrán modificar datos que no garanticen el buen funcionamiento del programa: o Datos referentes a la producción.

o Datos liquidados (es decir, se ha efectuado el pago). o Entradas de partidas.

(14)

A partir del análisis del problema y de la funcionalidad planteada se obtiene el siguiente diagrama. Sólo marcamos aquellas "entidades" que van a dar lugar a información propia de nuestro módulo. Como se verá más adelante, algunas de ellas estarán relacionadas con información global de la aplicación.

Figura 2. Diagrama entidad/relación del proyecto.

Para entender lo anterior conviene realizar algunas aclaraciones:

 El propietario de una "parcela" será el titular de la "cartilla" asociada.

 En cada "parcela" puede haber diferentes "variedades". Además un "análisis de una muestra" se hace para una "variedad" de una "parcela", y se basa en una "analítica", que incluye una serie de "parámetros". Los análisis se hacen por variedades ya que, por ejemplo, los parámetros de maduración pueden variar según la variedad.

 Otra información relevante en nuestro sistema son las "labores" realizadas. Para las labores realizadas en un año (cosecha) sobre una "parcela" se dispone de un

(15)

"diario". El "diario" estará formado por "consumos diarios" que, a su vez, consistirá en "labores" con sus correspondientes "consumos".

Se debe hacer notar que se trata de la información necesaria en cada una de las empresas del grupo que se pretenda gestionar. Por tanto, a la hora de pasar a la base de datos, habrá que añadir un identificador de la empresa.

4.4 Diseño.

En el final del análisis se obtuvo un modelo básico de la información a gestionar. Vamos a precisar ahora esa información para llegar a obtener un modelo de clases y tablas de la base de datos.

En el módulo de viñedos encontramos como entidades: las distintas variedades de uva que existen, las cartillas de los viticultores, las parcelas de los viticultores, las labores a las que se someten los viñedos, que incluyen el registro ó historial de tratamientos aplicados (a modo de diario), los parámetros de la maduración de la uva y el control adecuado de esa maduración.

Es norma de la empresa que todos los nombres de campos y tablas que creemos tengo el prefijo "Pi_". A partir de lo anterior se decide considerar las siguientes tablas:

Pi_Variedad

Recoge la información de las variedades. Se relaciona con la tabla artículos estándar.

Dato Tipo de

campo Comentario

CodigoEmpresa Entero (Id) Código de Murano Multiempresa.

Pi_CodigoVariedad Entero, 3 (Id) Es un código numérico que identifica la variedad de uva. Pi_Definicion Texto Nombre de las variedades.

CodigoArticulo Texto Articulo asociado para la liquidación de entregas a proveedores. Relación con artículos.

(16)

Se puede observar que el campo "CodigoEmpresa" aparece como primer campo de todas las tablas de la aplicación. Este campo se recoge porque se contemplan varias empresas. De la misma forma hay varios campos que no competen a este módulo pero son necesarios para los otros dos, como es el caso de "CodigoArticulo". Estos campos tienen que ver con la gestión completa que realiza la aplicación, aunque no son relevantes en nuestro módulo.

Pi_Cartilla

Recoge la información de las cartillas de los viticultores. Se relaciona con la tabla proveedores estándar.

CodigoEmpresa Entero (Id) Pi_NumCartillaViticultor Texto (Id)

Expedido por los CR’s. En otros ámbitos, en los que el reglamento no requiera un registro de viticultores será un dato asignado por la

propia bodega.

Pi_NombreViticultor Texto Nombre del titular de la cartilla.

CodigoProveedor Texto

Enlace con el fichero Murano de proveedores para generar albaranes en las liquidaciones de compras. Sin este dato el viticultor nos puede entregar uva y realizar operaciones en las fincas pero no podremos generarle automáticamente albaranes de

compra. Relación con proveedores. Pi_StatusBajaS/N Entero

La principal utilidad de este campo consiste en facilitar la creación de filtros y reglas de estado que simplifiquen las consultas del

usuario mostrando únicamente cartillas en activo.

En esta tabla se almacena el "códigoProveedor" para liquidar las compras en posteriores módulos.

(17)

Pi_Parcela

Recoge la información de las parcelas (ó fincas) asociadas a un propietario (titular). A partir de esta tabla podemos relacionar las variedades de cada parcela.

CodigoEmpresa Entero (Id)

Pi_CodigoParcela Texto (Id)

Puesto que en la recepción de uva es un dato obligatorio, lo será para todas las bodegas elaboradoras, no así para las que trabajen

únicamente con vino elaborado. Para cerrar la trazabilidad de la materia prima las bodegas que recojan uva de fincas sin identificar deberán informar fincas genéricas u otros conceptos

que justifiquen un origen y tipificación del producto, en estos casos se recomienda, al menos, un registro por cada variedad y

número de cartilla de viticultor. CodigoMunicipio Texto Tabla municipios. Relación con Municipios.

Pi_Termino Texto

Información catastral. Pi_Poligono Texto

Pi_Parcela Texto

Pi_NombreFinca Texto Forma local de identificar la finca. Pi_Situacion Memo Descripción y accesos.

Pi_Propietario Texto Nombre del titular de la parcela, es un dato informativo.

Pi_CartillaViticultor Texto

El titular de la cartilla de viticultor es el proveedor de la bodega y con quien hay que liquidar las entregas. Es posible que el propietario también disponga de cartilla de viticultor y sea necesario liquidar con dos ó más proveedores, en este caso, desde la entrada en báscula, o con posterioridad, se repartirá el

total de kg entregados según las proporciones pactadas entre ambos titulares. Relación con “Pi_Cartillas”.

(18)

Pi_SistemaConduccion Texto/Lista Vaso, doble cordón, vara y pulgar, cordón simple, doble guyot, otros. Por defecto Vaso

Pi_TipoVendimiaPrevista Lista Mecanizada / Manual en cajones / Manual en remolque / Otros. Por defecto Manual en remolque.

Pi_MarcoPlantacion Doble Nº de cepas por hectárea, densidad. Existen limitaciones según distintos CR’s.

Pi_TipoSuelo Memo Descripción informativa

Pi_Observaciones Memo Observaciones generales: Localización, accesos, relieve, etc. Pi_Imagen Binario Ext. Plano, fotografía.

Se recogen datos de importancia como el municipio, el nombre de la finca, la situación, el sistema de conducción ó el tipo de vendimia prevista. Muchos datos no son obligatorios pero es aconsejable introducirlos correctamente.

En esta tabla "CartillaViticultor" pertenece a la gestión de los otros módulos para posteriores liquidaciones de entregas de uva.

(19)

Pi_VariedadesParcela

Esta tabla recoge las variedades de cada parcela.

Pi_CodigoParcela Texto (Id) Enlace con la tabla de parcelas. Relación con "Pi_Parcela". Pi_CodigoVariedad Entero (Id) Enlace con la tabla variedades. Relación con “Pi_Variedades”.

Pi_TipoInjerto Texto Texto libre

Pi_%Variedad Doble Proporción de producción ó de superficie de cada variedad. Pi_AnoPlantacion Texto

Pi_Superficie Doble Dedicada a ésta variedad. Pi_RendimientoTeorico Doble Kg./Hectárea.

Esta tabla representa la relación entre una parcela y sus variedades. Añade atributos como: tipo de injerto, porcentaje de variedad, año de plantación, superficie y rendimiento teórico.

(20)

Pi_Labor

Recoge la información de las labores. Se relaciona con las tablas artículos y almacenes estándar. A partir de esta tabla se podrán recoger los consumos de cada labor.

Pi_CodigoLabor Texto (Id) Texto ó número que identifica cada labor. Pi_Definición Texto Sulfatado, Poda, Espergura, Laboreo, riego, Herbicidas,

Fitosanitarios, Abonado, Vendimia, etc.

CodigoAlmacen Texto Almacén del que descontar los artículos materiales. Enlace con la tabla Murano de Almacenes.

Pi_OperacionAsociada Texto Se trata del código de artículo inmaterial con el que liquidar al proveedor/agricultor.

Pi_CosteEstimado Doble Por operario y hora para ésta operación. Se confirmará al anotar la operación.

En esta tabla "CódigoAlmacén" y "Pi_OperacionAsociada" sirven para liquidar los precios con el agricultor en posteriores módulos.

(21)

Pi_ConsumosLabor

Esta tabla recoge los consumos de cada labor. Concretamente se guarda la dosis (recomendada) que se deberá utilizar por hectárea de cada material.

Pi_CodigoLabor Texto (Id) Texto ó número que identifica cada labor.

CodigoArticulo Texto (Id) En caso de tratamientos se trata del código de artículo material asociado para el rebaje de stock. Enlace con el fichero de artículos de Murano. Pi_Dosis Doble Según las recomendaciones del producto, por hectárea.

En esta tabla se almacena el "códigoArticulo" para controlar el stock en posteriores módulos.

(22)

Pi_DiarioVinedos

Recoge todas las labores realizadas sobre una parcela, ordenadas cronológicamente. Se relaciona con las tablas proveedores, almacenes y artículos estándar y con la tabla "Pi_Parcelas".

Pi_Cosecha Texto (Id) Campaña, año de la vendimia. Pi_CodigoParcela Texto (Id) Tabla “Pi_Parcelas”.

Pi_FechaOperacion Fecha (Id)

Las operaciones realizadas en la parcela entre la vendimia y el comienzo del nuevo año corresponden a la siguiente campaña, la fecha informada en estas operaciones no coincide con el año de la cosecha. Durante este periodo no coincide el año de la fecha con la

campaña en curso.

Pi_CodigoLabor Texto (Id) Tabla tipos de labor y tratamientos. CodigoProveedor Texto

No se generarán automáticamente los albaranes de compra de labores que no tengan informado el código de proveedor. Relación

con proveedores.

CodigoAlmacen Texto Almacén del que descontar el stock. Relación con almacenes. Pi_NumOperarios Entero Informativo. Sin distinción de categorías.

Pi_HorasTotales Doble Tiempo empleado por el conjunto de operarios.

Pi_CosteEstimado Doble

Coste unitario, precio/hora. La liquidación se hace por el total de horas, no se consideran categorías de operarios. Este dato es modificable pero, por defecto, se mostrará el precio de coste

(23)

Pi_OperacionAsociada Texto

Pi_StatusOperacion Entero

“0 Planificada”, “1 Finalizada” o “2 Liquidada”. Servirá para programar los trabajos en las viñas. Inicialmente las labores se dan

de alta como “Planificadas” y un proceso especifico (limitado por fechas, labores, fincas, etc.) marcará como “Ejecutadas” las labores seleccionadas. Solo se liquidarán operaciones que tengan informado

un código de proveedor, (se entiende por liquidar generar automáticamente el albarán de compras correspondiente). Para

subsanar posibles errores la situación “Finalizada” debe ser reversible. Una operación liquidada no es reversible si existe el

albarán relacionado.

Pi_Observaciones Memo Este campo puede contener anotaciones climatológicas o de muestreos no relacionados con el control de maduración. Pi_EjercicioAlbaranC Entero Número de albarán de compra en el que se ha liquidado la

operación.

Pi_SerieAlbaranC Texto Serie de albarán de compra en la que se ha liquidado la operación. Pi_NumeroAlbaranC Entero Número de albarán de compra en el que se ha liquidado la

operación.

Una operación será inicialmente planificada para pasar a estar finalizada y posteriormente se liquidará. De nuevo aparecen campos que están relacionados con la gestión total de la aplicación, por ejemplo, los campos relacionados con el albarán.

(24)

Pi_ConsumosDiario

Esta tabla recoge todos los consumos del diario.

CodigoEmpresa Entero (Id) Murano multiempresa. Pi_Cosecha Texto (Id) Campaña, año de la vendimia. Pi_CodigoParcela Texto (Id) Tabla “Parcelas”. Pi_FechaOperacion Fecha (Id)

Pi_CodigoLabor Texto (Id) Tabla tipos de labor y tratamientos. Pi_OperacionAsociada Texto (Id)

Pi_ConsumoAsociado Texto (Id)

En caso de tratamientos se trata del código de artículo material asociado para el rebaje de stock. Enlace con el fichero de artículos

de Murano.

Pi_PrecioCompra Doble Precio de artículo asociado al consumo. Se confirmará al anotar la operación en el diario.

Pi_CantidadUtilizada Doble

Unidades totales de stock a descontar, no dosis. (Ojo a las transformaciones: Sacos -> Kilos / Garrafas -> Litros, Etc.), este dato

debe estar informado en unidades de compra.

Ídem a la tabla "Pi_ConsumosLabor". Para una labor se realizan una serie de consumos de artículos materiales. Cabe la posibilidad de que alguna labor no realice ningún consumo material. En caso de que se utilicen materiales se registra la cantidad utilizada y el precio asociado.

(25)

Pi_Analiticas

Recoge todos los análisis de la uva. A partir de esta tabla podemos relacionar los parámetros de cada analítica.

Pi_CodigoAnalitica _{Texto (Id)} Código que identifica al tipo de control o al conjunto de parámetros que constituyen un tipo de análitica concreta.

Pi_DescripcionAnalitica Texto Descripción del tipo o grupo de parámetros (Tipo de tierra, control de maduración, análisis de plagas, etc.)

(26)

Pi_ParametrosAnalitica

Esta tabla recoge todos los parámetros de cada analítica junto a una breve descripción de éstos.

Pi_CodigoParametro Texto (Id) Código que identifica el parámetro a valorar

Pi_CodigoAnalitica Texto (Id) Conjunto de parámetros que constituyen una analítica completa. Pi_DescripcionParametro Texto Descripción del parámetro a medir

Pi_TipoParametro Texto Numérico con tres decimales ó texto de 50 caracteres. Pi_ValorMaximo Doble Cuando el tipo de parámetro es numérico se indicará el rango

superior admitido, límites de calidad.

Pi_ValorMinimo Doble Cuando el tipo de parámetro es numérico se indicará el rango inferior admitido, límites de calidad.

Pi_MaximoAlerta Doble Si el valorMaximo es excedido se emite una alerta. Pi_MinimoAlerta Doble Si el valorMinimo es excedido se emite una alerta.

De cada parámetro se contempla un valor máximo y un valor mínimo que no deben ser excedidos.

(27)

Pi_AnalisisMuestras

Refiere a una analítica de una variedad en una finca (parcela).

CodigoEmpresa Entero (Id) Pi_Cosecha Texto (Id)

Pi_CodigoFinca Texto (Id) Tabla fincas

Pi_CodigoVariedad Entero (Id) Variedad sobre la que se aplica el control.

Pi_CodigoAnalitica Texto (Id) Enlace con Pi_ParametrosAnalitica, conjunto de parámetros que constituyen una analítica completa.

Pi_CodigoParametro Texto (Id) Identifica el tipo de control a aplicar al muestreo. Pi_FechaControl Fecha (Id) Fecha del muestreo.

Pi_ValorObtenidoD Valor resultante del control, según los tipos de parámetro definidos como número con 3 decimales.

Pi_ValorObtenidoT Valor resultante del control, según los tipos de parámetro definidos como textos de 50 caracteres.

Esta tabla es el resultado de una relación ternaria entre las parcelas, sus variedades y los análisis realizados en ellas. En esta tabla se almacenan los valores reales obtenidos del análisis.

(28)

4.5 Implementación

El proceso de implementación en este proyecto es bastante diferente a otros procesos de implementación de un proyecto de informática. En efecto, en Sage Murano se trabaja sobre una base de datos previamente creada por cualquier gestor SQL. Desde allí todos los campos, tablas y sus relaciones se crearán a través de la interfaz de Sage Murano. Así pues, podemos decir que todo el proceso de implementación se realiza a través de una interfaz. Para ello, antes de comenzar a crear nada, necesitamos crear la base de datos manualmente, por ejemplo mediante SQL Server. De esta forma, cuando entremos a Sage Murano, deberemos ingresar (además de usuario y contraseña), el nombre de la base de datos sobre la que vamos a trabajar.

A continuación, comentaremos a grandes rasgos el proceso de implementación, para mostrar cómo es el trabajo con Sage Murano.

La primera tarea es crear los campos de repositorio que corresponden con los campos de las tablas. En este primer paso se crean los campos sin indicar a qué tabla corresponden. Es decir, únicamente indicamos características relacionadas con el propio campo: tipo, longitud, valor obligado, etc

Estos campos pasan a formar parte de un almacén para poder ser usados en cualquier momento. Los utilizaremos para nuestra siguiente fase, crear las tablas.

(29)

Figura 3. Cada vez que iniciamos sesión seleccionamos nuestra base de datos.

(30)

Como se ha comentado anteriormente, es norma de estilo de la empresa que todos los campos que creemos tengan el prefijo “Pi_” seguido del nombre que nosotros le designemos.

Una vez creados todos los campos, el siguiente paso es crear las tablas. Los nombres de las tablas se crean de la misma forma que los campos, asignándoles el prefijo “Pi_”. Para cada tabla se le asocian los campos que le correspondan.

Figura 5. Creando las tablas en Sage Murano.

A continuación se determinan las claves primarias de las tablas, eligiendo los campos que pertenecen a dicha clave. Permite indicar si el índice es Principal, Único y/o Clustered.

(31)

Figura 6. Creando las claves primarias de las tablas.

El siguiente y último paso de implementación es la creación de pantallas. Este proceso es complicado, ya que se debe tener en cuenta qué campos de qué tablas son claves extranjeras.

En un principio se crea una pantalla para cada tabla. Este primer paso no tiene ninguna complicación. El objetivo es dejar la pantalla atractiva y fácil de manejar de cara al usuario. Para crear una pantalla se tiene que elegir la tabla de la que partimos. El mismo programa se encarga de plasmar todas las etiquetas y cajas de texto en la pantalla, pero este trabajo no es perfecto por parte de la máquina. Debe ser el desarrollador el que “arregle” la pantalla con el fin de obtener un efecto visual más agradable. Este proceso consiste en agrupar los campos en “macros”, separando los datos identificativos de los registrales y de los técnicos. También se deben distribuir las etiquetas y cajas de una forma lógica.

(32)

Figura 7. Creando pantallas en Sage Murano.

Una vez creadas todas las pantallas simples (asociadas a una única pantalla), comenzamos con la creación de las pantallas compuestas. Las pantallas compuestas son las que están formadas por dos pantallas. Una de las pantallas hace la función de "cabecera" y la otra pantalla hace la función de "líneas".

Las pantallas compuestas surgen a partir de la necesidad de relacionar dos tablas, de forma que un elemento de la tabla que corresponde a la pantalla cabecera se relaciona con otro elemento que corresponde a la pantalla detalle. Pero no debemos confundir estas relaciones obligadas con lo que entendemos como relación entre dos tablas. Este tipo de relaciones se implementarán más tarde.

(33)

En Sage Murano, una pantalla compuesta se llama Master-Detail. Para crear una pantalla de este estilo, se debe asociar una pantalla a la cabecera (o Master) y otra pantalla a las líneas (o Detail).

Lo esencial para la creación es indicar qué campos relacionan estas dos pantallas, es decir, establecer la clave extranjera de la tabla que funciona como cabecera.

(34)

El resultado del proceso es una pantalla como la siguiente:

Figura 9. Así es una pantalla compuesta en Sage Murano.

En la figura 8 podemos observar la pantalla cabecera de un Master-Detail en Sage Murano. Es posible maximizar la pantalla con las líneas del Master-Detail, como se puede ver en la siguiente figura.

(35)

(36)

Por último, como hemos citado anteriormente, se termina el proceso de creación de pantallas, creando las relaciones que los campos de las pantallas tienen con tablas de otras pantallas. Es decir, debemos indicar qué campos de cada pantalla son claves foráneas y de qué tablas.

En Sage Murano se sigue el siguiente proceso. Primero se selecciona la consulta (origen de los datos) de la relación, para posteriormente elegir los campos que se relacionan de cada lado. Normalmente se selecciona el “textBox” de la pantalla por un lado junto al campo de la consulta relacionada. Por último se indica la operación a realizar. Esta operación se crea por defecto al hacer las tablas con el prefijo “op_pi…”. Simplemente debemos seleccionar la operación que hace referencia a la tabla del campo que estamos relacionando.

En alguna pantalla es posible que sea necesario añadir operaciones (Sage Murano lo llama cálculo asociado). Estas operaciones nos ayudan a simular eventos en nuestra aplicación, de forma que podemos activar/desactivar ciertos campos de las pantallas según nos interese. También se pueden establecer valores por defecto “pesados” de introducir constantemente por el usuario. En nuestra aplicación, por ejemplo, el valor de los campos “Cosecha” será normalmente el año en curso.

4.6 Plan de Pruebas

Es trabajo del desarrollador comprobar que la aplicación funciona correctamente. Es altamente recomendado diseñar durante todo el proceso de la implementación y sobre todo al terminar, un plan de pruebas que ayude a descubrir puntos erróneos y fallos en nuestro programa.

Sage Murano ayuda mucho en este proceso. Automáticamente introduce sistemas de seguridad que controla los valores que:

 Son nulos ó vacíos.

 Entran en conflicto.

 No deben ser introducidos.

 No existen en una relación.

Una vez se verifica que no hay problema con ningún valor, se realiza un plan de pruebas más exhaustivo con el fin de comprobar que todas las pantallas devuelven el resultado esperado.

(37)

De esta forma, al ejecutar las pantallas, nos hemos dado cuenta de que no siempre había descripciones adecuadas junto a los diversos códigos de las pantallas. Por ello hemos incluido los “textBox” necesarios junto a sus relaciones para describir estos códigos.

Figura 11. Descripciones explicativas junto a los códigos

De la misma forma, en la pantalla “Pi_DiarioViñedos” echamos en falta poder imprimir las operaciones planificados de forma que agilicemos este proceso de cara al usuario. Por ello hemos introducido un informe que imprima estas operaciones.

Un informe es un documento, algo similar a una factura en nuestro caso, donde indicamos qué campos se imprimen. Todas las operaciones planificadas se imprimirán. En el ejemplo del "Diario de Viñedos" se imprimen todos las tareas cuyo "status" es "planificadas".

(38)

(39)

4.7 Control y Cierre del proyecto

4.7.1. Gestión del tiempo.

La siguiente tabla muestra el tiempo dedicado finalmente a cada tarea frente al estimado inicialmente. Ha habido pocas desviaciones en el proyecto. Las más significativas están resaltadas de color verde o rojo según se haya tardado menos o más en ejecutarlas.

ID Tarea Estimado Dedicado

101 Análisis 10 h 20 h 102 Diseño 20 h 18 h 103 Implementación 200 h ~ 200 h 104 Plan de pruebas 20 h 10 h 201 Planificación 10 h 10 h 202 Control 15 h 20 h 300 Demostración 25 h 15 h 400 Memoria 25 h 25 h Total 325 h 318 h

Tabla 3. Tabla de tiempos al final del proyecto.

El análisis costó el doble de lo estimado inicialmente principalmente debido a que tuvimos que contemplar varios análisis posibles para escoger el diseño que mejor se adaptaba al interfaz de Sage Murano.

El plan de pruebas se ejecutó en 10 horas frente a las 20 estimadas inicialmente. Esta cifra se escribió al principio del proyecto. Si tenemos en cuenta el desconocimiento de este asunto al comienzo del proyecto, la desviación carece de importancia.

El Control se ha llevado a cabo durante todo el proyecto y de una forma minuciosa. Es de esperar que se haya excedido 5 horas lo inicialmente estimado.

Y, por último, la demostración, al igual que el plan de pruebas, se estimó al principio del proyecto. Era lo último que se iba a realizar y le dimos holgura en el tiempo para contemplar posibles retrasos.

(40)

4.7.2. Gestión de calidad.

Se enumeran los requisitos básicos de calidad establecidos entre el cliente y el director del proyecto. Todos los requisitos han sido alcanzados:

 El módulo sigue el estilo de Sage Murano.

 El diseño de campos y tablas sigue el estilo de Sage Murano.

 La funcionalidad es la esperada.

 La calidad de la aplicación es buena.

Los siguientes requisitos han sido establecidos por el alumno:

 La calidad de la memoria es buena.

 La memoria contiene todas las partes acordadas con el tutor del proyecto.

 La memoria ocupa menos de 50 páginas (sin anexos).

 El proyecto incluye una demo.

5. Conclusión

El primer módulo de la aplicación ha sido desarrollado satisfactoriamente. Todos sus componentes funcionan plenamente, tal y como se espera.

El inmediato uso de la aplicación por parte del cliente mostrará en breves las primeras impresiones del software desarrollado.

Visto el éxito del primer módulo, próximamente se prevé que se desarrollen los otros dos. El equipo de la empresa ya se ha puesto "manos a la obra" y pronto serán implementados. El alumno ha trabajado cómodamente junto a los trabajadores de la empresa y les transmite desde aquí todo su agradecimiento.