Diseño e implementación de un Sistema de Manejo de Consumo de Materiales Centralizado para la Empresa AMS Family SA.

Transcripción

1 UNIVERSIDAD DE TALCA FACULTAD DE INGENIERIA ESCUELA DE INGENIERÍA CIVIL EN COMPUTACION Diseño e implementación de un Sistema de Manejo de Consumo de Materiales Centralizado para la Empresa AMS Family SA. Profesor Guía: Ruth Garrido Profesores Informantes: Pablo Rojas Renzo Angles Curicó.-

2 Índice Índice Índice... i Índice de Tablas... iii Índice de Figuras... v 1. Introducción Descripción del Contexto Problemática Objetivos Objetivos Generales Objetivos Específicos Alcances y limitaciones Metodología a utilizar Resumen de capítulos Marco Teórico Introducción a los costos [3][4] Actual metodología de costos Metodología Características del proyecto Definición y selección Programación Extrema (XP) Scrum Selección UML Análisis y Requerimientos Adaptación de la metodología Requerimientos Requerimientos Funcionales Planilla Encabezado Detalle Despacho Perfiles de usuario Kárdex Envío de datos Requerimientos No Funcionales Compatibilidad de datos Seguridad de los datos Mantención Productos a entregar Requerimiento de desarrollo Requerimiento de interfaces Casos de uso Diagramas de casos de uso Diseño y Desarrollo Diseño i

3 Índice El proceso de diseño Diagrama de clases Descripción de las clases Modelo de base de datos Diagramas de secuencia Construcción Entorno de desarrollo Lenguaje de programación Motor de base de datos Arquitectura en capas Aplicación Descripción general Implantación y Resultados Implantación Levantamiento de la aplicación Capacitación Resultados Aceptación y utilización del sistema Análisis de los datos Análisis 1: Ingreso de datos Conclusiones y Recomendaciones futuras Objetivos Proceso Producto Trabajos futuros Bibliografía Anexos Glosario ii

4 Índice Índice de Tablas Tabla 1: RF 01, Crear planilla de consumo Tabla 2: RF 02, Modificar planilla de consumo Tabla 3: RF 03, Eliminar planilla Tabla 4: RF 04, Guardar planilla Tabla 5: RF 05, Bloquear planilla Tabla 6: RF 06, Desbloquear planilla Tabla 7: RF 07, Revisar planilla Tabla 8: RF 08, Numeración única Tabla 9: RF 09, Selección de bodega Tabla 10: RF 10, Selección de huerto Tabla 11: RF 11, Ingresar una observación sobre la planilla de consumo Tabla 12: RF 12, Selección de cuartel Tabla 13: RF 13, Ingreso de material Tabla 14: RF 14, Buscar material Tabla 15: RF 15, Agregar consumos a la planilla Tabla 16: RF 16, Bloquear el encabezado de la planilla Tabla 17: RF 17, Bloquear el encabezado de la planilla Tabla 18: RF 18, Generación Automática de una planilla de despacho Tabla 19: RF 19, Agregar detalle automáticamente Tabla 20: RF 20, Quitar detalle automáticamente Tabla 21: RF 21, Separación de datos Tabla 22: RF 22, Asignación de huertos Tabla 23: RF 23, Asignación de productores Tabla 24: RF 24, Asignación de bodegas Tabla 25: RF 25, Generar kárdex Tabla 26: RF 26, Filtrar kárdex Tabla 27: RF 27, Buscar código de material para poder filtrar el kárdex Tabla 28: RF 28, Imprimir el kárdex Tabla 29: RF 29, Convertir a Excel el kárdex Tabla 30: RF 30, Enviar datos Tabla 31: RNF 01, Integración de datos Tabla 32: RNF 02, Seguridad de los datos Tabla 33: RNF 03, Fácil mantención Tabla 34: RNF 04, Productos esperados por la empresa Tabla 35: RNF 05, Bases de datos Tabla 36: RNF 06, Visualización de los datos Tabla 37: RNF 07, Ingreso de datos Tabla 38: RNF 08, Selección de datos Tabla 39: CU-01. Crear planilla de consumo Tabla 40: CU-02. Modificar planilla de consumo Tabla 41: CU-03. Eliminar planilla de consumo Tabla 42: CU-04. Guardar planilla de consumo Tabla 43: CU-05. Bloquear una planilla de consumo Tabla 44: CU-06. Desbloquear una planilla de consumo iii

5 Índice Tabla 45: CU-07. Cargar una planilla de consumo Tabla 46: CU-08. Generación de numeración única Tabla 47: CU-09. Selección de bodega Tabla 48: CU-10. Selección de huerto Tabla 49: CU-11. Ingresar una observación Tabla 50: CU-12. Seleccionar cuartel Tabla 51: CU-13. Selección de material Tabla 52: CU-14. Buscar material Tabla 53: CU-15. Agregar un consumo al detalle de la planilla Tabla 54: CU-16. Bloquear el encabezado de una planilla de consumo Tabla 55: CU-17. Quitar consumo de la planilla de consumo Tabla 56: CU-18. Generar automáticamente planilla de despacho Tabla 57: CU-19. Agregar detalle automáticamente en planilla de despacho Tabla 58: CU-20. Quitar detalle automáticamente en planilla de despacho Tabla 59: CU-21. Separación de datos Tabla 60: CU-22. Generar Kárdex Tabla 61: CU-23. Imprimir Kárdex Tabla 62: CU-24. Exportar Kárdex a Excel Tabla 63: CU-25. Cargar privilegios Tabla 67: cuadro comparativo de los tiempos necesarios por la administración central para generar el informe mensual, mes Tabla 68: cuadro comparativo de los resultados obtenidos durante los meses 1 y iv

