CIS1330IS03 EXTENSIÓN DEL SISTEMA SCLOUD PARA MANEJAR EN LA NUBE EL FLUJO DE PEDIDO DE LA CADENA DE SUMINISTRO DE PYMES.

Transcripción

1 CIS1330IS03 EXTENSIÓN DEL SISTEMA SCLOUD PARA MANEJAR EN LA NUBE EL FLUJO DE PEDIDO DE LA CADENA DE SUMINISTRO DE PYMES. PABLO SEBASTIÁN PÁEZ MATEUS ANDRÉS FELIPE PEDRAZA INFANTE PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS BOGOTÁ, D.C. 2013

2

3 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica CIS1330IS03 Extensión del sistema SCLOUD para manejar en la nube el flujo de pedido de la cadena de suministro de pymes. Autor(es): Pablo Sebastián Páez Mateus Andrés Felipe Pedraza Infante MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE SISTEMAS Director Ing. Martha Helena Carrillo Ramírez Asesora Ing. Lina María Consuelo Franky De Toro Jurados del Trabajo de Grado Mariela Josefina Curiel Huérfano Jaime Andrés Pavlich Mariscal Página web del Trabajo de Grado PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS BOGOTÁ, D.C. Diciembre, 2013 Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 1

4 Ingeniería de Sistemas Istar - CIS1330IS03 PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS Rector Magnífico Joaquín Emilio Sánchez García S.J. Decano Académico Facultad de Ingeniería Ingeniero Jorge Luis Sánchez Téllez Decano del Medio Universitario Facultad de Ingeniería Padre Antonio José Sarmiento Nova S.J. Director de la Carrera de Ingeniería de Sistemas Ingeniero Germán Alberto Chavarro Flórez Director Departamento de Ingeniería de Sistemas Ingeniero Rafael Andrés González Rivera Página 2

5 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Artículo 23 de la Resolución No. 1 de Junio de 1946 La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 3

6 Ingeniería de Sistemas Istar - CIS1330IS03 AGRADECIMIENTOS En primera instancia queremos agradecer a nuestras madres, pues son las mujeres que nos han apoyado no solamente en esta etapa que estamos culminando sino en todas las situaciones de nuestras vidas. También queremos dar gracias a nuestra directora y asesora de trabajo de grado por toda su invaluable e incondicional ayuda que nos brindaron durante el desarrollo del proyecto, pues gracias a sus consejos se lograron buenos resultados del mismo. Página 4

7 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Lista de Figuras Figura 1: Actividades de la fase de Evaluación del estado del arte Figura 2: Actividades de la fase de Refactorización del sistema Figura 3: Actividades de la fase de Selección de requerimientos factibles Figura 4: Actividades de la fase de diseño del software Figura 5: Actividades de la fase de implementación del software Figura 6: Actividades de la fase de validación Figura 7: Gestión de la Cadena de Suministro Figura 8: Planeación de requerimientos de Materiales Figura 9: Elementos BPMN Figura 10: Arquitectura SCLOUD con una pyme Figura 11: Arquitectura SCLOUD con multitenants (múltiples pymes) Figura 12: Ejemplo DAR Figura 13: Buenas prácticas vs. Prácticas al extremo Figura 14: Agregar Cliente Figura 15: Validar Cliente Figura 16: Estimación de Fechas Figura 17: Confirmación final a Cliente Figura 18: Cancelación de pedido Figura 19: Cálculo MRP Figura 20: Hacer un Pedido Figura 21: Procesar un Pedido (1) Figura 22: Procesar un Pedido (2) Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 5

8 Ingeniería de Sistemas Istar - CIS1330IS03 Figura 23: Procesar un Pedido (3) Figura 24: Proceso MRP Figura 25: Proceso Notificar Pyme por MRP Figura 26: Proceso Notificar Proveedores Figura 27: Proceso Crear un Producto Figura 28: Proceso Añadir nuevo Proveedor Figura 29: Proceso Borrar Cliente Figura 30: Proceso Seleccionar Proveedor por Defecto Figura 31: Proceso Activar MRP Automático Figura 32: Proceso Calendario Parametrizable Figura 33: Estructura de Insumos para Jeans Ref Figura 34: Estructura de Insumos para Chaqueta Ref. Gomela Figura 35: Estructura de Insumos para Abrigo Princesa Ref Figura 36: Estructura de Insumos para Cama de Amarres Figura 37: Estructura de Insumos para Trabilla de Mosquetón (Correa) Figura 38: Estructura de Insumos para Saco con capota manga ranglan Página 6

9 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Lista de Tablas Tabla 1: Ventajas y desventajas de Sistemas ERP Tabla 2: Sistemas ERP a nivel mundial Tabla 3: requerimientos posibles del sistema Tabla 4: Criterios de calificación para requerimientos funcionales Tabla 5: Criterios de calificación para requerimientos no funcionales Tabla 6: requerimientos seleccionados para la extensión de SCLOUD Tabla 7: Puntos de Venta Confecciones Baker Tabla 8: Parametrización de Productos de Confecciones Baker Tabla 9: Puntos de Venta Can & Estilo Tabla 10: Parametrización de Productos de Can & Estilo Tabla 11: Tiempos de Cadena de Abastecimiento de Confecciones Baker Tabla 12: Tiempos de Cadena de Abastecimiento de Can & Estilo Tabla 13: Tiempos de Cadena de Abastecimiento de SCLOUD Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 7

10 Ingeniería de Sistemas Istar - CIS1330IS03 Contenido INTRODUCCIÓN...14 I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO Oportunidad, Problemática, Antecedentes Formulación del problema que se resolvió Justificación Impacto Esperado Visión global Objetivo general Objetivos Específicos Fases Metodológicas Fase 1: Evaluación del estado del arte Fase 2: Refactorización del sistema Fase 3: Selección de requerimientos factibles Fase 4: diseño del software Fase 5: implementación del software Fase 6: validación II - MARCO TEÓRICO Introducción Cadena de Suministro Planeación de requerimientos de Materiales (MRP) BonitaSoft Computación en la nube (Cloud Computing) Descripción de SCLOUD Flujo de información del cliente Flujo de información de la pyme Flujo MRP Características Arquitecturales y de implementación Enterprise Resource Planning (ERP) Sistema de gestión de pedidos Business Process Management (BPM) Business Process Management Notation (BPMN) Servidor de Aplicaciones DAR (Decision Analysis and Resolution) III DESARROLLO DEL TRABAJO Fase 1: Evaluación del estado del arte Fase 2: Refactorización del sistema Fase 3: Selección de requerimientos factibles Fases 4 y 5: Desarrollo e implementación del sistema Flujo de Información Cadena de Abastecimiento Página 8

11 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Proceso MRP Notificar Pyme por MRP Notificar Proveedores Crear un Producto Añadir nuevo Proveedor Borrar Cliente Seleccionar Proveedor por Defecto Activar MRP Automático Calendario Parametrizable Fase 6: validación del sistema validación con Confecciones Baker validación con Can & Estilo Comparación de Procesos de Flujo de Información IV - RESULTADOS Y REFLEXIÓN SOBRE LOS MISMOS Fase 1: Evaluación del estado del arte Fase 2: Refactorización del sistema Fase 3: Selección de requerimientos factibles Fases 4 y 5: Diseño e implementación del sistema Fase 6: Validación del sistema V CONCLUSIONES, RECOMENDACIONES Y TRABAJOS FUTUROS Conclusiones Recomendaciones Trabajos Futuros VI - REFERENCIAS Y BIBLIOGRAFÍA Referencias VII - ANEXOS Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 9

12 Ingeniería de Sistemas Istar - CIS1330IS03 ABSTRACT This project involves the design and development of a system to help different pymes to improve their business processes around the world. The document specifies all the process that was followed to accomplish with the creation of a new software, like the research about other systems in order to find functional characteristics that are now part of the software that was implemented, the design of an architecture that supports it and the validation to evaluate the software functionality. Página 10

13 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica RESUMEN Este proyecto involucra el diseño y la implementación de un sistema para ayudar a diferentes pymes en el mundo a mejorar sus procesos de negocio. El documento especifica todo el proceso que se siguió para cumplir con la creación de un nuevo software, como la investigación de otros sistemas con el fin de encontrar características que ahora hacen parte del sistema que fue implementado, el diseño de una arquitectura que lo soporta y la validación para evaluar la funcionalidad del software. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 11

14 Ingeniería de Sistemas Istar - CIS1330IS03 RESUMEN EJECUTIVO Hay una problemática entre las pymes de hoy en día y es que su información no está digitalizada. Existen múltiples herramientas de software que ayudan a la gestión de recursos empresariales en el mundo pero tienen muchas funcionalidades que las pequeñas empresas no usan, y es por esta razón que estos sistemas se hacen complejos y difíciles de manejar para ellas. Debido a esto, las pymes actualmente no se atreven a avanzar tecnológicamente por el miedo a aprender a utilizar un sistema tan grande. El objetivo de este proyecto fue crecer un sistema que ya venía en desarrollo para añadirle las funcionalidades básicas que podría necesitar una pyme, y para esto se pasó por 6 fases: La primera consistió en la investigación de otras herramientas de software que también se encargaran de la gestión de recursos empresariales con el fin de identificar características funcionales y tratar de mejorarlas al sistema SCLOUD que se estaba extendiendo. Durante la investigación se obtuvieron bastantes requerimientos y no era posible diseñarlos e implementarlos todos por el alcance de tiempo tan corto que se tenía en el proyecto de grado. Para solucionar el problema mencionado anteriormente se desarrolló una fase que consistía en la elección de los requerimientos más factibles para el sistema según la opinión de cuatro actores: Los dos desarrolladores, la asesora y la directora del trabajo de grado. Estas opiniones fueron plasmadas en un documento oficial para determinar cuáles requerimientos se elegían a partir de unos criterios de calificación. Para que los procesos de diseño y de implementación de los requerimientos que se eligieran fueran más sencillos de ejecutar, se hizo una refactorización del prototipo SCLOUD con el fin de separar responsabilidades del sistema y de esta forma organizarlo; así se facilitaba el diseño e implementación de una extensión. Página 12

15 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica La fase de diseño fue de gran importancia para lograr la incorporación de nuevas extensiones dentro del sistema, porque se logró diseñar una arquitectura que pudiera soportar todas las funcionalidades que se pretendían implementar, y a partir de ese diseño se desarrolló en términos de código el comportamiento de cada una de ellas. Por último se realizó una fase de validación que consistió en la prueba final de las extensiones que se le añadieron al prototipo de SCLOUD en dos pymes con el fin de determinar qué funcionalidades le harán falta al sistema, y qué funcionalidades habrá que mejorar. Esto se logró gracias a una encuesta que se le realizó a cada una de esas empresas para conocer sus opiniones al respecto. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 13

16 Ingeniería de Sistemas Istar - CIS1330IS03 INTRODUCCIÓN Este trabajo fue realizado para dar a conocer todo el proceso investigativo, de diseño e implementación de las nuevas funcionalidades que fueron incorporadas en el sistema SCLOUD. En el documento se explica la problemática por la cual el desarrollo de este trabajo comenzó a ejecutarse, el objetivo principal, los objetivos específicos del proyecto, y las fases por las cuales se incurrieron para lograrlos. Se espera que este documento sea utilizado como punto de partida para un proyecto futuro relacionado que pretenda incluir toda la retroalimentación que la fase de validación de este proyecto generó, y de esta forma lograr seguir creciendo el sistema SCLOUD con el fin de que sea más útil para las pymes. Página 14

17 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO 1. Oportunidad, Problemática, Antecedentes Hoy en día algunas empresas cuentan con herramientas de software que permiten gestionar todas las operaciones necesarias para llevar a cabo una excelente comunicación entre los integrantes de una Cadena de Abastecimiento (SCM [1]), con el fin de aumentar su productividad industrial o la eficiencia de la gestión financiera, ventas, atención al cliente, entre otras [2]. SCM (Supply Chain Management) es el conjunto de partes y elementos implicados para la correcta entrega de uno o varios productos a un cliente específico [3]. Para las pequeñas y medianas empresas (pymes [4]) que se involucran con pocos elementos de la cadena de abastecimiento y requieren del manejo de menos operaciones, existe un conjunto de herramientas de software disponible que ayudan a la correcta administración de la cadena de abastecimiento [5]. La cadena de abastecimiento tiene en cuenta dos flujos, El de Información (o Pedido) y el de Producto: El Flujo de Información: Es aquel que alimenta a cada uno de los componentes que conforman la cadena de abastecimiento con información necesaria para la fabricación de los productos que haya solicitado un cliente. Flujo de Producto: Se enfoca en la entrega del producto terminado al cliente [3]. Los diversos tipos de aplicaciones para las pymes que proveen un sistema para soportar el flujo de información [6] son conocidos como ERP (Enterprise Resource Planning); entre estos sistemas de administración de recursos empresariales se encuentran Supply Nexus [7] y SAP SCM [8] que fueron creados a partir de modelos de flujos de procesos Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 15

18 Ingeniería de Sistemas Istar - CIS1330IS03 como MACA [3], SCOR [9] o SCLOUD. Este último fue concebido por los departamentos de Ingeniería Industrial e Ingeniería de Sistemas de la Pontificia Universidad Javeriana y construido por ingenieros de sistemas para un trabajo de grado anterior, con el fin de que las pequeñas y medianas empresas tengan una mayor facilidad para realizar todas las tareas que estén involucradas en la distribución y elaboración de productos que vendan. Actualmente, los sistemas como Supply Nexus o SAP SCM son de gran utilidad para empresas muy grandes cuyas funcionalidades no son enfocadas a empresas pequeñas y medianas. El modelo SCLOUD tiene diseñado ciertos procesos que son para pymes pero no los suficientes como para ponerlo al servicio de ellas. A partir de esta problemática es que se decide crecer el prototipo que implementa el modelo SCLOUD, de tal forma que la herramienta resultante sea más útil para las pymes Formulación del problema que se resolvió Cómo extender el prototipo inicial que soporta el modelo de negocio para flujos de pedido en las pequeñas y medianas empresas (pymes) llamado SCLOUD, con el fin que sea una herramienta más completa para ellas? 1.2. Justificación Este proyecto es una buena elección porque va a permitir la extensión de una herramienta de software que gestiona el Flujo de Pedido [10] para las cadenas de abastecimiento llamado SCLOUD. Este toma como referencia algunos modelos como SCOR, MACA, entre otros, y mejora ciertos procesos para las pymes. Inicialmente un proyecto de grado anterior creó un prototipo que soporta SCLOUD, pero la idea principal de esta propuesta es extenderlo para que opere completamente en la nube y cuente con nuevas funcionalidades, con el fin de que una pyme pueda gestionar de forma correcta su inventario y la ayude a administrar los pedidos que haga para abastecerse de los productos que venda. Página 16

19 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica 1.3. Impacto Esperado Una vez determinados los requerimientos a implementar como extensiones del prototipo de SCLOUD, se pretende que la implementación de los mismos tenga un impacto positivo para las pymes en cuanto a utilidad, pues es muy importante que usen esas funcionalidades para mejorar su productividad y ser más competitivos dentro del ámbito empresarial Visión global El proyecto inició con la investigación de funcionalidades de diferentes ERPs a nivel nacional y mundial, y a partir de ella se conjuntaron en una tabla todos los requerimientos posibles que podían hacer parte de las extensiones de SCLOUD. De esas funcionalidades solamente harían parte del sistema definitivo aquellas que tuvieran una calificación total de 4.0 o mayor (calificación calculada con un método que se explica en el capítulo de desarrollo del trabajo). Luego se procedió a diseñar, implementar y validar cada uno de los requerimientos elegidos Objetivo general Extender el prototipo inicial que soporta el modelo de negocio propuesto por SCLOUD con el fin de generar una herramienta más completa para pymes Objetivos Específicos Los objetivos específicos planteados para este trabajo son los siguientes: 1. Realizar un análisis sobre el prototipo de SCLOUD y sistemas ERP actuales en el mercado, de tal forma que se determine qué funcionalidades son necesarias para extender este modelo. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 17

20 Ingeniería de Sistemas Istar - CIS1330IS03 2. Definir un conjunto de funcionalidades factibles para la extensión del prototipo de SCLOUD, según el análisis realizado sobre él y los sistemas ERP actuales en el mercado. 3. Diseñar un conjunto de componentes que representen la Arquitectura que soportará las funcionalidades factibles que se van a incluir en la extensión de SCLOUD. 4. Implementar los Componentes Arquitecturales que soportan las funcionalidades factibles de la extensión de SCLOUD. 5. Validar en dos empresas pequeñas las nuevas funcionalidades implementadas para SCLOUD mediante pruebas de aceptación, y determinar si la aplicación cumple o no con las necesidades de la empresa Fases Metodológicas El tipo de metodología que se escogió para cumplir con el desarrollo del trabajo de grado fue Programación Extrema (XP) [11]. Este permite seguir de una fase a otra y en cualquier momento brinda la posibilidad de devolverse a una fase anterior con el fin de aplicar acciones correctivas. Cada objetivo específico representa una fase metodológica, y la descripción de cada fase y las actividades que se establecieron para cada una de ellas están definidas a continuación: Fase 1: Evaluación del estado del arte Evaluación del estado del arte 1. Analizar extensión de requerimientos por trabajo de grado anterior 2. Analizar ventajas y desventajas de sistemas ERP actuales 3. Generar tabla comparativa 4. Establecer funcionalidades necesarias 5. Crear documento de Análisis de Requerimientos Figura 1: Actividades de la fase de Evaluación del estado del arte. Página 18

21 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Metodología Esta fase inicia con la investigación de las ventajas y desventajas que poseen los sistemas ERP actuales en el mercado, y luego son contrastadas con las características que tiene el prototipo SCLOUD. Una vez se haya hecho un análisis comparativo entre esos sistemas, se procede a elaborar una lista de requerimientos que pueden llegar a ser implementados en la extensión del prototipo. Actividades Las actividades para esta fase son: 1. Analizar las extensiones propuestas para el prototipo SCLOUD por el trabajo de grado anterior. 2. Analizar los sistemas ERP actuales en el mercado y definir sus ventajas y desventajas. 3. Generar una tabla que permita comparar las ventajas y desventajas de los sistemas ERP investigados y el prototipo de SCLOUD. 4. Establecer las funcionalidades necesarias para la extensión del prototipo de SCLOUD. 5. Crear el documento de Análisis de requerimientos que contenga las posibles funcionalidades generadas para la extensión del prototipo de SCLOUD Fase 2: Refactorización del sistema Refactorización del Sistema 1. Analizar las funcionalidades que ofrece la última versión de Bonita Open Solution (v6.0.2). 2. Decidir la versión de Bonita Open Solution que se va a usar para la refactorización. 3. Refactorizar el sistema con la versión elegida de Bonita Open Solution. Página 19 Preparado por el Grupo Investigación Istar- Versión /03/2008

22 Ingeniería de Sistemas Istar - CIS1330IS03 Figura 2: Actividades de la fase de Refactorización del sistema. Metodología Esta fase inicia con el estudio de las nuevas características y funcionalidades que ofrece la última versión de Bonita Open Solution (v6.0.2) [12], y a partir de los resultados de la investigación, se procede a decidir qué versión es la más factible para el desarrollo de la extensión del prototipo de SCLOUD. Una vez decidida la versión, se inicia el proceso de refactorización del sistema con el fin de aislar toda la lógica de negocio (Java) de la lógica de presentación (Bonitasoft). Actividades Las actividades para esta fase son: 1. Analizar las funcionalidades que ofrece la última versión de Bonita Open Solution (v6.0.2). 2. Decidir la versión de Bonita Open Solution que se va a usar para la refactorización. 3. Refactorizar el sistema con la versión elegida de Bonita Open Solution Fase 3: Selección de requerimientos factibles Selección de Requerimientos factibles 1. Crear HACER-USOS 2. Crear DAR 3. Elegir requerimientos con una definitiva mayor o igual a 4.0 Figura 3: Actividades de la fase de Selección de requerimientos factibles. Página 20

