Señores
Comité de Trabajo de Grado Facultad de Ingeniería
Pontificia Universidad Javeriana
Estimados colegas:
Como director del trabajo de grado del joven DANIEL WARNER WHITE titulado “SmartGauge:
Aplicación móvil de toma de dimensiones volumétricas de productos de consumo para mejorar los procesos de comercio B2B” autorizo la entrega del documento final.
La sustentación del trabajo de grado se llevó a cabo el pasado 12 de Junio y contó con la presencia de los ingenieros Rafael González y Alexandra Pomares quienes actuaron como jurados del proce-so. El concepto final correspondiente al trabajo de grado es Aprobado.
Cordialmente,
JUAN PABLO GARZÓN RUIZ Profesor
Facultad de Ingeniería
CIS1310SD04
SmartGauge: Aplicación móvil de toma de medidas volumétricas de productos
de consumo para mejorar los procesos de comercio B2B.
DANIEL WARNER WHITE
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SISTEMAS
CIS1310SD04
SmartGauge: Aplicación móvil de toma de medidas volumétricas de productos de consumo
para mejorar los procesos de comercio B2B.
Autor:
Daniel Warner White
MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO DE
LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE SISTEMAS
Director
Juan Pablo Garzón Ruiz
Jurados del Trabajo de Grado
Alexandra Pomares Quimbaya
Enrique González Guerrero
Página web del Trabajo de Grado
http://pegasus.javeriana.edu.co/~CIS1310SD04
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA 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 Sergio Bernal Restrepo S.J.
Director de la Carrera de Ingeniería de Sistemas
Ingeniero Germán Alberto Chavarro Flórez
Artículo 23 de la Resolución No. 1 de Junio de 1946
AGRADECIMIENTOS
Contenido
INTRODUCCIÓN ... 1
I
-
DESCRIPCIÓN
GENERAL
DEL
TRABAJO
DE
GRADO ... 3
1.
O
PORTUNIDAD-
P
ROBLEMÁTICA,
A
NTECEDENTES... 3
1.1 Descripción del contexto ... 3
1.2 Formulación del problema que se resolvió ... 4
1.3 Justificación ... 4
1.4 Alcance y limitaciones ... 5
1.5 Impacto Esperado ... 5
2.
D
ESCRIPCIÓN DELP
ROYECTO... 5
2.1 Visión global ... 5
2.2 Objetivo general ... 5
2.3 Objetivos específicos ... 5
2.4 Método que se propuso para satisfacer cada objetivo específico ... 6
II
-
MARCO
TEÓRICO ... 7
3.
M
ARCOC
ONTEXTUAL... 7
4.
M
ARCOC
ONCEPTUAL... 8
4.1 Trabajos Importantes en el Área ... 8
4.2 Fundamentos y conceptos relevantes para el proyecto ... 9
III
–
DESARROLLO
DEL
TRABAJO... 11
5.
C
OMPONENTE DE ANÁLISIS DE IMÁGENES... 11
5.1 Proceso de investigación ... 11
5.2 Instalación del entorno de desarrollo ... 14
5.3 Algoritmo de medición ... 16
5.4 Método de toma de fotografías ... 20
6.
P
LANTEAMIENTO DE UN MODELO QUE MEJORE EL PROCESO ACTUAL... 21
6.1 El proceso actualmente ... 22
6.2 El proceso propuesto ... 22
7.
D
ISEÑO DEL SISTEMA... 23
7.1 Capa de servicios web ... 25
7.2 Aplicación Móvil ... 29
7.3 Integración de aplicaciones ... 35
7.4 Ventajas y limitaciones de los dispositivos móviles ... 36
7.5 Cumplimiento de los requerimientos acordados ... 37
7.6 Riesgos presentados ... 37
8.
C
OMPARACIÓN DE MODELOS(A
CTUAL VS.
P
ROPUESTO)... 39
9.
M
EJORAS RESPECTO AL PROYECTO ANTERIOR... 40
10.
A
PLICACIÓN DE TOMA DE DIMENSIONES... 42
11.
C
UMPLIMIENTO DE LOS OBJETIVOS... 45
11.1 Objetivos específicos ... 45
11.2 Objetivo general ... 46
12.
V
ALIDACIÓN CUANTITATIVA DEL APORTE GENERADO... 46
13.
R
EFLEXIÓN SOBRE LOS RESULTADOS OBTENIDOS... 47
V
–
CONCLUSIONES,
RECOMENDACIONES
Y
TRABAJOS
FUTUROS ... 49
14.
C
ONCLUSIONES... 49
15.
R
ECOMENDACIONES... 50
16.
T
RABAJOSF
UTUROS... 50
VI
-
REFERENCIAS ... 51
17.
R
EFERENCIAS... 51
VII
-
ANEXOS ... 54
18.
G
LOSARIO... 54
19.
D
OCUMENTOSRS ... 56
19.1 PREFACIO ... 56
19.2 HISTORIAL DE CAMBIOS ... 57
19.3 ILUSTRACIONES ... 60
19.4 TABLAS ... 60
19.5 INTRODUCCIÓN ... 61
19.6 REFERENCIAS ... 63
19.7 ELABORACIÓN DE REQUERIMIENTOS ... 64
19.8 DESCRIPCIÓN DEL PRODUCTO ... 70
19.9 OPERACIONES ... 73
19.10 Modo Precarga: El usuario debe hacer una precarga de datos de las empresas que visitará y de los productos que necesitan actualización. ... 73
19.11 Modo Actualización: El usuario actualiza los datos de los productos que lo requieran y el sistema en un momento posterior actualiza el catálogo CABASnet con la nueva información. ... 73
19.12 73 19.13 REQUERIMIENTOS ESPECÍFICOS ... 78
[image:12.612.109.539.76.623.2]19.18 RESTRICCIONES DE DISEÑO ... 79
19.19 Las restricciones de diseño que existen para SmartGauge se mencionarán en los siguientes puntos. ... 79
19.20 Restricciones de Lenguajes de Programación. ... 79
19.21 La aplicación móvil será programada de acuerdo al paradigma de programación orientada a objetos, utilizando Java para Android y el IDE Eclipse. Por otra parte, las aplicaciones de escritorio que harán análisis de imágenes serán desarrolladas en C# utilizando el IDE Visual Studio 2010. ... 79
19.22 Restricciones de Herramientas Case. ... 80
19.23 Para el diagrama de clases y el diseño de los casos de usos se utilizará la herramienta Visual Paradigm. ... 80
19.24 Restricciones de Arquitectura Final del Sistema. ... 80
19.25 El sistema utilizará una arquitectura de cliente-servidor para la comunicación. ... 80
19.26 Restricciones del Cliente. ... 80
19.27 El sistema debe ser desarrollado entre las fechas 4 de febrero de 2013 y 21 de Mayo de 2013. 80 19.28 80 19.29 Restricciones Generales. ... 80
19.30 La aplicación móvil debe poseer un manual de instrucciones en el cual se le explique al usuario su funcionamiento y características. Dicho manual estará escrito en el idioma Español de Colombia. ... 80
19.31 80 19.32 80 19.33 ATRIBUTOS DEL SISTEMA DE SOFTWARE (NO FUNCIONALES) ... 80
19.34 80 19.35 SmartGauge dispondrá de diferentes atributos de calidad que se especificarán a continuación según su categoría. ... 80
19.36 REQUERIMIENTOS DE LA BASE DE DATOS ... 82
19.37 82 19.38 83 19.39 83
20.
D
OCUMENTOSPMP ... 83
20.1 HISTORIAL DE CAMBIOS ... 83
20.2 PREFACIO ... 84
20.3 TABLA DE CONTENIDO SPMP ... 85
20.4 LISTA DE TABLAS ... 87
20.5 VISION GENERAL DEL PROYECTO ... 88
20.6 RESUMEN DEL PROYECTO ... 88
20.7 Propósito, Alcance y Objetivos ... 88
20.8 Suposiciones y Restricciones ... 1
20.9 ENTREGABLES DEL PROYECTO ... 2
20.10 REFERENCIAS ... 4
20.11 DEFINICIONES Y ACRÓNIMOS ... 5
20.12 ORGANIZACIÓN DEL PROYECTO ... 6
20.13 PLAN DE PROCESOS DE GESTIÓN ... 7
20.14 PLAN DE TRABAJO ... 10
[image:13.612.109.559.70.714.2]21.
PLAN
DE
CIERRE ... 14
21.1 Actividades ... 14
21.2 Aceptación por parte del cliente ... 14
22.
PLAN
DE
PROCESOS
TÉCNICOS ... 15
23.
MODELO
DE
CICLO
DE
VIDA
DEL
PROCESO ... 15
23.1 Objetivos específicos: ... 15
23.2 Desarrollo del plan ... 15
I
LUSTRACIÓN10:
C
ICLO DE VIDA DEL PROYECTO... 16
24.
M
ÉTODOS,
H
ERRAMIENTAS YT
ÉCNICAS... 16
24.1 Objetivo ... 16
24.2 Metodología del desarrollo del proyecto ... 16
24.3 Lenguaje de programación ... 17
24.4 Herramientas de software ... 17
25.
P
LAN DEI
NFRAESTRUCTURA... 17
25.1 Introducción ... 17
25.2 Objetivo ... 17
25.3 Características de equipos ... 18
I
LUSTRACIÓN11:
E
QUIPOS... 18
26. ... 18
27.
P
LAN DEA
CEPTACIÓN DELP
RODUCTO... 18
28.
PLAN
DE
PROCESOS
DE
SOPORTE ... 19
29.
PLAN
DE
ADMINISTRACIÓN
DE
LA
CONFIGURACIÓN ... 19
29.1 INTRODUCCIÓN ... 19
29.2 OBJETIVOS ... 19
29.3 PLAN DE DESARROLLO ... 19
29.4 RIESGOS ... 20
29.5 HERRAMIENTAS... 20
I
LUSTRACIÓN12
H
ERRAMIENTAS DEC
ONFIGURACIÓN... 21
T
ABLA7
H
ERRAMIENTAS DEV
ERSIONES... 22
29.6 MONITOREO Y CONTROL ... 22
30.
PLAN
DE
VERIFICACIÓN
Y
VALIDACIÓN ... 22
30.1 INTRODUCCIÓN ... 22
30.2 OBJETIVOS ... 23
30.3 FUNCIONAMIENTO DEL SOFTWARE ... 23
30.4 EXPECTATIVAS DEL USUARIO ... 24
[image:14.612.107.537.85.501.2]33.
PLAN
DE
DOCUMENTACIÓN ... 24
33.1 INTRODUCCIÓN ... 24
33.2 OBJETIVOS ... 24
33.3 PLAN DE DESARROLLO ... 25
T
ABLA9
E
STÁNDARES... 25
33.4 RIESGOS ... 26
33.5 HERRAMIENTAS... 26
33.6 SUPERVISIÓN Y CONTROL ... 26
34.
PLAN
DE
ASEGURAMIENTO
DE
LA
CALIDAD ... 28
34.1 INTRODUCCIÓN ... 28
34.2 OBJETIVOS ... 28
34.3 REVISIÓN DE PLANES ... 28
34.4 RIESGOS ... 30
35.
PLAN
DE
REVISIONES
Y
AUDITORIAS ... 30
35.1 INTRODUCCIÓN ... 30
35.2 OBJETIVOS ... 30
35.3 RIESGOS ... 30
36.
PLAN
DE
ADMINISTRACIÓN
DE
SUBCONTRATOS ... 31
37.
PLAN
DE
MEJORAS
DEL
PROCESO ... 31
37.1 INTRODUCCIÓN ... 31
37.2 OBJETIVOS ... 31
37.3 PLAN DE DESARROLLO ... 31
37.4 RIESGOS ... 32
38.
R
EQUERIMIENTOSF
UNCIONALES... 33
39.
R
EQUERIMIENTOSN
OF
UNCIONALES... 35
ABSTRACT
This graduation work analyses and points out the importance of data quality in B2B and B2C trading processes for both, the costs and operations optimization in the first ones, and service and corporate image enhancement in the second ones. The mobile application made highlights the necessity of implementing solutions that address the issue of data quality inside GS1 Colombia. Also, it proposes an efficient alternative to a rudimentary process.
RESUMEN
RESUMEN EJECUTIVO
En la actualidad, las grandes cadenas de almacenes dedicadas a las ventas al por menor cuentan con información imprecisa acerca de los productos que compran a sus proveedores, esto genera proble-mas a la hora de hacer un embalaje para ser transportado ya que los costos y las estimaciones espa-ciales hacen que no se tenga certeza en cuanto al espacio requerido dentro de los vehículos transpor-tadores.
La oportunidad en este caso, estuvo encaminada a brindarles a las empresas productoras de artículos de la canasta familiar, una herramienta que permitiera obtener datos de diferentes productos para sincronizarlos con sus sistemas internos a través de una aplicación móvil, con el objetivo de mejorar la calidad de la información contenida en CABASnet, un catálogo electrónico de carácter global mediante el cual las mismas publican información de sus productos.
Dicho catálogo es utilizado a diario para llevar a cabo operaciones comerciales entre productores y almacenes de retail [1]. De esta manera, las empresas productoras, como Procter & Gamble, Wyeth Consumer Healthcare o Carvajal S.A. publican sus productos mediante un catálogo (llamado CA-BASnet) para que los almacenes de cadena (éxito, Carrefour, SAO,…) puedan realizar pedidos m e-diante una plataforma B2B.
Dicho catálogo es alimentado por una base de datos en cuyos registros, la tabla principal, MTM_PRODUCT y algunas de las que están directamente relacionadas, carecen de información que sería considerada de carácter vital para procesos de logística, transporte y almacenamiento en bodega. Lo anterior se debe a que los productores industriales no llevan a cabo un proceso juicioso para asegurar la calidad de los datos de sus nuevos productos dentro del sistema CABASnet, esto lo confirma un estudio realizado recientemente dentro de GS1, que reveló que más del 80% de la in-formación almacenada dentro del sistema es inconsistente con la inin-formación que realmente perte-nece a cada producto [2]; lo que se logró con este proyecto fue brindarle una oportunidad a los in-dustriales de organizar la información dentro del sistema CABASnet de una forma más ágil que la que se lleva a cabo actualmente, ya que debido a que el proceso es tan engorroso, no se le dedica el tiempo ni el esfuerzo requerido.
aplica-cuenten con información que pueda llegar a ser demasiado relevante en el mediano plazo, es decir, que una vez se tenga acceso a la información de un producto mediante un dispositivo móvil, se puedan tomar decisiones acertadas en cuanto a las unidades de transporte (cajas) a utilizar y al vehí-culo más adecuado para llevar los productos al cliente.
Para el desarrollo del proyecto, se trabajó sobre una base de datos real, alojada en un servidor desti-nado a realizar pruebas, con datos reales de productos y de empresas colombianas, se tomó un pro-totipo de una aplicación móvil elaborado el semestre anterior (2012-03) que fue elaborado con fines similares a los del presente proyecto.
En el proceso, se adaptaron los datos reales a la aplicación móvil dándole un especial énfasis a la interfaz gráfica de usuario, también se elaboró una aplicación de escritorio dedicada al análisis de imágenes para calcular las dimensiones de un objeto, además se tuvieron en cuenta múltiples reglas de negocio de GS1 Colombia* para lograr que:
Los datos introducidos al sistema fueran consistentes con los estándares de GS1. Se desplegara al usuario solamente información relevante sobre cada producto y, Se pueda llevar un rastreo de las modificaciones realizadas a cada uno de los productos.
El proyecto actual es la continuación, perfeccionamiento y puesta en marcha de una aplicación móvil que tiene como usuarios objetivo los encargados del manejo de los datos dentro del sistema CABASnet en cada una de las empresas dedicadas a la elaboración de productos, en su mayoría, de la canasta familiar.
Con el producto elaborado, se pretende brindarle a las empresas dedicadas a la elaboración de pro-ductos de consumo familiar, una herramienta que permita mejorar la exactitud de los datos de tipo logístico propios de sus productos, de manera que se genere una oportunidad de mejora en un alto grado a los procesos asociados a su venta y distribución. De esta manera, las grandes cadenas de almacenes en Colombia fortalecerán sus estrategias y estarán mejor preparadas para enfrentar gran-des retos tanto a nivel nacional, como regional.
Los principales logros del proyecto fueron:
Automatizar un proceso manual mediante una aplicación móvil altamente interactiva e in-tuitiva.
Construir un sistema en capas, que permite la integración con otras aplicaciones y la esca-labilidad.
Plantear una solución efectiva a un problema de consistencia de datos.
Brindarle a cada uno de los posibles usuarios la posibilidad de obtener la aplicación fácil-mente mediante la tienda en línea de aplicaciones para móviles de Google [4].
Desarrollar un sistema totalmente integrado a las políticas y estándares de GS1 Colombia.
Finalmente, se validó cuantitativamente que la solución entregada a GS1 Colombia tuviera un im-pacto positivo en la calidad de la información, de manera que pudo verificarse que haber automati-zado el proceso no solo reduce costos en cuanto a tiempo y manejo de errores de carácter logístico, sino que también propone un modelo que facilita su adopción por cada uno de los usuarios de una manera efectiva y poco burocrática.
INTRODUCCIÓN
Tener una buena calidad de datos significa que la información acerca de los bienes y servicios se encuentra completa, es consistente, acertada, tiene vigencia y está basada en estándares [5]. Para empresas dedicadas al retail, el tema de la calidad de datos ha venido tomando mayor relevancia a medida que las posibilidades tecnológicas están cada vez más al alcance de los consumidores, pues
según una investigación realizada por GS1 Global, “40% de los consumidores no compran un pr
o-ducto si no confían en la información publicada” [6].
Teniendo en cuenta lo anterior, se han conformado equipos de trabajo, de los cuales hacen parte grandes empresas como Unilever, Procter & Gamble, Campbells, Ahold y Carrefour, entre otras. Los esfuerzos dedicados al tema de calidad de datos han sugerido protocolos que buscan estandari-zar la forma en que se captura la información, los mecanismos de comunicación entre productores y
retailers y los procesos para mantener la calidad de la información en el largo plazo.
Actualmente, la información contenida dentro del catálogo global CABASnet*, utilizado por la mayoría de las cadenas de retail es administrada por cada uno de los productores industriales, lo cual hace que no se siga un estándar ni un proceso juicioso de toma de datos por parte de los mis-mos; de esto se deriva que gran parte de la información contenida en los catálogos sea inconsistente con los datos reales de los productos. Es por ello que el sistema propuesto en el presente trabajo de grado busca proponer un modelo de toma de datos de los productos que unifique esfuerzos y esté basado en estándares con vistas a reducir el porcentaje de inconsistencias en los catálogos electróni-cos, que en última instancia incidirá en la satisfacción de los consumidores finales.
El sistema SmartGauge ha sido desarrollado con el objetivo de maximizar la calidad de los datos suministrados al catálogo CABASnet, para así evitar de manera considerable errores e inconsisten-cias en la base de datos actualmente ocasionados por fallas de carácter humano. Se han utilizado validadores de texto en cada uno de los campos de los formularios contenidos dentro de la aplica-ción móvil y se han establecido medidas que aseguren una calidad mínima en los datos respectivos de cada producto.
El proceso manual, anteriormente mencionado, recurre a documentos de hoja de cálculo para la toma de los datos y la sincronización con los sistemas internos. A pesar de que las hojas de cálculo tengan la posibilidad de validar los datos para hacerlos más fiables y reducir el número de errores en la introducción de los datos, carece de las prestaciones que ofrece una aplicación móvil para desplegar contenido gráfico, además de requerir del manejo de un computador, que hace aún más engorroso el proceso de toma de datos. SmartGauge minimiza esfuerzos y asegura que los datos sean introducidos de manera correcta.
I - DESCRIPCIÓN GENERAL DEL TRABAJO DE GRADO
1. Oportunidad - Problemática, Antecedentes
En la actualidad, las grandes cadenas de almacenes dedicadas al retail [1], (ventas al por menor) cuentan con información imprecisa acerca de los productos que compran a sus proveedores a través de un catálogo electrónico administrado por GS1 Colombia. Dicho catálogo posee información de carácter logístico y los datos son almacenados por cada uno de los productores industriales.
Debido a que la tarea de introducir todos los datos de cada uno de los productos está a cargo de sus fabricantes, no se cuenta con un procedimiento estándar y por ende muchos de los productos care-cen de datos relevantes para la cadena de valor. Uno de los principales problemas identificados es la falta de información concerniente a las dimensiones de una cantidad muy considerable de produc-tos, este problema ocasiona que no se puedan hacer estimaciones espaciales adecuadas, por una parte, en cuanto al tipo de vehículos a utilizar para transportar un pedido, y por otra, en cuanto al espacio en bodega que ocuparía este último.
1.1 Descripción del contexto
Muchas de las más importantes cadenas de almacenes en Colombia, dedicadas a la venta de produc-tos de retail, llevan a cabo operaciones de compra-venta a través de un catálogo global, llamado CABASnet, un sistema de información que provee datos estándar de productos, que son tenidos en cuenta a la hora de tomar decisiones en cuanto al transporte de embalajes de los mismos.
Actualmente se necesita alineación de los datos, debido a que los industriales no llevan a cabo un proceso juicioso para asegurar la calidad de los datos de sus nuevos productos dentro del sistema CABASnet y, como consecuencia, sus clientes llegan a efectuar compras mal hechas debidas a con-fusiones respecto a las referencias de los productos y se generan problemas logísticos como devolu-ciones por inconsistencias y notas crédito, que finalmente incurren en pérdidas de dinero.
mejo-res finales calidad en los datos de los productos que compran, mantiene buenas relaciones comer-ciales y crea confianza en las marcas.
En el año 2005 se formalizó un equipo global de empresas industriales, por medio del cual se busca desarrollar recomendaciones que soporten a las empresas en el manejo de información con calidad, [5] y una de las conclusiones a las que han llegado, afirma que “la captura de información sobre los
productos que se comercializan en el retail debe ser realizada por terceros y no por las cadenas”.
Así que se busca entonces plantear un modelo en el que se capturen los datos por un tercero, que realizaría visitas a cada uno de los puntos y tomaría los datos en cada una de ellas.
1.2 Formulación del problema que se resolvió
¿Cómo agilizar un proceso de toma de datos de productos mediante una aplicación móvil para ase-gurar la consistencia de los datos dentro de un catálogo de alta relevancia para el comercio electró-nico B2B?
1.3 Justificación
Teniendo en cuenta la problemática descrita en la sección 1.1, se requirió replantear las herramien-tas y los procedimientos utilizados dentro del proceso de toma y sincronización de datos dentro del catálogo, de manera que se agilizaran el tiempo y el esfuerzo dedicados a esta tarea. Por otra parte, al plantear dicho modelo, se espera que las nuevas tecnologías empleadas en la labor, garanticen la corrección y pertinencia de los datos ingresados o actualizados en la base de datos.
A medida que los datos de los productos comercializados sean más confiables, se verá reducida la incertidumbre con respecto a un conjunto de variables de orden logístico, como el peso, el volumen o el número máximo de unidades apilables; por ende, se podrán optimizar los recursos de cargue, almacenamiento, descargue y transporte de mercancías al igual que se reduciría el número de devo-luciones por averías.
Un estudio realizado por GS1 Australia en 2011 reveló que los retailers trabajan con datos inconsis-tentes más del 80% del tiempo y que además en los siguientes cinco años, tanto productores, como
1.4 Alcance y limitaciones
Alcance: el alcance del proyecto estuvo definido por la elaboración del sistema que respondiera a las necesidades identificadas dentro de la problemática general del proyecto, anteriormente descrita.
Limitaciones: se contó además con limitaciones de carácter logístico, pues se dependía en gran medida del tiempo extra disponible por parte de los interlocutores de GS1 para las reuniones.
1.5 Impacto Esperado
Al haber implantado la solución propuesta, se corrigen muchos errores en los datos de los catálogos de GS1 Colombia y al mismo tiempo, aumenta la calidad en las descripciones de los productos, pues aunque haya campos de una base de datos que no apliquen para determinados productos, hay campos en los que sí es relevante cierto tipo de información y muchas veces está ausente. De este modo se reducen muchos errores en el manejo de mercancías y por ende los costos asociados a la corrección de los mismos.
2. Descripción del Proyecto
Esta sección contiene los componentes fundamentales que pautan la completitud del proyecto.
2.1 Visión global
Se desarrolló una aplicación móvil que, además de asegurar que las actualizaciones de datos de productos del catálogo electrónico CABASnet fueran realizadas de una manera adecuada y poco propensa a errores, pudiera analizar las fotografías de éstos con el fin de calcular sus dimensiones.
2.2 Objetivo general
Desarrollar una aplicación móvil que permita tomar medidas volumétricas de diferentes objetos para poder obtener información logística que sea útil a los procesos de transporte y almacenamiento en bodega asociados a su venta.
2.3 Objetivos específicos
Plantear un modelo de toma de datos que permita que se mejore la calidad del contenido dentro del catálogo CABASnet en un 30%.
Construir un prototipo funcional de la aplicación propuesta.
Validar cuantitativamente el aporte que brinda la aplicación al ser implantada en un am-biente productivo real.
2.4 Método que se propuso para satisfacer cada objetivo
específico
A continuación se detalla el método propuesto para lograr cada uno de los objetivos específicos que llevarían a la consecución exitosa del objetivo general del presente trabajo.
Para el primer objetivo, se llevó a cabo un proceso de investigación en el que se empezó por llevar a cabo una extensa consulta sobre análisis de imágenes y visión artificial, se llevaron a cabo reunio-nes con un experto en análisis de imágereunio-nes, se abordaron los principales métodos y tecnologías disponibles para elaborar la solución al problema y finalmente se elaboró un informe con los resul-tados del proceso de investigación concerniente a los distintos métodos de visión artificial que dar-ían paso a gran parte de la consecución del objetivo general del presente proyecto.
Para el segundo objetivo, por su parte, se programaron reuniones con quienes serían los asesores y principales clientes del producto con ánimo de entender mejor la problemática a solucionar, se ela-boró un documento de especificación de requerimientos (ver anexo Documento SRS) validado por los principales stakeholders y se diseñó un modelo que mejorara el proceso actual.
Para el tercer objetivo específico, se hizo entrega de un documento SPMP (ver anexo Documento SPMP) que plantea el proceso de desarrollo de software que se llevaría a cabo, se detalló el modelo de dominio del sistema actual, se diseñó y validó la arquitectura propuesta tanto con el director del trabajo de grado, como con los clientes en Logyca, posteriormente se llevaron a cabo tareas de per-feccionamiento de la aplicación móvil a ser continuada y finalmente se elaboraron sus manuales de usuario.
II - MARCO TEÓRICO
3. Marco Contextual
GS1 Colombia es una “Organización internacional, que lleva presente 24 años en Colombia como una organización que trabaja para dar soluciones de sostenibilidad y rentabilidad a todas las com-pañías que hacen parte de la cadena de abastecimiento…”
“…Dentro de sus servicios, se encuentran el desarrollo de sincronización de información, inter-cambio electrónico de documentos, codificación en masa de los productos, el interinter-cambio de in-formación de DDVI (datos de venta de inventarios) y el desarrollo de sistemas de trazabilidad, entre otros” [7].
La problemática que solucionó el trabajo de grado fue conocida gracias a una asignatura de la Ma-estría en Ingeniería de Sistemas y Computación (MISYC) de la Pontificia Universidad Javeriana tomada en el periodo 2012-03. A lo largo de dicho semestre, se logró construir un prototipo funcio-nal que fue tomado como base para el desarrollo del proyecto. Para el presente periodo académico, se adaptó dicha solución a las bases de datos de GS1 Colombia y se perfeccionaron aspectos que quedaron pendientes, adicionalmente, se logró implantar la solución y poner en marcha el proyecto dentro de GS1.
4. Marco Conceptual
Luego de haber realizado un proceso investigativo y de recopilación de información, se identifica-ron varios aspectos que fueidentifica-ron tenidos en cuenta durante el desarrollo del trabajo de grado, dichos aspectos incluyen documentación específica de la plataforma sobre la cual piensa ser implantada la solución, conceptos básicos de computación gráfica[8] y temas relacionados sobre los cuales se ahondó durante el modelado de la solución al problema planteado dados los requerimientos obteni-dos en las primeras fases de todo el proceso.
Por otra parte, se analizó información que pudiera contribuir en el proceso final de validación del aporte que brinda la solución desarrollada, de una manera rigurosa.
La búsqueda de información relevante se fundamenta en consultas de bases de datos, Internet y libros de texto.
4.1 Trabajos Importantes en el Área
Invariant 2D object recognition using KRA and GRA.
Es un estudio realizado en Noviembre de 2009 en la universidad nacional de TaiPei, Chi-na que busca modelar computacioChi-nalmente objetos en dos dimensiones basándose en los métodos K-Curvature[8] (KRA) y GreyRelationalAnalysis[9] (GRA).
En el estudio se tomaron 50 objetos reales de prueba y 50 objetos sintéticos para ser digi-talizados representándolos por medio de patrones. Este mismo método fue probado me-diante un Benchmark contra el método de Lee [10] y el primero arrojó mejores resultados
de desempeño que el segundo [11].
A picture is worth a thousand keywords: image-based object search on a mobile platform.
Un sistema diseñado para analizar patrones en diferentes fotos de objetos con el objetivo de hallar páginas web relevantes que coincidan con las características de dichos objetos [12].
El sistema fue desarrollado en MIT en el año 2005 y tiene bastante relación con la aplicación Goggles[13], desarrollada para Android.
Lo interesante de la aplicación Goggles es que hace un uso eficiente de los recursos, pues de-bido a la carga de procesamiento que conllevan dichos análisis, el trabajo es realizado con el procesador gráfico del mismo celular en una cantidad de tiempo respetable.
4.2 Fundamentos y conceptos relevantes para el proyecto
Librería OpenCV
OpenCV es una librería de funciones de programación para resolver problemas de visión artificial en tiempo real, su nombre es un acrónimo de Open Source Computer Vision, ha sido desarrollada bajo licencia BSD, es decir, su uso es libre tanto para desarrollar aplicaciones de carácter académi-co, como aplicaciones con fines comerciales, su versión estable más reciente fue publicada en Mayo de 2012. Con respecto a la documentación asociada que servirá como fuente bibliográfica para aprender a usar las características y funciones de la misma que apliquen a la solución del problema, se tomarán como referentes algunos libros como [14] y [15] además de la documentación en línea del proyecto, disponible en su sitio web oficial. [16]
OpenCV tiene una estructura modular, lo cual significa que el paquete contiene algunas librerías compartidas [17] o estáticas [18]. Los siguientes son los módulos principales:
core: Un módulo compacto que define estructuras de datos básicas, incluyendo el arreglo densa-mente multidimensional Mat y funciones básicas usadas por los otros módulos.
imgproc: Un módulo de procesamiento de imágenes que incluye filtrado de imágenes lineal y no lineal, transformaciones geométricas de imágenes, conversión del espacio de colores, histogramas, etc.
Video: Un módulo de análisis de video que incluye estimación del movimiento, substracción del fondo, y algoritmos de rastreo de objetos.
calib3d: Algoritmos básicos de geometría de múltiples vistas, calibración de cámaras, estimación de la posición del objeto y elementos de reconstrucción 3D.
descripto-objdetect: detección de objetos e instancias de las clases predefinidas (por ejemplo rostros, ojos, mugs, gente, carros, etc.).
highgui: Una interfaz de captura de video fácil de usar, códecs de imagen y de video, así como características simples de interfaz de usuario.
gpu: Algoritmos acelerados por GPU de los diferentes módulos de OpenCV.
Además de los módulos mencionados, OpenCV cuenta con una serie de características que aprove-chan inteligentemente los recursos y que hacen de OpenCV una librería apropiada para el análisis de imágenes con métodos de visión artificial, a saber [19]:
Manejo automático de memoria
Asignación automática de los datos de salida
Aritmética de saturación
Tipos de Pixel fijos y uso limitado de templates InputArrays y OutputArrays
Manejo de errores
Multi-threading y Re-enterability
III
–
DESARROLLO DEL TRABAJO
5. Componente de análisis de imágenes
El proyecto inició con un proceso de investigación por medio del cual se buscaba conocer técnicas de análisis de imágenes que tuvieran aplicabilidad dentro de la solución al problema planteado (cal-cular las dimensiones de un objeto tridimensional).
5.1 Proceso de investigación
En primera instancia, se llevó a cabo una reunión con Leonardo Flórez, profesor investigador del grupo de investigación Takina de la Pontificia Universidad Javeriana, experto en el tema de proce-samiento de imágenes y visión artificial, en la cual se trataron temas relacionados con librerías gráficas, formas de plantear la solución del problema y posibles recursos bibliográficos a los cuales acudir.
Durante dicha reunión surgieron nuevos interrogantes y nuevos recursos para poder empezar con el proceso investigativo y se llegó a las siguientes conclusiones:
OpenCV puede llegar a ser la librería de tratamiento de imágenes más apropiada para el de-sarrollo del componente de toma de dimensiones de los objetos.
El modelo que se debe plantear tiene que contemplar una posición y una distancia fijas al objeto que será analizado.
Se deben tener en cuenta variables de luminosidad de la fotografía para lograr hacer un aná-lisis correcto de la misma.
OpenCV es una librería desarrollada en lenguaje C, por lo que habría que buscar alguna forma de integrarla a la aplicación móvil a desarrollar.
OpenCV posee todas las características necesarias y las funciones apropiadas para poder desarrollar el módulo de toma de dimensiones de productos.
La librería actualmente ha sido adaptada a la plataforma de desarrollo de Android, de mane-ra que se podría logmane-rar adaptar una solución que funcione directamente en el dispositivo móvil.
Para el uso de la librería OpenCV en Android, es necesario el plugin de eclipse, NDK, ( Na-tiveDevelopment Kit) que permite la implementación de aplicaciones utilizando lenguajes de programación nativos, como C y C++.
Es necesario entender en qué inciden, (si es que lo hacen) las características de la cámara del dispositivo móvil con que se toma la fotografía, en los resultados del análisis de la ima-gen. Pues en el modelo a plantear, se requiere que dicho factor no influya de manera que el modelo sea homogéneo a la mayoría de dispositivos Android.
Respecto a los cinco métodos de análisis de imágenes propuestos, se lograron hallar solamente tres que tuvieran aplicabilidad dentro de la solución:
El primer método se basa en una técnica llamada “estereoscopía”, que consiste en analizar dos imágenes del mismo objeto tomadas desde diferentes perspectivas para, con ayuda de un mecanismo de análisis gráfico que simule la visión natural, poder analizar las tres di-mensiones de un objeto en un solo paso dado que este método permite percibir la profundi-dad del espacio, tal y como lo hace el cerebro humano con ayuda de los dos ojos.
El segundo método consiste en utilizar un objeto A de dimensiones conocidas para compa-rarlo dentro de la misma fotografía con el objeto a medir, B, y de esta manera, conociendo el tamaño real de A y las dimensiones equivalentes en pixeles de A y B, aproximar una constante de equivalencia para aproximar las dimensiones del objeto B.
pixe-les, fácilmente convertibles a milímetros utilizando un factor de equivalencia entre pixeles y milímetros.
A continuación se llevó a cabo un análisis comparativo de cada uno de los tres métodos distingui-dos, presentado en la siguiente matriz DOFA.
Método
Debilidades
Oportunidades
Fortalezas
Amenazas
Estereoscopía Requiere de altas capa-cidades de procesamien-to.
Necesita una alta preci-sión en la toma de las fotografías
Brinda una mayor confiabilidad en el algoritmo y en sus resultados.
Es un método más preciso que los otros dos.
Solo necesita un paso analítico para calcular las tres dimensiones
Su complejidad lo hace poco apto para ser desple-gado en un dispo-sitivo móvil.
Comparación con objeto conocido
Requiere del uso de un objeto estandarizado para todos los usuarios, lo cual dificulta su repli-cabilidad.
Requiere del análisis de dos fotografías para calcular las tres dimen-siones.
Facilmente adaptable a una solución móvil.
Mayor flexibilidad en cuanto a los paráme-tros del entorno de la toma de la foto.
Necesita de más pasos que los otros dos méto-dos.
Modelo Geométrico
– Algoritmo Canny
Está restringido a utilizar una distancia predefini-da.
Requiere del análisis de dos fotografías para calcular las tres dimen-siones.
Su baja complejidad lo hace más adapta-ble a una solución móvil.
Utiliza un modelo estándar para la toma de las fotografías.
Baja complejidad en el análisis de las imáge-nes.
Requiere del cuidado de mu-chas variables para la toma de las fotografías.
Así pues, se le dio preferencia al tercer método que utiliza un modelo geométrico y el algoritmo de Canny sobre los otros por los siguientes motivos principalmente:
1. El método es fácilmente adaptable a cualquier organización que lo desee implementar, pues para su correcto funcionamiento solo requiere de la toma de dos fotografías bajo unos parámetros establecidos.
2. Su baja demanda de recursos computacionales para el análisis de las fotografías lo hace más atractivo y factible a ser adaptado a una aplicación móvil.
3. No necesita de un segundo objeto para hacer comparaciones de equivalencia, lo cual facilita su fácil uso y entendimiento por parte de los usuarios de SmartGauge, además de que per-mite ser usado a gran escala desde un principio sin necesidad de utilizar objetos idénticos en cada fábrica.
4. La complejidad en su desarrollo lo hace más adecuado y alcanzable si se tiene en cuenta que será solamente un componente modular del sistema.
5. Requiere de un procedimiento cuidadoso para la toma de las fotografías en el que hay que controlar variables como la distancia de la cámara al objeto, de luminosidad del espacio, así como de los colores a utilizar para el fondo de la fotografía, lo cual hace que el proceso sea muy estricto, pero a su vez define un método estándar para asegurar calidad en la toma de los datos, que es el gran problema a atacar con el sistema propuesto.
5.2 Instalación del entorno de desarrollo
Posteriormente a esto, se procedió a instalar todo el entorno de desarrollo necesario, de manera que se pudiera empezar a programar y a aprender sobre el funcionamiento y las herramientas que provee OpenCV para análisis de imágenes.
utilizar las funciones y comprender de su uso de una manera simple, sin tener que mezclar concep-tos de desarrollo sobre dispositivos móviles, con concepconcep-tos de la librería gráfica.
Luego de haber preparado el entorno de programación con Xcode, empezaron a surgir problemas de compatibilidad en el aprendizaje, pues el libro oficial que se tomó como referencia utilizaba como entorno de desarrollo Microsoft Visual Studio y en los ejemplos se hacía uso de funciones básicas propias de las librerías de Windows, de manera que el aprendizaje de la librería estuvo estancado por una semana debido a que no se pudo continuar con la lectura del libro y no se hallaron tutoria-les, documentación, ni bibliografía que llevaran los ejemplos más allá de los primeros pasos con OpenCV sobre Xcode.
Posteriormente, se procedió a buscar instalar sobre un entorno de Microsoft Windows, el entorno de programación Visual Studio, de manera que esta vez se llevó a cabo la instalación de la librería, en su versión 2.2 para Visual Studio 2010. Se presentaron diversos problemas con dicha instalación debido a que la forma de proceder para la instalación de cada una de las versiones es distinta y la documentación al respecto en la página oficial era incompatible con la documentación del libro guía. Además hubo problemas con la forma de referenciar la librería tanto en Visual Studio, como en Windows, porque dependiendo de la arquitectura de la máquina, es decir, si es de 32 o de 64 bits, se debe descargar una versión de la librería u otra y el procedimiento diferenciado con respecto a la instalación de cada una no es muy claro en los tutoriales hallados en Internet.
Inicialmente, se estaba trabajando con el aprendizaje y la librería instalada sobre Windows 7 de 64 bits, y en cierta ocasión, después de un apagado forzoso de la máquina, se desconfiguró el ambiente de C++ de Visual Studio. De manera que se intentó reinstalar Visual Studio, y de igual manera con su Service Pack, pero el problema persistió y se optó por reinstalar Windows de 32 bits.
5.3 Algoritmo de medición
El modelo al que se llegó finalmente, es el siguiente:
Se hace uso del Algoritmo de Canny, que detecta los bordes del objeto dentro de la fotografía. Para
lograr encontrar los bordes, se debe primero “binarizar” la imagen, esto quiere decir, que se debe
transformar la imagen a color, en una imagen representada en escala de grises, de manera que se puedan diferenciar de manera clara los bordes del objeto y el fondo de la imagen. Se requiere en-tonces que el color del objeto sea lo más alejado posible del color blanco, que es el que se tomará como fondo predeterminado para tomar las fotografías, de ahí el término “binarizar”.
Así entonces, se hace uso de la función cvCvtColor para transformar la foto original en una foto a blanco y negro.
A continuación, de la obtención de los bordes, podemos pasar a analizar los contornos de la imagen, los cuales son vectores de puntos que representan los bordes. Es decir, que pasamos de una imagen
“rasterizada” a vectores que contienen cada punto que pertenece a un contorno aislado. Esto lo hacemos mediante la función cvFindContours.
Ahora, si el resultado de la anterior operación nos arroja una imagen con al menos un contorno, lo que se hace es calcular un rectángulo que bordee dicho contorno. Esto lo hacemos mediante la fun-ción cvBoundingRect y obtenemos una imagen como la siguiente:
Ahora que tenemos en memoria la representación del tamaño en pixeles del objeto, debemos calcu-lar un factor de conversión para saber cuánto representa cada uno de dichos pixeles en espacio real.
El tamaño del objeto es calculado por semejanza de triángulos entre OAB y OCE:
Esta fórmula nos da el tamaño real del objeto en el sensor de la cámara; ahora tenemos que conver-tir este tamaño en pixeles. Esto lo podemos calcular con otra proporción:
Ahora, S, el tamaño físico del sensor, al igual que la resolución, pueden ser hallados en las especifi-caciones de la cámara utilizada. De manera que la fórmula final para el tamaño del objeto será:
El único valor desconocido es la distancia focal, el cual puede ser calculado simplemente haciendo algunas mediciones de objetos de tamaño conocido, a una distancia conocida.
Ahora, de la anterior fórmula tenemos:
factor: Que es calculado según las especificaciones de la cámara.
d: La distancia que determinamos para toma la foto.
f: La tomamos como 1, pues la distancia de la cámara al objeto, es la misma que la distancia del observador al objeto.
De esta manera, se plantea el modelo utilizado para calcular las dimensiones de un objeto, dada una distancia conocida. Ahora lo que resta es integrarlo con la solución móvil que administre las captu-ras de datos del catálogo CABASnet.
5.4 Método de toma de fotografías
De acuerdo con el método escogido como el más apto para llevar a cabo el proceso de toma y análi-sis de imágenes, se presenta a continuación el ambiente fotográfico a tener en cuenta para que el método sea eficaz.
Paso 1. Adecuar el escenario.
Para esto, necesitamos papel de color verde fosforescente, de manera que resalte y sea un color que
poco se encuentre en las características físicas de los productos a analizar para que así, al “separar”
el objeto del fondo del escenario con ánimo de realizar transformaciones gráficas sobre la región de la fotografía que representa el objeto, éstas puedan llevarse a cabo con la menor cantidad de errores sobre el proceso.
Como siguiente medida, debemos utilizar dos lámparas que tengan la misma intensidad de luz, de manera que se puedan eliminar todo tipo de sombras. Ubicadas a cada lado del escenario.
Para que la fotografía pueda ser analizada sin dar lugar a errores, el dispositivo con el que se tomen las fotografías debe estar ubicado a 40 centímetros del objeto en cuestión, de manera que solamen-te podrán ser analizados los objetos cuyo tamaño no supere las siguiensolamen-tes dimensiones:
Alto: 20 centímetros.
Ancho: 43 centímetros.
Profundo: 20 centímetros.
Lo anterior, debido a que las fotos deben ser tomadas en posición panorámica. Estas dimensiones funcionan tanto para dispositivos de 10 pulgadas, como de 7 pulgadas, pues el espacio que abarca la cámara es el mismo (esto probado en un Samsung Nexus 10” y en un Lenovo ideapad 7”).
Paso 3. Tomar las fotografías.
Para tomar las fotografías, el dispositivo debe estar totalmente vertical, se debe cuidar que se elimi-ne cualquier tipo de sombra y que el objeto quede encuadrado totalmente dentro de la foto. Adicio-nalmente, se debe tomar una fotografía de frente, mediante la cual se analizarán Alto y Ancho y otra fotografía de lado, con la que se analizará la profundidad.
Aparte de esto dentro del análisis se validarán internamente las alturas del objeto determinadas me-diante cada fotografía.
6. Planteamiento de un modelo que mejore el proceso actual
Para lograr comprender en detalle la problemática, se programaron reuniones con los representantes de GS1 con el fin de aclarar conceptos, reforzar los objetivos y en general, comprender la forma en la cual se llevan a cabo los procesos que pretende optimizar el sistema desarrollado.
De dichas reuniones surgieron acuerdos, se logró modelar el problema y se buscó levantar requeri-mientos del cliente.
6.1 El proceso actualmente
A la fecha, el proceso de añadir o actualizar productos dentro del catálogo electrónico CABASnet, es llevado a cabo por un empleado encargado de dicha labor, perteneciente a cada uno de los luga-res en los que son elaborados dichos productos. Antes de lanzar un producto al mercado, o cuando se requiere actualizar su información logística, el empleado realiza la labor de hacer la inser-ción/actualización de datos en un archivo de hoja de cálculo de Excel, que posteriormente es sin-cronizado con la base de datos de productos.
Dicho proceso requiere del desplazamiento del operario desde su lugar de trabajo, hasta las oficinas de GS1 para poder sincronizar la nueva información, lo cual hace que se emplee demasiado tiempo en desplazamientos y en logística para realizar todas y cada una de las nuevas sincronizaciones.
Por otra parte, la calidad en el proceso no está siendo regulada y se deja de lado información muy apreciable dentro de los procesos logísticos de la cadena de valor, como las dimensiones de los productos: al hacer un análisis sobre una muestra de 451 productos de la base de datos, se encontró que solamente el 10.9% de los productos del catálogo CABASnet cuentan con alguna información referente a sus dimensiones, lo cual hace que en general, la información de las dimensiones que pueda llegar a ocupar un pedido cualquiera, sea imposible de calcular y se recurra a hacer estima-ciones con un alto grado de incertidumbre.
Se ha encontrado también que para una misma empresa, hay datos que son llenados en algunos formularios de los productos, pero son ignorados en otros, de manera que se deduce que a falta de un estándar en la forma de actualizar o introducir nuevos productos dentro del catálogo, muchas veces el valor de la información es despreciado, pues sería imposible saber en detalle qué caracterís-ticas básicas posee cada producto de un mismo pedido.
6.2 El proceso propuesto
Se propuso también que la actividad en cuestión sea llevada a cabo usando un dispositivo móvil que tenga una pantalla lo suficientemente amplia (7 pulgadas o más) para desplegar los datos requeridos de tal manera que sea cómodo para el usuario hacer ediciones y contemplar a primera vista todos los campos de texto, botones e imágenes de la aplicación. Además también porque el dispositivo sería mucho más ligero que el usado actualmente (un computador), lo que tendría ventajas conside-rables en el desplazamiento del operario encargado de las visitas.
La aplicación móvil propuesta además, al hacer un filtrado de productos por categoría, hace que sea actualizada, en primera instancia, información relevante de cada producto, de manera que se asegu-ra una calidad mínima y un estándar en la forma de actualizar los datos de los productos.
El valor generado por este servicio estandarizaría en alguna medida el proceso, de manera que ase-gurar que una mínima cantidad de datos acerca de las características y dimensiones de cada produc-to posibilitaría reducir el número de errores en los pedidos y en las estimaciones relacionadas direc-tamente, como los vehículos a utilizar para su transporte y el espacio en bodega destinado a su al-macenamiento.
Se busca pues, aumentar en gran medida ese 10.9% mencionado en la sección 6.1, ya que las di-mensiones de cada producto se convertirán en un campo obligatorio en los formularios de la aplica-ción móvil.
7. Diseño del sistema
Tal como especifica el diagrama, se tendrán en cuenta tres entidades principales: Visita, Empresa y Producto. El usuario final de la aplicación móvil será quien (indirectamente) actualice la informa-ción de los productos en la base de datos.
La aplicación móvil entonces haría uso de servicios web a través de Internet, montados sobre servi-dores de GS1, que accederían directamente a la base de datos de productos que maneja CABASnet.
7.1 Capa de servicios web
7.1.1 Entidades principales
Para poder consumir y actualizar datos de la base de datos de CABASnet, se recurrió a utilizar un
Backup de la base de datos del mismo. Se recurrió a esta opción a fin de realizar pruebas y no inter-ferir con las bases de datos reales.
Para empezar, la base de datos, llamada Metamodelo, sigue estándares internacionales de GS1 Glo-bal, por lo que sus especificaciones y campos están en el idioma Inglés, sus diagramas principales son los siguientes:
Diagrama Product: Contiene todas las tablas que describen a los productos, como sus característi-cas, dimensiones, instrucciones de manejo, contenido neto, categorización estándar, empresa a la que pertenece, información de jerarquía, información nutricional (si aplica), entre otros.
Diagrama Security: Contiene todas las tablas que definen los permisos de acceso de los usuarios y las empresas a las diferentes secciones, aplicaciones y servicios ofrecidos por GS1 Colombia.
Como se ha mencionado anteriormente, cada uno de los productores es el encargado de administrar los datos de sus productos en el catálogo electrónico, y que una solución planteada desde hace ya varios años para reducir errores e índices de pérdidas por devoluciones, averías o compras mal hechas sería que un tercero se encargara de las actualizaciones de datos de los productos, de manera que se llevaría a cabo un procedimiento estandarizado y habría una mejora considerable en la canti-dad y la calicanti-dad de los datos propios de cada producto en la base de datos, de manera que se redu-cirían incertidumbres y se podría proceder de una mejor manera en temas logísticos de transporte y almacenamiento en bodega.
Del diagrama Enterprise, se tomó solamente información de la tabla MTM_ENTERPRISE, pues solo nos interesa en este caso el campo id_enterprise. Esto debido a que se generó una nueva tabla dentro de la base de datos, llamada MTM_VISIT, a la cuál accedería el “tercero” encargado de re a-lizar las visitas a las diferentes empresas. Dicha tabla contiene el campo id_enterprise, además de los campos obligatorios de GS1 utilizados para hacer seguimiento a los cambios realizados en cada registro de la base de datos. Dichos campos son:
CREATION_LOGIN
CREATION_DATE
MODIFICATION_LOGIN
MODIFICATION_DATE
De este modo, el flujo de información a través del sistema se dará teniendo en cuenta el nuevo mo-delo planteado, que terceriza la labor de toma de datos de los productos. Del diagrama Product, se utilizaron las tablas:
MTM_PRODUCT,
MTM_STANDARD_CATEGORY
Que serán las principales tablas que brinden toda la información relevante de cada uno de los pro-ductos que vamos a tomar como propro-ductos de prueba dentro de la solución propuesta a resolver mediante la aplicación móvil.
[image:46.612.104.562.343.699.2]Necesitamos entonces, todas las características de cada producto, para lo cual hemos recurrido a las tablas mencionadas anteriormente.
Del diagrama Security, se utilizó solamente la tabla SSO_USER, la aplicación móvil no interac-tuará con las otras aplicaciones de GS1, así que por sencillez en la aplicación, se utilizaría un nom-bre de usuario y una contraseña para acceder a la aplicación móvil e identificarse en el sistema.
7.1.2 Servicios Web publicados
La tabla mostrada a continuación enuncia cada uno de los servicios y su funcionalidad respectiva.
SERVICIO DESCRIPCIÓN
Login Se utiliza para brindarle acceso a la aplicación
móvil al usuario.
ProductCharacteristics Entrada: id_product .
Salida: Una lista con todos los campos de la tabla
MTM_PRODUCT_CHARACTERISTICS para un
pro-ducto dado.
ProductDimensions Entrada: id_product.
Salida: Una lista con todos los campos de la tabla
MTM_PRODUCT_DIMENSIONS para un product
dado.
ProductsByEnterprise Entrada: id_enterprise.
Salida: Una lista con los productos que necesitan
actualizarse dada una empresa.
VisitList Entrada: ninguna.
Salida: Una lista de las empresas que debe visitar
un usuario. Contiene nombre, dirección y teléfono
de cada empresa
appliancesList Entrada: ninguna.
trodomésticos. autoPartsList Entrada: ninguna.
Salida: Una lista con todos los ID de la tabla
MTM_STANDARD_CATEGORY que corresponden a
productos cuya categoría generalizada es auto-partes.
cleaningList Entrada: ninguna.
Salida: Una lista con todos los ID de la tabla
MTM_STANDARD_CATEGORY que corresponden a
productos cuya categoría generalizada es aseo. clothingList Entrada: ninguna.
Salida: Una lista con todos los ID de la tabla
MTM_STANDARD_CATEGORY que corresponden a
productos cuya categoría generalizada es ropa. foodList Entrada: ninguna.
Salida: Una lista con todos los ID de la tabla
MTM_STANDARD_CATEGORY que corresponden a
productos cuya categoría generalizada es comi-da.
hardwareList Entrada: ninguna.
Salida: Una lista con todos los ID de la tabla
MTM_STANDARD_CATEGORY que corresponden a
productos cuya categoría generalizada es herra-mientas.
homeList Entrada: ninguna.
Salida: Una lista con todos los ID de la tabla
MTM_STANDARD_CATEGORY que corresponden a
productos cuya categoría generalizada es hogar. medicinesList Entrada: ninguna.
Salida: Una lista con todos los ID de la tabla
MTM_STANDARD_CATEGORY que corresponden a
productos cuya categoría generalizada es medi-cinas.
paperList Entrada: ninguna.
Salida: Una lista con todos los ID de la tabla
MTM_STANDARD_CATEGORY que corresponden a
Salida: Una lista con todos los ID de la tabla
MTM_STANDARD_CATEGORY que corresponden a
productos cuya categoría generalizada es aseo personal.
Measure Entrada: un arreglo de bytes correspondientes a
una imagen.
Salida: dos dimensiones de una imagen: ancho y
alto.
synchronize Entrada: Un arreglo de objetos JSON,
interpreta-dos localmente como productos. Los nuevos
da-tos de dichos producda-tos son actualizados en la
base de datos Metamodelo.
Salida: ninguna.
Así pues, la aplicación móvil accederá a todos estos servicios para poder llevar a cabo la tarea de actualizar datos de los productos.
7.2 Aplicación Móvil
7.2.1 Generalidades
La aplicación móvil es la aplicación central del proyecto, durante el desarrollo de la misma, se tuvieron en cuenta las siguientes necesidades:
La aplicación debe responder a la necesidad de mejorar la información básica de cada uno de los productos.
Debe hacerse un filtrado por categorías de los productos, con tal de asegurar un mínimo de calidad y de información relevante para los mismos.
El despliegue gráfico de la aplicación debe acomodarse a la categoría de cada producto.
La aplicación debe hacer uso de servicios web mediante tareas asíncronas, de manera que se garan-tice la navegabilidad del usuario en todo momento.
La aplicación debe poder persistir datos localmente, para poder ser sincronizados en momentos diferentes con las bases de datos de GS1.
La aplicación debe hacer uso de componentes gráficos de última generación, que faciliten la nave-gabilidad y que hagan intuitivo el uso de ésta.
contempla-La aplicación en su flujo básico, contempla como primer paso el acceso del usuario. Para ello se accede vía servicios web a la base de datos de usuarios y se confirma que efectivamente el usuario exista, el password sea correcto y que el acceso esté activado.
Como segundo paso, se procede a realizar una “precarga” de información. Para llevar a cabo dicho procedimiento, se debe tener una conexión a Internet estable. Durante la precarga se recolectan datos correspondientes a empresas, productos y categorías. Para la ejecución de la precarga de in-formación, al ser realizada mediante tareas asíncronas que acceden a los servicios web, hubo que hacer un manejo cuidadoso de la concurrencia, pues el proceso es semi-secuencial ya que primero hay que cargar información de empresas, para poder cargar información de productos y de igual manera, primero hay que cargar información de productos para poder cargar información de cate-gorías.
La precarga, según el modelo planteado por la aplicación, (de realizar visitas a cada uno de los esta-blecimientos) se realizaría en un instante previo a las visitas, cuando se cuente con una conexión activa y confiable a Internet. Luego de la precarga, los datos se persisten localmente en una base de datos SQLite [20], de manera que el operario podría desplazarse hasta el sitio en el cual deba hacer actualizaciones de datos, allí hacer los cambios necesarios en la información de cada producto y, posteriormente, cuando se cuente nuevamente con una conexión fija a Internet, se haga la sincroni-zación con la base de datos que vendría a utilizar el catálogo electrónico.
7.2.2 Interfaces Gráficas de Usuario
La actividad más relevante de la aplicación es ProductosActivity, en ella se prestó especial énfasis en el despliegue gráfico, de manera que para el usuario fuera muy sencilla la navegación y la actua-lización de los datos de cada producto. Para ello se utilizó una convención de colores y alertas vi-suales, que le indican al usuario qué tipo de información es inexistente en un producto, qué tan ur-gente es que se actualice dicha información y qué tan confiable es.
[image:50.612.108.555.77.362.2]De esta manera, se asegura que los formularios presenten información relevante y pertinente para cata tipo de producto y que se mejore la calidad de la información asegurando que se cumpla con unos parámetros mínimos de completitud. Es aquí donde se ataca el problema principal, pues se le muestra al usuario el grado de completitud de cada producto, utilizando los tonos de los colores y además se le muestra gráficamente si un aspecto del producto necesita ser actualizado. Lo anterior se explica con detalle en la siguiente tabla:
Indicadores Función
Tonos oscuros y señal de peligro Indican que el producto tiene la mayoría de los campos en blanco en dicho aspecto.
Tonos medios y señal de advertencia Indican que el producto tiene menos de la mi-tad de los campos en blanco en dicho aspecto. Tonos claros y señal de aprobado Indican que todos los campos de dicho aspecto
se encuentran correctamente llenados.
Lo anterior se puede apreciar en la siguiente figura.
Sin categoría
Vestuario
Aseo – Aseo Personal
Hogar
Autopartes - Herramientas
Papelería
Electrodomésticos
venciones estándar de GS1 y que, al cometer un error de digitación, se genere una alerta audiovisual que le indique al usuario el error y cómo corregirlo.
7.2.3 El proceso de desarrollo
La aplicación móvil utilizada para este proyecto parte de un prototipo previamente elaborado, que trabajaba sobre una base de datos simplificada, cuyas entidades eran apenas las tres necesarias para demostrar su funcionamiento: visita, empresa y producto.
La aplicación fue desarrollada para una asignatura de la Maestría en Ingeniería de Sistemas y Com-putación (MISYC) de la Pontificia Universidad Javeriana, así que se venía trabajando en la solución al problema de calidad de datos en los procesos de retail de la mano con GS1 desde Agosto de 2012
y en vista de que el proyecto quedó “congelado” al finalizar el año 2012, se le quiso dar continuidad
y ponerlo en marcha para el presente año.
apli-más apegada a la solución de un problema global a todas las organizaciones que hacen uso del catá-logo electrónico.
Adicionalmente, se perfeccionaron detalles de interfaz gráfica de usuario, correspondientes a com-ponentes de despliegue gráfico, que en un momento dado fueron planteados como soluciones, pero el tiempo de desarrollo no permitió que se terminaran.
Al hacer uso de servicios web en versiones previas, adaptar la aplicación a la nueva base de datos, fue una actividad trivial que no presentó problemas mayores de compatibilidad. De esta manera, el proceso de desarrollo del semestre con respecto a la aplicación móvil consistió en:
Adaptar los datos provenientes de GS1 al despliegue gráfico de la aplicación.
Hacer uso de servicios web, desarrollados sobre la plataforma .NET de Microsoft, de manera que se manejara el acceso a datos en una capa intermedia.
Perfeccionar detalles de interfaz gráfica de usuario.
Añadir un filtrado por categorías aun más genéricas (apodadas categorías smart) que las manejadas como categorías estándar dentro de las bases de datos de GS1.
7.3 Integración de aplicaciones
Las aplicaciones del sistema fueron desarrolladas todas a la par en un ambiente de red local, de manera que las pruebas que se hicieron la mayor parte del tiempo fueron locales.
Se trabajó sobre un ambiente de desarrollo que integraba Servicios Web de .NET, desarrollados sobre Visual Studio 2010, La aplicación móvil, desarrollada sobre el I.D.E. Eclipse Juno, corre sobre una tablet Samsung Nexus 10, la base de datos Metamodelo, montada en un servidor SQL Server de GS1 Colombia.