6 Índice Índice de Figuras Figura 1. Flujo de acciones en Scrum Figura 2. Diagrama de casos de uso GLOBAL Figura 3. Diagrama de casos de uso Generar Kárdex Figura 4. Diagrama de casos de uso Crear Planilla de Consumo Figura 5. Diagrama de clases Figura 6. Modelo de base de datos Figura 7. Ejemplo de tabla omitida, Tabla de Recepciones Figura 8. Diagrama de Secuencia 01, Crear Planilla de consumo Figura 9. Diagrama de Secuencia 02, Modificar Planilla de consumo Figura 10. Diagrama de Secuencia 03, Generar Kárdex Figura 11. Diagrama de Secuencia 04, Separar datos Figura 12. Arquitectura WEB en tres capas Figura 13. Módulo privilegios Figura 14. Vista del encabezado de una planilla Figura 15. Vista de una planilla completa Figura 16. Vista de la interfaz del buscador de materiales Figura 17. Vista del Kárdex v

7 1.Introducción 1

8 Introducción El objetivo de este Capítulo es explicar el contexto en el cual se realizó esta memoria, así como también, mostrar la problemática que posee la empresa y plantear el objetivo general y los objetivos específicos que se deben efectuar para concretar el objetivo general y por ende dar una real y efectiva solución a la problemática a plantear Descripción del Contexto En la actualidad es de vital importancia, para la correcta toma de decisiones, poder contar con información real, actualizada y fiable, así como también, llevar un control absoluto de los costos y el control de existencias completo y actualizado. Para poder satisfacer estas necesidades, las cuales cada día toman una mayor importancia, se han ideado diferentes metodologías y procedimientos de control, cada una con sus ventajas y desventajas, las que son ajustadas a las necesidades de cada empresa. Esta memoria es un complemento del trabajo realizado hace un par de años por Manuel Pineda, alumno egresado de esta misma facultad, quien diseñó e implementó un sistema para el manejo de costos asociados a la mano de obra; y ésta estará enfocada en la optimización de la entrega de información de los consumos de materiales realizados por los distintos huertos de la empresa Agrícola Manuel Santa María y familia S.A. (AMS Family), la cual fue fundada en el Valle de Curicó hace más de 50 años por Don Manuel Santa María, su actual presidente. La actividad principal de la empresa es el procesamiento de la fruta, desde su recepción hasta su posterior despacho. Para ello actualmente la planta procesadora, cuenta con 30 cámaras frigoríficas, varias de ellas con atmósfera controlada y 6 líneas de proceso. En sus inicios la empresa trabajó en satisfacer la demanda del mercado local por frutas de calidad, posteriormente se concentró en mejorar los 2

9 Introducción sistemas de cosecha y riego. En la actualidad la empresa cuenta con 19 huertos, distribuidos en localidades cercanas a la ciudad de Curicó. Otra actividad comercial que realiza la empresa es la producción y comercialización de vinos a granel. Actualmente la viña Santa María produce vino rosado, tinto y blanco. La bodega de vinos tiene una capacidad de almacenamiento de tres millones seiscientos mil litros. Esta producción de vinos se realiza en el fundo Santa Teresa ubicado a 10 kilómetros al poniente de Curicó, en la ruta que une esta ciudad con la comuna de Rauco Problemática Actualmente la información asociada a los costos, se lleva de manera manual, en planillas Excel, cuadernos o planillas de papel, documentación que va creciendo en forma considerable a medida que avanza la temporada, siendo cada vez más dificultoso poder acceder a la información almacenada. Por otra parte cada huerto lleva su información de costos en forma independiente, enviándola una vez por semana a la planta central para que ésta sea reunida y ordenada. Esto conlleva a una notoria carencia de orden y claridad en los informes generales de los costos totales, traduciéndose en una pérdida de tiempo y una baja calidad de la información, pues ésta debe ser filtrada y estandarizada, para así obtener información de calidad y útil para la toma de decisiones. Esta memoria está enfocada fundamentalmente en el control de las existencias de las bodegas ubicadas en los distintos huertos, que es llevado por medio de carpetas de consumo, en las cuales se detalla el nombre del producto, la fecha de aplicación, la cantidad y el lugar donde fue aplicado. Estas carpetas son enviadas a la planta central una vez por semana, como se señaló anteriormente, donde son digitadas para actualizar el stock (cantidad de material disponible para consumo) y luego regresadas a la brevedad al huerto, para continuar con el registro de los consumos. Este proceso es realizado varias veces al mes, dando como resultado un desfase de una semana o más en el stock real. 3