23 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Metodología Una vez el documento de Análisis de requerimientos haya sido completado, se procede a definir las funcionalidades que van a implementarse definitivamente en la extensión del prototipo de SCLOUD. Para eso se crearán dos documentos: el HACER-USOS (Histórico, Actores, Conceptos, Escenarios, requerimientos) que muestra una descripción y el comportamiento de los diferentes requerimientos que hacen parte de un sistema; y el DAR (Decision Analysis and Resolution) que es un documento que se usa para evaluar alternativas (en este caso, los requerimientos) según un conjunto de criterios y puntajes para cada uno de ellos. Los criterios serán calificados entre los desarrolladores, la asesora y la directora del trabajo de grado por un valor entero entre 1 y 5 que representan el nivel de importancia para un criterio determinado, siendo 1 el valor de menor importancia y 5 el mayor. Luego, el puntaje total de un requerimiento será el promedio de calificaciones de los criterios y este servirá para compararse con otros requerimientos. Las funcionalidades definitivas a tomar en cuenta para la extensión de SCLOUD serán los requerimientos con puntajes mayores o iguales a 4.0. Actividades Las actividades para esta fase son: 1. Crear HACER-USOS. 2. Crear DAR. 3. Elegir los requerimientos que hayan obtenido una definitiva mayor o igual a 4.0. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 21

24 Ingeniería de Sistemas Istar - CIS1330IS Fase 4: diseño del software Diseño del Software 1. Diseñar los nuevos procesos que se agregarán a SCLOUD 2. Actualizar documento de mantenimiento Figura 4: Actividades de la fase de diseño del software. Metodología Una vez el DAR haya sido completado, se procede a diseñar una Arquitectura que soporte los requerimientos que cumplen el criterio de selección en dicho documento. Para esto se tomarán las funcionalidades definitivas de la extensión del prototipo de SCLOUD y se creará una lógica de negocio por medio de la suite de gestión de procesos empresariales BonitaSoft que las soporte. El diseño de los requerimientos se irá actualizando en un documento de mantenimiento con el fin de mantener una explicación de los mismos. Actividades Las actividades para esta fase son: 1. Diseñar los procesos que se van a agregar a la extensión del prototipo de SCLOUD. 2. Actualizar el documento de Mantenimiento con los diseños de los nuevos procesos. Página 22

25 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Fase 5: implementación del software Implementación del Software 1. Implementar cada una de las funcionalidades factibles Instalar sistema en Servidores de la Universidad 2. Crear el documento de Mantenimiento 3. Crear el manual de Pruebas 4. Crear el manual de Usuario Figura 5: Actividades de la fase de implementación del software. Metodología En esta fase se tomará la Arquitectura diseñada en la fase anterior y se implementará cada uno de sus componentes usando Bonita y Java Empresarial. Luego de que se hayan implementado, el sistema se montará en los servidores de la Pontificia Universidad Javeriana sede Bogotá. Cada una de las funciones que se implementaron en el sistema se documentará en el manual de mantenimiento y se creará la versión final del mismo. Actividades 1. Implementar cada una de las funcionalidades factibles bajo la metodología ágil de programación extrema (XP). 2. Instalar sistema en los servidores de la Pontificia Universidad Javeriana sede Bogotá. 3. Crear el documento de Mantenimiento. 4. Crear el manual de Pruebas. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 23

26 Ingeniería de Sistemas Istar - CIS1330IS03 5. Crear el manual de Usuario Fase 6: validación Validación 1. Contactar empresa pequeña 2. Enseñar funcionalidades a PYME 3. Probar sistema 4. Tomar acciones correctivas Figura 6: Actividades de la fase de validación. Metodología Esta fase inicia cuando la extensión del prototipo de SCLOUD haya sido instalada en los servidores de la Pontificia Universidad Javeriana sede Bogotá, y se haya creado el manual de usuario y el documento de mantenimiento. Para lograr la validación del sistema, se tendrá que contactar diferentes empresas que cumplan el papel de usuarios del mismo, de tal forma que alimenten la base de datos con información real proveniente de sus procesos de negocio. Durante 2 semanas, los usuarios del sistema harán observaciones que tengan que ver con el funcionamiento de la extensión del prototipo de SCLOUD, y después de ese tiempo se hará una retroalimentación que permita identificar las características positivas y negativas del sistema. Actividades 1. Contactar empresas para que prueben el sistema final. Página 24

27 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica 2. Enseñar las funcionalidades del sistema a las empresas para que puedan usarlo en el proceso de validación. 3. Probar sistema. 4. Realizar una retroalimentación sobre las observaciones que las empresas hicieron sobre la herramienta de software. II - MARCO TEÓRICO 2.1. Introducción En esta sección se definen los conceptos básicos que permiten entender todo lo necesario respecto al proyecto que se realizó, desde lo que significa una cadena de abastecimiento hasta lo que fue el prototipo SCLOUD. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 25

28 Ingeniería de Sistemas Istar - CIS1330IS Cadena de Suministro Es un conjunto de actividades funcionales (transporte, control de inventarios, etc.) que se repiten muchas veces a lo largo de flujos, mediante los cuales la materia prima se convierte en productos terminados y se añade valor para el consumidor [16]. Esto quiere decir que la cadena de suministro incluye las actividades asociadas desde la obtención de materiales para la transformación del producto, hasta su colocación en el mercado [15], como se muestra en la figura 7. Figura 7: Gestión de la Cadena de Suministro. Al tener una adecuada gestión de la cadena de suministro se pueden obtener las siguientes ventajas [17]: Mayor eficacia en las negociaciones gracias a las posibilidades de las nuevas tecnologías en el intercambio de información con los proveedores. Mayor control en la gestión con proveedores. Pueden accederse a un mayor número de proveedores potenciales y a un mayor número de ofertas de manera rápida, sencilla y automatizada. Página 26

29 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Reducción de costes entre un 20% al 30%. La integración de una cadena de suministro puede reducir costes operativos drásticamente. Disminución del tiempo de aprovisionamiento gracias a la comunicación en tiempo real con proveedores. Mejoras en la gestión de inventarios. La información en línea de suministros en almacenes permite prever las necesidades de producción y optimizar la gestión de stocks. Seguimiento de fechas de entrega de suministros, plazos de producción, y fechas de embarque, lo cual garantiza una mayor capacidad de reacción frente a la demanda del mercado Planeación de requerimientos de Materiales (MRP) El MRP (Material Requirements Planning) permite a una compañía calcular cuánto material de cada tipo requiere y en qué momento. Todo esto lo realiza con base a los registros de órdenes de venta que contienen las órdenes futuras conocidas y pronostica las órdenes que razonablemente se tendrán. Después verifica todos los ingredientes o componentes que se necesitan para fabricar esas órdenes futuras y luego asegura que estén listas a tiempo [18]. Los objetivos del MRP son [19]: Mejorar el servicio al cliente Reducir la inversión en el inventario Mejorar la eficiencia de operación de la planta La figura 8 muestra el esquema de la planeación de requerimientos de materiales [24]: Página 27 Preparado por el Grupo Investigación Istar- Versión /03/2008

30 Ingeniería de Sistemas Istar - CIS1330IS03 Figura 8: Planeación de requerimientos de Materiales. Órdenes de los clientes: Son los registros que exactamente ordena un cliente, cuánto ordena y cuándo requiere la entrega Pronóstico de demanda: Uso de datos históricos para predecir tendencias futuras. Combinación de órdenes y pronósticos: Es importante que el pronóstico usado para planear las operaciones no sea la meta de ventas. Programa maestro de producción: se Utiliza para planificar partes o productos que tienen una gran influencia en los beneficios de la empresa o que asumen recursos críticos y que, por tanto, deben planificarse con especial atención. Lista de materiales: El programa maestro maneja el resto del proceso MRP. Una vez establecido el programa de nivel máximo. El MRP realiza cálculos que obtiene volúmenes y tiempos de ensamble y materiales requeridos para cumplir este programa maestreo. Inventario: Cantidad de inventario físico Programa de órdenes planeadas: Es un plan que indica la cantidad de cada material que se debe ordenar en cada periodo. Página 28

31 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica 2.4. BonitaSoft El proyecto de software Bonita fue cofundado en 2001 por Miguel Valdés Faura, un ingeniero de informática en el Instituto Nacional Francés para la Investigación en Informática y Automática (INRIA). A través del Consorcio OW2 se puso a disposición de los usuarios como una alternativa de código abierto a soluciones de BPM comerciales existentes [32]. Las aplicaciones desplegadas con Bonita abarcan toda la gama de proyectos de BPM, desde la migración de Sistemas de Información hacia una Arquitectura Orientada a Servicios (SOA), a la automatización de los procesos de e-administración, ERP y procesos de venta con interacciones humanas para los pasos de aprobación, a los contratos de base y la gestión de nuevos clientes, y más [12]. Bonitasoft es una herramienta BPMS (Business Process Management Suit) que permite implementar procesos al mismo tiempo que se van diseñando Computación en la nube (Cloud Computing) Computación en la nube es el sitio donde los recursos y servicios informáticos, tales como infraestructura, plataforma y aplicaciones, son ofrecidos y consumidos como servicios a través de internet sin que los usuarios tengan que tener ningún conocimiento de lo que sucede detrás [41]. Los servicios en la nube son de tres tipos: el software como servicio ( software-as-aservice o SAAS), el cual entrega aplicaciones; la plataforma como servicio ( platform-as a-service o PAAS), que proporciona ambientes y herramientas para desarrollar aplicaciones, en cuyo caso el proveedor se encarga de operar la infraestructura (los servidores, las redes, los sistemas operacionales, los medios de almacenamiento) y la infraestructura como servicio; (infrastructure-as-a-service IAAS), la cual proporciona infraestructura para procesamiento, almacenamiento, redes y otros elementos sobre los Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 29

32 Ingeniería de Sistemas Istar - CIS1330IS03 cuales los clientes corren sus sistemas operacionales y sus aplicaciones, y tienen la posibilidad de controlar elementos importantes como los firewalls o los balanceadores de carga [42]. Hasta este punto, los usuarios si deben tener conocimiento de la configuración de los servidores que hayan solicitado en la nube para lograr cierto control sobre ellos Descripción de SCLOUD El prototipo SCLOUD es un sistema que cuenta con 5 módulos [3]: Flujo de información del cliente Hace referencia a todas aquellas actividades que permiten desde la radicación de una solicitud (compra por parte del cliente), hasta la confirmación final en caso de que sea exitoso el acuerdo entre la pyme y el cliente Flujo de información de la pyme Hace referencia a todas aquellas actividades que permiten gestionar una solicitud hecha por un cliente. Estas actividades están divididas de acuerdo a los roles planteados (distribución, producción, abastecimiento) Flujo MRP Es el encargado de gestionar toda la información retornada por el generador del plan de requerimientos de materiales. Este módulo está compuesto a su vez por los siguientes módulos: Generador del plan de requerimientos de materiales: Es aquel que acoge toda la información que se ingresa a la pyme y necesita ser procesada de tal forma que responda a las siguientes preguntas Qué materiales son requeridos?, Cuánto se necesita de cada material? y Cuándo cada material es requerido? Página 30

33 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Estimador del plan de requerimientos de materiales: Este módulo trabaja bajo la misma lógica del generador del plan de requerimientos de materiales con la excepción que este módulo no modifica inventarios de materiales, productos ni la capacidad disponible del día hábil de producción del producto Características Arquitecturales y de implementación Para el desarrollo de cada uno de los módulos del prototipo de SCLOUD se usó BonitaSoft Open Solution para el diseño BPM (Bussines Process Managent) y desplegar el sistema en la nube [12], pero también algunos módulos se implementaron en Java EE 6 [13]. Por otro lado, la arquitectura de SCLOUD es Multi Tenant ya que se necesita tener la lógica del gestor de procesos compartida entre los diferentes clientes (pymes). Para esto se está usando una base de datos (MYSQL) compartida con esquemas separados [14]. Bajo la implicación de este enfoque en la arquitectura de SCLOUD por cada una de las pymes (tenant) se necesitan de dos esquemas. Adicionalmente a esto se debe disponer de una instancia del servidor JBoss por cada uno de los tenants [3] Enterprise Resource Planning (ERP) ERP Es una aplicación de software que automatiza e integra tanto los procesos del manejo de un negocio así como la producción y distribución [20]. Los sistemas ERP unen y sincronizan todas las operaciones de la compañía incluyendo [20]: Recursos humanos Finanzas Manufactura Distribución Clientes Página 31 Preparado por el Grupo Investigación Istar- Versión /03/2008

34 Ingeniería de Sistemas Istar - CIS1330IS03 Proveedores Los ERP son considerados como la evolución natural de los sistemas de planeación de recursos de manufactura (MRP). Se posicionan como la integración de diferentes sistemas de información en todas las áreas de las empresas [21]. Las ERP cuentan con principales tareas de apoyo como [20]: Control, gestión y planeación de los recursos financieros Planeación de Productos Aprovisionamiento de Materiales Manejo de Inventarios Interacción con Proveedores Proveen Servicio a Clientes Seguimiento de órdenes Manejo de Recursos Humanos Gestión de costos de distribución y manufactura Sistema de gestión de pedidos Un sistema de gestión de pedidos o también llamado OMS (Order Management System), es un sistema de proceso integrado dentro de la gestión documental y es utilizado por las empresas para la entrada de pedidos y el procesamiento de los mismos[37]. El OMS funciona de la siguiente manera: El OMS se comunica con el sistema de administración de almacén para comprobar la disponibilidad del producto, bien desde los inventarios, o los programas de producción. Esto da información sobre la ubicación del producto en la red de suministros, la cantidad disponible y tal vez el tiempo estimado de entrega. Una vez que el pedido es aprobado, el OMS asignará el producto al pedido Página 32

35 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica del cliente, le dará una ubicación de producción, lo disminuirá del inventario, y cuando el envío haya sido confirmado, preparará una factura [38]. Un OMS abarca los siguientes módulos [16]: Información del producto (descripciones, atributos, lugares, cantidades). Inventario de disponibilidad y abastecimiento. Los proveedores, compras y envíos. Marketing (catálogos, promociones, precios). Clientes actuales y potenciales. Pedidos de clientes y servicio de atención (incluyendo devoluciones y rembolsos). Procedimiento de pago (las tarjetas de crédito, facturación, cargos en cuenta). Proceso de pedidos de clientes (selección, impresión, recolección, embalaje, gastos de envío). Análisis de datos y presentación de informes. Datos financieros (cuentas a pagar, cuentas a cobrar, libro mayor general) Business Process Management (BPM) El (BPM) se concentra en la administración de los procesos de negocio. Se entiende como tal a la metodología que orienta los esfuerzos para hacer más óptimos los procesos de la empresa, en busca de mejorar la eficiencia y la eficacia por medio de la gestión sistemática de los mismos. Estos procesos deben ser modelados, automatizados, integrados, monitoreados y optimizados de forma continua [38]. Se puede decir que las tecnologías BPM son el análisis de la administración de los procesos de una empresa, desde que comienzan hasta que terminan; es decir, que BPM es la convergencia de plataformas de gestión, tecnologías y aplicaciones de colaboración y gestión. La tecnología BPM es considerada como una estrategia para la gestión Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 33

36 Ingeniería de Sistemas Istar - CIS1330IS03 de procesos de negocio y una mejora de la ejecución del negocio a partir de la eficaz y eficiente articulación del modelado, la ejecución y medición [38]. En cuanto a las principales funcionalidades que BPM provee, se tiene [39]: Asignar actividades a las personas de forma automática y según cualquier criterio, o según cargas de trabajo. Recordar a las personas sus actividades, las cuales son parte de una cola de WorkFlow. Optimizar la colaboración entre personas que comparten actividades. Automatizar y controlar el flujo de documentos, datos e imágenes. Asignarle proactivamente a las personas que deben ejecutar las actividades, todos los recursos necesarios (Documentos, información, Aplicaciones, etc.) en cada una de ellas. Definir y controlar alertas según criterios de tiempo, de evento o de condición, provocando así algún mensaje a un supervisor, un escalado de actividades a otras personas para que las resuelvan, y/o una resignación automática. Modificar los procesos y gestionar excepciones en vivo, o al vuelo, es decir, permitir modificar cualquier instancia de proceso ya iniciada, sin necesidad de volver a iniciarla y sin necesidad de meter mano informáticamente. Proveer una vista on-line para supervisores del estado e histórico de cada instancia de proceso, de cada actividad, y del desempeño de las personas. Hacerles llegar a cada persona sus actividades y alertas, independientemente de su ubicación geográfica, a través de la WEB, , SMS, o cualquier otro dispositivo móvil. Proveer métricas para responsables de áreas, organizadores, gestores de procesos y calidad, tanto para efectos de Mejora contínua como de Indicadores de Calidad y de Gestión. Integrarse fácilmente con otros sistemas, aplicaciones y ERPs. Proveer un alto nivel de soporte para la interacción humana. Página 34

37 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Business Process Management Notation (BPMN) Es una notación gráfica que describe la lógica de los pasos de un proceso de Negocio. Esta notación ha sido especialmente diseñada para coordinar la secuencia de los procesos y los mensajes que fluyen entre los participantes de las diferentes actividades. BPMN proporciona un lenguaje común para que las partes involucradas puedan comunicar los procesos de forma clara, completa y eficiente. De esta forma BPMN define la notación y semántica de un Diagrama de Procesos de Negocio (Business Process Diagram, BPD). BPD es un diagrama diseñado para ser usado por los analistas, quienes diseñan, controlan y gestionan procesos. Dentro de un Diagrama de Procesos de Negocio BPD se utiliza un conjunto de elementos gráficos, agrupados en categorías, que permite el fácil desarrollo de diagramas simples y de fácil comprensión, pero que a su manejan la complejidad inherente a los procesos de negocio [40]. Los elementos del BPMN son los siguientes [43]: Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 35

38 Ingeniería de Sistemas Istar - CIS1330IS03 Figura 9: Elementos BPMN. Los conectores permiten establecer una secuencia de actividades, de tal forma que una actividad se realice primero y otra después. Esas actividades están definidas dentro de un Lane (este representa el rol que debe realizarlas). Los elementos que permiten la conexión entre actividades son los flujos de secuencia, los flujos de mensaje y las asociaciones. Todo proceso debe tener un inicio y un fin, y estos son eventos que maneja Bonita con un círculo como notación. En cualquier momento pueden haber flujos alternativos dentro del mismo proceso: Si pasa determinado evento, se hace una actividad, de lo contrario se hace otra. Estas decisiones son compuertas de decisión y Bonita las representa por rombos. Página 36

39 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Servidor de Aplicaciones Un servidor de aplicaciones es un sistema que permite mejorar tres aspectos fundamentales en una aplicación que está desplegada en ese servidor: La alta disponibilidad, que hace referencia a que un sistema debe estar funcionando las 24 horas del día y los 7 días de la semana. La escalabilidad, que se relaciona con el crecimiento del sistema cuando se incrementa la carga de trabajo. El mantenimiento, que tiene que ver con la versatilidad a la hora de actualizar la aplicación DAR (Decision Analysis and Resolution) El DAR es un documento que permite analizar múltiples alternativas para tomar una decisión, evaluando diferentes grupos de criterios de calificación. Cada grupo tiene un peso general en porcentaje frente a otros grupos para la calificación total de una alternativa, y a su vez, cada uno de los criterios de cada grupo tiene también un peso en porcentaje. Cada uno de los evaluadores del DAR asigna un puntaje de 1.0 a 5.0 a cada criterio, luego esta calificación es multiplicada por el peso de cada uno y se pondera un subtotal. Este subtotal es multiplicado por el peso del grupo respectivo y al final se ponderan los subtotales con el fin de calcular la calificación definitiva de una alternativa. Esto se hace para conocer la mejor de las alternativas para un problema dado [49]. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 37