10 Introducción Una vez que la información de los costos es reunida y estandarizada, se genera un informe, el cual se presenta a la gerencia en una reunión mensual, la cual es realizada aproximadamente el día 10 de cada mes. Por no contar con la información antes, produciéndose un desfase de 10 días o más de retraso en la toma de decisiones. Además del problema que presenta el retraso, también se pretende resolver un problema de calidad de la información. Cada huerto está subdividido en cuarteles, cada cuartel representa una especie de fruta, por ejemplo, si el huerto produce Kiwis, estos pueden ser de HAYWARD o JINTAO. Estas subdivisiones, permiten realizar un control más detallado de los costos y determinar cuál o cuáles son los cuarteles con niveles de costos mayores. Todas estas divisiones y subdivisiones, son codificadas por ejemplo como KI01HA, y al escribirlas en las distintas planillas, la calidad de la información se veía afectada por errores de escritura o digitación. Las principales falencias que se presentan en la empresa AMS Family son: Falta de gestión adecuada de la información, actualmente al interior de la empresa se presentan problemas de eficacia en cuanto a la contabilización y manejo de los datos, ya que no existe un método definido para la realización de estas tareas. Falta de Eficiencia, si bien existen metodologías al interior de la empresa para el manejo de los consumos, éstas no reflejan que el proceso se desarrolle de manera eficiente, por ejemplo actualmente la contabilización y unificación de datos toma aproximadamente una semana, dependiendo de la cantidad de materiales utilizados en los huertos. 4

11 Introducción Falta de Confiabilidad de los datos, esto se origina porque actualmente se utilizan, en promedio, dos o tres formas distintas y paralelas de registro de consumo de materiales, entonces se crea una confusión al momento de contabilizar y unificar dicho conteo. Gran cantidad de fuentes de datos, como se mencionó anteriormente existe una gran cantidad de fuentes de datos lo que implica una gran cantidad de papeles para poder manejar todos los datos. Descentralización de la información, los datos se manejan en los huertos y luego son enviados a las oficinas administrativas, lo que conlleva a un desfase en el stock real y un retraso en la toma de decisiones. Administración de recursos, como se ha mencionado hasta ahora el manejo de los datos se realiza de forma manual, razón por la cual se requiere de la utilización de varias personas. Esto implica para la empresa sacar a estas personas de sus labores cotidianas y asignarles la tarea del manejo de los datos, obligando a la empresa al pago de horas extras, viáticos, etc., dependiendo de la circunstancia. Estos son los principales problemas a los que, mes a mes, se enfrenta la empresa al momento de querer llevar un control de costos, específicamente aquellos asociados al consumo de materiales. Por todo esto, se quiere desarrollar una aplicación que entregue una solución real a estos problemas. 5

12 Introducción 1.3. Objetivos Objetivos Generales Diseñar e implementar un sistema de software que permita realizar un ingreso remoto y un control centralizado de los consumos realizados en los huertos pertenecientes a la empresa AMS Family S.A Objetivos Específicos Comprender el flujo de los costos y de información, concerniente al consumo de materiales en los huertos, para poder asimilarlos al diseño del sistema. Diseñar un sistema que permita el ingreso remoto de datos referente a los consumos, optimizando la forma de ingreso, así como también, la obtención de información de los datos. Implementar el sistema diseñado. Optimizar la centralización de los datos Alcances y limitaciones Esta memoria se desarrollará en la empresa AMS Family S.A., siendo el contacto directo con la empresa, es Don Rodrigo Allende Leyton, Gerente de Administración, Finanzas e Informática dentro de la empresa y a su vez encargado de supervisar el diseño y desarrollo de procesos e interfaces. El sistema se realizará en ASP, lo cual es un requisito de la empresa, con el objetivo de lograr migrar, en un futuro cercano, los códigos a.net; para poder trabajar con el desarrollo orientado a objetos. En cuanto al motor de base de datos será Microsoft SQL Server 2000, este también es un requisito impuesto por la empresa. 6

13 Introducción La centralización de los datos, se logrará mediante el envío de los datos vía WEB. Actualmente, sólo 11 huertos cuentan con acceso a Internet, mediante Internet Móvil, y los computadores con los que cuentan los huertos son básicos, lo cual limita las opciones de desarrollo del sistema. Por otro lado el diseño de esta aplicación deberá ser abierto y fácilmente integrable a otros módulos (por ejemplo, recepción de materiales) que interactúen directamente con ella o con los datos generados Metodología a utilizar La metodología que se utilizará será una metodología híbrida, la cual será una mezcla de Programación Extrema (XP) y Scrum. Esta mezcla se describe en el marco teórico como metodología de desarrollo, que a su vez es complementada con actividades de formalización de requerimientos y diseño, las cuales serán documentadas en UML, para así, facilitar y asegurar la calidad del sistema. De esta manera mediante UML se especificarán los requerimientos, casos de uso, diagramas de secuencia, etc. 7

14 Introducción 1.6. Resumen de capítulos En este capítulo se presentó la problemática de la empresa, el contexto en el cual se desarrollará esta memoria, así como también, se presentaron los objetivos que se busca conseguir. El resto de este documento está dividido en los siguientes capítulos: Capítulo 2: Marco Teórico. Trata sobre Costos, Metodologías Ágiles y UML. Capítulo 3: Análisis y Requerimientos. Abarca la especificación de requerimientos y casos de uso. Capítulo 4: Diseño y Desarrollo. Contiene los principales diagramas del sistema. Se muestran las clases y las interacciones del sistema, así como también las decisiones tomadas con respecto al entorno de desarrollo, lenguaje de programación, motor de base de datos, arquitectura de desarrollo. Además este capítulo incluye una descripción global de la aplicación junto con algunas imágenes del sistema implementado. Capítulo 5: Implantación y resultados. Este capítulo trata de la puesta en marcha del sistema y los resultados obtenidos luego de un período de prueba. Capítulo 6: Conclusiones. Finalmente aquí se muestran las conclusiones del trabajo realizado. 8

15 2.Marco Teórico. 9

16 Marco Teórico En este Capítulo se establecerán las bases teóricas para el desarrollo de esta memoria. Se explicará la metodología que se utiliza al interior de la empresa, para el control de costos, así como también, se describirá la metodología de desarrollo des software utilizada Introducción a los costos La fruticultura a nivel nacional enfrenta un escenario complejo para esta temporada. Por un lado, la demanda internacional de productos frutícolas es creciente y por otro, los costos de producción se han elevado, mientras que la mano de obra escasea. Según Antonio Walker [21], presidente de Fruséptima y Gerente de Agropecuaria Wapri, Estamos en una situación peligrosa porque si los precios bajan un poco la cosa sería muy complicada, porque los costos de producción han aumentado un 35% respecto de la temporada anterior. Adicionalmente a esto hay que destacar que hoy en día existe un déficit de mano de obra, dado que hoy día el trabajador elige en qué empresa quiere trabajar y el empresario no escoge con qué trabajador quiere trabajar. Según palabras del mismo empresario. Ahora, en relación a la demanda, Walker explicó que aparentemente el hemisferio norte viene con una producción relativamente normal, pero como se abrieron mercados como China, Rusia e India, debiera haber una demanda importante [21]. Todos los factores señalados anteriormente nos permiten vislumbrar la tendencia e importancia de llevar un correcto control de los costos basado principalmente en las inestabilidades del mercado y en la alta competencia que reina actualmente, no tan solo en el sector frutícola, sino que también en la gran mayoría de los mercados existentes. De acuerdo a la teoría de costos, éstos mismos se distribuyen en base a clasificaciones independientes (insumos, mano de obra, maquinaria) y se deben 10

17 Marco Teórico asociar a cada actividad. En el caso específico de una empresa como AMS Family podrían señalarse el siguiente caso: Para la actividad de Fertilización de Suelo se tiene como insumo al fertilizante, la mano de obra corresponde a los trabajadores que aplican el fertilizante y al tractorista, mientras que la maquinaria corresponde al tractor y su respectivo acoplado para llevar el fertilizante. Para determinar el costo de esta actividad, que utilizamos como ejemplo, se debe realizar inicialmente la separación entre dos grandes grupos que son Costos directos y Costos indirectos. Para esto es necesario tomar en cuenta las siguientes consideraciones: Debe tenerse la precaución de identificar, con la mayor precisión posible, cuáles son los recursos que efectivamente se han usado para el establecimiento, dejando de lado aquellos que se vinculan con gastos propios del productor y su familia, pero no asociados a la producción. En el caso de productores que tengan otra actividad adicional a la frutícola y compartan algunos recursos entre ambas, debe estimarse un porcentaje de utilización para cada una de estas actividades. Teniendo en consideración lo anterior, los costos directos se pueden definir como la suma de las labores y/o actividades realizadas para cada tipo de plantación y que tienen directa relación con lo producido, como por ejemplo el fertilizante. Los costos indirectos son todos los costos, que si bien son necesarios para producir, no participan directamente en este proceso, como ejemplo de este caso se puede mencionar la energía eléctrica utilizada en las máquinas. 11

18 Marco Teórico En fin, para obtener los Costos de la compañía se debe tratar a cada tipo de plantación como una unidad de negocio diferente, dado que todas las plantaciones tienen diferentes rentabilidades, nivel de rendimiento, precio, etc. Si se quiere observar a nivel agregado entonces hay que sumar los costos de cada una de las unidades de negocios identificadas, los cuales están compuestos según lo desarrollado anteriormente, por los costos directos e indirectos de cada una de las labores realizadas. Por último se debe aclarar que en este apartado se dividieron las erogaciones de dinero necesarias para lograr la producción de la empresa solamente entre costos directos e indirectos, no entrando, intencionalmente, en la discusión respecto a la diferencia entre Costo y Gasto, ni tampoco en las subdivisiones dentro de cada grupo, como por ejemplo dentro de la mano de obra, se puede separar entre directa e indirecta, o en lo referente a los costos indirectos también se podría hablar más específicamente de costos indirectos de fabricación, etc, ni tampoco se quiso ahondar en los diferentes sistemas de costos como por ordenes específicas, costos por procesos, costos por operaciones, etc. Todo lo anterior dado que se aleja del espíritu de este informe y tomaría realizar una memoria por si sola el desarrollo en detalle de las diferente teorías y aplicaciones de la Contabilidad de costos. En resumen, es de vital importancia para la empresa conocer exactamente cuáles son los costos asociados al desarrollo de su actividad para establecer, en base a ellos, una correcta y adecuada estrategia comercial que se adecue tanto a la realidad de la empresa (costos) como a la realidad del entorno (mercado). Ésto permite asegurar el correcto desarrollo y supervivencia de la empresa en el tiempo, para lo cual se atacará en este proyecto el desarrollo de una herramienta asociada a las tecnologías de información que otorgará a la administración la información de costos necesaria para la toma de decisiones tanto en tiempo como en forma. 12