40 Ingeniería de Sistemas Istar - CIS1330IS03 III DESARROLLO DEL TRABAJO 3.1. Fase 1: Evaluación del estado del arte Esta fase inició con la investigación de las ventajas y desventajas que poseen los sistemas ERP actuales en el mercado, dando como resultado el cuadro comparativo referenciado en la tabla 1. software Descripción Ventajas Desventajas Logility Voyage Solutions[33] (software Empresarial) JDA Demand[34] (software Empresarial) JDA Fulfillment[34] (software Empresarial) Es un conjunto de soluciones colaborativas para la administración de cadenas de suministro que ayuda a pequeñas, medianas y grandes empresas en tiempo real Ofrece a sus clientes el uso de herramientas de modelación estadística para el análisis de los consumidores Ofrece a los clientes una herramienta para asegurar que los ítems correctos es-tén en los centros de distribución correctos en el tiempo correcto Gestión de Rendimiento: Permite proactivamente monitorear, controlar y medir operaciones de la cadena de suministro. Optimización de Demandas: Incrementa la precisión de pronósticos mediante el planeamiento efectivo y gestión de ciclos de vida. Evalúa los planes de demanda. Valoración de colaboración en cadena: La aplicación permite el trabajo concurrente usando aplicaciones basadas en servicios web. Modelado estadístico avanzado, clasificación de la demanda y segmentación, pronóstico de nuevos productos, administración de promociones y pronóstico colaborativo. Planeación multinivel de reabastecimiento, asignación flexible de producto terminado, administración de datos sensibles del inventario. Optimiza los inventarios en cuento reducción de costos, pero no en cuanto agotados. No tiene un módulo para el manejo del personal. No tiene un módulo para la gestión financiera. No optimiza la gestión de transporte, no tiene un módulo para el manejo del personal, ni de gestión financiera, no optimiza la gestión de transporte. No optimiza la gestión de transporte, no tiene un módulo para el manejo del personal, no tiene un módulo para la gestión financiera. Advanced Planning[35] (software Empresarial) Ayuda a mejorar el desempeño y rentabilidad optimizando la producción y los planes Integración de los pronósticos, optimización de las compras, dinámica de presentación. Ayuda a mejorar el desempeño y rentabilidad optimizando la producción y los planes. No tiene un módulo para el manejo del personal. No tiene un módulo para la gestión financiera. SAP SCM[36] (software Empresarial) Openbravo[10] (software Libre) Ayuda a sincronizar la parte financiera, planificación, distribución, transporte y logística las 24 horas del día y los 7 días de la semana Es una solución ERP basada en la nube que se distribuye gratis bajo licencia opensource. Está pensada para Pymes (negocio particular o empresa de hasta 50 trabajadores) Permite la comparación entre los resultados de las diferentes estrategias y presupuestos, para replantear y reaccionar rápidamente ante alguna contingencia. Ayudar a mantener las relaciones con los proveedores, los clientes y los fabricantes de piezas, lo cual facilita su conexión y colaboración en todo el mundo. Integra la gestión de compras y almacenes, gestiona proyectos y servicios, posee un módulo de contabilidad. Gestión económico-financiera, gestión avanzada de clientes (CRM), inteligencia de negocio (BI). Baja implementación para los productos agotados. No posee integración con VoIP. No implementa gestión de stocks, ni gestión de distribución, no posee módulo de producción, ni un módulo de diseño de productos. No envía correos electrónicos. Página 38

41 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Neogia[10] (software Libre) OpenERP[28] (software Libre) ERP5[10] (software Libre) ADempiere[24] (software Libre) SCLOUD[3] OMS (Order Management System)[44] Order Dynamics[10] Ability OMS[44] Es una solución ERP opensource gratis para pequeñas y medianas empresas Es una solución ERP opensource que integra múltiples módulos en un solo paquete de software Es una solución ERP opensourse y gratis especializada en empresas y administraciones públicas Es un paquete de software opensource que combina soporte ERP, CRM y SCM Prototipo funcional del modelo SCLOUD elaborado por ingenieros de sistemas de la Pontificia Universidad Javeriana Order Management System es una llave en mano que proporciona un sistema personalizado de gestión de pedidos en línea y soluciones de logística para diferentes empresas de todo el mundo. La solidez de este OMS permite a los minoristas en línea para procesar fiable decenas de miles de pedidos al día a través de múltiples almacenes o centros de distribución. Ability OMS es una aplicación integral de negocios para la industria de marketing multicanal. Ability OMS trasciende la gestión de pedidos, ya que se encarga de todo el ciclo de vida de su día a día las operaciones de negocio. De compras su inventario para depositar fondos de pedidos completados, Capacidad OMS se encarga de todo lo demás. Posee un módulo de actividades de producción, uno para finanzas, uno para expediciones y recepciones, gestiona stocks, distribuciones, y clientes (CRM). Módulo de ventas, CRM, gestión de proyectos, gestión de almacenes, gestión de inventarios, módulo de fabricación, gestión financiera, módulo de recursos humanos. Posee funciones contables y gestión de clientes (CRM). Gestión de almacenes, de inventarios, módulo de envíos y logística, módulo de facturación, gestión de recursos humanos, diseño de productos, producción y gestión de proyectos, módulo de comercio. Gestión de clientes CRM, envío de correos electrónicos, centralización de autenticación de acceso, gestión financiera, de producción, de SCM, de almacenes, de ventas, de documentación, de repositorio de información, tiene inteligencia de negocio (BI) e integración VoIP. Flujo de información del cliente, flujo de información de la pyme, flujo MRP, generador de plan de requerimientos, estimador del plan de requerimientos de materiales. Gestión de órdenes, gestión de inventarios, gestión de relaciones con los clientes de la empresa, y un módulo de cumplimiento de órdenes. Ofrece plataformas E-Commerce, Sistemas de contabilidad, call centers y sistemas de facilidad de pago. Automatiza la captura, el procesamiento y el cumplimiento de las órdenes de comercio electrónico. La OMS acepta pedidos de múltiples canales, incluyendo estores, centros de llamadas, sistemas de IVR, sitios de compras. Posee un control de órdenes. Gestión de Inventarios y Bases de Datos, Gestión de Marketing, Gestión de órdenes, Procesamiento de pagos, Gestión de Clientes, Módulo de Contabilidad y módulo de reportes informativos. Tabla 1: Ventajas y desventajas de Sistemas ERP. No posee gestión de recursos humanos, no tiene integración con VoIP, no envía correos electrónicos, no tiene inteligencia de negocio (BI), no posee un módulo de producción, ni uno de diseño de productos. No envía correos electrónicos, no tiene integración con VoIP, no posee módulo de diseño de productos, no tiene inteligencia de negocio (BI), no posee gestión de distribución. No posee integración con VoIP, ni envía correos electrónicos. No posee Inteligencia de negocio (BI). No posee módulo de diseño de productos. Un proveedor por producto, no toma en cuenta días festivos ni tiempos de mantenimiento, y siempre se asume que los proveedores podrán entregar un pedido en un tiempo específico. No tiene en cuenta inventarios existentes. No envía correos electrónicos, no tiene integración con VoIP, no posee módulo de diseño de productos, no tiene inteligencia de negocio (BI), no posee gestión de distribución. No posee gestión de recursos humanos, no tiene integración con VoIP, no envía correos electrónicos, no tiene inteligencia de negocio (BI), no posee un módulo de producción, ni uno de diseño de productos. No cuenta con una integración VoIP, no envía correos electrónicos, no cuenta con un módulo estadístico ni inteligencia de negocio (BI), no posee módulo de modelamiento de productos. Página 39 Preparado por el Grupo Investigación Istar- Versión /03/2008

42 Ingeniería de Sistemas Istar - CIS1330IS03 Con el fin de tener una visión más amplia sobre estas herramientas, se prosiguió a realizar otra investigación en la cual se mostraran las ventajas y desventajas de los sistemas ERP en 6 países, la cual permitió hacer una profundización en qué funcionalidades de esos sistemas actuales en el mundo son competitivas para aplicarlas a SCLOUD (Ver tabla 2). Los países seleccionados fueron aquellos cuya producción de software para gestión de cadenas de abastecimiento tienen un mayor impacto en el mundo. Página 40

43 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica ERP Descripción Ventaja Desventaja Rusia [26] La mayoría de software en Rusia es importado, Las aplicaciones cuentan con módulos de ERP tales como financieros, logísticos y de control. Los principales participantes en el mercado ruso son SAP ERP, 1c, Microsoft y Oracle, en donde SAP se convirtió en el líder del mercado en el 2006, y en el segundo puesto se encuentra 1c, que es una compañía rusa dedicada al desarrollo de software [26]. 1. Las herramientas de software que producen son líderes de mercado por sus módulos financieros. 1. La gran parte de herramientas de software que usan es importado. España [27] En España, el ERP se enfoca en las organizaciones tanto del sector público como del privado para estados de cambio frecuente y dinámico. 1. Permite a las organizaciones sustituir sus múltiples sistemas internos a una sola solución integrada ERP completa. 2. En este país, sus herramientas como UNIT4 o ekon son construidas sobre arquitecturas Karat y VITA que satisface problemas de flexibilidad y usabilidad para los usuarios finales. 3. Estas arquitecturas tratan de ofrecer soluciones para satisfacer los más variados requerimientos de gestión y operacionales, trata de eliminar las ineficiencias en todos los procesos de administra- 1. Como se dijo anteriormente existen varias herramientas de software con buenas soluciones, el inconveniente es que cada herramienta ofrece sus propias soluciones. Página 41

44 Ingeniería de Sistemas Istar - CIS1330IS03 Japón Las herramientas de software que crea Japón son con la colaboración de otros países como Rusia y España. ción, controla el riesgo y mejora diferentes mecanismos de control de procesos, entre otras. 4. Para pymes ofrecen servicios web para conectarse desde cualquier equipo (incluyendo dispositivos móviles). 1. Japón tiene empresas las cuales se encuentran aliadas con otras empresas del mundo, para poder ofrecer soluciones ERP, por ejemplo esta Rooms For (Hong Kong) Limited y Aquasys G.K [28]. Existe un software de código libre que fue desarrollado en parte por Japón y otros países llamado ERP5 [29]. 1. Japón se encuentra en una situación difícil debido a la tendencia global de la utilización de ERP en la práctica empresarial, sus sistemas no son fáciles de adaptar a los modelos estadounidenses o de otros países [30]. Brasil USA [32] Las herramientas de software creadas en Brazil se enfocan en su sistema económico mezclado con el de otros países [31]. Las herramientas de Estados Unidos fueron las que gobernaron inicialmente el mercado de los sistemas ERP. 1. Gran parte de las herramientas de software en Brasil son de código abierto, así que, los módulos creados para ciertas funcionalidades que se basan en el sistema económico de ese país pueden ser adaptados para otro [31]. 1. Estados unidos cuenta con la empresa Oracle la cual empezó a implementar ERP en 1993, y desde el 2003 aproximadamente se convierte en 1. Las herramientas de software provenientes de Brasil están creadas en base al sistema económico de ese país, haciendo que no sean funcionales en otros países [31]. 1. Aunque estados Unidos cuente con una de las empresas con más reconocimiento en el mundo, y cuente con varios software que ofrezcan solucio- Página 42

45 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica uno de los grandes proveedores junto con SAP y SSA Global. nes para ERP, todavía no se ha fabricado una herramienta que logre modificar todas estas soluciones en uno solo. Colombia En Colombia existen varias herramientas ERP, y las más utilizadas en este país son: Productivos LTDA: Es un software comercial y de Manufactura para empresas industriales y se encuentra integrado con las demás aplicaciones a nivel financiero, comercial y administrativo. Ofrece un módulo de MRPII que incluye: Inventarios, costos (por orden y por proceso), planeación de producción, control de producción, programación de producción, compras, importaciones, mantenimiento y control de calidad [22]. SIIGO: Cuenta con 4 módulos que permiten la gestión de la empresa desde diferentes áreas. El primer módulo se centra en la parte contable de la organización, el segundo módulo trabaja con ventas, el tercer módulo se centra en la cartera de la empresa, y el cuarto módulo se centra en la parte de información como reportes [23]. 1. Tiene varias herramientas de software que son de código abierto, y cualquier usuario puede hacer modificaciones sobre él. 2. La mayoría de las herramientas de software son especialmente para pymes Colombianas. 3. La mayoría de las herramientas de software están instaladas en la nube, haciendo que el rendimiento de un sistema ERP sea eficiente. 1. Las licencias de uso que se pagan por herramienta de software son costosas. A diferencia de otros países, las herramientas de software Colombianas no cuentan con una arquitectura estándar de diseño. Adempiere: Es un paquete de software, cuya característica principal es que es de código abierto. Y que se limita a algunas funcionalidades tales como: Ventas, gestión de productos, compras, finanzas, gestión de proyectos [24]. OasisIT: Ofrece varios productos con diferentes soluciones para las empresas: Oasis ERP (Financiera), SCM (Logística), MRP (Manufactura), WMS (Bodegas), HRM (Recursos humanos), POS (Punto de venta), CRM (Clientes), PM (Proyectos), E-Bussines,BI (inteligencia de negocios),dss Decisiones [25]. Tabla 2: Sistemas ERP a nivel mundial. Página 43

46 Ingeniería de Sistemas Istar - CIS1330IS03 A partir de estos cuadros comparativos se analizaron las características de cada una de esas herramientas para decidir qué requerimientos eran posibles incluir en la extensión del prototipo de SCLOUD. De la tabla 1 se logró concluir que la funcionalidad más importante que se puede obtener es el módulo de ventas y contabilidad que implementan otros sistemas, pues es de gran importancia para las pymes, y la que menos tiene importancia es el mecanismo de alertas por correo electrónico puesto que el prototipo de SCLOUD ya lo tiene implementado. En cuanto a la tabla 2 cabe resaltar que Colombia es el mayor productor de herramientas de software con código abierto y esto es muy importante, pues una empresa puede tomar el código de un sistema y lo puede adaptar a sus procesos de negocio sin incurrir en problemas legales. Al comparar estas herramientas con las producidas en Rusia se muestra una desventaja en cuanto a módulos financieros, pues ellos son líderes en ese tema. Luego de toda la investigación que se desarrolló en esta fase, se generó un documento que contiene información detallada sobre los requerimientos propuestos para la extensión del prototipo de SCLOUD (Ver Anexo 1). En la tabla 3 se resume los requerimientos definidos en esta fase. Página 44

47 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Requerimiento Descripción Funcionalidad de análisis? Funcionalidad Operativa? Origen del requerimiento requerimientos Funcionales 1 SCLOUD debe permitir la gestión de inventarios para Pymes. x Tesis de Grado Camilo Ruiz y Camilo Méndez [4]. 2 SCLOUD debe permitir a una pyme hacer pedidos de productos por lotes a un proveedor. x Tesis de Grado Camilo Ruiz y Camilo Méndez [4]. 3 SCLOUD debe permitir que una pyme pueda seleccionar un proveedor para el pedido que desee realizar. x Tesis de Grado Camilo Ruiz y Camilo Méndez [4] SCLOUD debe implementar un módulo de contabilidad básico que permita persistir los ingresos y los gastos de una pyme. SCLOUD debe permitir la generación de reportes contables para analizar el estado de ingresos y egresos de una pyme. SCLOUD debe implementar un módulo de estadística que permita a un proveedor determinar si un pedido hecho por una pyme puede realizarse o no, según pedidos históricos. x x x SAP. SAP. ERP5. Página 45

48 Ingeniería de Sistemas Istar - CIS1330IS03 7 SCLOUD debe permitir a una pyme asociarse con múltiples proveedores. x ERP5. 8 SCLOUD debe permitir a una pyme eliminar un cliente. x Investigación ERP. 9 SCLOUD debe permitir la creación de un distribuidor. x Investigación ERP. 10 SCLOUD debe permitir la autenticación de un distribuidor. x Investigación ERP. 11 SCLOUD debe permitir la creación de un productor. x Investigación ERP. 12 SCLOUD debe permitir la autenticación de un productor. x Investigación ERP SCLOUD debe permitir a una pyme la adición de bodegas contenedoras de productos. SCLOUD debe permitir a una pyme la eliminación de bodegas contenedoras de productos. SCLOUD debe permitir a una pyme la edición de productos que contiene una bodega. SCLOUD debe permitir la persistencia de empleados que trabajan en una pyme. SCLOUD debe permitir la eliminación de empleados de una pyme. x x x x x OpenERP. OpenERP. OpenBravo. OpenBravo. SAP. Página 46

49 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica SCLOUD debe contar con un histórico de ventas para gestionar la interacción con los clientes de la pyme. SCLOUD debe permitir dar una descripción a los productos ( Datos maestros del producto ). SCLOUD debe mostrar información histórica de los productos (cuando fue vendido, cantidad, si estuvo en promoción, agotados). SCLOUD debe permitir que un cliente se asocie con múltiples Pymes. x x x x SAP. SAP. SAP. SAP SCLOUD debe permitir poner propiedades a los productos, por ejemplo si un producto se encuentra en promoción. SCLOUD debe implementar un calendario parametrizable por la pyme, indicando qué días son laborables. x x SAP. Tesis de Grado Camilo Ruiz y Camilo Méndez [4]. 24 SCLOUD debe permitir parametrizar a una pyme un tiempo de espera por pedido hecho por un cliente. x Tesis de Grado Camilo Ruiz y Camilo Méndez [4]. 25 SCLOUD debe permitir conjuntar las órdenes de un mismo producto solicitadas por diferentes clientes. x Tesis de Grado Camilo Ruiz y Camilo Méndez [4]. Página 47

50 Ingeniería de Sistemas Istar - CIS1330IS SCLOUD debe implementar un sistema BRMS (Business Rule Management System) para controlar decisiones complejas de negocio. SCLOUD debe implementar una interfaz web que informe a una pyme del sistema de manera rápida el estado de su inventario. x x Tesis de Grado Camilo Ruiz y Camilo Méndez [4]. Tesis de Grado Camilo Ruiz y Camilo Méndez [4]. requerimientos No Funcionales SCLOUD debe implementar algoritmos que permitan realizar consultas eficientes a la base de datos. SCLOUD debe estar disponible las 24 horas del día para todo tipo de usuario mediante clúster. SCLOUD debe persistir los datos de los usuarios en una base de datos Postgres. SCLOUD debe ser instalado y ejecutado en los servidores de la Pontificia Universidad Javeriana sede Bogotá. x x x x Investigación ERP. Investigación ERP. Investigación ERP. Investigación ERP. 32 SCLOUD debe funcionar en una máquina virtual en ambiente Linux. x Investigación ERP. 33 Se deben generar Session Beans remotos que ofrezcan los servicios que tiene SCLOUD. x Tesis de Grado Camilo Ruiz y Camilo Méndez [4]. Tabla 3: requerimientos posibles del sistema. Página 48

51 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Página 49

52 Ingeniería de Sistemas Istar - CIS1330IS Fase 2: Refactorización del sistema Dentro de esta fase, se hizo un análisis en torno a la herramienta de desarrollo que se usó en la implementación del prototipo de SCLOUD, en este caso se habla de Bonita Open Solution v5.8 [12]. Dentro del análisis se pudo determinar la forma como se modelan los procesos de negocio con dicha herramienta, y cómo utilizar los comandos básicos de la misma para comenzar a extender el prototipo de SCLOUD. Al momento de conocer Bonita Open Solution, salió al mercado la versión cuyas características eran mucho mejores que la 5.8, y con esto surgió la idea de migrar todo el prototipo de SCLOUD a la nueva versión (6.0.1). Por problemas de compatibilidad de librerías y otros problemas técnicos, no se pudo mudar el sistema, pues lo más probable era reescribir todo el prototipo para la nueva versión. Así que se decidió continuar con la versión vieja (5.8) para lograr el objetivo principal del proyecto que es la extensión de dicho prototipo. Una meta que se propuso durante esta fase es que el código Java que se desarrollara debía ser lo más independiente posible del entorno de Bonita; para esto se crearon clases especiales que tienen métodos que llaman a la lógica de negocio implementada en Java, y estos son llamados desde Bonita. Toda la lógica de negocio se refactorizó en EJBs [46] cuyos métodos están expuestos en iterfaces remotas [47] para lograr la comunicación por red entre los módulos del sistema en caso de que estos tengan que desplegarse en máquinas diferentes (para este proyecto, todos los módulos están en un mismo servidor), en este caso, para desplegar las interfaces de la lógica de negocio, se usó el servidor de aplicaciones de JBoss 7.1 [48], de tal forma que las clases especiales que tienen los métodos que son invocados desde Bonita, llaman a la lógica de negocio desplegada en el servidor. Página 50

53 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica La decisión de refactorizar el sistema en EJBs fue por la facilidad de implementación que brinda y su seguridad en cuanto a transaccionalidad, pues los contenedores de EJB que están en el servidor de aplicaciones de JBoss 7.1 se encargan de eso y ya prácticamente es transparente para el programador. Además, la persistencia automática está presente en el servidor de aplicación (el código SQL burocrático desaparece [49]). A partir del desarrollo del proyecto para esta fase se generó una nueva arquitectura que contiene todas las funcionalidades del prototipo de SCLOUD encapsuladas en EJBs con el fin de lograr transaccionalidad por parte del servidor de aplicaciones y mejorar las sesiones de conexión por parte de los clientes del sistema. A continuación se muestran dos diagramas de despliegue: uno representa el funcionamiento de SCLOUD con una sola pyme y el otro representa el sistema multitenant de SCLOUD. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 51

54 Ingeniería de Sistemas Istar - CIS1330IS03 Figura 10: Arquitectura SCLOUD con una pyme. Página 52