19 Marco Teórico 2.2. Metodología actual de costos La actual metodología de costos fue implementada en el año 2006 y fue propuesta por Don Rodrigo Allende Leyton. Esta metodología establecía un esquema de divisiones y subdivisiones dentro de la empresa. La empresa se dividió en áreas de producción, las cuales se denominaron centros de costos y estos a su vez, se dividieron en subcentros de costos. Por ejemplo, cada huerto se considera un centro de costo y dentro de estos cada cuartel es un subcentro de costo, en el caso de las plantas procesadoras, cada una es un centro de costo y cada sección (los parking, romana, control de calidad, etc.), que posea dicha planta corresponde a un subcentro de costo. Este esquema pretendía saber con mayor exactitud el costo asociado a un área de producción, ya que una vez implantado este esquema, es fácil asociar costos y saber exactamente donde se está ocupando el dinero. Además de dividir en centros de costo y subcentros de costos, también se hace necesario clasificar los diferentes tipos de costos. En esta metodología solo se consideran los costos directos ya que son estos los que aportan información relevante y decidora sobre los costos de producción. Los costos directos se agruparon en familias y subfamilias. Cada familia se les denomina concepto y cada subfamilia se le denomina subconcepto. Por ejemplo, para el caso de los huertos tenemos los siguientes conceptos: materiales, pesticidas, mano de obra, mantención, otros imprevistos, entre otros, y cada uno de estos conceptos se divide en subconceptos, por ejemplo para el concepto de materiales se tienen como subconceptos: pernos, clavos, alambre, palos, pilas, baterías, etc. Con esta metodología se logró realizar un análisis de costos más detallado y exacto, y asi mismo, facilita la toma de decisiones por parte de la gerencia. 13

20 Marco Teórico 2.3. Requerimientos metodológicos En la presente sección se presentan las características de mayor relevancia para la selección de la metodología que será utilizada en el desarrollo de esta memoria. Posteriormente se definirán las características de la metodología elegida y finalmente se explicará la forma en que esta metodología ha sido adaptada al proyecto Características del proyecto A continuación se listarán las características de este proyecto. En la parte de recursos humanos, el proyecto contará con sólo dos personas para el desarrollo. Se trabajará en las dependencias de la empresa AMS Family S.A. El tiempo de desarrollo de este proyecto es de un semestre académico, lo que implica que se cuenta con tiempo limitado para realizar este proyecto. Para lograr un buen manejo de requerimientos se hace posible la realización de reuniones semanales con parte de los usuarios, en este caso con las personas que trabajan en el área de manejo de materiales y bodegas. Por otro lado se cuenta con la supervisión directa del señor Rodrigo Allende Leyton, quien es el gerente del área informática y finanzas de la empresa Definición y selección De acuerdo a las características del proyecto se optó por la utilización de una metodología ágil. Dentro de ellas, usaremos Programación Extrema (XP) y SCRUM, considerando que son las mayoritariamente usadas. A continuación se presenta una breve descripción de cada una de ellas. 14

21 Marco Teórico Programación Extrema (XP) Es la más destacada de las metodologías ágiles de desarrollo de software. La programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Se puede considerar la programación extrema como la adopción de las mejores prácticas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software. Los principios básicos de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Las características fundamentales del método son: Desarrollo iterativo e incremental. Pequeñas mejoras, una tras otra. Pruebas unitarias continuas. Frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Programación en parejas. Se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera es más importante que la posible pérdida de productividad inmediata, ya que el código es revisado y discutido mientras se escribe. 15

22 Marco Teórico Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes. Refactorización del código. Es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo. Propiedad compartida del código. En vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados. Simplicidad en el código. Es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo. La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa Scrum Más que una metodología de desarrollo de software, es una forma de autogestión de los programadores. Un grupo de programadores decide como hacer sus tareas y cuánto va a tardar en ello. Scrum ayuda a que todos trabajen en la misma dirección y con un objetivo claro. 16

23 Marco Teórico Scrum permite realizar el seguimiento de las tareas en forma clara y precisa, de forma que los jefes de proyecto y clientes puedan ver día a día cómo progresa el trabajo. Esta característica hace que Scrum sea una metodología más adaptable ya que no sigue un plan rígido, sino que a medida que cambian las situaciones y las necesidades se adapta fácilmente a los cambios. Scrum es una metodología incremental basada en iteraciones y revisiones. Cada iteración es una revisión global del proyecto, donde se establecen y detallan las funcionalidades o partes del mismo que se pueden desarrollar en un plazo breve (normalmente 30 días). Al final de cada iteración se muestra un incremento funcional sobre el sistema en desarrollo. Como se dijo anteriormente Scrum es una metodología de autogestión Para ello se distinguen distintos actores y acciones. Dentro de los actores, tenemos: [6][7][8][15][20][21] Product Owner: marca y conoce las prioridades del proyecto, es el responsable del mismo y está en contacto directo con el cliente. Scrum Master: es el encargado de asegurar que se aplique correctamente la metodología, guiando las reuniones, ayudando al equipo y entregando soluciones a los problemas que se pudieran presentar. Scrum Team: son los encargados de la implementación de las funcionalidades. Usuario o cliente: son los beneficiarios finales del producto. Ellos revisan y ven los progresos, aportan con ideas, sugerencias o con nuevas necesidades. Las acciones son esenciales o todo sería un desorden. En Scrum se establecen claramente cuáles son las acciones a realizar y cómo hacerlas. Para aplicar correctamente esta metodología, es necesario seguir estas acciones en 17