55 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Figura 11: Arquitectura SCLOUD con multitenants (múltiples pymes). Página 53

56 Ingeniería de Sistemas Istar - CIS1330IS03 La primera arquitectura (Ver Anexo 2) muestra que toda la lógica de presentación y de procesos de Bonita se encuentran desplegados en un servidor de aplicaciones JBoss 5.1.0, mientras que la lógica de negocio de SCLOUD está en otro servidor JBoss pero versión 7.1. Ambas versiones de JBoss se encuentran instaladas en un mismo servidor porque no se cuentan con más. La base de datos que se usó para el proyecto fue PostgreSQL y también se encuentra instalada en el mismo servidor que los servidores de aplicaciones, y es aquí donde la capa de lógica de negocio de SCLOUD obtiene información de clientes, inventarios, pedidos, etc. La forma como se comunican los nodos del sistema (cliente y servidor) es por protocolo HTTP, y la manera como la lógica de Bonita se comunica con el modelo de negocio que está en JBoss 7.1 es por RMI (Remote Method Invocation). Hay un paquete JAR que está en JBoss llamado SCLOUD, y es el que tiene el llamado a los métodos de la lógica de negocio de forma remota. La segunda arquitectura (Ver Anexo 3) muestra únicamente una instancia de más de JBoss 5.1.0, que representa otra pyme en caso de que el sistema cree una nueva. El mecanismo de comunicación es el mismo que se explicó en la primera arquitectura Fase 3: Selección de requerimientos factibles Los requerimientos que se obtuvieron durante la fase de Evaluación del estado del arte fueron plasmados en un documento HACER-USOS (Ver Anexo 19), que ayuda a definir si un requerimiento es alcanzable, medible, y porqué es necesario. A partir de este archivo, para la selección de los requerimientos que hacen parte de las extensiones de SCLOUD, se aplicó una metodología para toma de decisiones en una empresa sobre tecnologías de información llamada DAR (Decision Analisys and Resolution). Esta metodología ayuda a analizar las posibles alternativas de decisión utilizando un proceso de evaluación formal que evalúa las alternativas respecto a un conjunto de criterios establecidos [50]. Página 54

57 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Para este proyecto, las alternativas de decisión son los posibles requerimientos que se establecieron en la fase de Evaluación del estado del arte, y los criterios que se utilizaron para evaluar cada una de las alternativas se definen en las tablas 4 y 5 [51]. Los requerimientos se dividieron en funcionales y no funcionales: Los funcionales son aquellos describen un comportamiento entre el sistema y el usuario final, y los no funcionales son aquellos que ayudan a mejorar comportamientos del sistema como tiempo de ejecución, tiempo de respuesta, recursos consumidos, etc. Para los requerimientos funcionales: Grupo Criterio Definición Correctitud Trazabilidad Tiempo de vida de un requerimiento, es decir, cuánto va a durar en funcionamiento dentro del sistema. Completitud Hace referencia al nivel de madurez que adquiere el sistema con el requerimiento. Usabilidad Operabilidad Minimiza la complejidad del manejo del requerimiento para un usuario? Poco Entrenamiento de Usuario Facilita la familiarización del usuario con el requerimiento? Eficiencia Eficiencia de Ejecución Minimiza el nivel de procesamiento que necesita el sistema para cumplir con el requerimiento? Eficiencia de Almacenamiento Minimiza el espacio de almacenamiento ne- Preparado por el Grupo Investigación Istar- Versión /03/2008 cesario? Tabla 4: Criterios de calificación para requerimientos funcionales. Página 55

58 Ingeniería de Sistemas Mantenibilidad Funcionalidad Alta Modularidad Bajo Acoplamiento Adecuación Cobertura de Roles Indispensable para el sistema Istar - CIS1330IS03 Nivel de dependencia de un requerimiento para otros. Nivel de interacción con otros requerimientos. Hace referencia al nivel de adaptación que tiene el requerimiento, sin perder la calidad de los servicios que ofrece a la hora de un cambio en el sistema. Hace referencia al nivel de afectación del requerimiento a los diferentes roles del sistema. Hace referencia al nivel de importancia que tiene el requerimiento para el sistema. Para los requerimientos no funcionales: Criterio Definición Grupo Confiabilidad Tolerancia a Fallos Nivel de continuidad del sistema bajo condiciones no usuales. Recuperabilidad Capacidad del requerimiento para devolverse a un estado anterior en caso de un fallo. Eficiencia Escalabilidad Hace referencia a que el sistema puede funcionar adecuadamente Página 56

59 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica a medida que aumentan los usuarios. Desempeño Hace referencia al aporte significativo que hace el requerimiento al sistema en cuanto a tiempo de procesamiento por unidad de tiempo. Seguridad Seguridad Interna (Security) Nivel del requerimiento para resistir a intentos de uso no autorizados. Tabla 5: Criterios de calificación para requerimientos no funcionales. Cada grupo tiene un peso general en porcentaje frente a otros grupos para la calificación total del requerimiento, por ejemplo para el proyecto, en los requerimientos no funcionales, es muy importante el grupo de Eficiencia (con un 45% de peso total respecto a los demás). A su vez, cada uno de los criterios de cada grupo tiene también un peso en porcentaje. Cada evaluador (en este caso los desarrolladores del proyecto, la directora y la asesora del trabajo de grado) asigna un puntaje de 1.0 a 5.0 a cada criterio, luego esta calificación es multiplicada por el peso de cada uno y se pondera un subtotal. Este subtotal es multiplicado por el peso del grupo respectivo y al final se ponderan los subtotales con el fin de calcular la calificación definitiva de un requerimiento. En el siguiente capítulo se muestran los resultados del DAR. A partir del desarrollo del proyecto para esta fase se generó una tabla que contiene los criterios y las calificaciones definitivas de cada uno de los requerimientos posibles que pueden hacer parte de las extensiones de SCLOUD. En la figura 11 se muestra un ejemplo del DAR generado para el proyecto (Ver anexo 4). Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 57

60 Ingeniería de Sistemas Istar - CIS1330IS03 Figura 12: Ejemplo DAR. Las zonas marcadas con rojo son los grupos definidos, y las que están en verde son los criterios de cada uno de los grupos. El peso de los grupos en porcentaje se marca en el recuadro azul y los pesos por criterio en el naranja. La definitiva de cada uno de los requerimientos está coloreada en azul claro en la imagen. Los requerimientos que harán parte de las extensiones de SCLOUD serán los que tengan un puntaje mayor o igual a 4.0, y para este proyecto, 19 requerimientos cumplieron con esa nota y son los referenciados en la tabla 6. Id Código Requerimiento Calificación 1 REQF-008 SCLOUD debe permitir a una pyme eliminar un cliente. 2 REQF-003 SCLOUD debe permitir que una pyme pueda seleccionar un proveedor para el pedido que desee realizar. 3 REQF-025 SCLOUD debe permitir conjuntar las órdenes de un mismo producto solicitadas por diferentes pymes. 4 REQF-021 SCLOUD debe permitir que un cliente se asocie con múltiples Pymes. 5 REQF-007 SCLOUD debe permitir a una pyme asociarse con múltiples proveedores. 4,53 4,42 4,36 4,35 4,32 Página 58

61 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica 6 REQF-023 SCLOUD debe implementar un calendario parametrizable 4,32 por la pyme, indicando qué dias son laborables. 7 REQNF-028 SCLOUD debe implementar algoritmos que 4,3 permitan realizar consultas eficientes a la base de datos. 8 REQF-019 SCLOUD debe permitir dar una descripción a 4,28 los productos ( Datos maestros del producto ). 9 REQF-024 SCLOUD debe permitir parametrizar a una pyme un tiempo de espera por pedido hecho a un proveedor. 10 REQF-002 SCLOUD debe permitir a una pyme hacer pedidos de productos por lotes a un proveedor. 4,24 4,23 11 REQNF-033 Se deben generar Session Beans remotos que ofrezcan los servicios que tiene SCLOUD. 4,23 12 REQF-011 SCLOUD debe permitir la creación de un productor. 13 REQF-010 SCLOUD debe permitir la autenticación de un distribuidor. 14 REQF-012 SCLOUD debe permitir la autenticación de un productor. 15 REQF-009 SCLOUD debe permitir la creación de un distribuidor. 16 REQNF-030 SCLOUD debe persistir los datos de los usuarios en una base de datos Postgres. 17 REQNF-029 SCLOUD debe estar disponible las 24 horas del día para todo tipo de usuario mediante clúster. 4,18 4,16 4,16 4,15 4,13 4,09 18 REQNF-032 SCLOUD debe funcionar en una máquina virtual en ambiente Linux. 19 REQNF-031 SCLOUD debe ser instalado y ejecutado en los servidores de la Pontificia Universidad Javeriana sede Bogotá. 4,06 4,01 Tabla 6: requerimientos seleccionados para la extensión de SCLOUD. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 59

62 Ingeniería de Sistemas Istar - CIS1330IS Fases 4 y 5: Desarrollo e implementación del sistema Para diseñar e implementar las extensiones propuestas para SCLOUD, se siguió la metodología de Programación Extrema (XP) aprovechando que es una metodología ágil. XP pretende llevar buenas prácticas de la Ingeniería de software pero al extremo, según Kent Beck, y se muestran en la figura 12 [52]: Buenas Prácticas Software funcionando Revisiones de código Sistema de pruebas estructurado Tener alineado al cliente Prácticas al Extremo Entregas incrementales e integración continua Programación por pares Desarrollo guiado por pruebas Cliente "in situ" Figura 13: Buenas prácticas vs. Prácticas al extremo. El gráfico anterior muestra un conjunto de buenas prácticas que son llevadas a un nivel más preciso que es el objetivo de la programación extrema. En otro tipo de metodologías que se rigen por buenas prácticas, deben entregar en un solo momento el software completamente funcional, mientras que XP presenta múltiples entregas con el fin de ir validando lo que el cliente desea en su sistema, además la implementación del software se hace por parejas de programadores, de tal forma que haya una menor probabilidad de que se cometan errores de programación y que se aumente el nivel de comunicación entre los integrantes del equipo de desarrollo. Los resultados de las pruebas que se hagan en el sistema serán muy importantes en la fase de implementación, pues basándose en ellos se harán las respectivas correcciones en caso de que surjan problemas dentro de la misma (se pueden demostrar las pruebas realizadas Página 60

63 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica al sistema consultando el Anexo 17). Al momento de presentar las entregas incrementales, XP necesita tener al cliente in situ, es decir, se debe tenerlo cara a cara para tomar las respectivas retroalimentaciones del sistema y mejorarlo. Es posible demostrar las reuniones que se hicieron con el cliente consultando el Anexo 12, que contiene las actas en donde se estipulan correcciones y comentarios respecto a cada una de las entregas que se presentaron. XP divide el desarrollo del software en iteraciones cortas con un tiempo fijo de duración. Aplicado a este proyecto de grado, cada una de las iteraciones representaban el diseño y la implementación de un requerimiento factible elegido para la extensión de SCLOUD, de esta forma se aseguraba que las prácticas propuestas por XP se ejecutaran durante el desarrollo del sistema. A partir del desarrollo del proyecto para esta fase se diseñó un modelo de tablas mediante el uso de JPA, el API de Java para manipular las tablas de una base de datos a partir de objetos bajo el paradigma de programación orientada a objetos [23]. Para ver el diagrama de clases que representa el modelo de tablas del sistema se muestra en el Anexo 10 de la memoria del trabajo de grado, o puede consultar el Anexo 9 para obtener más información sobre cada una de las clases que se crearon. La Arquitectura para el sistema que se siguió fue la misma generada en la fase de refactorización, solamente que se agregaron más procesos en el servidor de aplicaciones de JBoss Para completar el conjunto de procesos que se modelaron inicialmente en el prototipo de SCLOUD (Supply Chain Information Flow Client, Supply Chain Information Flow Pyme y MRP Process), se crearon otros que soportan los requerimientos seleccionados para la extensión de SCLOUD, y son: Flujo_de_Información_Cadena_de_Abastecimiento--8.0.bar Proceso_MRP--3.1.bar Notificar_Pyme_por_MRP--1.0.bar Notificar_a_Proveedores--1.0.bar Agregar_Datos_Maestros 1.0.bar Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 61

64 Ingeniería de Sistemas Istar - CIS1330IS03 Agregar_nuevo_Proveedor--1.0.bar Seleccionar_Proveedor_por_defecto--1.0.bar Borrar_Cliente--1.0.bar Activar_MRP_Automatico--1.0.bar Calendario Parametrizable 1.0.bar La definición de actividades y métodos usados para la implementación se encuentran detallados en el documento de mantenimiento del proyecto (Ver Anexo 5). A continuación se mostrará por cada uno de los procesos que se diseñaron su diagrama de actividades respectivo y una descripción de lo que hace el mismo Flujo de Información Cadena de Abastecimiento En este proceso es donde se encuentra tanto el flujo de información para el cliente como el flujo para la pyme (Ver Anexo 6). La interacción del proceso inicia con la identificación del cliente, en donde si el cliente es nuevo tiene la posibilidad de registrarse por medio de datos personales básicos, en el caso que el cliente ya esté registrado, el sistema automáticamente busca los productos asociados a la pyme donde el cliente está haciendo la solicitud y de esta forma el cliente puede seleccionar los productos que conformarán su solicitud, el siguiente fragmento del proceso Hacer_un_Pedido muestra solamente la parte de registrar un nuevo cliente. Página 62

65 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Figura 14: Agregar Cliente. Para el caso de cuando el cliente se encuentra registrado se muestra en la figura 14: Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 63

66 Ingeniería de Sistemas Istar - CIS1330IS03 Figura 15: Validar Cliente. Luego de esto el sistema guarda la solicitud del cliente y estima una posible fecha de entrega, así como se muestra en la figura 15: Página 64

67 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Figura 16: Estimación de Fechas. Una vez el sistema termina, notifica al cliente vía la solicitud actual y de esta forma el sistema queda en espera de la confirmación final del cliente. Este flujo se muestra en la figura 16. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 65

68 Ingeniería de Sistemas Istar - CIS1330IS03 Figura 17: Confirmación final a Cliente. De esta forma si el cliente no acepta los parámetros de entrega, o se agota el tiempo de solicitud del pedido, el proceso finalizará como lo indica la figura 17. Página 66

69 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Figura 18: Cancelación de pedido. Pero en caso contrario, es decir cuando el cliente acepte los parámetros de la compra, el sistema evaluará si no se han cambiado los parámetros de entrega y valor del pedido del cliente con el fin de poder continuar con las notificaciones a cada uno de los roles de la pyme que tienen una interacción humana como lo son (Distribución, Producción y Aprovisionamiento), donde se informan los datos necesarios para que cada uno de ellos pueden continuar posteriormente con el flujo de producto, donde se hace la transformación de las materias y se hace la entrega al cliente, el cual no es contemplado en el diseño del proceso de SCLOUD. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 67

70 Ingeniería de Sistemas Istar - CIS1330IS03 Figura 19: Cálculo MRP. Página 68

71 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica En caso contrario en donde los parámetros de fecha de entrega y total del pedido del cliente tengan modificaciones el cliente será notificado nuevamente a cliente con el fin de informar que no se puede continuar con los parámetros iniciales, de tal forma que el cliente tendría que modificar, cancelar o aceptar su solicitud bajo los nuevos parámetros de entrega. Hacer un Pedido Este proceso cuenta con el rol cliente el cual radica la solicitud de compra inicial. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 69

72 Ingeniería de Sistemas Istar - CIS1330IS03 Figura 20: Hacer un Pedido. Página 70

73 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Procesar un Pedido El proceso definido en la pyme está compuesto por cuatro roles (Distribución, Producción, Abastecimiento y sistema) los cuales tiene el mismo significado estipulado en el modelo MACA, sin embargo el rol del sistema no es contemplado y es el encargado de ejecutar todas aquellas tareas automáticas que tiene el proceso definido. Figura 21: Procesar un Pedido (1). Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 71

74 Ingeniería de Sistemas Istar - CIS1330IS03 Figura 22: Procesar un Pedido (2). Página 72

75 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Figura 23: Procesar un Pedido (3). Página 73

76 Ingeniería de Sistemas Istar - CIS1330IS Proceso MRP El proceso del MRP es el encargado de ejecutar la lógica desarrollada en los módulos de Java para validar las estimaciones de la cantidad de materiales, productos, etc. en la base de datos del sistema. Figura 24: Proceso MRP Notificar Pyme por MRP Este proceso es el encargado de ejecutar el MRP, y de realizar las respectivas notificaciones a los diferentes roles de la pyme. El diagrama BPM es el mostrado en la figura 24. Página 74

77 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Figura 25: Proceso Notificar Pyme por MRP. Página 75

78 Ingeniería de Sistemas Istar - CIS1330IS03 Este proceso solamente se inicia cuando el Flujo de Información Cadena de Abastecimiento llama a la actividad Pyme MRP Notification, una vez esta es llamada se ejecuta el MRP, para luego notificar a los roles de la pyme. En dado caso que se tenga que hacer una notificación a producción, este proceso calculara los lotes que se hayan creado en producción para la fabricación de un producto. Por ultimo si se necesita hacer una compra a proveedores el sistema utilizara otro proceso encargado de notificar estas compras por medio de correo electrónico Notificar Proveedores Este proceso es el encargado de realizar las respectivas notificaciones cuando la pyme necesite hacer una compra a un determinado proveedor. El diagrama BPM es el mostrado en la figura 25. Figura 26: Proceso Notificar Proveedores. Este proceso inicia cuando Notificar por MRP ejecute la actividad de notify Suppiers, a partir de esto se seleccionaran los proveedores que la pyme tiene elegidos como favoritos, los conjuntará y enviara a cada uno un respectivo correo notificando cual es la compra que la pyme desea realizar. Página 76

79 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Crear un Producto Este proceso se inicia con el rol Distribuidor, cando se quiere agregar un nuevo producto a la base de datos de SCLOUD, o también cuando se quiere modificar los datos maestros de cualquier producto. El diagrama BPM es el representado en la figura 26. Figura 27: Proceso Crear un Producto Añadir nuevo Proveedor Este proceso inicia con el rol de abastecimiento (source), el cual ingresara la identificación de un proveedor para asociarse con este. El modelo BPM para este proceso se muestra en la figura 27. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 77

80 Ingeniería de Sistemas Istar - CIS1330IS03 Figura 28: Proceso Añadir nuevo Proveedor Borrar Cliente Este proceso se inicia con el rol distribuidor, en donde ingresa la identificación de un cliente de la pyme, y en dado caso que este se encuentre registrado en la base de datos será eliminado, si no existe se le volverá a pedir al usuario que digite una identificación correcta. El modelo BPM correspondiente a este proceso es detallado en la figura 28. Página 78

81 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Figura 29: Proceso Borrar Cliente Seleccionar Proveedor por Defecto Este proceso inicia con el rol de abastecimiento, en donde primero se mostraran los materiales que están asociados a los productos, a partir de esta información el usuario de abastecimiento podrá seleccionar un material y verificar todos los proveedores que la pyme tiene asociado a este, y el usuario tendrá la capacidad de elegir un proveedor favorito. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 79

82 Ingeniería de Sistemas Istar - CIS1330IS03 Figura 30: Proceso Seleccionar Proveedor por Defecto Activar MRP Automático Este proceso se encarga de ejecutar un timer el cual es parametrizable por la pyme, una vez alcanzado el tiempo se procesaran los lotes que la pyme tenga en producción. El diagrama se muestra en la figura 30. Página 80

83 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Figura 31: Proceso Activar MRP Automático. Este proceso es iniciado por el rol de producción, donde inicialmente mostrará un formulario, el cual pedirá un tiempo específico, una vez que se llene este proceso enviara al MRP los lotes de producción que se encuentren disponibles hasta el momento. Una vez acabado el MRP el timer vuelve a iniciar. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 81

84 Ingeniería de Sistemas Istar - CIS1330IS Calendario Parametrizable Este proceso se encarga de guardar las fechas en que la pyme no trabaja. Su diagrama BPM es el que se muestra en la figura 31. Figura 32: Proceso Calendario Parametrizable. Este proceso inicia buscando todos los días no laborales de la pyme, para luego ser mostrados en un formulario que se le despliega al distribuidor, en este él es capaz de agregar un nuevo día no laboral de la pyme, el cual será guardado en la base de datos Fase 6: validación del sistema Para validar las extensiones de SCLOUD que se diseñaron e implementaron durante el desarrollo del proyecto, se seleccionaron dos empresas con el fin de parametrizar al Página 82