24 Marco Teórico forma un tanto rígida. Estas acciones son de carácter repetitivo y tienen como objetivo minimizar el esfuerzo y maximizar el rendimiento en el desarrollo, establecer un marco de trabajo común para todos, y éstas son las siguientes: [6][7][8][15][20][21] Product Backlog: es una lista de tareas que se deben realizar a lo largo del proyecto El Product Owner es quien establece, mantiene, actualiza, si es que se da el caso, esta lista de tareas. La lista es creada al inicio del proyecto y mantenida a lo largo del mismo. Sprint Planning Meeting: ésta es una reunión que se realiza antes de cada iteración o Sprint, en la cual se reúne el Scrum Team y se seleccionan las tareas que son realizables, a juicio del Scrum Team, dentro de la duración del Sprint. Este conjunto de tareas se conoce como Sprint Backlog. Sprint Backlog: es un subconjunto de las tareas pertenecientes al Product Backlog. Puede ser una o varias tareas, las cuales deben ser realizadas en un plazo de 2 a 4 semanas, este plazo se establece al inicio del Sprint Backlog y mientras éste se esté realizando, no puede ser modificado; cualquier cambio se realizará posteriormente y corresponderá a otro Sprint Backlog. Daily Scrum Meeting: se trata de una reunión operativa, que se realiza a diario, mientras se realice algún Sprint Backlog. Es una reunión que no debe durar más de 30 minutos, en la cual se realizan 3 preguntas a los miembros del equipo. o Qué tareas ha realizado desde la última reunión? o En qué va a trabajar en el día actual? o Qué obstáculos ha identificado? Necesita ayuda para superarlos? El moderador de esta reunión es el Scrum Master, quien debe procurar que la duración de la reunión no supere los 30 minutos, 18

25 Marco Teórico además de proveer ayuda y solucionar a la brevedad, posibles problemas que pueda tener el equipo para terminar alguna tarea. Sprint Review: es una reunión de un par de horas, que se realiza una vez que se cumple el tiempo estimado para terminar un Sprint Backlog, en la cual se hace una demostración de las funcionalidades terminadas del proyecto. Suelen asistir el cliente o usuarios, el Product Owner, el Scrum Master, el Scrum Team y otras personas relacionadas con el proyecto. Los asistentes pueden dar opiniones, posibles mejoras, etc. Sprint Retrospective: esta una reunión que se realiza posteriormente al Sprint Review. En ella se reúnen el Scrum Master, el Scrum Team y el Product Owner. El objetivo de esta reunión es analizar que cosas se puede mejorar para el próximo Sprint. 19

26 Marco Teórico Figura 1. Flujo de acciones en Scrum Selección Basándonos en las características del proyecto y las características propias de las metodologías antes descritas, se optó por realizar una fusión de ambas metodologías, ya que ambas, aportan herramientas útiles para llevar a cabo un buen proceso de desarrollo. Como metodología para la gestión del proyecto se utilizará SCRUM y como metodología para la codificación del mismo se utilizará XP UML Esta sigla proviene de Unified Modeling Language, es decir, Lenguaje Unificado de Modelado. UML es un lenguaje gráfico que permite, especificar y documentar cada una de las partes que corresponde al desarrollo de un software. UML entrega una forma de modelar aspectos conceptuales como los procesos de negocios y funciones de sistema, además de aspectos concretos como escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software reutilizables. UML especifica pero no describe métodos o procesos, sino que se utiliza para definir un sistema de software, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en una gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como RUP), pero no especifica en sí mismo qué metodología o proceso usar. El objetivo principal de UML es entregar un material de apoyo que le permita al lector poder definir diagramas propios como también poder entender el modelamiento de diagramas ya existentes. 20

27 Marco Teórico UML no es un lenguaje de programación, sólo diagrama la realidad de la utilización de un requerimiento. La programación orientada a objetos es el complemento perfecto para UML, pero eso no significa que UML sólo se pueda utilizar para lenguajes orientados a objetos. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas. En la versión 2.0 de UML se distinguen 13 diagramas agrupados en 3 grupos: [22] Diagramas de estructura o Diagrama de clases o Diagrama de componentes o Diagrama de objetos o Diagrama de estructura compuesta (UML 2.0) o Diagrama de despliegue o Diagrama de paquetes Diagramas de comportamiento o Diagrama de actividades o Diagrama de casos de uso o Diagrama de estados Diagramas de interacción o Diagrama de secuencia o Diagrama de comunicación, que es una versión simplificada del diagrama de colaboración (UML 1.x) o Diagrama de tiempos (UML 2.0) o Diagrama de vista de interacción (UML 2.0) Los diagramas más utilizados son los diagramas de clase, de casos de uso y de secuencia. 21

28 Marco Teórico Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas informáticos, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro. Los diagramas de casos de uso son utilizados durante el proceso de análisis, para describir gráficamente las especificaciones de casos de usos, los cuales consisten en la descripción escrita del comportamiento del sistema al afrontar una tarea o requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas. Los diagramas de secuencia son utilizados durante el proceso de diseño y son uno de los diagramas más efectivos para modelar la interacción entre objetos en un sistema. Éstos muestran la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que los diagramas de casos de uso permiten el modelado de una vista global del escenario, los diagramas de secuencia contienen detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos. Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario; si se tiene modelada la descripción de cada caso de uso, como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. 22

29 3.Análisis y Requerimientos. 23