85 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica sistema ciertos productos que venden y así mostrarles la funcionalidad y el comportamiento del sistema con datos reales para ellos. Las dos empresas seleccionadas para esta fase fueron Confecciones Baker y Can & Estilo. Se eligieron esas por tener una relación cercana con los gerentes de cada una: Para Confecciones Baker la gerente es conocida por Martha Carrillo (directora del trabajo de grado), así que los datos de contacto fueron brindados por ella, y el gerente de Can & Estilo es conocido por uno de los autores del trabajo de grado. La validación se realizó mediante la demostración del sistema SCLOUD con los productos de cada uno parametrizados en el mismo, e inmediatamente luego de la demostración se realizó una encuesta que permite saber qué tan útil es el sistema para la empresa. Antes de iniciar con la validación del sistema fue necesario crear una copia limpia del mismo siguiendo el manual de instalación (Ver Anexo 14). Los resultados para esta fase se encuentran especificados a continuación: validación con Confecciones Baker Confecciones Baker es una empresa dedicada a la producción de artículos en cuero como chaquetas, zapatos, pantalones, etc. Actualmente cuenta con tres puntos de venta en la ciudad de Bogotá D.C. que están referenciados en la tabla 7. Puntos de Venta Confecciones Baker Local Dirección Teléfono San Andresito de San José Calle 9ª # Centro Calle 16 # 5 70 Local 13-d (Frente al Museo del Oro) Galerías Calle 51 # Tabla 7: Puntos de Venta Confecciones Baker. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 83

86 Ingeniería de Sistemas Istar - CIS1330IS03 El local que queda ubicado en Galerías es el punto de fábrica, y es el único que tiene esta empresa. Para la validación se habló con la gerente que se llama Dora Castillo, quien fue la persona a la que se le mostró el funcionamiento del sistema SCLOUD a partir de la parametrización de productos que se muestra en la tabla 8. Parametrización de Productos de Confecciones Baker Producto Materiales para Producción Costo de Materiales Pantalón en Cuero Ref. 200 decímetros de Cuero $ Jean-01 1 Cremallera 1 metro de Forro Hilo Pegante 25 centímetros de Entretela Tiempo de Producción (Por Unidad) 4 horas por costurero Mínimo de Producción 1 Pedido Chaqueta en Cuero Ref. Gomela 250 decímetros de Cuero 1,50 metros de Forro 4 Cremalleras de 20 centímetros $ hora por costurero 2 Pedidos 1 Cremallera de 60 centímetros 2 Hombreras 30 centímetros de entretela Hilo Pegante Abrigo Princesa Ref decímetros de Cuero 2,50 metros de Forro $ horas por costurero 1 Pedido 4 Botones Página 84

87 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica 50 centímetros de Entretela Pegante Tabla 8: Parametrización de Productos de Confecciones Baker. La estructura de producción por cada producto se muestran en las figuras 32, 33 y 34. Pantalón en Cuero Ref. Jean-01 Jean Ref. 01 Tejido Bolsillos Pasadores Relojeras Cuero Cuero Hilo Cuero Forro Hilo Entretela Hilo Cuero Pegante Entretela Hilo Entretela Cremallera Figura 33: Estructura de Insumos para Jeans Ref. 01. Chaqueta en Cuero Ref. Gomela Página 85 Preparado por el Grupo Investigación Istar- Versión /03/2008

88 Ingeniería de Sistemas Istar - CIS1330IS03 Chaqueta Ref. Gomela Mangas Bolsillos Torso Cuero Forro Hilo Cremalleras Entretela Hilo Cuero Cremallera Entretela Pegante Figura 34: Estructura de Insumos para Chaqueta Ref. Gomela. Abrigo Princesa Ref. 02 Abrigo Princesa Ref. 02 Brazos Bolsillos Torso Cuero Forro Hilo Entretela Cremalleras Entretela Botones Hilo Cuero Cremallera Pegante Botones Figura 35: Estructura de Insumos para Abrigo Princesa Ref. 02. Página 86

89 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Las estructuras de producción de cada uno de los productos preguntados en la empresa Confecciones Baker, fueron parametrizadas en el sistema SCLOUD con el fin de probar cada una de las funcionalidades del mismo y así mostrar resultados de forma presencial al usuario. En el Anexo 7 puede consultar los resultados de la encuesta realizada a la empresa luego de haber enseñado el sistema en su totalidad. Confecciones Baker compra su materia prima a los siguientes proveedores: Textiles Estela (proveedor de textiles), Hilos Venus (proveedor de hilos) y Herrajes del Sur (proveedor de cremalleras) validación con Can & Estilo Can & Estilo es una empresa dedicada a la producción de artículos para perro como chaquetas, camas, correas, etc. Actualmente cuenta con tres puntos de venta en la ciudad de Bogotá D.C. que se muestran en la tabla 9. Puntos de Venta Can & Estilo Local Dirección Teléfono Bonanza Carrera 71D # 74ª Tabla 9: Puntos de Venta Can & Estilo. El local que queda ubicado en Bonanza es el punto de fábrica, y es el único que tiene esta empresa. Para la validación se habló con el gerente que se llama Juan Camilo Roa Ortiz, quien fue la persona a la que se le mostró el funcionamiento del sistema SCLOUD a partir de la parametrización de productos que se muestra en la tabla 10. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 87

90 Ingeniería de Sistemas Istar - CIS1330IS03 Parametrización de Productos de Can & Estilo Producto Materiales para Producción Mínimo de Producción Cama de Amarres Trabilla de Mosquetón (Correa) Saco con capota manga ranglan Algodón siliconado nacional de alto retorno. Lona codra nacional, unicolor. Fleece unicolor. Cariñosito (coral). Hilaza. Cremallera. Cordón trenzado de 1 pulgada. Mosquetón. Riata unicolor. Cordón unicolor de ¼ pulgadas. Agarre en espuma. Yersilon estampado. Hilo. Rib. Marquilla. 7 Pedidos 50 Pedidos 30 Pedidos Tabla 10: Parametrización de Productos de Can & Estilo. La estructura de producción por cada producto se muestran en las figuras 35, 36 y 37. Cama de Amarres Página 88

91 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Cama de Amarres Cubierta Forro Relleno Fleece Cariñosito Hilo Lona Codra Hilaza Cremallera Algodón Siliconado Figura 36: Estructura de Insumos para Cama de Amarres. Trabilla de Mosquetón (Correa) Trabilla de Mosquetón (Correa) Tratamiento Cordón Adherir Mosquetón Acabados Finales Cordón Trenzado Mosquetón Agarre Cordón Unicolor Riata Figura 37: Estructura de Insumos para Trabilla de Mosquetón (Correa). Saco con capota manga ranglan Página 89 Preparado por el Grupo Investigación Istar- Versión /03/2008

92 Ingeniería de Sistemas Istar - CIS1330IS03 Saco con capota manga ranglan Delantero Espalda Mangas Capota Rib Rib Rib Rib Yersilon Yersilon Yersilon Yersilon Hilo Hilo Hilo Hilo Figura 38: Estructura de Insumos para Saco con capota manga ranglan. Las estructuras de producción de cada uno de los productos preguntados en la empresa Can & Estilo, fueron parametrizados al sistema SCLOUD con el fin de probar cada una de las funcionalidades del mismo y así mostrar resultados de forma presencial al usuario. En el Anexo 8 puede consultar los resultados de la encuesta realizada a la empresa luego de haber enseñado el sistema en su totalidad. Can & Estilo compra su materia prima a los siguientes proveedores: Distrinsumos (proveedor de algodón), Textilería Alpopular (proveedor de Lona), e Hilaza Aguilar (proveedor de hilaza) Comparación de Procesos de Flujo de Información A continuación se muestra una comparación en tiempo de ejecución del flujo de información entre Confecciones Baker, Can & Estilo y SCLOUD (Ver el Anexo 16 para conocer la gestión de la cadena de abastecimiento de cada una de las empresas). Página 90

93 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Se puede apreciar que todas las actividades que conforman el proceso son humanas, pues no hay un sistema involucrado que automatice todas o parte de las mismas. El proceso de flujo de información proveído por SCLOUD automatiza todas las tareas del proceso usado por las pymes permitiendo un desempeño mucho mayor. En la tabla 11 se muestra los tiempos de comunicación entre cada uno de los componentes de la cadena de abastecimiento de Confecciones Baker. Tiempos de Confecciones Baker Parte de la Cadena de Abastecimiento Distribución - Producción Producción - Compras Compras - Proveedores Tiempo 1,5 horas No se contempla 24 horas Total: 25,5 horas Tabla 11: Tiempos de Cadena de Abastecimiento de Confecciones Baker. Al momento de que un cliente hace un pedido y la empresa no tiene el inventario suficiente para suplir su necesidad, se confirma el pedido y transcurre una hora y media como máximo mientras que el punto de venta donde se originó el mismo se comunica con producción. Cuando producción recibe la información del pedido tiene que reenviársela a compras (abastecimiento) pero no transcurre tiempo porque la persona encargada de este punto es la misma que se encarga de la compra de materias primas. Cuando la información llega a compras, el proceso desde este punto a la solicitud de materias primas a los proveedores es demorado porque se debe calcular la cantidad de Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 91

94 Ingeniería de Sistemas Istar - CIS1330IS03 materiales que se necesitan para suplir ese pedido y corroborarlo con el inventario actual. Si hacen falta materiales les toca comunicarse con los proveedores que en algunos momentos no están disponibles en el momento que se necesitan. Para este proceso se estima un tiempo máximo de 24 horas. El total de tiempo que se calcula para la ejecución completa del flujo de información para Confecciones Baker es de 25,5 horas. Esto indica que la solicitud de un pedido hecha por un cliente puede tardar más de un día para solo hacer que la empresa pida la materia prima necesaria para poder producir lo que el cliente necesita. Por otro lado, el cálculo de tiempos para Can & Estilo se muestra en la tabla 12. Tiempos de Can & Estilo Parte de la Cadena de Abastecimiento Distribución - Producción Producción - Compras Compras - Proveedores Tiempo 2 horas 1 hora 24 horas Total: 27 horas Tabla 12: Tiempos de Cadena de Abastecimiento de Can & Estilo. Para hacer las mediciones de tiempo del sistema SCLOUD en cada una de las partes de la cadena de abastecimiento, fue necesario hacer pedidos grandes porque de lo contrario si es un pedido pequeño el sistema lo hace en menos de 10 segundos. La medición del tiempo se muestra en la tabla 13. Página 92

95 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Tiempos de SCLOUD Funcionalidad del sistema Estimación de Fechas y Disponibilidad de Inventario Ejecución MRP Notificación a Usuarios del sistema y a Proveedores Tiempo 1 minuto 1 minuto 3 minutos Total: 5 minutos Tabla 13: Tiempos de Cadena de Abastecimiento de SCLOUD. Para la estimación del tiempo se simuló un pedido de dos productos: 150 zapatos y 150 maletas. La estimación de fechas y disponibilidad de inventario calcula para cuándo se debe tener listo el pedido, lo cual incluye fechas de producción y fechas de entrega. Este proceso se demora 1 minuto. Cuando se confirma la compra es importante actualizar la base de datos con las nuevas cantidades que quedan en inventario y la fecha de venta. Este proceso dura el mismo tiempo que el anterior. Por último, al notificar las tareas que deben hacer cada uno de los usuarios del sistema y al enviar los correos con los pedidos hechos a los diferentes proveedores dura como máximo 3 minutos. Haciendo la comparación entre los tiempos que invierten Confecciones Baker, Can & Estilo y el sistema SCLOUD en ejecutar el flujo de información, se puede apreciar que SCLOUD logra el mismo proceso en solamente 5 minutos, una gran diferencia de tiempo respecto a las pymes. De igual manera al sistema le hacen falta múltiples funcionalidades para que sea más completo y pueda ser utilizado como sistema base en las empresas de hoy en día. Algunas funcionalidades faltantes que se estimaron durante la fase de validación de SCLOUD se definen en la sección de Trabajos Futuros de la memoria del trabajo de grado. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 93

96 Ingeniería de Sistemas Istar - CIS1330IS03 IV - RESULTADOS Y REFLEXIÓN SOBRE LOS MISMOS 4.1. Fase 1: Evaluación del estado del arte Durante el desarrollo de esta fase se logró cumplir con el primer objetivo específico del trabajo que era realizar un análisis sobre el prototipo de SCLOUD y sistemas ERP actuales en el mercado, y con esto definir las funcionalidades que podrían ser parte de las extensiones de SCLOUD. Se puede corroborar el desarrollo y el cumplimiento del objetivo con el documento generado de análisis de requerimientos (Ver Anexo 1) Fase 2: Refactorización del sistema El desarrollo de esta fase no cumplió con algún objetivo específico, pero fue de gran ayuda para facilitar el diseño e implementación de las extensiones de SCLOUD, pues se logró hacer que la transaccionalidad del sistema fuera transparente para los programadores porque ahora lo maneja el contenedor de EJB del servidor de aplicaciones de JBoss 7.1. También se logró una clara separación de las múltiples capas que usa el sistema: Una de presentación (todas las interfaces de usuario las maneja Bonitasoft y no Java), una de lógica de negocio y una de datos (manejadas directamente desde las librerías Java). Todo esto permitió una separación de responsabilidades para mejorar la modificabilidad del sistema Fase 3: Selección de requerimientos factibles Durante el desarrollo de esta fase se logró cumplir con el segundo objetivo específico del trabajo que era definir un conjunto de funcionalidades factibles para la extensión del prototipo de SCLOUD. Se puede corroborar el desarrollo y el cumplimiento del objetivo con el documento que muestra el DAR generado (Ver anexo 4). Página 94

97 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica 4.4. Fases 4 y 5: Diseño e implementación del sistema Durante el desarrollo de esta fase se logró cumplir con el tercer y cuarto objetivo específico del trabajo que resumen el diseño y la implementación de componentes arquitecturales. Estos componentes están soportando todas las funcionalidades que las extensiones del sistema SCLOUD están ofreciendo actualmente. Se puede corroborar el desarrollo y cumplimiento de estos objetivos consultando el diagrama de clases y el código fuente del trabajo Fase 6: Validación del sistema El desarrollo de esta fase permitió cumplir con el quinto objetivo específico del trabajo que es validar en dos empresas pequeñas las nuevas funcionalidades implementadas para SCLOUD mediante pruebas de aceptación. Se puede corroborar el desarrollo y cumplimiento del objetivo consultando las encuestas realizadas a cada una de las empresas. (Para Confecciones Baker ver Anexo 7 y para Can & Estilo el Anexo 8). Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 95

98 Ingeniería de Sistemas Istar - CIS1330IS03 V CONCLUSIONES, RECOMENDACIONES Y TRABAJOS FUTUROS 5.1. Conclusiones Luego de todo el trabajo desarrollado durante el tiempo estipulado para el proyecto de grado, es importante responder a la pregunta de si se logró cumplir o no el objetivo principal: Extender el prototipo inicial que soporta el modelo de negocio propuesto por SCLOUD con el fin de generar una herramienta más completa para pymes. La respuesta a esta pregunta es que sí, puesto que las extensiones que fueron elegidas para el sistema SCLOUD se lograron implementar en su totalidad y se logró generar una herramienta más completa para ayudar con el flujo de información a las pymes. Por supuesto que, para lograr este objetivo, fue necesario cumplir con los objetivos específicos que se plantearon desde un inicio y se lograron con cada una de las fases que se desarrollaron en el proyecto. Una conclusión importante que se obtuvo de la fase de validación fue que hacen falta aún múltiples funcionalidades que son importantes para que una pyme pueda digitalizar su información, como el manejo de la información de empleados, módulos de ventas, de contabilidad, etc. Estas retroalimentaciones se tienen en cuenta en la sección de trabajos futuros de este documento. Aunque hayan faltado ciertas características en el sistema, las funcionalidades implementadas son de gran utilidad ya que el tiempo empleado para cumplir con el flujo de información para los pedidos realizados por un cliente mejora bastante respecto al sistema no digitalizado que usan hoy en día. La facilidad de uso del sistema y las funcionalidades implementadas en el mismo hacen que se evidencie un aporte significativo para las pymes, según los resultados de las encuestas aplicadas a Confecciones Baker y a Can & Estilo al final de la demostración del sistema SCLOUD. Página 96

99 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica 5.2. Recomendaciones Para lograr iniciar una instancia de trabajo de grado tomando como referencia la problemática que trata este, es importante que los requerimientos que se levanten sean por medio de entrevistas realizadas a diferentes pymes; de esta forma se logra un mayor grado de satisfacción por parte de ellas con el sistema SCLOUD, ya que el levantamiento de requerimientos en este trabajo se llevó a cabo por una investigación de características funcionales de otros sistemas. Otra recomendación importante es que como toda la lógica de negocio se implementó en librerías de Java, es posible hacer una migración del sistema de Bonitasoft 5.8 a la última versión que, a la fecha de publicación de este trabajo de grado, es la Entonces es cuestión de rehacer los modelos de negocio en la nueva versión de Bonita y relacionarlos con las librerías que se proveen en este trabajo. Para comparar el tipo de metodología que se podría seguir en un trabajo futuro con la que se usó para desarrollar este proyecto, se puede consultar el Post-Mortem del mismo (Ver Anexo 11) Trabajos Futuros Las ideas que se brindan para trabajos futuros fueron obtenidas de la fase de validación de este proyecto de grado, y son las siguientes: Módulo de Ventas: Una idea muy importante es la implementación de un módulo de ventas de tal forma que una pyme pueda guardar la información de las mismas. Según las necesidades de Confecciones Baker, el desarrollo de este módulo se debería hacer por punto de venta para que se pueda mantener la información separada y organizada. Página 97 Preparado por el Grupo Investigación Istar- Versión /03/2008

100 Ingeniería de Sistemas Istar - CIS1330IS03 Módulo de Reportes: De nada sirve guardar las ventas por punto de distribución de una pyme si no se puede extraer conocimiento de la información que se guarda. Los reportes serían de gran utilidad para saber el total de ingresos que se han obtenido por punto de venta, y tomar decisiones importantes para la empresa como por ejemplo, si durante 3 años las ventas en un local fueron menores a cierto valor establecido por la pyme, se podría tomar la decisión de cerrarlo. También debería sacar reportes con los ingresos totales de todos los puntos de venta para otro tipo de decisiones. Gestión avanzada de Inventarios: Usualmente las pymes manejan bodegas de inventarios, y esto hace que el manejo de los mismos deba ser un poco más avanzado en el sistema, pues el hecho de crear una nueva tabla que indique las bodegas actuales que tiene una pyme y el direccionamiento de los productos que tiene la empresa en alguna de sus bodegas, ya hace crecer más el sistema y lo hace más robusto en cuanto a la organización de la información. Interfaz de Usuario para relacionar la estructura de un producto a la venta y el producto en sí: Actualmente el sistema SCLOUD crea un producto que vende una pyme, y además crea los insumos por los cuales está compuesto ese producto. Lo que no se ha implementado aún es la relación que hay entre el producto y sus insumos, y esto es muy importante para el MRP del sistema. Es importante que la interfaz que se genere deba ser lo más sencilla y entendible posible para el usuario. Multitenant sin restricciones: Actualmente la arquitectura multitenant por la cual se está rigiendo el sistema funciona mediante la ejecución de diferentes instancias de JBoss (que es el servidor de aplicaciones que contiene los procesos de bonita). El problema es que, cada instancia que se ejecuta utiliza un conjunto de puertos de comunicación del servidor, y estos son muy complicados de cambiar porque hay que modificar varios archivos del servidor, lo que hace que crear una nueva pyme sea complejo. Para una próxima instancia de trabajo de grado que tome esta problemática se debe rediseñar esta idea para que se puedan ejecutar múltiples pymes al tiempo sin restricciones. Página 98

101 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica SCLOUD para otros tipos de pymes: Actualmente el funcionamiento de SCLOUD solo está para pymes manufactureras. En un futuro sería bueno implementar el sistema para todos los tipos de pequeñas y medianas empresas que existan. Integración del Proveedor a SCLOUD: Es importante que se integre un rol proveedor en el sistema SCLOUD, pues actualmente solo se les notifica las materias primas necesarias por medio de correos electrónicos. Página 99 Preparado por el Grupo Investigación Istar- Versión /03/2008

102 Ingeniería de Sistemas Istar - CIS1330IS03 VI - REFERENCIAS Y BIBLIOGRAFÍA 6.1. Referencias [1] Blog de WordPress, Qué es cadena de abastecimiento (SCM)? [Página Web], 2008, Disponible en: [2] Empresas Colombianas que aplican ERP en sus páginas web [Página Web]. Disponible en línea: [3] RUIZ, Camilo, MÉNDEZ, Camilo, SCLOUD: Modelo del flujo de pedido de la cadena de suministro para pymes Colombianas e interpretación para la nube. Pontificia Universidad Javeriana, Colombia, [4] Comisión Europea, Pequeñas y medianas empresas (pyme) Qué es una pyme? [Página Web], Disponible en: [5] 10 Programas ERP software Libre y gratis para pymes [Página Web]. Disponible en línea: [6] Epicor, Administración de la Cadena de Suministro [Página Web], Disponible en: [7] Supply Nexus, Soluciones para Pymes [Página Web], Disponible en: [8] SAP, Gestión de la Cadena de Suministro: SCM [Página Web], Disponible en: [9] Supply Chain Council, What is SCOR? [Página Web], Disponible en: [10] El Corte Inglés, El Proceso de Pedidos [Página Web], Disponible en: ocument Página 100

103 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica [11] Metodologías ágiles en el desarrollo de software. [Página Web], Disponible en: [12] Bonita Open Solution [Página Web]. Disponible en línea: [13] Java EE at Glance [Página Web]. Disponible en línea: [14] Pippal, S.; Sharma, V.; Mishra, S.; Kushwaha, D.S., "An Efficient Schema Shared Approach for Cloud Based Multitenant Database with Authentication and Authorization Framework," P2P, Parallel, Grid, Cloud and Internet Computing (3PGCIC), 2011 International Conference on, vol., no., pp.213,218, Oct [15] SCM GESTION DE LA CADENA DE SUMINISTRO [Página Web]. Disponible [16] BALLOU, Donald H. Logística. Administración de la cadena de suministros. 5 ed. México: Prentice Hall [17] Ventajas y Desventajas de la Gestion Integral de Suministros [Pagina Web]. Disponible en linea: [18] What is MRP and how can it help my business? [Página Web]. Disponible en línea: [19] Desarrollo del MRP [Página Web]. Disponible en: [20] Enterprise Resource Planning [Página Web]. Disponible en línea: [21] ENTERPRISE RESOURCE PLANNING [Pagina Web]. Disponible en línea: [22] Factory el software industrial [Página Web]. Disponible en línea: [23] Siigo [Página Web]. Disponible en línea: Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 101

104 Ingeniería de Sistemas Istar - CIS1330IS03 [24] Adempiere [Página Web]. Disponible en línea: [25] Oasis [Página Web]. Disponible en línea: [26] Doing Business in Russia: ERP market overview [Página Web]. Disponible en: gle.com.co/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ved=0cei- QFjAB&url=http%3A%2F%2Fwww.ipoboard.ru%2Ffiles%2Fcompanies%2Fpublic%2Febf87f30a466698a399dffc273e77193&ei=Vyd2UZ_qNYjl0gHdsoDwAw&u sg=afqjcnefovm1rzf7ls0_xi_z2izyazbwqg&bvm=bv ,d.dmq [27] EPICOR Business Inspired [Página Web]. Disponible en línea: c&utm_campaign=co_- _EPIC_ERP_ES&utm_term=erp&utm_content=covepi25p5787 [28] Open ERP [Página Web]. Disponible en: [29] software ERP [Página Web]. Disponible en: [30] JAPANESE COMPANIES AND ERP: A STUDY ON INFORMATION TECHNOLOGY AND MANEGERIAL [Página Web]. Disponible en: [31] Site original da comunidade da Localização Brasileira do OpenERP [Página Web]. Disponible en línea: [32] Sistemas de Información Integrados (ERP) [Página Web]. Disponible en: [33] Logility [Página Web]. Disponible en línea: [34] JDA [Página Web]. Disponible en línea: Página 102

105 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica [35] Advanced Planning [Página Web]. Disponible en línea: [36] SAP-SCM [Página Web]. Disponible en línea: [37] sistema Gestión pedidos de cliente [Página Web]. Disponible en [38] Flor Nancy Díaz Piraquive. Gestión de procesos de negocio BPM (Business Process Management), TICs y crecimiento empresarial Qué es BPM y cómo se articula con el crecimiento empresarial?. Disponible en: [39] Club-BPM. BPM Business Process Management Gestión de Procesos de Negocio Disponible en [40] Bizagi. Bizagi BPMN 2.0. Disponible en [41] Hernán Barrios Verdugo, Cristián Lucero Fuentes Arturo Veras Olivos. Computación en la nube. Disponible en: [42] Francisco Rueda F. Qué es la computación en la nube?. Disponible en [43] THE TOOLS TO MANAGE YOUR BUSINESS [Página Web]. Disponible en: [44] Order Management System Ability OMS [Página Web]. Disponible en: [45] Order Management System [Página Web]. Disponible en: [46] Enterprise JavaBeans Technology [Página Web]. Disponible en: Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 103

106 Ingeniería de Sistemas Istar - CIS1330IS03 [47] Implementing a Remote Interface [Página Web]. Disponible en: [48] JBoss Application Server 7 [Página Web]. Disponible en: [49] Modelo Entidad Relación: Q.E.P.D.: La persistencia en los nuevos frameworks [Página Web]. Disponible en: [50] FRANKY, María; TORO, Victor; Toma de decisiones en la empresa sobre Tecnologías de Información. [51] CERVERA, Angel; NÚÑEZ, Bernando; El modelo de mccall como aplicación de la calidad a la revisión del software de gestión empresarial ; Universidad Cádiz. [52] Introducción Ágil a extreme Programming [Página Web]. Disponible en: [53] Tema 1: Introducción a los servidores de aplicaciones [Página Web]. Disponible en: apuntes.htm Página 104

107 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica VII - ANEXOS I. Anexo 1 Análisis de requerimientos v4.0: En este anexo se muestran todos los requerimientos que fueron levantados durante la primera fase del trabajo de grado que fue el estado del arte. II. Anexo 2 SCLOUD Architecture: Este anexo es una imagen que muestra la arquitectura de SCLOUD después de la refactorización que se hizo del sistema. III. Anexo 3 SCLOUD Architecture Multitenant: Este anexo es una imagen que muestra la arquitectura de SCLOUD con Multitenant después de la refactorización que se hizo del sistema. IV. Anexo 4 DAR requerimientos v6.0: En este anexo se muestran los criterios que se usaron para elegir las extensiones a diseñar e implementar en el sistema SCLOUD, y las calificaciones definitivas para cada requerimiento especificado en la fase del estado del arte. V. Anexo 5 SCLOUD Manual de Mantenimiento v2.0: Este anexo es el manual de mantenimiento que contiene la información completa del diseño e implementación de cada una de las extensiones que ahora hacen parte del sistema SCLOUD. VI. Anexo 6 - Flujo de información cadena de abastecimiento 8.0: Este anexo es una imagen que muestra el proceso completo del flujo de información para una cadena de abastecimiento. VII. Anexo 7 Encuesta Confecciones Baker: Este anexo es un comprimido (.rar) que contiene las imágenes que representan la encuesta que fue aplicada a la empresa Confecciones Baker como parte del proceso de validación. VIII. Anexo 8 Encuesta Can & Estilo: Este anexo es un comprimido (.rar) que contiene las imágenes que representan la encuesta que fue aplicada a la empresa Can & Estilo como parte del proceso de validación. IX. Anexo 9 Diagrama de Clases v1.0: Este anexo es un documento que muestra la definición y la estructura de cada una de las clases diseñadas para el sistema SCLOUD. X. Anexo 10 Diagrama de Clases: Este anexo es una imagen que muestra el diagrama de clases del sistema SCLOUD. XI. Anexo 11 Post-Mortem: Este anexo es un documento en donde se compara lo escrito en la propuesta del trabajo de grado versu Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 105

108 Ingeniería de Sistemas Istar - CIS1330IS03 XII. XIII. XIV. XV. XVI. XVII. XVIII. XIX. Anexo 12 Actas de Reunión SCLOUD: Este anexo es un comprimido (.rar) que contiene todas las actas que demuestran las reuniones hechas entre los desarrolladores, la directora y la asesora del trabajo de grado. Anexo 13 SCLOUD Manual de Usuario v1.0: Este anexo es el documento que muestra al usuario las nuevas funcionalidades de SCLOUD y cómo debe usarlas. Anexo 14 SCLOUD Manual de Instalación v4.0: Este anexo es el manual de instalación que contiene todos los pasos para crear una copia limpia del sistema SCLOUD. Anexo 15 Glosario: Este anexo es un documento en donde se definen diferentes conceptos que son necesarios comprenderlos para entender este trabajo de grado. Anexo 16 Gestión Cadenas de Abastecimiento v1.0: Este anexo es el documento que muestra los flujos de información y de pedido que llevan a cabo las empresas Confecciones Baker y Can & Estilo. Anexo 17 SCLOUD Documento de Pruebas v1.0: Este anexo es el documento que muestra las pruebas realizadas para comprobar la correcta funcionalidad del sistema SCLOUD. Anexo 18 SCLOUD Carta de Confidencialidad: Este anexo es una carta que especifica la responsabilidad por parte de los desarrolladores del trabajo de grado, con las próximas personas que se encarguen de una instancia del mismo. Anexo 19 HACER-USOS: Este anexo es un documento que especifica de manera concreta cada uno de los requerimientos candidatos para ser parte de las extensiones de SCLOUD. Página 106

109 Pontificia Universidad Javeriana Anexo 1 Memoria de Trabajo de Grado Aplicación Práctica PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA EXTENSIÓN DEL SISTEMA SCLOUD PARA MANEJAR EN LA NUBE EL FLUJO DE PEDIDO DE LA CADENA DE SUMINISTRO DE PYMES 11 de Octubre de 2013 Trabajo de Grado Ingeniería de Sistemas ANÁLISIS DE REQUERIMIENTOS Versión del Documento: 4.0 El presente documento especifica los posibles requerimientos para SCLOUD, los cuales son recolectados a partir del trabajo de grado anterior, y del análisis de las diferentes funcionalidades que ofrecen las diferentes ERP. 1. REQUERIMIENTOS FUNCIONALES REQF-001: SCLOUD debe permitir la gestión de inventarios para PYMEs. REQF-002: SCLOUD debe permitir a una PYME hacer pedidos de productos por lotes a un proveedor. REQF-003: SCLOUD debe permitir que una PYME pueda seleccionar un proveedor para el pedido que desee realizar. REQF-004: SCLOUD debe implementar un módulo de contabilidad básico que permita persistir los ingresos y los gastos de una PYME. REQF-005: SCLOUD debe permitir la generación de reportes contables para analizar el estado de ingresos y egresos de una PYME. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 107

110 Ingeniería de Sistemas Istar - CIS1330IS03 REQF-006: SCLOUD debe implementar un módulo de estadística que permita a un proveedor determinar si un pedido hecho por una PYME puede realizarse o no, según pedidos históricos. REQF-007: SCLOUD debe permitir a una PYME asociarse con múltiples proveedores. REQF-008: SCLOUD debe permitir a una PYME eliminar un cliente. REQF-009: SCLOUD debe permitir la creación de un distribuidor. REQF-010: SCLOUD debe permitir la autenticación de un distribuidor. REQF-011: SCLOUD debe permitir la creación de un productor. REQF-012: SCLOUD debe permitir la autenticación de un productor. REQF-013: SCLOUD debe permitir a una PYME la adición de bodegas contenedoras de productos. REQF-014: SCLOUD debe permitir a una PYME la eliminación de bodegas contenedoras de productos. REQF-015: SCLOUD debe permitir a una PYME la edición de productos que contiene una bodega. REQF-016: SCLOUD debe permitir la persistencia de empleados que trabajan en una PYME. REQF-017: SCLOUD debe permitir la eliminación de empleados de una PYME. REQF-018: SCLOUD debe contar con un histórico de ventas para gestionar la interacción con los clientes de la PYME. REQF-019: SCLOUD debe permitir dar una descripción a los productos ( Datos maestros del producto ). Página 108

111 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica REQF-020: SCLOUD debe mostrar información histórica de los productos (cuando fue vendido, cantidad, si estuvo en promoción, agotados). REQF-021: SCLOUD debe permitir que un cliente se asocie con múltiples PYMEs. REQF-022: SCLOUD debe permitir poner propiedades a los productos, por ejemplo si un producto se encuentra en promoción. REQF-023: SCLOUD debe implementar un calendario parametrizable por la PYME, indicando qué días son laborables. REQF-024: SCLOUD debe permitir parametrizar a una PYME un tiempo de espera por pedido hecho por un cliente. REQF-025: SCLOUD debe permitir conjuntar las órdenes de un mismo producto solicitadas por diferentes clientes. REQF-026: SCLOUD debe implementar un sistema BRMS (Business Rule Management System) para controlar decisiones complejas de negocio. REQF-027: SCLOUD debe implementar una interfaz web que informe a una PYME del sistema de manera rápida el estado de su inventario. 2. REQUERIMIENTOS NO FUNCIONALES REQUERIMIENTOS DE RENDIMIENTO o REQNF-RENDIMIENTO-028: SCLOUD debe implementar algoritmos que permitan realizar consultas eficientes a la base de datos. REQUERIMIENTOS DE DISPONIBILIDAD o REQNF-DISPONIBILIDAD-029: SCLOUD debe estar disponible las 24 horas del día para todo tipo de usuario mediante clúster. REQUERIMIENTOS DE OPERATIVIDAD o REQNF-OPERATIVIDAD-030: SCLOUD debe persistir los datos de los usuarios en una base de datos Postgres. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 109

112 Ingeniería de Sistemas Istar - CIS1330IS03 o REQNF-OPERATIVIDAD-031: SCLOUD debe ser instalado y ejecutado en los servidores de la Pontificia Universidad Javeriana sede Bogotá. o REQNF-OPERATIVIDAD-032: SCLOUD debe funcionar en una máquina virtual en ambiente Linux. o REQNF-OPERATIVIDAD-033: Se deben generar Session Beans remotos que ofrezcan los servicios que tiene SCLOUD. 3. Tabla resumen: La siguiente tabla recolecta todos los requerimientos encontrados, los cuales se clasificarán según su funcionalidad: Operativa si modifica el flujo, o simplemente de análisis. Tambien se mostrará de cual ERP fue encontrado este requerimiento. Página 110

113 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Preparado Reque- por el Grupo Descripción Investigación Istar- Versión 1.01 Fun- 12/03/2008 Fun- Origen del Página 111

114 Ingeniería de Sistemas rimiento 1 SCLOUD debe permitir la gestión de inventarios para PY- MEs. 2 SCLOUD debe permitir a una PYME hacer pedidos de productos por lotes a un proveedor. 3 SCLOUD debe permitir que una PYME pueda seleccionar un proveedor para el pedido que desee realizar. 4 SCLOUD debe implementar un módulo de contabilidad básico que permita persistir los ingresos y los gastos de una PYME. 5 SCLOUD debe permitir la generación de reportes contables para analizar el estado de ingresos y egresos de una PYME. 6 SCLOUD debe implementar un módulo de estadística que permita a un proveedor determinar si un pedido hecho por una PYME puede realizarse o no, según pedidos históricos. Requerimientos Funcionales x x x x x x Istar - CIS1330IS03 cionalidad de análisis? cionalidad Operativa? requerimiento Tesis de Grado Camilo Ruiz y Camilo Méndez. Tesis de Grado Camilo Ruiz y Camilo Méndez. Tesis de Grado Camilo Ruiz y Camilo Méndez. SAP. SAP. ERP5. Página 112

115 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica 7 Preparado por el Grupo SCLOUD Investigación debe Istar- per- Versión 1.01 x 12/03/2008 ERP5. Página 113

116 Ingeniería de Sistemas Istar - CIS1330IS03 mitir a una PYME asociarse con múltiples proveedores. 8 SCLOUD debe permitir a una PYME eliminar un cliente. 9 SCLOUD debe permitir la creación de un distribuidor. 10 SCLOUD debe permitir la autenticación de un distribuidor. 11 SCLOUD debe permitir la creación de un productor. 12 SCLOUD debe permitir la autenticación de un productor. 13 SCLOUD debe permitir a una PYME la adición de bodegas contenedoras de productos. 14 SCLOUD debe permitir a una PYME la eliminación de bodegas contenedoras de productos. 15 SCLOUD debe permitir a una PYME la edición de productos que contiene una bodega. 16 SCLOUD debe permitir la persistencia de empleados que trabajan en una PYME. 17 SCLOUD debe permitir la eliminación de empleados de una PYME. 18 SCLOUD debe contar con un histórico x x x x x x x x x x x Investigación ERP. Investigación ERP. Investigación ERP. Investigación ERP. Investigación ERP. OpenERP. OpenERP. Open- Bravo. Open- Bravo. SAP. SAP. Página 114

117 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Preparado por el Grupo de ventas Investigación para ges- Istar- Versión /03/2008 Página 115

118 Ingeniería de Sistemas Istar - CIS1330IS03 x x x x x x x tionar la interacción con los clientes de la PYME. 19 SCLOUD debe permitir dar una descripción a los productos ( Datos maestros del producto ). 20 SCLOUD debe mostrar información histórica de los productos (cuando fue vendido, cantidad, si estuvo en promoción, agotados). 21 SCLOUD debe permitir que un cliente se asocie con múltiples PYMEs. 22 SCLOUD debe permitir poner propiedades a los productos, por ejemplo si un producto se encuentra en promoción. 23 SCLOUD debe implementar un calendario parametrizable por la PYME, indicando qué días son laborables. 24 SCLOUD debe permitir parametrizar a una PYME un tiempo de espera por pedido hecho por un cliente. 25 SCLOUD debe permitir conjuntar las órdenes de un mismo producto solicitadas por diferentes clientes. 26 SCLOUD debe implementar un sistema BRMS (Busix SAP. SAP. SAP. SAP. Tesis de Grado Camilo Ruiz y Camilo Méndez. Tesis de Grado Camilo Ruiz y Camilo Méndez. Tesis de Grado Camilo Ruiz y Camilo Méndez. Tesis de Grado Camilo Ruiz y Página 116

119 Pontificia Universidad Javeriana ness Rule Management System) para controlar decisiones complejas de negocio. 27 SCLOUD debe implementar x una inter- faz web que informe a una PYME del sistema de manera rápida el estado de su inventario. Requerimientos No Funcionales Memoria de Trabajo de Grado Aplicación Práctica Camilo Méndez. Tesis de Grado Camilo Ruiz y Camilo Méndez. 28 SCLOUD debe implementar algoritmos que permitan realizar consultas eficientes a la base de datos. 29 SCLOUD debe estar disponible las 24 horas del día para todo tipo de usuario mediante clúster. 30 SCLOUD debe persistir los datos de los usuarios en una base de datos Postgres. 31 SCLOUD debe ser instalado y ejecutado en los servidores de la Pontificia Universidad Javeriana sede Bogotá. 32 SCLOUD debe funcionar en una máquina virtual en ambiente Linux. 33 Se deben generar Session Beans remotos que ofrezcan los servicios que tiene SCLOUD. x x x x x x Investigación ERP. Investigación ERP. Investigación ERP. Investigación ERP. Investigación ERP. Tesis de Grado Camilo Ruiz y Camilo Méndez. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 117

120 Ingeniería de Sistemas Istar - CIS1330IS03 Anexo 2 Página 118

121 Pontificia Universidad Javeriana Anexo 3 Memoria de Trabajo de Grado Aplicación Práctica Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 119

122 Ingeniería de Sistemas Istar - CIS1330IS03 Anexo 4 Comparación de Alternativas 5: Totalmente de acuerdo. 1:Totalmente en desacuerdo. PesoGrupo Correctitud 20% Trazabilidad Completitud Subtotal Usabilidad 20% Operabilidad (poca exigencia de usuario) Poco entrenamiento de Usuario Subtotal Eficiencia 20% Eficiencia de Ejecución Eficiencia de Almacenamiento Subtotal Mantenibilidad 10% Alta Modularidad Bajo Acoplamiento Subtotal Funcionalidad 30% Adecuación cobertura de roles (actual) Indispensable para el Sistema Subtotal Calificación ponderada de cada asesor: TOTALES 100% Criterios La calificación de cada criterio va de 1 a 5, siendo 1 el menor nivel Página 120