30 Análisis y Requerimientos En este Capítulo se presentarán las bases para el diseño del proceso de desarrollo para esta aplicación. Estas bases corresponden a la adaptación de la metodología, especificación de requerimientos, casos de uso y diagramas de casos de uso. Estas bases se convierten en la columna vertebral para el proceso de desarrollo y futuras mantenciones de la aplicación. Todas estas especificaciones de diseño se realizan de acuerdo a los requerimientos planteados por el usuario Adaptación de la metodología Tanto SCRUM como XP, se han debido adecuar a los requerimientos y limitaciones del proyecto. Algunas de las adecuaciones realizadas son: El equipo de trabajo, esta compuesto por: o El alumno que desarrolla el sistema y el supervisor dentro la empresa, quienes vendrían constituyendo el SCRUM TEAM, así como también, la asistente de gerencia del área agrícola. Al hacer la separación de roles, el supervisor tomará el papel de Product Owner y en las reuniones diarias (Daily Scrum Meeting), también asumirá el rol de Scrum Master, la asistente de gerencia, asumirá el rol de Cliente principal, así como las secretarias de los huertos. El Sprint Review se realizará cada 30 días, con un total de 4 ciclos, lo cual da como resultado el término del proyecto en aproximadamente 4 meses. El código será escrito en forma individual por el alumno, sin embargo, durante la reunión diaria, se realizará una revisión del código en conjunto con el supervisor, con el fin de mejorar el código, hacerlo más entendible, y encontrar posibles errores en el mismo. La documentación formal, estará desplazada a segundo plano, solamente para fines académicos. La documentación para la mantención del código, se basará en el código mismo, por este motivo, se pondrá especial 24

31 Análisis y Requerimientos cuidado en la codificación, dando tiempo diariamente para mejorar los algoritmos críticos. La premisa es entregas rápidas, de calidad, que cumplan con los requerimientos del usuario. Teniendo en consideración lo anterior, el flujo regular del proyecto fue regido por SCRUM. En la Figura 1 se mostró como funciona el ciclo de la metodología, al comienzo del mismo se realizó una reunión con el cliente y los participantes del proyecto, es decir, asistente de gerencia y algunas secretarias de los huertos, así como también con el supervisor del proyecto y el alumno, en la cual se establecieron los objetivos y las tareas que se debían realizar. Esta reunión corresponde al Product Backlog, este listado de tareas, será la base para la generación de los requerimientos. Como se mencionó anteriormente, el supervisor fue quien tomo el rol de Product Owner Posterior a ello, se reunió el equipo de trabajo, para analizar, cuáles de estas tareas sería posible terminar dentro del plazo de la iteración. Al término de las iteraciones, la distribución fue la siguiente: 1. Primer Iteración o Crear planilla de consumo o Modificar planilla de consumo o Guardar planilla o Revisar planilla o Numeración única o Selección de bodega o Selección de huerto o Ingresar una observación sobre la planilla de consumo o Selección de cuartel o Ingreso de material o Agregar consumos a la planilla 25

32 Análisis y Requerimientos o Generación Automática de una planilla de despacho o Agregar detalle automáticamente o Quitar detalle automáticamente o Enviar datos 2. Segunda Iteración o Eliminar planilla o Bloquear planilla o Buscar material o Bloquear el encabezado de la planilla o Quitar consumos de la planilla 3. Tercera Iteración o Separación de datos o Asignación de huertos o Asignación de productores o Asignación de bodegas 4. Cuarta Iteración o Desbloquear planilla o Generar kárdex o Filtrar kárdex o Buscar código de material para poder filtrar el kárdex o Imprimir el kárdex o Convertir a Excel el kárdex Nota: durante todas las iteraciones se realizaron mejoras en cuanto al diseño de interfaces y accesibilidad, para lograr una aplicación más amigable y funcional, acorde al modo de trabajo de los usuarios, dichas mejoras no fueron incluidas como tareas de la iteración. 26

33 Análisis y Requerimientos El Sprint review se realizó en forma presencial y remota, primeramente con el usuario presencial, el cual se encuentra en las dependencias de desarrollo (como lo recomienda XP), y posteriormente se liberaba un versión de prueba funcional, para que fuera probada en forma remota, y se continúa con la siguiente iteración 3.2. Requerimientos A continuación se presentará la descripción de cada uno de los requerimientos planteados por los usuarios, para posteriormente tener una mayor claridad de las funcionalidades que tendrá la aplicación. Estas especificaciones serán una guía para el desarrollo, ya que se podrá consultar en cualquiera de las etapas del desarrollo y así evitar desviarse del objetivo final Requerimientos Funcionales Planilla RF(01) Definición Origen Prioridad Iteración Crear planilla de consumo El sistema debe permitir al usuario crear una nueva planilla de consumo, la cual debe poseer los siguientes datos: Temporada Empresa Zona Número planilla orden Número planilla recepción Fecha aplicación Bodega Huerto Observaciones Cuartel Código material Descripción material Unidad Cantidad Este requerimiento fue capturado de un sistema similar Requerimiento obtenido en la primera iteración Tabla 1: RF 01, Crear planilla de consumo RF(02) Modificar planilla de consumo 27