123 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Anexo 5 MANUAL DE MANTENIMIENTO Elaborado por: Pablo Sebastián Páez Mateus Andrés Felipe Pedraza Infante. Versión del Documento: 3.0 El presente documento explica los procesos BPM de SCLOUD y sus integraciones con Java EE 6. En el momento SCLOUD cuenta con 10 procesos, los cuales se encuentran desarrollados en BonitaSoft 5.8, estos son: Flujo_de_Información_Cadena_de_Abastecimiento--8.0.bar Proceso_MRP--3.1.bar Notificar_Pyme_por_MRP--1.0.bar Notificar_a_Proveedores--1.0.bar Agregar_Datos_Maestros 1.0.bar Agregar_nuevo_Proveedor--1.0.bar Seleccionar_Proveedor_por_defecto--1.0.bar Borrar_Cliente--1.0.bar Activar_MRP_Automatico--1.0.bar Calendario Parametrizable 1.0.bar A continuación se explicará la funcionalidad de cada uno de estos, y como se integran con java: Flujo de Información Cadena de Abastecimiento En este proceso es donde se encuentra tanto el flujo de información para el cliente como el flujo para la PYME. La interacción del proceso inicia con la identificación del cliente, en donde si el cliente es nuevo tiene la posibilidad de registrarse por medio de datos personales básicos, en el caso que el cliente ya esté registrado, el sistema automáticamente busca los productos asociados a la PYME donde el cliente está haciendo la solicitud y de esta forma el cliente puede seleccionar los productos que conformarán su solicitud, el siguiente fragmento del proceso Hacer_un_Pedido muestra solamente la parte de registrar un nuevo cliente. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 121

124 Ingeniería de Sistemas Istar - CIS1330IS03 1 Agregar Cliente Para el caso en cuando el cliente se encuentra registrado el proceso es el siguiente: Página 122

125 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Luego de esto el sistema guarda la solicitud del cliente y estima una posible fecha de entrega, de la siguiente manera: Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 123

126 Ingeniería de Sistemas Istar - CIS1330IS03 Una vez el sistema termina, notifica al cliente vía la solicitud actual y de esta forma el sistema queda en espera de la confirmación final del cliente: Página 124

127 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica De esta forma si el cliente no acepta los parámetros de entrega, o se agota el tiempo de solicitud del pedido, el proceso finalizará: Pero en caso contrario, es decir cuando el cliente acepte los parámetros de la compra, el sistema evaluará si no se han cambiado los parámetros de entrega y valor del pedido del cliente con el fin de poder continuar con las notificaciones a cada uno de los roles de la PYME que tienen Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 125

128 Ingeniería de Sistemas Istar - CIS1330IS03 una interacción humana como lo son (Distribución, Producción y Aprovisionamiento), donde se informan los datos necesarios para que cada uno de ellos pueden continuar posteriormente con el flujo de producto, donde se hace la transformación de las materias y se hace la entrega al cliente, el cual no es contemplado en el diseño del proceso de SCLOUD. Página 126

129 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Página 127

130 Ingeniería de Sistemas Istar - CIS1330IS03 En caso contrario en donde los parámetros de fecha de entrega y total del pedido del cliente tengan modificaciones el cliente será notificado nuevamente a cliente con el fin de informar que no se puede continuar con los parámetros iniciales, de tal forma que el cliente tendría que modificar, cancelar o aceptar su solicitud bajo los nuevos parámetros de entrega. a) Hacer un Pedido Este proceso cuenta con el rol cliente el cual radica la solicitud de compra inicial. Página 128

131 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Página 129

132 Ingeniería de Sistemas Istar - CIS1330IS03 DEFINICIÓN DE TAREAS Indentify Client: El objetivo de esta tarea es por medio de la identificación del cliente (Número de identificación personal o NIT) asociar desde el principio todo el proceso al cliente en cuestión. Register New Customer: En el caso de que el cliente no este registrado esta actividad permite el registro del cliente Make CustomerRequest: Esta actividad permite realizar la solicitud de compra por parte del cliente. AcceptQuoteParameter: Esta actividad permite confirmar con el cliente los parámetros establecidos por la PYME. Final Customer Notification: Esta actividad permite al usuario del rol Drive informar al cliente que la solicitud de compra ya se procesó con los parámetros de aceptación. Final Customer Request: Esta actividad termina el proceso cuando al cliente se le ha terminado el tiempo de espera para aceptar un pedido. b) Procesar un Pedido El proceso definido en la PYME está compuesto por cuatro roles (Distribución, Producción, Abastecimiento y Sistema) los cuales tiene el mismo significado estipulado en el modelo MACA, sin embargo el rol del sistema no es contemplado y es el encargado de ejecutar todas aquellas tareas automáticas que tiene el proceso definido. Página 130

133 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Página 131

134 Ingeniería de Sistemas Istar - CIS1330IS03 Página 132

135 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica TAREAS RELACIONADAS CON EL ROL DE DISTRIBUCIÓN Authorize Customer: Luego que el cliente es registrado, ésta tiene que ser autorizado por un usuario dentro del rol de distribución. TAREAS RELACIONADAS CON EL ROL DEL SISTEMA Find Customer: Esta actividad está encargada de verificar la existencia de un cliente. Sus conectores son: Get Customer Information: Script que se conecta a java mediante el método List<String> getcustomerinformation(string customeridentification, long pymeidentification), el cual busca un cliente. Assing Customer Variable: Script que asigna datos a las variables del pool de acuerdo a la información traída por el anterior script. Find Product List: Esta actividad está encargada de consultar los productos asociadas a la PYME. Sus conectores son: Get Products Information: Script que se conecta con java por medio del método List<List<String>> getproductsinformation(long pymeidentification, int tosell), el cual busca la información de los productos que la PYME vende. Save Customer Request: Esta actividad es la encargada de almacenar la solicitud del cliente. Sus conectores son: Get Id Request: Script que se conecta con java por medio del método long getidrequest (String customeridentification,long pymeidentification), el cual guarda la orden de un cliente, y retorna el identificador de esa orden. Save Request Customer Script: Se conceta con java mediante el metodo double getquoteprice (long idrequest, ArrayList<ArrayList<Object>> customerrecuest ), el cuál retorna el valor de la orden hecha por un cliente de la PYME. Notify Quote to Customer: Esta actividad es la encargada de notificar vía al cliente la solicitud realizada por él. Sus conectores son: Find Pyme Information2: Script encargado de buscr el de la pyme a través del siguiente método: List<String> get pyme (long pymeidentification); Asign Pyme Information 2: Asigna el encontrado con el anterior script a una variable del pool. Send Quote to Customer: Concetor que envía un correo al cliente. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 133

136 Ingeniería de Sistemas Istar - CIS1330IS03 Estimate a Possible Deliver Date: Esta actividad es la encargada de estimar una fecha de entrega bajo la lógica del MRP. Sus conectores son: Exec MRP Connector: Script que realiza la estimación del pedido a traves del método List<List<String>>getCustomerPlan (ArrayList<ArrayList<Object>> customerrecuest, long pymeidentication), para después invocar el método Date getdatedeliver (List<List<String>> customer- Plan), y a si hallar la fecha de estimación. Get Products Information on Accept: Script que se conecta con java por medio del método List<List<String>> getproductsinformation(long pymeidentification, int tosell), el cual busca la información de los productos que la PYME vende. Verify Date: Esta actividad es la encargada de comprobar que no se haya agotado el tiempo de espera de un pedido. Sus conectores son: verify Date: Script que verifica si el tiempo de espera de un pedido se ha vencido, esto lo hace a través del método boolean verifydate (long idrequest); Notify Final Customer Request: Esta actividad es la encargada de notificar vía la información de la solicitud de compra del cliente confirmando que la solicitud ya está en proceso. Sus conectores son: Find Pyme Information3: Script encargado de buscr el de la pyme a través del siguiente método: List<String> get pyme (long pymeidentification); Asign Pyme Information3: Asigna el encontrado con el anterior script a una variable del pool. Send Quote to Customer: Concetor que envía un correo al cliente. Create Production Batches: Esta Actividad se encarga de procesar el pedido de un cliente, y trasformrlo en lotes para el rol de producción. Sus conectores son: Add production order: Script encargado de realizar los lotes de producción a traes del siguiente método: List<List<String>> addproduction- ListOrders(ArrayList<ArrayList<Object>> customerrequest); Pyme MRP Notifications: Este subproceso se encarga de realizar el MRP, y enviar las notificaciones los demás roles (distribución, producción y abasteciemiento). Save Customer Purchase: Esta actividad es la encargada de almacenar la solicitud final del cliente como compra. Sus conectores son: Save Customer Purchase: Script que guarda la venta realizada por la PYME por medio del método void savecustomerpurchase(string customeridentification,long pymeidentification,double total,date date, ArrayList<ArrayList<Object>> customerrequest). Página 134

137 Pontificia Universidad Javeriana Proceso_MRP Memoria de Trabajo de Grado Aplicación Práctica El proceso del MRP es el encargado de ejecutar la lógica desarrollada en los módulos de Java. 2: MRP Process DEFINICIÓN DE TAREAS Call MRP Component: Esta actividad es la encargada de hacer la conexión por medio de conectores Java a la lógica desarrollada en el modelo MRP. Sus conectores son: Exec MRP Process Connector: Script que conecta con java a traves del método MasterPlan createproductsplan(arraylist<arraylist<object>> customerrequests, long pymeidentification, long requestid), y realiza todo el MRP GetProductionInformation: Esta actividad es la encargada de transformar los datos de tal forma que queden listos para ser mostrados en la notificación de producción. Sus conectores son: A partir del Master Plan guarda el plan de producción GetSupplyInformation: Esta actividad es la encargada de transformar los datos de tal forma que queden listos para ser mostrados en la notificación de aprovisionamiento. Sus conectores son: A partir del Master Plan guarda el plan de abastecimiento. GetDistributionInformation: Esta actividad es la encargada de transformar los datos de tal forma que queden listos para ser mostrados en la notificación de distribución. Sus conectores son: A partir del Master Plan guarda el plan de Distribución Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 135

138 Ingeniería de Sistemas Istar - CIS1330IS03 Notificar Pyme por MRP Este proceso es el encargado de ejecutar el MRP, y de realizar las respectivas notificaciones a los diferentes roles de la PYME. El diagrama BPM es el siguiente: Página 136

139 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Página 137

140 Ingeniería de Sistemas Istar - CIS1330IS03 Este proceso solamente se inicia cuando el Flujo de Información Cadena de Abastecimiento llama a la actividad Pyme MRP Notification, una vez esta es llamada se ejecuta el MRP, para luego notificar a los roles de la PYME. En dado caso que se tenga que hacer una notificación a producción, este proceso calculara los lotes que se hayan creado en producción para la fabricación de un producto. Por ultimo si se necesita hacer una compra a proveedores el sistema utilizara otro proceso encargado de notificar estas compras por medio de correo electrónico. TAREAS RELACIONADAS CON EL ROL DE DISTRIBUCIÓN Notify Customer Request Distribution: Esta actividad permite a distribución enterarse de la solicitud del cliente e informase de cuánto tiene que esperar de producción y cuanto de inventario con el fin de cumplir con la entrega posterior al cliente. TAREAS RELACIONADAS CON EL ROL DE PRODUCCIÓN Notify Customer Request Production: Esta actividad permite a producción enterarse de los productos que debe fabricar y la transformación de las materias primas que debe realizar. TAREAS RELACIONADAS CON EL ROL DE APROVISIONAMIENTO Notify Customer Request Source: Esta actividad permite a aprovisionamiento enterarse de las materias primas que deben ser solicitadas a los proveedores con el fin de suministrarle a producción los insumos necesarios para la fabricación de los productos. TAREAS RELACIONADAS CON EL ROL DE SISTEMA MRP Process: Este subproceso es el encargado de utilizar la lógica desarrollada en el módulo MRP. Mapping variables MRP: Esta actividad es la encargada de transformar todos los datos retornados por el MRP con el fin de que cada rol sea informado con la información que le corresponde. Sus conectores son: Find Pyme Information4: Script encargado de buscr el de la pyme a través del siguiente método: List<String> get pyme (long pymeidentification); Página 138

141 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Asign Pyme Information4: Asigna el encontrado con el anterior script a una variable del pool. Esta actividad posee otros tipos de conectores encargados de tomar las variables que son retornadas por el subproceso MRP y guardarlas en el pool. Notify Suppliers: Este subproceso es el encargado de notificar a cada uno de los proveedores de las materias que se necesitan para satisfacer el pedido del cliente. Notificar a Proveedores: Este proceso es el encargado de realizar las respectivas notificaciones cuando la pyme necesite hacer una compra a una determinado proveedor. El diagrama BPM es el siguiente: Este proceso inicia cuando Notificar por MRP ejecute la actividad de notify Suppiers, a partir de esto se seleccionaran los proveedores que la pyme tiene elegidos como favoritos, los conjuntará y enviara a cada uno un respectivo correo notificando cual es la compra que la PYME desea realizar. TAREAS RELACIONADAS CON EL ROL DE SISTEMA Combine Suppliers Orders: Esta actividad es la encargada de seleccionar los proveedores que la pyme haya elegido por defecto. Sus conectores son: Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 139

142 Ingeniería de Sistemas Istar - CIS1330IS03 Combine Supply Order: Script encargado de buscar los proveedores favoritos elegidos por la pyme, esto lo hace a traves del método: List<List<Order>> combinesuppliersorder(list<order> sourcelist ); Set Supplier Orders: Esta actividad es la encargada de conjuntar todas las compras que se necesiten hacer a proveedores. Sus conectores son: Set Suppliers: Script encargado de conjuntar los proveedores a través del método: List<List<Order>> notifysuppliers(list<list<string>> sourcelist); Notify Suppliers: Esta actividad es la encargada de notificar a cada uno de los proveedores de las materias que se necesitan para satisfacer el pedido del cliente. Sus conectores son: Send Supplier Message: Concetor que envía correo a los proveedores elegidos por la pyme. Crear Producto Este proceso se inicia con el rol Distribuidor, cando se quiere agregar un nuevo producto a la base de datos de SCLOUD, o tambien cuando se quiere modificar los datos maestros de cualquier producto. A continuación se muestra el diagrama BMP Página 140

143 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica 3: Add_Data_Master TAREAS RELACIONADAS CON EL ROL DE DISTRIBUCION Select Product: Esta actividad muestra los productos que existen en la base de datos, además permite seleccionar si se quiere editar un producto o se quiere registrar uno nuevo. Add New Product: Esta actividad es un formulario donde se ingresan los datos del nuevo producto. Add Data Master: Esta actividad es un formulario donde se ingresan los datos maestros de un producto ya existente en la base de datos. View Product Information: Esta actividad despliega toda la información de un producto des pues de haber editado sus datos maestros. TAREAS RELACIONADAS CON EL ROL SISTEMA Find All Products: Esta actividad es la encargada de buscar todos los productos en la base de datos. Sus conectores son: Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 141

144 Ingeniería de Sistemas Istar - CIS1330IS03 Find Products Information: Script que busca todos los productos a través del método List<List<String>> getproductsinformation(long pymeidentification, int tosell); Add Product: Esta actividad guarda en la base de datos un nuevo producto. Sus conectores son: Add New Product: Script que añade un nuevo producto a través del método void addnewproduct (String nombre,string datamaster,double price, double quantity, double capacity,date productionabledate, double productiontime, int tosell, long pymeidentification, String typematerial); Add New Data Product: Esta actividad Edita en la base de datos un producto existente. Sus conectores son: Save Product Data Master: Script que edita un producto a través del método void savedatamaster (int idproduct, String datamaster); Agregar Nuevo Proveedor Este proceso inicia con el rol de abastecimiento (source), el cual ingresara la identificación de un proveedor para asociarse con este. El modelo BPM para este proceso es: Página 142

145 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica 4: Add_New_Supplier_Pyme TAREAS RELACIONADAS CON EL ROL DE ABASTECIMIENTO Select Supplier: Esta actividad despliega un formulario donde se ingresara la identificación de un proveedor para asociarse con este. TAREAS RELACIONADAS CON EL ROL SISTEMA Get Supplier Information: Esta actividad verifica que el proveedor exista en la base de datos. Sus conectores son: Get Supplier Information script: Llama al método List<String> getsupplierinformation(long supplieridentification), retornando la información del proveedor solicitado. Set Error: Esta actividad guarda un mensaje para decir que el proveedor no existe en la base de datos. Add Supplier: Esta actividad asocia una pyme con un proveedor. Sus conectores son: Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 143

146 Ingeniería de Sistemas Istar - CIS1330IS03 Add Supplier script: Encargado de asociar una pyme con un proveedor a través del metodo void addsuppliertopyme(long pymeidentification, long supplieridentification). Borrar Cliente Este proceso se inicia con el rol distribuidor, en donde ingresa la identificación de un cliente de la pyme, y en dado caso que este se encuentre registrado en la base de datos será eliminado, si no existe se le volverá a pedir al usuario que digite una identificación correcta. El modelo BPM correspondiente a este proceso es: 5: Delete_Client_Pyme TAREAS RELACIONADAS CON EL ROL DE DISTRIBUCION Select Customer: En esta actividad despliega un formulario en donde se digitará la identificación del cliente que quiere ser borrado. Página 144

147 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica TAREAS RELACIONADAS CON EL ROL SISTEMA Get Customer Information: Esta actividad verifica que el proveedor exista en la base de datos. Sus conectores son: Get Customer Information script: Llama al método List<String> getcustomerinformation(string customeridentification, long pymeidentification), retornando la información del proveedor solicitado. Set Error: Esta actividad guarda un mensaje para decir que el cliente no existe en la base de datos. Delete Customer: Esta actividad borra a un cliente de una pyme de la base de datos. Sus conectores son: Delete Customer Script: Elimina el cliente a través de método void deletecustomer(string customeridentification, long pymeidentification). Seleccionar Proveedor por defecto Este proceso inicia con el rol de abastecimiento, en donde primero se mostraran los materiales que están asociados a los productos, a partir de esta información el usuario de abastecimiento podrá seleccionar un material y verificar todos los proveedores que la pyme tiene asociado a este, y el usuario tendrá la capacidad de elegir un proveedor favorito. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 145

148 Ingeniería de Sistemas Istar - CIS1330IS03 6: SCLOUD_Select_Default_Supplier TAREAS RELACIONADAS CON EL ROL DE ABASTECIMIENTO Select Default Supplier: Esta actividad carga inicialmente todos los materiales registrados con la posibilidad de escoger uno y mostrar los proveedores asociados a este, para luego seleccionar un proveedor favorito. TAREAS RELACIONADAS CON EL ROL SISTEMA Find All Materials: Esta actividad busca en la base de datos todos los materiales existentes. Sus conectores son: Find Materials: Scritp en java que llama al método List<String> findallmaterials (); y retorna los materiales. Find Suppliers by Material: Esta actividad se encarga de buscar todos los proveedores asociados a un material y a una PYME. Sus conectores son: Find Suppliers by Material: Script en java que llama al método List<String> findsuppliersbymaterial(string material, long pymeidentification). Save Default Supplier: Esta actividad guarda el proveedor favorito que el usuario de abastecimiento haya elegido. Sus conectores son: Página 146

149 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Save Default Supplier: void savedefaultsupplier (String supplier, long pymeidentification), el cual guarda el proovedor seleccionado por la PYME. Activar MRP Automático Este proceso se encarga de ejecutar un timer el cual es parametrizable por la pyme, una vez alcanzado el tiempo se procesaran los lotes que la pyme tenga en producción. El diagrama es el siguiente: Este proceso es iniciado por el rol de producción, donde inicialmente mostrará un formulario, el cual pedirá un tiempo específico, una vez que se llene este proceso enviara al MRP los lotes de producción que se encuentren disponibles hasta el momento. Una vez acabado el MRP el timer vuelve a iniciar. TAREAS RELACIONADAS CON EL ROL DE PRODUCCIÓN Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 147

150 Ingeniería de Sistemas Istar - CIS1330IS03 Set Timer: Esta actividad despliega un formulario en el cual el rol de producción decidirá cada cuanto quiere que se procesen los lotes que estén disponibles. TAREAS RELACIONADAS CON EL ROL SISTEMA Find Pyme Information: Esta actividad es la encargada de buscar el de la pyme. Sus conectores son: Find Pyme Information 3: Script encargado de buscr el de la pyme a través del siguiente método: List<String> get - Pyme (long pymeidentification); Asign Pyme Information 3: Asigna el encontrado con el anterior script a una variable del pool. Get Reques To MRP: Esta actividad se encarga de verificar si hay lotes listos para producir. Sus conectores son: Get requests to MRP: Script encargado de buscar los lotes que estén listos para producir, a través del método List<List<String>> getrequeststomrp(boolean timer); Pyme MRP Notifications: Este subproceso se encarga de realizar el proceso de Notificar Pyme por MRP Calendario Parametrizable Este proceso se encarga de guardar las fechas en que la pyme no trabaja. Su diagrama BPM es el siguiente: Página 148