34 Análisis y Requerimientos Definición Origen Prioridad Iteración RF(03) Definición Origen Prioridad Iteración RF(04) Definición Origen Prioridad Iteración RF(05) Definición Origen Prioridad Iteración El sistema debe permitir al usuario modificar una planilla, pero solamente debe permitir agregar y/o eliminar el consumo de un material, es decir, sólo permitirá modificar los siguientes datos: Cuartel Código material Descripción material Unidad Cantidad Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa Requerimiento obtenido en la primera iteración Tabla 2: RF 02, Modificar planilla de consumo Eliminar planilla El sistema debe permitir al usuario administrador eliminar completamente una planilla. Este requerimiento fue capturado en reuniones con Gerente de informática y administrativos de la empresa Requerimiento obtenido en la segunda iteración Tabla 3: RF 03, Eliminar planilla Guardar planilla El sistema debe permitir al usuario guardar una planilla, ya sea nueva o guardar los cambios sobre alguna planilla. Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa Requerimiento obtenido en la primera iteración Tabla 4: RF 04, Guardar planilla Bloquear planilla El sistema debe permitir al usuario bloquear una planilla, para que ésta no pueda ser modificada. Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa Requerimiento obtenido en la segunda iteración Tabla 5: RF 05, Bloquear planilla RF(06) Definición Origen Desbloquear planilla El sistema debe permitir al usuario con permisos de administración desbloquear una planilla, para que ésta pueda volver a ser modificada. Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa 28

35 Análisis y Requerimientos Prioridad Iteración RF(07) Definición Origen Prioridad Iteración Requerimiento obtenido en la cuarta iteración Tabla 6: RF 06, Desbloquear planilla Revisar planilla El sistema debe permitir al usuario cargar una planilla que ha sido guardada con anterioridad. Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa Requerimiento obtenido en la segunda iteración Tabla 7: RF 07, Revisar planilla Encabezado RF(08) Definición Origen Prioridad Iteración RF(09) Definición Origen Prioridad Iteración RF(10) Definición Origen Prioridad Iteración RF(11) Definición Origen Numeración única El sistema debe generar automáticamente una numeración única, al momento de guardar una planilla Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa Requerimiento obtenido en la primera iteración Tabla 8: RF 08, Numeración única Selección de bodega El sistema debe permitir al usuario seleccionar una bodega a la cual se le asignará la planilla de consumo. Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa Requerimiento obtenido en la primera iteración Tabla 9: RF 09, Selección de bodega Selección de huerto El sistema debe permitir al usuario seleccionar un huerto al cual se le asignará la planilla de consumo. Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa Requerimiento obtenido en la primera iteración Tabla 10: RF 10, Selección de huerto Ingresar una observación sobre la planilla de consumo El sistema debe permitir al usuario ingresar una observación sobre la planilla de consumo, en caso que sea requerido. Este requerimiento fue capturado en reuniones con el Gerente de 29

36 Análisis y Requerimientos Prioridad Iteración informática y administrativos de la empresa Baja Requerimiento obtenido en la primera iteración Tabla 11: RF 11, Ingresar una observación sobre la planilla de consumo Detalle RF(12) Definición Origen Prioridad Iteración RF(13) Definición Origen Prioridad Iteración RF(14) Definición Origen Prioridad Iteración RF(15) Definición Selección de cuartel El sistema debe permitir al usuario seleccionar un cuartel al cual se le asignará la planilla de consumo, este cuartel depende directamente del huerto que se seleccione, por lo tanto, si no ha sido seleccionado el huerto, no se podrá seleccionar un cuartel. Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa Requerimiento obtenido en la primera iteración Tabla 12: RF 12, Selección de cuartel Ingreso de material El sistema debe permitir al usuario ingresar el material que será consumido y la respectiva cantidad consumida. Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa Requerimiento obtenido en la primera iteración Tabla 13: RF 13, Ingreso de material Buscar material El sistema debe permitir al usuario buscar un material, ya sea por: Código Parte del código Descripción Parte de la descripción O alguna combinación de las anteriores Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa Requerimiento obtenido en la segunda iteración Tabla 14: RF 14, Buscar material Agregar consumos a la planilla El sistema debe permitir al usuario agregar consumos de uno o varios materiales en la planilla de consumo. En la planilla se mostrará la siguiente información. Código de cuartel Código de material 30

37 Análisis y Requerimientos Origen Prioridad Iteración RF(16) Definición Origen Prioridad Iteración RF(17) Definición Origen Prioridad Iteración Descripción del material Unidades Cantidad consumida Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa Requerimiento obtenido en la primera iteración Tabla 15: RF 15, Agregar consumos a la planilla Bloquear el encabezado de la planilla El sistema debe bloquear el encabezado de la planilla de consumo, una vez agregado el primer consumo de un material. Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa Requerimiento obtenido en la segunda iteración Tabla 16: RF 16, Bloquear el encabezado de la planilla Quitar consumos de la planilla El sistema debe permitir al usuario quitar el consumo de un material la planilla de consumo. Este requerimiento fue capturado en reuniones con el Gerente de informática y administrativos de la empresa Requerimiento obtenido en la segunda iteración Tabla 17: RF 17, Bloquear el encabezado de la planilla Despacho RF(18) Definición Generación Automática de una planilla de despacho El sistema debe poder crear una planilla de despacho y asociarla directamente a la planilla de consumo creada. Esta planilla deberá contener la siguiente información. Temporada Empresa Zona Número de planilla Código de bodega de origen Código de movimiento Código de productor Fecha de despacho Código de bodega de destino Número de guía Nombre del despachador Número de planilla de recepción 31