151 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Este proceso inicia buscando todos los días no laborales de la pyme, para luego ser mostrados en un formulario que se le despliega al distribuidor, en este el es capaz de agregar un nuevo día no laboral de la pyme, el cual será guardado en la base de datos. TAREAS RELACIONADAS CON EL ROL DE DISTRIBUCIÓN ADD NON WORKING DAYS: Esta actividad despliega un formulario en el cual el distribuidor podrá agregar un día no laborable.. TAREAS RELACIONADAS CON EL ROL SISTEMA Find All Non Working Days: Esta actividad busca todos los días no laborables que una pyme haya registrado. Sus conectores son: Find All Non Working Days: Script encargado de retornar todos los días no laborables, a través del método List<List<Date>> findallnonworkday(long pymeidentification); Save Non Working Day: Esta actividad guarda en la base de datos un día no laborable. Sus conectores son: Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 149

152 Ingeniería de Sistemas Istar - CIS1330IS03 Save non working day: Script encargado de guarder en la base de datos, a través del método void savenonworkingdays(long pymeidentification, List<List<Date>> dates); Agregar Nueva Pyme (Multi- Tenant) : SCLOUD posee una aquitectura multitenant, para lograr esto se necesita crear una instancia de jboss en el servidor por cada pyme existente. Si se desea agregar una nueva pyme se necesita crear una nueva instancia de jboss, y dentro de este, en la carpeta bin se debe crear un archivo llamado PymeConfig.Dat, y en el solo se debe escribir el identificador de la pyme, tal cual como aparece en la base de datos. Página 150

153 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Anexo 6 Página 151 Preparado por el Grupo Investigación Istar- Versión /03/2008

154 Ingeniería de Sistemas Istar - CIS1330IS03 Anexo 7 Página 152

155 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Página 153 Preparado por el Grupo Investigación Istar- Versión /03/2008

156 Ingeniería de Sistemas Istar - CIS1330IS03 Página 154

157 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Página 155 Preparado por el Grupo Investigación Istar- Versión /03/2008

158 Ingeniería de Sistemas Istar - CIS1330IS03 Anexo 8 Página 156

159 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Página 157 Preparado por el Grupo Investigación Istar- Versión /03/2008

160 Ingeniería de Sistemas Istar - CIS1330IS03 Página 158

161 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Página 159 Preparado por el Grupo Investigación Istar- Versión /03/2008

162 Ingeniería de Sistemas Istar - CIS1330IS03 Anexo 9 DIAGRAMA DE CLASES Elaborado por: Pablo Sebastián Páez Mateus Andrés Felipe Pedraza Infante. Versión del Documento: 1.0 El presente documento especifica diagrama de clases para las tablas de la base de datos que usa SCLOUD. El diagrama lo podrá encontrar en Diagrama de Clases.png. Continuación se encuentra la explicación de cada una de las clases: Pyme: Esta clase guarda la información asociada a las pymes: Página 160

163 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Customer: Esta clase guarda la información asociada con los clientes de una pyme. Página 161 Preparado por el Grupo Investigación Istar- Versión /03/2008

164 Ingeniería de Sistemas Istar - CIS1330IS03 CustomerPK: Esta clase almacena la llave primaria de la tabla customer de la base de datos: Página 162

165 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Pyme: Esta tabla almacena la información de todos los correos electrónicos que posee una pyme: NonWorkingDay Esta es una clase que sale de la extensión de SCLOUD, con el fin de que el sistema tuvieran en cuenta los días que nos son laborables para la pyme Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 163

166 Ingeniería de Sistemas Istar - CIS1330IS03 NonWorkingDayPK Esta clase es la llave primaria de la tabla NonWorkinkDay y está compuesta por un día, un mes y un año y la identificación de la pyme con la cual esta fecha esta asociada. Página 164

167 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica CustomerRequest Esta clase almacena la información de cuando un cliente hace un pedido al sistema: Product Esta clase almacena toda la información de un producto que tiene una pyme, con las nuevas extensiones de SCLOUD fue necesario agregar 2 nuevos atributos, el primero es el material con el fin de categorizar la materia prima que necesita la PYME. Y el otro atributo fue el datamaster en donde se puede agregar una descripción de cualquier producto. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 165

168 Ingeniería de Sistemas Istar - CIS1330IS03 ProductStructure Esta clase es la que permita la creación del árbol genérico de materiales. Página 166

169 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica ProductStructurePK En esta clase se almacena la llave primaria de la tabla ProductStructure. Página 167 Preparado por el Grupo Investigación Istar- Versión /03/2008

170 Ingeniería de Sistemas Istar - CIS1330IS03 Material Esta es una nueva clase como resultado de las extensiones de Scloud, y está encargada de almacenar todos los materiales existentes, con el fin de clasificar la materia prima. Supplier En esta clase se almacena la información relacionada con los proveedores de las PYME s: Página 168

171 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica SupplierXpyme En esta clase es una nueva extensión del Scloud con el fin de asociar varios proveedores a una PYME. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 169

172 Ingeniería de Sistemas Istar - CIS1330IS03 SupplierXpymePK Esta clase guarda la llave primaria de la tabla supplierxpyme. SupplierXproduct En esta clase se almacenan la materia prima que surte cada proveedor existente en la base de datos, como resultado de la extensión de SCLOUD se agregó un nuevo atributo lote, con el fin de que la pyme hiciera compras a proveedor por lotes: Página 170

173 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica SupplierxproductPK Esta clase almacena la llave primaria de la tabla Supplierxproduct: Página 171 Preparado por el Grupo Investigación Istar- Versión /03/2008

174 Ingeniería de Sistemas Istar - CIS1330IS03 Requestxproduct En esta clase se almacena las peticiones que se hacen sobre cada producto de la PYME: RequestxproductPK Esta clase almacena la llave primaria de la tabla Requestxproduct: Página 172

175 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Sales En esta clase se almacena la venta que la pyme hizo al cliente: Página 173 Preparado por el Grupo Investigación Istar- Versión /03/2008

176 Ingeniería de Sistemas Istar - CIS1330IS03 ProductXsales En esta clase se almacena las ventas por cada producto: ProductXsalesPK Esta clase almacena la llave primaria de la tabla productxsales: Página 174

177 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Anexo 10 Página 175 Preparado por el Grupo Investigación Istar- Versión /03/2008

178 Ingeniería de Sistemas Istar - CIS1330IS03 Página 176

179 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Anexo 11 POST-MORTEM Elaborado por: Pablo Sebastián Páez Mateus Andrés Felipe Pedraza Infante. Versión del Documento: 1.0 Este documento presenta un post-mortem del Trabajo de Grado en donde se compara lo escrito en la propuesta versus la realidad, y abarca desde la metodología propuesta hasta la gestión del proyecto. 1. Metodología propuesta vs. Metodología realmente utilizada. En la propuesta de trabajo de grado se mencionó sobre la aplicación de una metodología ágil que fue la de Programación Extrema (XP). Durante el desarrollo del proyecto efectivamente se respetó los lineamientos de esta metodología que son: La programación en parejas (reuniones semanales cada 4 días por 5 horas cada uno). Reuniones periódicas con el cliente (en este caso con la directora y asesora del trabajo de grado). Documentación no exhaustiva (documentos como el manual de mantenimiento y el de instalación no tienen un formato estándar). Entregas incrementales e integración continua (En cada reunión con el cliente se mostraban avances del diseño y la implementación del sistema). Desarrollo guiado por pruebas (No se siguió un procedimiento específico para pruebas sino que se hacían pruebas a medida que se iba desarrollando el sistema). 2. Actividades propuestas vs. Actividades realizadas. En la propuesta de trabajo de grado se establecieron ciertas actividades por cada fase del proyecto, pero durante el desarrollo del mismo si cambiaron. De hecho se creó una actividad para la refactorización del sistema anterior, pero el tiempo que se estimó para Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 177

180 Ingeniería de Sistemas Istar - CIS1330IS03 el desarrollo de la misma no se cumplió y tocó extenderlo; así que se creó una fase completa para esta actividad. En cuanto a la validación del sistema, inicialmente se estimaba un mes para pruebas en las empresas elegidas, pero por cuestiones de tiempo tocó reducir ese tiempo a dos semanas únicamente, pero se logó el objetivo principal de esa fase que era la parametrización de los productos que ellos crean al sistema SCLOUD y así obtener resultados. 3. Efectividad en la estimación de tiempos del proyecto. Como bien se dijo en el punto anterior, la inserción de una nueva fase dedicada a la refactorización del sistema anterior cambió bastante las fechas de entrega de las extensiones y de los documentos de mantenimiento y manual de instalación. Es por esta razón que se cambió el tiempo estimado para la validación de un mes a dos semanas únicamente. 4. Costo estimado vs. Costo real del proyecto. En la propuesta de trabajo de grado se establecieron costos como el pago por hora de trabajo de la directora y asesora del proyecto. Se lograron cumplir aproximadamente las horas que se estimaron contra las que realmente se usaron durante el desarrollo del proyecto (ver anexo que contiene las constancias de reuniones realizadas). No se definieron otros costos para el trabajo de grado. 5. Efectividad en la estimación y mitigación de los riesgos del proyecto. El riesgo más importante que se estimó para el desarrollo del trabajo de grado fue la falta de tiempo para la validación del sistema resultante, y efectivamente se presentó. El plan de mitigación ejecutado fue la reducción a un tiempo propicio para realizar esa fase del proyecto de tal forma que se lograra hacer lo que se planeó (parametrización de información al sistema y prueba del mismo por parte de las PYMES elegidas). Un riesgo que ocurrió pero no se contempló fue la demora para refactorizar el sistema anterior, pues se invirtieron bastantes horas en esta fase y no se contaba con un plan de mitigación para ese riesgo. Lamentablemente este hecho hizo reducir el tiempo de validación con las PYMES seleccionadas. Página 178

181 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Anexo 12 Página 179 Preparado por el Grupo Investigación Istar- Versión /03/2008

182 Ingeniería de Sistemas Istar - CIS1330IS03 Anexo 13 MANUAL DE USUARIO Elaborado por: Pablo Sebastián Páez Mateus Andrés Felipe Pedraza Infante. Versión del Documento: 1.0 El presente documento muestra paso a paso las funcionalidades del sistema. Flujo de Información Cadena de Abastecimiento El primer paso para el cliente es identificarse: Una vez el cliente haya sido aceptado en el sistema, se desplegará una página en donde puede hacer el pedido, en este caso se pidieron 4 maletas y un zapato. Una vez enviada la solicitud el cliente decidirá si acepta o no el pedido: Página 180

183 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica En este caso el pedido fue aceptado, y se le notico al cliente: Como el cliente acepto el pedido se generaron las notificaciones a distribución, a producción y a abastecimiento, como se muestra en las siguientes imágenes: Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 181

184 Ingeniería de Sistemas Istar - CIS1330IS03 Como se puede observar en las anteriores imágenes hay dos notificaciones en cada usuario, Esto se debe a los lotes de producción, como el cliente pidió 4 maletas y la pyme produce 2 maletas por día, el sistema armo lotes de producción para las maletas y se notificaron el proceso llamado procesar_un_pedido # 9, pero en cambio como el cliente pidió un solo zapato y la pyme produce 2 zapatos por dia, el sistema no pudo armar un lote completo y lo dejo guardado. Tiempo después como no hubo mas pedidos de zapatos el sistema automáticamente libera las ordenes que tenga en producción sin importar si se cumple el lote, y esto se notificó a través del proceso Activar MRP Automatico # 2. Por otro lado la siguiente imagen muestra los correos enviados por la pyme: Página 182

185 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Una vez completado todo el proceso anterior se hizo una nueva orden, pero esta vez el cliente se esperó por más de 5 minutos para aceptar los parámetros de compra, y debido a que el sistema estaba configurado para aceptar confirmaciones antes de 5 minutos esta compra caduco: Crear Producto En este proceso se seleccionó un producto y se dio click en el botón enviar: Una vez dado click el sistema nos permite agregar una nuva descripción (Datos Maestros) al producto. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 183

186 Ingeniería de Sistemas Istar - CIS1330IS03 Una vez guardada la información, se despliega las características del producto: Otra característica de este proceso es el poder agregar un nuevos producto, como se muestra en la siguiente grafica: Página 184

187 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Agregar Nuevo Proveedor El sistema permite asociarse a un nuevo proveedor seleccionando el proveedor en el combo box: Borrar Cliente El sistema permite a la pyme eliminar a un cliente seleccionándolo en el combo box. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 185

188 Ingeniería de Sistemas Istar - CIS1330IS03 Seleccionar Proveedor Por defecto El sistema permite Seleccionar a un proveedor favorito por cada material existente: Activar MRP Automático Este proceso permite activar el timer para procesar debidamente los lotes de producción, en este caso el timerfue de 5 minutos. Página 186

189 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Calendario Parametrizable Este proceso mostro en una tabla todos los días no laborales de la pyme, además permite ingresar un nuevo día no laboral o eliminar: Cuando se selecciona agregar, se despliega la siguiente pantalla: Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 187

190 Ingeniería de Sistemas Istar - CIS1330IS03 Por ultimo cuando se selecciona la opción eliminar se despliega una pantalla que atreves de un combo box nos permite seleccionar un día no laborable para borrarlo. Página 188

191 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Anexo 14 Instalación de herramientas c) Instalar PostgreSQL Instalar PostgreSQL versión Se debe tomar el archivo postgresql windowsx64 que se encuentra en la carpeta PostgreSQL. Procedimiento: Ejecutar el instalador con doble click. Seguir las instrucciones de instalación. Nota: Para la correcta instalación de PostgreSQL debe estar en una sesión con privilegios de administrador. d) Instalar JBoss Application Server 7.1. JBoss Application Server 7.1 contiene toda la lógica de negocio de SCLOUD desplegada en este servidor de aplicaciones, así que es fundamental su instalación para el funcionamiento de la aplicación. Procedimiento: Copiar la carpeta jboss-as final preferiblemente en la raíz del disco donde tenga instalado el Sistema Operativo con el cual está trabajando (Generalmente es C:\). e) Instalar Bundle JBoss para BonitaSoft 5.8. Este bundle permite la integración del servidor de aplicaciones JBoss con Bonita Open Solution 5.8, y es en donde se va a desplegar toda la lógica de presentación de SCLOUD, así que es fundamental su instalación para el funcionamiento de la aplicación. Viendo la aplicación desde Procedimiento: Copiar la carpeta BOS-5.8-JBoss GA preferiblemente en la raíz del disco donde tenga instalado el Sistema Operativo con el cual está trabajando (Generalmente es C:\). Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 189

192 Ingeniería de Sistemas Istar - CIS1330IS03 Activación de herramientas a) Activar JBoss Application Server 7.1. Dentro de este servidor de aplicaciones se encuentran los EJB que se usaron para implementar la lógica de negocio de SCLOUD, y para poder desplegarlos es necesario hacer el siguiente procedimiento: Procedimiento: Ingresar al directorio donde copió la carpeta jboss-as final. Ingresar a la carpeta bin. Ejecutar el archivo standalone.bat. b) Activar Bundle JBoss para BonitaSoft 5.8. Dentro de este servidor de aplicaciones se instalarán los procesos respectivos con los que cuenta SCLOUD para lograr las funcionalidades que promete en el manual de mantenimiento. Para activar el servidor debe hacer el siguiente procedimiento: Procedimiento: Ingresar al directorio donde copió la carpeta BOS-5.8-JBoss GA. Ingresar a la carpeta bin. Ejecutar el archivo run.bat. Creación de la base de datos de SCLOUD La creación de la base de datos se logra con el siguiente procedimiento (Nota: No puede continuar con este punto si no ha instalado PostgreSQL): Procedimiento: Ejecutar pgadminiii.exe. Conectarse a un servidor de bases de datos en el menú desplegable de la izquierda. Página 190

193 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Click derecho sobre Databases y oprimir la opción Create Database. Especificar el nombre de la nueva base de datos como SCLOUD y luego hacer click sobre el botón OK. Página 191 Preparado por el Grupo Investigación Istar- Versión /03/2008

194 Ingeniería de Sistemas Istar - CIS1330IS03 Seleccionar la nueva base de datos y hacer click sobre la opción SQL ubicada en la barra de opciones principales. Página 192

195 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica Hacer click sobre el menú File y seleccionar la opción Open. Deberá cargar el archivo Todo.sql (se encuentra en la carpeta Modelo de Datos) que contiene la información de Tablas y Tuplas que componen el modelo de datos de SCLOUD. Hacer click sobre el botón Execute Query para armar el modelo de datos de SCLOUD. Página 193 Preparado por el Grupo Investigación Istar- Versión /03/2008

196 Ingeniería de Sistemas Istar - CIS1330IS03 Publicar y configurar los procesos de SCLOUD en el servidor de Bonita a) Invocar Bonita por el navegador Suponiendo que el servidor de Bonita está activo, se debe invocar Bonita mediante el siguiente URL: Si el servicio está activo se debe observar la siguiente pantalla: b) Publicar los procesos de SCLOUD mediante la consola de Bonita Ingresar a Bonita con las credenciales admin / bpm las cuales permiten utilizar la Consola de Bonita. Cambiar a modo Administrator: en la parte superior derecha esta el modo de la Consola (Administrator o User view); debe cambiarse a la vista Administrator. En la vista Administrator seleccionar en el menú izquierdo la opción Processes y luego el botón Install: permite indicar la ubicación de un proceso.bar para publicarlo en el servidor. Indicar uno por uno los procesos que se exportarán al sistema: o o o Activar_MRP_Automatico--1.0.bar Agregar_nuevo_Proveedor--1.0.bar Borrar_Cliente--1.0.bar Página 194

197 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Aplicación Práctica o o o o o o o o Crear_Producto--1.0.bar Hacer_un_Pedido--8.0.bar Notificar_a_Proveedores--1.0.bar Notificar_Pyme_por_MRP--1.0.bar Parametrizar_Calendario--1.0.bar Procesar_un_Pedido--8.0.bar Proceso_MRP--3.1.bar Seleccionar_Proveedor_por_defecto--1.0.bar En la consola del servidor se debe observar la publicación sin excepciones de cada proceso. Además la vista Administrador de la Consola de Bonita muestra los procesos publicados: c) Crear los roles y usuarios que requiere SCLOUD Estando en la consola de Bonita en la vista de Administrator (ver sección anterior) se deben crear los roles que requieren los procesos de SCLOUD: o o o o Drivers (Cliente): Este rol es el encardo de representar a todos los clientes que hacen pedidos a una determinada PYME. Distribution (Distribuidor): Este rol es el encargado de representar al distribuidor de una pyme, el cual recibe los pedidos de los clientes. Production (Productor): Este rol es el encargado de representar al productor, el cual fabrica los productos de la pyme. Source(Compras): Este rol es el encargado de representar a la persona de abastecimiento, el cual está hace compras a los proveedores. Página 195 Preparado por el Grupo Investigación Istar- Versión /03/2008

198 Ingeniería de Sistemas Istar - CIS1330IS03 También se debe crear un usuario por cada rol: cada uno debe inscribirse en el grupo platform (grupo por defecto) y en el rol respectivo: o driuser / driuser debe inscribirse en el rol Drivers o disuser/ disuser debe inscribirse en el rol Distribution o prouser / prouser debe inscribirse en el rol Production o souser / souser debe inscribirse en el rol Source d) Dejar la consola de Bonita en la vista de usuario Después de los pasos anteriores, en la consola de Bonita debe seleccionarse la vista de Usuario seleccionando el enlace User view en la parte de arriba a la derecha y luego se puede salir de la sesión con la opción logout. Si no se realizan estas acciones, los usuarios de SCLOUD no podrán autenticarse. Ejecutar los procesos de negocio de SCLOUD e) Invocar Bonita con un usuario de rol Drivers para iniciar un proceso cliente e inscribir un nuevo usuario Invocar Bonita mediante el URL: y autenticarse con las credenciales driuser / driuser Lanzar una instancia del proceso Hacer un Pedido, seleccionándolo en el menú de la izquierda: Oprimir el botón Start case cuando aparezca. El sistema pedirá la identificación del cliente, ante lo cual se puede solicitar un nuevo cliente y luego suministrar los datos del nuevo cliente. Finalmente oprimir el botón Continuar. Página 196