PROYECTO DE GRADO
Presentado a
LA UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIER´
IA
DEPARTAMENTO DE INGENIER´
IA EL´
ECTRICA Y ELECTR ´
ONICA
Para obtener el t´ıtulo de
INGENIERO ELECTR ´
ONICO
por
Christian Felipe Amaya C´
aceres
SmartStock: Stocktaking & sales control solutions
Sustentado el 11 de Diciembre de 2014 frente al jurado:
Composici´
on del jurado
- Asesor: Fredy Segura Q. PhD, Profesor Titular, Universidad de Los Andes
CFAC
Agradecimientos
Quiero agradecer a mi familia y amigos que ayudaron aportando para mi educaci´on y formaci´on desde temprana edad. A la Universidad de los Andes por ser un espacio en el que se permite el pensamiento propio y auto-cr´ıtico para generaci´on de conocimiento. A los maestros que transmiten el conocimiento y se interesan en ser guias en el proceso de aprendizaje.
Tabla de contenido
1 Resumen Ejecutivo 1
2 Introducci´on 3
2.1 Descripci´on de la problem´atica y justificaci´on del trabajo . . . 3
2.2 Alcance y productos finales . . . 4
2.3 Objetivos . . . 4
2.3.1 Objetivo General . . . 4
2.3.2 Objetivos Espec´ıficos . . . 5
3 Marco te´orico, conceptual e hist´orico 6 3.1 Marco Te´orico y conceptual . . . 6
3.1.1 Introducci´on a Android . . . 6
3.1.2 Near Field Communication . . . 8
3.1.3 Servidor y Base de Datos . . . 10
3.2 Marco Hist´orico . . . 13
3.2.1 Antecedentes . . . 13
4 Definici´on y especificaci´on del trabajo 14 4.1 Definici´on . . . 14
4.2 Especificaciones y Restricciones . . . 14
4.2.1 Especificaci´ones . . . 14
4.2.2 Restricciones . . . 14
4.2.3 Diagrama de bloques . . . 15
5 Metodolog´ıa del trabajo 16 5.1 Plan de trabajo . . . 16
5.2 Alternativas de desarrollo . . . 17
5.3 Desarrollo aplicaci´on Android . . . 19
5.4 Desarrollo Servidor en App Engine . . . 21
6 Resultado Final 23 6.1 Descripci´on del Resultado Final . . . 23
7 Validaci´on del trabajo 26 7.1 Metodolog´ıa de prueba . . . 26
7.2 Validaci´on de los resultados del trabajo: Caso de aplicaci´on Joyeria AJR’s . . . 27
8 Conclusiones y trabajos futuros 33 8.1 Conclusiones . . . 33
8.2 Trabajo Futuros . . . 33
TABLA DE CONTENIDO iii
Referencias 34
´
Indice de figuras
2.1 Esquema estado actual y estado al que se desea llegar . . . 4
3.1 Arquitectura del sistema operativo Android . . . 7
3.2 Tres modos de operaci´on a los que operan los dispositivos compatibles con tecnolog´ıa NFC . . . 8
3.3 Usos, productos y servicios venideros para tecnolog´ıa NFC . . . 9
3.4 Especificaciones tecnicas para los tipos de definici´on de grabaci´on (RTDs) . . . 10
3.5 Tipos de servicios para plataformas de computo en la nube . . . 11
3.6 Crecimiento estimado en ventas de mercados en la nube . . . 12
3.7 Ejemplos de empresas en cloud computing . . . 13
4.1 Diagrama de bloques del sistema . . . 15
5.1 Plan de trabajo Inicial . . . 17
5.2 Mercado Mundial de ventas de SmartPhones desde 2011 hasta segundo cuarto de 2014 18 5.3 Diagrama UML del mundo para la aplicaci´on m´ovil . . . 20
5.4 Diagrama UML para la clase principal de SmartStock . . . 21
5.5 Cloud Endpoints de Google . . . 21
5.6 Diagrama de clases general del Servidor . . . 22
6.1 icono de acceso a la aplicaci´on en Android . . . 23
6.2 Ventana buscar . . . 24
6.3 Icono de acceso a la aplicaci´on en Android . . . 25
7.1 Libreta de anotaciones de ventas en peque˜nas empresas . . . 27
7.2 Algunos Productos a usar . . . 28
7.3 Cambio en el inventario para algunos productos . . . 30
7.4 Proceso de Implementaci´on (Uso Aplicaci´on M´ovil) . . . 31
7.5 registro de ventas separado de productos . . . 32
´
Indice de tablas
2.1 Tabla de precios actuales equipos para inventario . . . 3
7.1 Inventario inicial registrado . . . 29
Cap´ıtulo 1
Resumen Ejecutivo
SMARTSTOCK: STOCKTAKING & SALES CONTROL
SOLUTIONS
Estudiante: Christian Felipe Amaya C´aceres
Asesor: Fredy Segura Quijano, PhD
En peque˜nas y medianas empresas se tiene una problem´atica respecto a la forma en que se controlan las ventas, se registran productos, se manejan inventarios, y a la vez, se hace uso de tecnolog´ıas disponibles. El presente proyecto de grado tiene como finalidad cerrar la brecha creada entre empresas surgientes y tecnolog´ıas accesibles, debido a restricciones econ´omicas, de inmersi´on de tecnolog´ıa en industrias y de automatizaci´on de procesos.
As´ı, se desea dise˜nar una aplicaci´on m´ovil de f´acil entendimiento y operaci´on que incorpore her-ramientas tecnol´ogicas capaces de ayudar con el control de ventas y manejo de inventarios de empresas con poco presupuesto y/o inter´es de inversi´on en sistemas actuales de toma de inventarios.
Objetivos del proyecto de grado
Objetivo General
• Mejoramiento de procesos y atenci´on de clientes en empresas de servicio utilizando tecnolog´ıas actuales de f´acil acceso y bajo costo comparado con alternativas en el mercado actual.
Objetivos Espec´ıficos
• Crear una aplicaci´on que incorpore herramientas tecnol´ogicas e innovadoras (tags NFC) para el control de ventas e inventario de peque˜nas y medianas empresas.
• Creaci´on de la base de datos y servidor que presten el servicio de ”Cloud” para el almacene-namiento y manejo de datos provenientes de ventas y compras de productos.
• Dise˜nar pruebas para validar el correcto funcionamiento del prototipo.
CAP´ITULO 1. RESUMEN EJECUTIVO 2
Resultados Esperados
De acuerdo al cronograma presentado en la propuesta inicial, se distinguen 3 alcances que se de-sean lograr en el transcurso del proyecto de grado:
A. Aplicaci´on funcional con comunicaci´on por NFC y c´amara para el registro de art´ıculos (dise˜no de interfaz b´asico). (100% completo)
B. Aplicaci´on M´ovil con conectividad a servidor e intercambio de datos (interf´az modificada). (90% completo)
Cap´ıtulo 2
Introducci´
on
Los objetivos educativos de la Universidad de los Andes contemplan la capacidad de sus ingenieros para desarrollar soluciones desde la electr´onica que generen riqueza y bienestar social incorporando el estado de arte en su disciplina, aprovechando oportunidades de innovaci´on con autonom´ıa y capacidad de aprendizaje cont´ınuo. Adem´as, como un ingeniero en la sociedad se espera la capacidad del mismo para participar eficazmente en marcos interdisciplinados, para solucionar problemas de la sociedad. El presente proyecto de grado busca hacer uso del sistema operativo de codigo libre Android para dar soluci´on a un problema en la industria de peque˜nas y medianas empresas (Pymes) con el fin de hacer frente a un problema de contexto real con herramientas de soluci´on desde la ingenier´ıa.
De ´esta forma, se espera un impacto positivo en la situaci´on actual de la problem´atica.
2.1
Descripci´
on de la problem´
atica y justificaci´
on del trabajo
Actualmente el desarrollo de sistemas de registro en micro peque˜nas y medianas empresas (micro-pymes) de la industria colombiana implica costos altos para la capacidad de inversi´on en equipos que dichas compa˜n´ıas poseen. Lo anterior causa que se opten por sistemas poco novedosos y antiguos para el registro de productos, manejo de inventarios, bases de datos de clientes y generaci´on de facturas. Lo que se desea implementar es un sistema novedoso, ´util, de f´acil acceso y uso a un costo razonable haciendo uso de la capacidad de procesamiento de un tel´efono inteligente y recursos de f´acil obtenci´on como lo son etiquetas NFC (tags). Lo anterior con el fin de incrementar el uso de herramientas tecnol´ogicas en aplicaciones industriales reales a partir de una soluci´on de ingenier´ıa, obteniendo un mejoramiento en la calidad de servicios en micro-pymes con respecto al actual sistema registradora-libro de entradas-recibos en MS-DOS)
los precios actuales de adquisici´on, puesta en marcha y mantenimiento de equipos para el manejo de inventarios y ventas se muestran en la tabla 1.1:
Tabla 2.1: Tabla de precios actuales equipos para inventario
item Rango de Valor
M´aquina registradora $1’600.000-$1’800.000 Software y Capacitaci´on $600.000-$800.000
Se estima que, como consecuencia a la falta de desarrollo tecnol´ogico la mitad de las pymes mueren en los primeros 5 a˜nos de funcionamiento en colombia(Redacci´on tecnol´ogica El Tiempo, 2013). ´Esto
CAP´ITULO 2. INTRODUCCI ´ON 4
Figura 2.1: Esquema estado actual y estado al que se desea llegar
sumado a que de acuerdo al considerable crecimiento del uso de sistemas basados en almacenamiento en la nube, se espera una mayor atenci´on de la industria hacia soluciones de automatizaci´on que incluyan ´este tipo de sistemas y que permitan generar una mayor productividad y beneficios para las peque˜nas y medianas empresas.(Leloglu, Ayav, & Galip, 2013), resulta en el planteamiento de la necesidad de que el sector de las pymes tenga acceso a sistemas tecnol´ogicos de bajo costo para impulsar su crecimiento en lugar de frenarlo, pues ´este sector de la microindustria representa actualmente el 37 % del producto interno bruto del pa´ıs.
Dentro de ´este contexto, la soluci´on tendr´ıa un impacto considerable en empresas actuales y nacientes que concentran su presupuesto en actividades escenciales de su raz´on social y no en grandes inversiones en sistemas de inventareo y control de ventas. Adicionalmente, al atacar el problema del manejo de inventario, se podr´ıa contribuir al mejoramiento en la atenci´on de clientes entendido como la forma en que el anterior interact´ua tanto con el personal humano como con los recursos disponibles. Generando valor para la empresa al incrementar la buena percepci´on que tengas los clientes de ´esta.
2.2
Alcance y productos finales
De acuerdo al planteamiento inicial de la propuesta de proyecto de grado, los compromisos adquiridos y productos finales deseados son:
• Prototipo funcional consistente de:
– aplicaci´on m´ovil en Android con conectividad a servidor y base de datos que registre pro-ductos y lleve a cabo tareas de control de ventas
– sistema novedoso de registro usando NFC
• Resultado de estudio de mercado e implementaci´on en un negocio comercial real
2.3
Objetivos
2.3.1
Objetivo General
• Mejoramiento de procesos y atenci´on de clientes en empresas de servicio utilizando tecnolog´ıas actuales de f´acil acceso y bajo costo comparado con alternativas en el mercado actual.
CAP´ITULO 2. INTRODUCCI ´ON 5
2.3.2
Objetivos Espec´ıficos
• Crear una aplicaci´on que incorpore herramientas tecnol´ogicas e innovadoras (tags NFC) para el control de ventas e inventario de peque˜nas y medianas empresas.
• Creaci´on de la base de datos y servidor que presten el servicio de ”Cloud” para el almacene-namiento y manejo de datos provenientes de ventas y compras de productos.
Cap´ıtulo 3
Marco te´
orico, conceptual e
hist´
orico
3.1
Marco Te´
orico y conceptual
3.1.1
Introducci´
on a Android
¿QU ´E ES ANDROID?
Android es un sistema operativo m´ovil basado en Linux Kernel desarrollado por Android Inc., que est´a actualmente administrado por la Open Handset Alliance (liderada y comprada por Google Inc.) Esta plataforma provee un set completo de software para dispositivos m´oviles: un kit de desarrollo de software (SDK), interfaces de programaci´on de aplicaciones, y una colecci´on de librer´ıas que permiten la interacci´on facilitada con el Sistema Operativo. Dadas estas caracter´ısticas y dado que es un software open source, la plataforma permite el desarrollo de forma libre y f´acil de aplicaciones. Adicionalmente, es reconocido por diferentes plataformas de hardware m´oviles como tel´efonos inteligentes o tabletas, relojes inteligentes, televisores y dem´as.
CARACTER´ISTICAS PRINCIPALES
• Es un sistema de desarrollo integrado y flexible.
• Permite la programaci´on r´apida y de alto nivel en XML y Java
• Incluye herramientas inform´aticas como OpenGL, ON2, CSS, HTML5, PNG y JPEG.
• Es de bajo riesgo de desarrollo
• Contiene una m´aquina virtual Dalvik (DVM) la cual optimiza recursos para dispositivos m´oviles
• Tiene soporte para comunicaciones (Bluetooth, 3G, WiFi, y EDGE) y soporte para perif´ericos como C´amara, GPS, etc.
• Es un software Open Source multiplataforma
• Es capacitado con la ADB: virtual machine
ARQUITECTURA DEL SISTEMA OPERATIVO
CAP´ITULO 3. MARCO TE ´ORICO, CONCEPTUAL E HIST ´ORICO 7
Figura 3.1: Arquitectura del sistema operativo Android
Aplicaciones
El primer nivel, contiene aplicaciones por defecto de Android y aquellas que el usuario vaya a˜nadiento atrav´es de la tienda de aplicaciones, o de su propia autor´ıa. Todas ´estas aplicaciones utilizan los ser-vicios, API y librerias de los niveles anteriores.
Framework de aplicaciones
Son el conjunto de herramientas de cualquier aplicaci´on. Todas las aplicaciones, sin importar su proce-dencia, usan el mismo conjunto de API y el mismo ”Framework”.
Entre las API m´as importantes se distinguen [10]:
• Administrador de actividades: API que gestiona el ciclo de vida de las aplicaciones en el sistema operativo Android.
• Administrador de ventanas: Utiliza la libreria surface Manager y gestiona las ventanas de apli-caciones.
• Administrador de telefonia: son todas las API que tienen que ver con las funcionalidades propias del tel´efono como llamadas, mensajet, etc.
• Proveedor de contenidos: Permite a cualquier aplicaci´on compartir sus datos con las dem´as aplicaciones de Android. ´Esta API permite que la informaci´on de contactos, mensajes, calendario, etc. sea accesible para otras aplicaciones.
• Vista del sistema: proporciona elementos para poder construir interfaces de usuario (GUI) como listas, mosaicos, botones,”check boxes”, tama˜no de ventanas, control mediante teclado, etc.
Librerias
CAP´ITULO 3. MARCO TE ´ORICO, CONCEPTUAL E HIST ´ORICO 8
programaci´on C/C++ y le proporcionan a Android la mayor parte de sus capacidades esenciales. entre las librerias m´as importantes en ´esta capa se encuentran:
• Libreria Libc: incluye todas las cabeceras y funciones de acuerdo al est´andar del lenguaje en C.
• libreria OpenGL/SL y SGL: son las librerias gr´aficas que majean gr´aficos en 3D y 2D, por lo que es la librer´ıa m´as habitual entre las aplicaciones.
• librer´ıa Media Libraries: proporciona todos los codigos necesarios para el contenido multimedia que soporta Android (video, audio, im´agenes, etc.)
• Librer´ıa SQLite: permite la creaci´on y gesti´on de bases de datos relacionales.
Tiempo de ejecuci´on de Android
de igual forma que la capa de las librer´ıas de Android, se sit´ua en el mismo nivel el entorno de ejecuci´on. ´
Este est´a constituido por las librer´ıas n´ucleo que poseen variedad de clases Java y la m´aquina vistual Dalvik.
N´ucleo Linux
El sistema operativo Android utiliza el n´ucleo de Linux 2.6 como una capa de abstracci´on para el hardware disponible en los dispositivos m´oviles. En dicha capa est´an contenidos los drivers necesarios para que cualquier componente hardware pueda ser utilizado mediante las llamadas que se realicen. Cada vez que un fabricante incluye un nuevo hardware, lo primero que debe hacer para que funcione en Android es crear las librer´ıas de control necesarias y debe hacerlo dentro de ´este kernel de Linux embebido en Android.
Figura 3.2: Tres modos de operaci´on a los que operan los dispositivos compatibles con tecnolog´ıa NFC
3.1.2
Near Field Communication
¿QU ´E ES NFC?
La comunicaci´on de campo cercano es una tecnologia de conectividad inal´ambrica est´andar de corto rango y frecuencia (13.54 MHz) que para usuarios de todo el mundo hace tareas mas convenientes y f´aciles por medio de transacciones, intercambio digital de contenido, interconexi´on de dispositivos con un toque, entre otras. NFC es compatible con cientos de millones de tarjetas ”ContactLess” y lectores
CAP´ITULO 3. MARCO TE ´ORICO, CONCEPTUAL E HIST ´ORICO 9
Figura 3.3: Usos, productos y servicios venideros para tecnolog´ıa NFC
ya implementados en todo el mundo.
La tecnolog´ıa NFC complementa varias tecnolog´ıas inal´ambricas de consumo populares, al utilizar los elementos clave en los estandares existentes para tarjetas de no-contacto (ISO/IEC 14443 A&B y JIS-X 6319-4). ´Esta tecnolog´ıa puede ser compatible con las tarjetas existentes y permite a los usuarios usar un solo dispositivo en diferentes sistemas e infraestructuras.
Todo lo anterior significa facilidades para el usuario, conexi´on simple, transferencia r´apida y compar-timiento de datos simples de forma m´as eficiente.
¿QU ´E HACE NFC?
´
Esta tecnolog´ıa hace m´as eficiente las tecnolog´ıas de no-contacto existentes, permitiendo soluciones en ´areas como recolecci´on e intercambio de datos, control de accesos, cuidado de la salud, fidelidad de clientes y cupones, transporte p´ublico, pagos electr´onicos y dispositivos electr´onicos de consumidores.
Las 3 formas de uso de NFC de acuerdo al NFC Forum son mostradas en la figura 3.2
• Tag/Card Reader: el modo de lectura/escritura permite a dispositivos compatibles con NFC leer y modificar informaci´on almacenada en tags NFC de bajo costo y embebidos en los denominados ”Smart Posters”y displays, dando una muy buena herramienta de mercadeo a las compa˜n´ıas.
• Point to Point communication: (dispositivo a dispositivo) Permite a dos dispositivos compatibles con NFC comunicarse para intercambiar informaci´on y compartir archivos, de forma que los dispositivos puedan r´apida y f´acilmente conectarse y comunicarse con un toque (cercan´ıa). Es muy usado en el intercambio de tarjetas de negocios o fotos digitales. El modo P2P (point to point
CAP´ITULO 3. MARCO TE ´ORICO, CONCEPTUAL E HIST ´ORICO 10
Figura 3.4: Especificaciones tecnicas para los tipos de definici´on de grabaci´on (RTDs)
o peer-to-peer) est´a estandarizado con la norma ISO/IEC 18092 y se basa en las especificaciones t´ecnicas del protocolo de control del NFC Forum.
• Card Emulation: (elemento seguro) ´Este modo permite a dispositivos compatibles con NFC funcionar como tarjetas inteligentes, dejando a los usuarios realizar transacciones para compras, tiquetes, y control de acceso con solo un toque. Lo anterior permite pagos electr´onicos y creaci´on de tiquetes sin realizar cambio alguno en la infraestructura disponible.
RTD (Record Type Definition)
Los tipos de grabaciones que permite la comunicaci´on de campo cercano son grabaciones de texto( forma eficiente de almacenar cadenas de texto en m´ultiples lenguajes con el uso de mecanismos RTD y formato NDEF); URI( provee una forma eficiente de almacenar identificadores uniformes de recursos, utilizando mecanismos RTD y formatos NDEF); como Smart Poster (define un protocolo especifico de grabar Tags NFC con direcciones URL, SMS y numeros de tel´efono, asi como transportar entre dispositivos la informaci´on. Los bloques de construcci´on de los Smart Posters son URI RTD y texto RTD) y control gen´erico.
3.1.3
Servidor y Base de Datos
¿QU ´E ES UN SERVIDOR WEB?
Un servidor es un ordenador remoto que provee los datos solicitados por parte de los navegadores de otros usuarios. En redes locales se entiende como el software que configura un PC como servidor para facilitar el acceso a la red y sus recursos.
Los Servidores almacenan informaci´on y , en forma de p´aginas web, la entregan a petici´on de los clientes (navegadores web). Son los medios de comunicaci´on entre el usuario y los datos, de manera que son fundamentales en aplicaciones en la nube.
CAP´ITULO 3. MARCO TE ´ORICO, CONCEPTUAL E HIST ´ORICO 11
Base de Datos
Una base de datos es un almac´en de datos con diferentes modos de organizaci´on. Representa datos del mundo real de inter´es para el usuario y son almacenadas con un prop´osito espec´ıfico en un sistema de computo por un determinado periodo de tiempo. Los denominados sistemas de manejo de bases de datos (DBMS) se encargan de permitir al cliente almacenar, acceder y modificar la informaci´on dentro de una Data Base [8].
Teniendo en cuenta que la forma en que la informaci´on es organizada puede tener un efecto consider-able en la facilidad y efectividad con la que se accede a la misma y la forma en que se maneja, existen principalmente dos clasificaciones de los datos que se almacenan en tablas: :
• Tablas Relacionales:
aquellas basadas en la idea de organizaci´on de datos en colecciones de tablas de dos dimensiones llamadas ”Relaciones” y a trav´es de dichas relaciones se conectan los datos entre diferentes tablas.
• Tablas No-Relacionales: Tambi´en llamadas NoSQL o de almacenamiento estructurado, son una clase de gesti´on de informaci´on en el que los datos almacenados no requieren estructuras fijas como tablas. Lo anterior permite el manejo de datos de diferentes tipos como los orientados a grafos, documentales, de clave/valor (BigTable), entre otras.
Las tablas no relacionales surgen de los desafios en el tratamiento de datos que tuvieron empresas de internet como Google, Twitter y Facebook.
Computaci´on en la nube
Existen principalmente 4 divisiones en cuanto a los tipos de servicios en la nube, de acuerdo a la
Figura 3.5: Tipos de servicios para plataformas de computo en la nube
CAP´ITULO 3. MARCO TE ´ORICO, CONCEPTUAL E HIST ´ORICO 12
Software. La primera significa que el usuario es el que se encarga de realizar todas las tareas desde la creaci´on de la red, adquisicion y configuracion del servidor, los datos y la aplicaci´on. Los servicios de infraestructura (Infrastructure as a Service o IaaS) proveen al cliente los procesos de estructura necesarios para que ´este se enfoque en el sistema operativo y aplicaci´on. Los servicios de plataforma (Platform as a Service o PaaS) permiten que el usuario solo se preocupe por la creaci´on y manejo de los datos y la aplicaci´on al proveerlo con todos los servicios de sistema operativo y hardware de la red. Los servicios de software (SaaS) que ofrecen actualmente varias empresas corresponden al servicios en los que el usuario presenta requerimientos especificos y toda la responsabilidad de la computaci´on en la nube la realiza la empresa.
La figura 3.5 muestra los tipos de servicios en la nube con los que se trabaja actualmente as´ı como los servicios que prestan diferentes tipos de compa˜n´ıas.
La justificaci´on detr´as del uso de Plataformas en la nube es el considerable crecimiento y tendencia que desde 2011 se observa en el mercado. La figura 3.6 muestra el crecimiento estimado de la inversi´on an-ual de empresas en servicios en la nube (cloud computing) con detalle para Servicios de infraestructura (IaaS), plataforma (PaaS), Software y el esperado crecimiento hacia servicios denominados Procesos de negocios( Business Process as a Service o BPaaS).
Figura 3.6: Crecimiento estimado en ventas de mercados en la nube
Algunos ejemplos de plataformas de computaci´on en la nube ofreciendo actualmente sus servicios son mostrados en la figura 3.7
CAP´ITULO 3. MARCO TE ´ORICO, CONCEPTUAL E HIST ´ORICO 13
Figura 3.7: Ejemplos de empresas en cloud computing
3.2
Marco Hist´
orico
3.2.1
Antecedentes
De acuerdo a la justificaci´on planteada sobre la importancia de la cadena de inventarios en una empresa de servicios, se encontraron algunos trabajos (detalle en referencias [13] [6] [12]) relacionados con la problem´atica. En dichos trabajos se encuentra una justificaci´on relacionada con el correcto manejo de inventarios, necesidad de control de responsabilidades relacionadas con entradas y salidas de dinero en establecimientos comerciales y seguimiento de tendencias de mercado para optimizaci´on de pedidos a minoristas.
En el contexto global, se encontr´o un proyecto af´ın realizado por la empresa de suplementos de se-guridad industrial Rope, Soap And Dope [14]. El proyecto, llevado a cabo en 2013, consisti´o en el desarrollo de un sistema para clientes exclusivos de la empresa que permitiera crear ordenes de compra, ver estad´ısticas de ventas y obtener el inventario en tiempo real de sus negocios. Lo anterior con el fin de mantener una comunicaci´on de una forma mas eficiente con los distribuidores.
Cap´ıtulo 4
Definici´
on y especificaci´
on del
trabajo
4.1
Definici´
on
La soluci´on que se plantea es el dise˜no de un prototipo de aplicaci´on m´ovil que tenga interacci´on con etiquetas con tecnolog´ıa NFC (Near Field communication) y servicios Cloud para el almacenamiento y manejo de la informaci´on. Dicha soluci´on ser´a aplicada en peque˜nas y medianas empresas (Pymes) que, por la naturaleza de su raz´on social, requieran el manejo de inventarios. Adem´as la aplicaci´on es soluci´on para empresas que, aunque no manejen inventarios, quieran llevar a cabo su manejo de caja y de ventas de una forma mas eficaz y con uso de tecnolog´ıa.
el acceso a los servicios ofrecidos ser´a m´ınimo comparado con las alternativas de control de ventas e inventarios en el mercado actual (haciendo uso de tecnolog´ıa). Con seguridad y protecci´on de los datos almacenados.
4.2
Especificaciones y Restricciones
4.2.1
Especificaci´
ones
• se podr´a crear una base de datos con productos (cliente)
• mediante link al servidor, los usuarios interactuar´an con la base de datos viendo especificaciones de los productos asi como disponibilidad y promociones.
• Protocolo de comunicaci´on: NFC (local), Wi-fi/EDGE/3G/HSPA/LTE (servidor)
• El cliente podr´a descargar los datos del servidor a un archivo CSV con el fin de realizar an´alisis posteriores y/o la propia a plicacion tendra estad´ısticas simples sobre tendencias de ventas e inventario(Deseable)
4.2.2
Restricciones
• se investigo sobre plataformas de lenguaje intermedio y se realiz´o una comparaci´on con debili-dades fortalezas y amenazas sobre la viabilidad de implementaci´on versus una plataforma nativa. Se lleg´o a la conclusi´on de que, por motivos principales de compatibilidad y simplicidad, se tra-bajar´ıa en el sistema operativo android con su SDK de Eclipse.
• el dispositivo en el que se ejecuta la aplicaci´on debe ser compatible con Android y (deseable) tener funcionalidad NFC
CAP´ITULO 4. DEFINICI ´ON Y ESPECIFICACI ´ON DEL TRABAJO 15
• se debe contar con conexi´on a internet estable, sea proveniente de una red Wi-Fi o la misma red de datos del tel´efono m´ovil.
• Sistema operativo android 3.0 API 11 o superior.
• tiempo de ejecuci´on de la implementaci´on deseada. por cronograma son 3 semanas de imple-mentaci´on y para este momento todo el prototipo deber´ıa estar terminado y corregido.
4.2.3
Diagrama de bloques
La Figura 3.1 muestra el diagrama de bloques del sistema, como entradas se tienen los productos del inventario del cliente que son los que alimentan la base de datos; Los requerimientos de los usuarios que interactuan con la etiqueta NFC y el servidor. Como salidas se tiene la informaci´on a los usuarios proveniente del servidor y la informaci´on del cliente (administrador de la aplicaci´on) sobre el estado de ventas e inventario.
Cap´ıtulo 5
Metodolog´ıa del trabajo
De acuerdo al planteamiento inicial y el proceso de dise˜no de la soluci´on, se identificaron 3 actividades principales que, con sus principales hitos, son presentados a continuaci´on :
• Actividad Comunicaci´on (NFC y Servidor)
– Caracterizaci´on funcionamiento NFC.
– An´alisis de requerimientos y restricciones del Servidor.
– Selecci´on de servidor y base de datos de acuerdo a an´alisis realizado.
– An´alisis mejor uso de etiquetas NFC en establecimientos comerciales.
• Actividad Aplicaci´on
– An´alisis de requerimientos funcionales.
– Dise˜no de interfaz de acuerdo a requerimientos.
– Ejemplos no integrados de de comunicaci´on con servidor,base de datos, NFC.
–
• Actividad implementaci´on Real
– Estudio de mercado para aplicaci´on de prototipo.
– Contacto locar comercial para implementaci´on.
– tutorial de uso de aplicaci´on prototipo.
Describa el trabajo realizado posterior a tener las especificaciones iniciales y hasta el final del proceso de validaci´on. Esta informaci´on debe ser soportada por resultados parciales de su proceso de dise˜no: simulaciones, mediciones, tablas de datos, etc.
5.1
Plan de trabajo
Dentro del plan de trabajo se contemplaron tanto los hitos mencionados previamente en la metodolog´ıa, como los siguientes alcances:
• Creaci´on de un proyecto prototipo consistente de los siguientes alcances:
A. Funcionalidad con NFC y c´amara.
B. Interfaz Aplicaci´on M´ovil con conectividad a servidor e intercambio de datos.
C. Resultados de implementaci´on en negocio comercial por algunas semanas.
CAP´ITULO 5. METODOLOG´IA DEL TRABAJO 17
Figura 5.1: Plan de trabajo Inicial
5.2
Alternativas de desarrollo
• Android Vs plataforma de lenguaje intermedio
Una de las primeras dudas en la definici´on del trabajo fu´e la selecci´on del lenguaje de programaci´on a utilizar, lo anterior depende del sistema operativo para el cu´al se desea la implementaci´on.
Entre las opciones de sistemas operativos m´oviles se tiene IOS de apple, Android OS de google, Sym-bian, Windows phone, y el sistema operativo de BlackBerry de RIM
Adem´as de los anteriores, se tienen los lenguajes intermedios, como el proyecto Phone Gap, que per-miten realizar aplicaciones de forma gen´erica para varios dispositivos. Al consultar la viabilidad de programar en phoneGap (en general plataformas con lenguajes intermedios), se encontr´o que el las aplicaciones que se pueden generar con dichos c´odigos son no-nativas para cada sistema operativo. Lo anterior significa que, ya que se hace de forma gen´erica, muchas de las funciones espec´ıficas en cada sistema operativo no podr´an ser usadas y en muchos casos, para lograr compatibilidad entre los diferentes sistemas operativos, se debe hacer uso de lenguajes propios de los mismos.
Teniendo en cuenta lo anterior y que para los diferentes sistemas operativos existen restricciones tanto de hardware, econom´ıa, simplicidad y funciones propias, se decidi´o trabajar con el sistema operativo Android. ´Este sistema no solamente tiene mayor soporte por parte de la comunidad de programadores, resulta mas econ´omica la suscripci´on anual como desarrollador de Android o, como se evidencia en la gr´afica de ventas de smartphones por categoria, es de mayor tendencia actual y futura de uso entre el p´ublico en general; Sino que tambi´en tiene caracter´ısticas que se acoplan mejor al proyecto deseado como el manejo interno de bases de datos por SQLite, librer´ıa propia y liderazgo en programaci´on con tecnolog´ıa NFC, entre otros.
International Data
Corporation-• NFC vs bluetooth vs wi-fi vs QR code
Otra alternativa que se tuvo bajo criterio de elecci´on fue el tipo de tecnolog´ıa o mecanismo que se usar´ıa para la comunicaci´on entre el dispositivo m´ovil, actuando como registradora, y los productos pertenecientes al inventario a manejar.
CAP´ITULO 5. METODOLOG´IA DEL TRABAJO 18
Figura 5.2: Mercado Mundial de ventas de SmartPhones desde 2011 hasta segundo cuarto de 2014
• Bluetooth: Se refiere al protocolo de comunicaciones dise˜nado especialmente para dispositivos de bajo consumo, que requieren corto alcance de emisi´on y basados en transceptores de costo moderado. el alcance de ´estos dispositivos est´a en un radio de entre los 5 y 10 metros.
• Wi-Fi: para el caso de Wi-Fi,el establecimiento de comunicaci´on necesita una configuraci´on previa. Utiliza el mismo espectro de frecuencia que Bluetooth con una potencia de salida mayor que lleva a conexiones m´as s´olidas.
• NFC: las etiquetas NFC pueden ser reutilizadas cada vez que se le quiera dar un diferente uso, se estima que su tiempo de vida es de unos 10 a˜nos, comprando en grandes cantidades su costo es menor de los US 0.1 y su consumo es ¡ de 15mA.
• C´odigo QR: permite un m´aximo de 2953 bytes, requiere que cada nuevo uso que se quiera dar deba ser re-escrito y el doblarse el material resulta dificil realizar la lectura del mismo. Por otro lado, es muy econ´omico teniendo en cuenta la capacidad que se puede almacenar.
Entre las diferentes opciones analizadas, se decidi´o optar por la tecnolog´ıa NFC pues su ca-pacidad de almacenamiento es de m´aximo 1.6 MB (apropiado dados los requerimientos exigidos por el proyecto), sus costos de adquisici´on son reducidos comparados con los costos de tecnolog´ıa bluetooth, su consumo es mucho menor comparado con dispositivos wi-fi o bluetooth y, dado que se va a trabajar con servicios en la nuve, resulta simple grabar un link para consulta de m´as datos relacionados con un producto, en lugar de grabar toda la informaci´on en un c´odigo QR [4] .
• Elecci´on Servidor y Base de Datos
Entre las opciones disponibles de computo en la nube (ver marco te´orico) se escogi´o el servicio de plataforma Paas (Platform as a Service). Lo anterior debido a los requerimientos especificados para ´este proyecto (recursos, tiempo y optimizaci´on) y adem´as por la gran variedad de empresas en internet
CAP´ITULO 5. METODOLOG´IA DEL TRABAJO 19
que ofrecen sus servicios dependiendo de la necesidad del usuario.
Dentro de los servicios PaaS se encontraron, teniendo en cuenta las necesidades de almacenamiento y servicios web con funcionalidad en android, principalmente 3 alternativas de plataformas por las que optar.
• Google App Engine: es un servicio de alojamiento web que es gratuito hasta ciertas cantidades de informaci´on. El servicio permite ejecutar aplicaciones sobre la infraestructura de google, se puede solicitar un dominio propio o usar el de app engine para ´estos propositos (appspot.com). permite 500 MB gratuitos de almacenamiento (suficientes para 5 millones de visitas mensuales). Permite los lenguajes de programaci´on de Pythin, Java, Go y PHP. Posee su propia base de datos.
• microsoft Azure: es una PaaS alojada en los centros de datos de microsoft. permite alojar aplicaciones en su infraestructura en una autodenominada capa en la nube (Cloud Layer). usa microsoft SQL Azure como base de datos para alojar la informaci´on de las aplicaciones. Adem´as de los lenguajes que soportan otros servicios en la nube, soporta c++
• OpenShift By Red Hat:es una plataforma de servicio de red hat que funcionacon codigo abierto y es usado para desplegar aplicaciones web en diferentes lenguajes soportados como Node.js, ruby, python php,perl y java. Tiene un buen soporte con frameworks para PHP ruby phyton y perl. no posee base de datos propia.
Teniendo en cuenta las caracter´ısticas que ofrece cada servicio PaaS seleccionado, el que mejor se acopla a las necesidades de ´este proyecto fu´e Google App Engine. La elecci´on se hizo debido a la gratuidad ofrecida, adem´as de f´acil escalabilidad al aumentar la demanda de productos/clientes,en caso de resultar exitoso el proyecto.
Adem´as de lo anterior App engine ofrece,dentro de su amplia plataforma en la nube (Google Cloud Platform), un mecanismo especializado de gesti´on de informaci´on para plataformas m´oviles (IOS y Android) el cual permite almacenar y registrar toda la informaci´on proveniente de ´estos dispositivos de forma no-local, por medio de la comunicaci´on con el servidor en la nube.
• Selecci´on lenguaje de programaci´on Servidor.
Entre las opciones disponibles:
• Java
• Python
• PHP
• Ruby
• Perl
Se decidi´o trabajar con Python debido a la viabilidad consultada en creaci´on de paginas web asi como simplicidad para el manejo de formatos Json que son con los que se trabajar´an.
5.3
Desarrollo aplicaci´
on Android
La interfaz de usuario de la aplicaci´on es la imagen de todo el proyecto ante el usuario. En ella se evidencia cada uno de los aspectos y funcionalidades que tiene la aplicaci´on, asi como la comunicaci´on que tiene con el servidor para el intercambio de datos. SmartStock fu´e dise˜nada de acuerdo a la teor´ıa sobre aplicaciones en Android vista en el marco te´orico.
CAP´ITULO 5. METODOLOG´IA DEL TRABAJO 20
Figura 5.3: Diagrama UML del mundo para la aplicaci´on m´ovil
• SmartStock: Clase principal que por un lado, se comunica directamente con el servidor para la consulta, creaci´on y modificaci´on de datos. Por otro lado, se comunica con la clase Producto para obtener y crear caracteristicas propias para cada producto a registrar.
Dentro de la Clase SmartStock se encuentra la actividad MainActivity que en realidad solo se dedica a ser el anfitri´on para la visualizaci´on de 5 ventanas en la aplicaci´on (Ver figura 5.4 ):
– Ventana principal o Home: utilizara la funci´on de graficas de Android para generar es-tad´ısticas b´asicas de la operaci´on de la empresa. Adem´as proporciona informaci´on b´asica sobre t´erminos de uso de la aplicaci´on, version, entre otros.
– Ventana Buscar: por medio de la lectura de NFC adquiere los datos provenientes de un TAG NFC para hacer la b´usqueda en el servidor de la referencia le´ıda y, por medio del m´etodo HttpAsyncTask, modificarla.
– Ventana A˜nadir: Env´ıa al servidor los datos correspondientes a los atributos de un producto, a˜nade a la interfaz una imagen capturada por la c´amara del tel´efono para que el usuario especifique detalles gr´aficos a su producto. Finalmente escribe un TAG NFC con el nombre de la referencia del nuevo producto para que sea puesto al ´este.
– Ventana Carrito: Crea una lista expandible con las referencias de productos con una can-tidad inferior a 5 para tener en cuenta por parte del usuario con el fin de alimentar el inventario de ´estas existencias de nuevo.
– Ventana Registradora: Ventana que permite formalizar ante la base de datos las ventas re-alizadas en la empresa. Lee el TAG NFC, a˜nade productos a un carro de compras temporal, se comunica con la base de datos en el servidor para modificarlos.
• Producto: Clase que temporalmente almacena los los atributos de un nuevo producto con datos especificados por el usuario. Los atributos a editar y almacenar son:
– Referencia: Identificaci´on ´unica de producto, las 4 primeras letras (en may´usculas) especif-ican el tipo de producto y los dem´as d´ıgitos se reservan para enumeraci´on. Por ejemplo la referencia ”CUCH001” Corresponde, por efectos de manejo interno de inventario de ejemplo, al tipo cucharas y es la numero 1.
CAP´ITULO 5. METODOLOG´IA DEL TRABAJO 21
Figura 5.4: Diagrama UML para la clase principal de SmartStock
– Descripci´on: Breve resumen de las caracter´ısticas del producto a ingresar.
– Precio: Valor del Art´ıculo en espec´ıfico.
– Cantidad: Numero de unidades del mismo producto.
5.4
Desarrollo Servidor en App Engine
De acuerdo a la decisi´on sobre el uso de la plataforma en la nube de Google (ver secci´on de alternativas de desarrollo), y teniendo en cuenta que se deseaba crear un API (Application Programming Interface) que se alojara en el servidor y que manejara los datos enviados por la aplicacion m´ovil, se hizo uso de los Cloud endPoints de Google:
Figura 5.5: Cloud Endpoints de Google
Los EndPoints de Google son una soluci´on de la empresa para la creaci´on de APIs para sus aplicaciones en App Engine [1]. generan la posibilidad de creaci´on de librerias de cliente para terminales m´oviles como Android y IOS para facilitar el backend de cualquier funcionalidad incluida en la aplicaci´on web.
CAP´ITULO 5. METODOLOG´IA DEL TRABAJO 22
(Ver Figura 5.5 )
Teniendo en cuenta lo anterior, se realizo un backend del manejo que da el servidor a los datos recibidos antes de almacenarlos. El API, creado en python, contiene los m´etodos de listar e insertar los cuales pertenecen al API de la aplicaci´on. Dicho API est´a comunicado con dos clases encargadas del modelo para el manejo de los datos y de la comunicaci´on con la base de datos para listar. A su vez, las clases nombradas pertenecen a la clase principal Stock que es la que contiene la totalidad del backend. La anterior explicaci´on se ve plasmada en la figura 5.6 .
Figura 5.6: Diagrama de clases general del Servidor
La implementaci´on de la interf´az de programaci´on de la aplicaci´on (API) permite a la aplicaci´on m´ovil SmartStock la comunicaci´on directa con los m´etodos de insertar (mismo para modificar) y enlistar los productos existentes en la base de datos. Lo anterior se realiza mediante peticiones HTTP (ya sean de obtener como un GET o a˜nadir como un POST) mediante la direcci´on URL: https: //appsmartstock.appspot.com/_ah/api/stocks/v2/stock
Cap´ıtulo 6
Resultado Final
6.1
Descripci´
on del Resultado Final
Para el resultado final de la aplicaci´on SmartStock, se distinguen las funciones de la aplicaci´on m´ovil y las del servidor web.
• Funciones finales de la aplicaci´on o Interfaz general:
La interfaz Final de la aplicaci´on m´ovil consta de 5 ventanas incluidas en un mismo servicio de ventanas(en Android tabHost) cada una como una clase de la aplicaci´on representada por un bot´on de acci´on.
Figura 6.1: icono de acceso a la aplicaci´on en Android
– La primera corresponde al bot´on de inicio o home, el cual permite al usuario accedes a informaci´on b´asica como el nombre e icono de su empresa, estad´ısticas (deseado en versi´on beta) de la venta e inventarios, e informaci´on legal sobre la aplicaci´on y su versi´on. USO: informaci´on de inter´es y general
– La segunda ventana corresponde a la clase de b´usqueda y se accede a ella con el bot´on de b´usqueda (lupa). En ´esta clase el usuario puede hacer lectura de un tag NFC con una referencia, o ingresar un nombre de producto para hacer la b´usqueda del mismo en la base de datos (servidor). Posteriormente la aplicaci´on retorna las propiedades (nombre, referencia, precio, cantidad, descripci´on) del producto encontrado, o un mensaje de error en el caso de no ser encontrado. Mediante las opciones de eliminar y actualizar, El usuario puede modificar la informaci´on antes de subirla a la base de datos de nuevo, o eliminar el producto si as´ı lo desea. USO: modificaci´on de precio/cantidad/descripci´on al alimentar el inventario.
– La tercera ventana corresponde al bot´on de agregar. All´ı el usuario puede agregar una fotograf´ıa, un nombre, precio, cantidad y descripci´on a un producto, as´ı como una referencia (que se escribe en un tag NFC) y subir dicha informaci´on mediante el servidor a la base de datos. USO: Ingreso de nuevos productos a la base de datos.
– La cuarta ventana (con el bot´on de carro de compras) es donde se muestra (cada que el usuario lo desea) una lista con el nombre y la referencia de los productos del inventario que
CAP´ITULO 6. RESULTADO FINAL 24
tienen una cantidad inferior a cierto n´umero (Ej. 10 unidades del producto Reloj Swatch). Lo anterior, con el fin de informar al mismo sobre la baja disponibilidad del producto para tener en cuenta en la pr´oxima alimentaci´on de inventario. USO: alerta de inventario bajo para algunos productos.
– La ´ultima ventana (bot´on de caja registradora), es la clase en donde se efect´uan las ventas de productos. Mediante el escaneo NFC de una referencia (el producto comprado por un cliente) se realiza una b´usqueda en la base de datos en la nube, se agrega al carrito de compras del cliente y al finalizar el pedido total se efect´ua la venta, disminuyendo en 1 unidad el atributo cantidad en el servidor (para ese producto) y aumentando el precio de la venta para cada art´ıculo vendido. USO: Venta de productos, Registro de Ingresos detallado (Versi´on posterior)
NFC:
De acuerdo a la biograf´ıa consultada [ALGUNA] y las tendencias del mercado de tecnolog´ıa y espec´ıficamente tel´efonos m´oviles, se encontr´o que el uso de sistemas con NFC puede ser una soluci´on pr´actica, econ´omica, viable y simple para actividades diarias en peque˜nas y medianas empresas. Espec´ıficamente, como en este caso, se puede trabajar con inventarios y asignaci´on de referencias.
En las ventanas dos, tres y cinco de la aplicaci´on SmartStock se hizo uso de librer´ıas en Android que permiten en manejo de los recursos para etiquetas NFC con el est´andar permitido a la frecuencia de 13.56 MHz y de tipo RTD & NDEF (ver Figura 3.4). Estas etiquetas contienen, para cada art´ıculo, la referencia del producto al que pertenece como una identificaci´on de todas sus caracter´ısticas almacenadas en la nube. Caracter´ısticas a las cuales se accede y modifica cada vez que se lee una etiqueta por medio de la aplicaci´on.
Figura 6.2: Ventana buscar
• Funcionalidad En l´ınea:
Adem´as de la visualizaci´on y modificaci´on de los datos desde la aplicaci´on m´ovil, el usuario puede acceder en l´ınea desde cualquier dispositivo conectado a internet a una interfaz mediante la cual puede hacer consulta de los art´ıculos en inventario. o Interfaz de usuario para inventario: accediendo a la direcci´on URL: appsmartstock.appspot.com el usuario puede visualizar una tabla actualizada con los atributos o caracter´ısticas de cada producto en su inventario. La tabla debe ser actualizada para ver los ´ultimos datos insertados o modificados (refrescar el navegador)
CAP´ITULO 6. RESULTADO FINAL 25
Cap´ıtulo 7
Validaci´
on del trabajo
7.1
Metodolog´ıa de prueba
Para verificar el correcto funcionamiento de todas las funciones de la aplicaci´on y el servidor, se de-sarrollaron los siguientes protocolos de prueba:
1. B´usqueda de un producto en servidor:
Se verifica que al ingresar una referencia o un nombre en el servidor se visualicen de manera correcta los datos del producto en la pantalla de la aplicaci´on, previamente obtenidos del servidor.
2. Lectura NFC
Por medio de la lectura NFC se verifica que la escritura de los productos haya sido correcta. Si no lo es, deben salir mensajes de error manejados por la aplicaci´on (handlers)
3. Escritura NFC
Por medio de la identificaci´on de la etiqueta se escriben datos en esta. Luego, se verifica con la apli-caci´on que el contenido en la etiqueta sea el que se visualiza.
4. Actualizar de producto en servidor:
Por medio del acceso a la base de datos, se verifica que los datos ingresados en el Tab 3 de la aplicaci´on son guardados de manera correcta.
5. Agregar producto a servidor:
Por medio del acceso a la base de datos, se verifica que los datos cambiados en el Tab 3 de la aplicaci´on son guardados de manera correcta.
6. Tomar foto:
Se verifica que la imagen almacenada en el dispositivo sea visualizada en la aplicaci´on en la Tab 3 de la aplicaci´on.
7. Obtener lista de productos con bajo inventario:
En la Tab 4 de le aplicaci´on, se verifica que por medio del acceso a la base de datos, los productos con cantidad menor a 10 unidades son los que aparecen en la lista.
8. Vender producto:
Por medio del acceso a la base de datos, se verifica que los datos cambiados en el Tab 3 de la aplicaci´on son guardados de manera correcta.
CAP´ITULO 7. VALIDACI ´ON DEL TRABAJO 27
9. Correcta visualizaci´on en el servidor (correcto funcionamiento de m´etodos insertar y enlistar):
Ingresando al url: http://appsmartstock.appspot.com se verifica que las caracter´ısticas almace-nadas en la base de datos actual corresponden a la visualizaci´on html. De esta manera, se observa que los m´etodos insertar y enlistar funcionan de manera correcta.
7.2
Validaci´
on de los resultados del trabajo: Caso de
apli-caci´
on Joyeria AJR’s
Seg´un estaba estipulado en los objetivos del proyecto, para comprobar el funcionamiento y la utilidad de la aplicaci´on desarrollada en un ´ambito real, esta se implement´o en una peque˜na empresa de la ciudad de Bogot´a, Colombia. La empresa fue elegida tal que cumpliera con los siguientes requisitos:
•Mantenimiento de inventario a trav´es de libros a mano.
•Identificaci´on de productos usando etiquetas escritas a mano.
•Uso de registradora ´unicamente para almacenamiento de dinero.
•Acceso a internet.
•Acceso a tel´efono inteligente con sistema operativo Android.
•Inventario grande y establecido.
Teniendo esto en cuenta, se escogi´o la Joyer´ıa AJR’s ubicada en el barrio 7 de Agosto de la ciu-dad de Bogot´a. Este negocio es dirigido por el se˜nor Freddy Amaya y lleva en el mercado alrededor de 50 a˜nos. Se especializa en la venta de todo tipo de joyer´ıa y relojes, el arreglo y mantenimiento de estos y el dise˜no personalizado de joyer´ıa. Ocasionalmente vende perfumes, cremas y miscel´aneas.
Actualmente, su manejo diario de inventario se lleva a cabo por anotaciones de ventas en una li-breta. De tal manera, cuando se realiza una venta, se anota la referencia del producto y su valor en la libreta.
CAP´ITULO 7. VALIDACI ´ON DEL TRABAJO 28
Figura 7.2: Algunos Productos a usar
No se registran las salidas y entradas de productos diariamente. Esto se hace despu´es de un periodo de 1-2 meses usando las etiquetas previamente guardadas e ingresando las salidas y entradas en un Excel. Este proceso puede tardar alrededor de 4-6 horas. No se lleva un control estad´ıstico de ingresos/salidas por producto.(ver figura 7.5 )
Teniendo en cuenta la falta de eficiencia en el manejo de inventario de la compa˜n´ıa, se propuso im-plementar la aplicaci´on SmartStock con un inventario limitado y definido de productos durante una semana. El prop´osito ser´ıa observar el correcto funcionamiento de la aplicaci´on para manejo de in-ventario y realizaci´on de ventas en el negocio. Adicionalmente, se podr´ıa mirar la viabilidad de la aplicaci´on dise˜nada.
Su implementaci´on se llevo a cabo la semana del 24 al 29 de Noviembre del 2014. La aplicaci´on fue descargada al celular personal de la se˜nora Ruby Cac´eres quien maneja la caja e inventario en el local. El costo total de implementaci´on del sistema fue de $60,000 que equivale a la compra de 228 etiquetas NFC. Al principio del primer d´ıa se hizo un tutorial del funcionamiento de la aplicaci´on. As´ı mismo, el inventario se defini´o para incluir los diferentes tipos de productos: bater´ıas de relojes, relojes de referencias variadas, sets de cremas y perfumes y joyas varias (aretes y pulseras)(ver figura 7.2 )
CAP´ITULO 7. VALIDACI ´ON DEL TRABAJO 29
Tabla 7.1: Inventario inicial registrado
etiqueta NFC y creaci´on de base de datos. Para esto, primero a cada producto se le asign´o una eti-queta NFC. Una vez todos los productos estaban equipados con una etieti-queta, siguiendo el protocolo de prueba, se le asign´o a cada etiqueta una referencia de producto, definida por los due˜nos del local. Las referencias asignadas fueron las que se observan en la tabla 7.1
De esta manera, cada producto obtuvo su referencia, descripci´on, nombre y cantidad. Para productos de la misma referencia, se le asigno a la etiqueta NFC la informaci´on previamente ingresada. Toda esta informaci´on fue enviada al servidor. Una vez ingresado el inventario, se corroboro que en la p´agina URL el inventario estuviera completo. Posteriormente, durante todos los 6 d´ıas de prueba, se llevaron a cabo las siguientes actividades:
1. Buscar:
Para consultar el precio o cantidad de alg´un producto o proporcionar caracter´ısticas especificas de este a los clientes, se le´ıa la etiqueta NFC usando la funci´on Buscar de la aplicaci´on seg´un el protocolo de pruebas. De esta manera, se obten´ıan todas las caracter´ısticas del producto para proporcionar a los clientes.
CAP´ITULO 7. VALIDACI ´ON DEL TRABAJO 30
2. Vender:
Durante el d´ıa, cuando alguno de los productos del inventario era vendido, se usaba la funci´on Vender de la aplicaci´on. De esta manera, se pasaba la etiqueta por el lector del celular y siguiendo el protocolo de prueba para ventas de productos, se registraba la venta de estos.
Una vez realizada la venta, se observaba en la p´agina del servidor como iba evolucionando el inventario.
Figura 7.3: Cambio en el inventario para algunos productos
3. Modificaci´on de inventario:
En el tercer d´ıa se adicionaron 2 bater´ıas nuevas de una referencia espec´ıfica. Para modificar el in-ventario seg´un esta adici´on, se consulto la cantidad que hab´ıa en el inventario mirando la p´agina del servidor, se sumo la cantidad adicional, y usando el celular y el protocolo de prueba Agregar, se modific´o el inventario para incluir las nuevas adiciones. Al finalizar cada d´ıa se guardaba la informaci´on de inventario para ese d´ıa.
An´alisis de Datos
Una vez finalizada la semana de prueba, se hizo un an´alisis de los datos obtenidos. Con esta infor-maci´on, se grafic´o la evoluci´on del inventario por producto por d´ıa (Ver Figura 7.3 )
Finalmente, usando la aplicaci´on y siguiendo el protocolo de Alerta Inventario Bajo, se miraron los productos que estaban por debajo de 10 unidades al finalizar la semana (en figura 7.4 )
De esta manera, al final la semana se obtuvo un an´alisis del movimiento de productos, el m´as vendido, el menos vendido y aquellos productos cuya cantidad estaba por debajo de un n´umero definido. Todo esto se realiz´o en un tiempo menor a 5 minutos.
Resultados
Comparando los resultados obtenidos mediante el uso de la aplicaci´on con el sistema de inventario previo, hubo una significante disminuci´on en el tiempo utilizado para realizar una venta. Adem´as, se logro hacer un manejo de inventario diario e inmediato, ahorr´andole a la compa˜n´ıa el trabajo manual y largo tiempo al final del mes. As´ı mismo, se pudo hacer un an´alisis estad´ıstico de los movimientos de productos y se pudo determinar aquellos que estaban por debajo de la cantidad m´ınima para realizar un pedido nuevo de estos.
CAP´ITULO 7. VALIDACI ´ON DEL TRABAJO 31
Figura 7.4: Proceso de Implementaci´on (Uso Aplicaci´on M´ovil)
con los objetivos propuestos. Esto ya que hubo un manejo de inventario efectivo y f´acil, gener´andole costos muy bajos a la compa˜n´ıa (compra de los NFC etiquetas). Es claro que para su implementaci´on en todo el local, ser´ıa necesario primero hacer un inventario completo de todos los productos. Una vez logrado este inventario, el uso de la aplicaci´on resulta efectivo y f´acil.
CAP´ITULO 7. VALIDACI ´ON DEL TRABAJO 32
Cap´ıtulo 8
Conclusiones y trabajos futuros
8.1
Conclusiones
• A trav´es de la creaci´on de la aplicaci´on SmartStock, se plantean soluciones a un problema de ingenier´ıa real a partir de las herramientas aprendidas durante la carrera e informaci´on consultada para generar dichas soluciones.
• Mediante la realizaci´on del proyecto se implementan nuevas tecnolog´ıas como NFC, celulares inteligentes, y almacenamiento en la nube, lo cual tiene gran aplicaci´on a futuro.
• Se evidencia que el almacenamiento de datos en la nube permite el uso remoto de aplicaciones y otorga mayor flexibilidad al usuario.
• Se evidencia que la aplicaci´on funciona correctamente en un ´ambito real y es aplicable para uso en peque˜nas y medianas empresas.
• Es evidente que para reemplazar la manera de completa los sistemas de inventario a mano, es necesario agregarle funciones adicionales a la aplicaci´on como manejo de caja, an´alisis de datos y dem´as.
• El uso de la aplicaci´on en peque˜nas y medianas empresas se plantea como una idea de negocio que puede ser rentable a futuro.
8.2
Trabajo Futuros
Con el fin de continuar hacia el objetivo de crear un modelo de negocio exitoso para la aplicaci´on SmartStock,Adem´as de realizar un estudio de mercado que permita identificar de manera apropiada los clientes potenciales para iniciar con los temas relacionados a comercializaci´on, es necesario a˜nadir funciones tales como:
• Creaci´on de variable costo: especificando para un producto el precio de venta y el costo rela-cionado, con el fin de generar informes estad´ısticos con respecto a las ganancias por producto.
• Implementaci´on de Fotografias: a˜nadir la opci´on de envio y almacenamiento de im´agenes al servi-dor con el fin de permitir una mejor visualizaci´on de los productos en el momento de consultarse.
• Generaci´on y manejo de gr´aficas: crear estad´ısticas descriptivas de los datos mensuales almace-nados en la base de datos con el fin de generar reportes de resultados para la implementaci´on de un sistema de apoyo a la decisi´on. Lo anterior con el fin de ayudar a optimizar los tiempos y selecciones de compra de productos.
CAP´ITULO 8. CONCLUSIONES Y TRABAJOS FUTUROS 34
• Inicio de sesi´on: con la creaci´on de diferentes empresas en la base de datos, se har´a necesaria la implementaci´on de autentificaci´on a cada una por medio de la asignaci´on de un nombre de usuario y contrase˜na tanto para la versi´on WEB como para la versi´on M´ovil
• Escalamiento a otros SO: dada la restricci´on planteada sobre la elecci´on del sistema a usar (Android), se debe replicar la aplicaci´on para otros sistemas operativos (a´un sin funcionalidad NFC) como IOS y Windows Phone.
Referencias
[1] Google app engine cloud endpoints in a nutshell: Google’s documenta-tion for all topics related to cloud platform paas in app engine. [online]
https://cloud.google.com/developers/articles/google-cloud-endpoints-for-android/, Consultado el 26 de Octubre de 2014.
[2] Enstream emerging trend of nfc-enabled devices in the market today [online]
http://www.enstream.com/images/NFC infographic.jpg, Consultado el 28 de Septiem-bre de 2014.
[3] Nfc forum: Technical specifications for record type definitions (rtds) and four specific rtds: Text, uri, smart poster, and generic control. [online]
http://nfc-forum.org/our-work/specifications-and-application-documents/specifications/record-type-definition-technical-specifications/, Consultado el 28 de Septiembre de 2014.
[4] E. Arendarenko. A study of comparing rfid and 2d barcode tag technologies for pervasive mobile applications, 2009.
[5] G. Bawa, A. Huang, and M. Ghovanloo. An efficient 13.56 mhz active back-telemetry recti-fier in standard cmos technology. In Circuits and Systems (ISCAS), Proceedings of 2010 IEEE International Symposium on, pages 1201 –1204, 30 2010-june 2 2010.
[6] I. Bueno. Dise ˜No de las tecnolog´Ias de informaci ´On para la gesti ´On de inventarios de empresas comercializadoras en regiones aisladas de colombia. el caso de una empresa distribuidora de ma-teriales de construccion en leticia, amazonas. Tesis de grado, Universidad de los Andes Colombia, 2007.
[7] D. S. Flechas. Sistema inal ´Ambrico de medici ´On de monoxido de carbono con interfaz sobre un tel ´Efono inteligente. Tesis de grado, Universidad de los Andes Colombia, 2012.
[8] M. d. C. Gil rivera. La base de datos, importancia y aplicaci´on en educaci´on, 1994.
[9] W. Jackson. InAndroid Apps for Absolute Beginners (Second Edition), pages 1 – 393. Academic Press, San Diego, second edition edition, 2012.
[10] Lara Cancela Garc´ıa y Sara Ostos Lobo. Universidad carlos iii de madrid. material estudio asig-natura software de comunicaciones, departamento de ingenier´ıa t´ecnica de telecomunicaci´on [on-line]https://sites.google.com/site/swcuc3m/home/android, Consultado el 28 de Septiembre de 2014.
[11] J. Liu and J. Yu. Research on development of android applications. 2011 Fourth International Conference on Intelligent Networks and Intelligent Systems, (4), 2011.
[12] J. C. Machado. Imporrepuestos ltda: Desarrollo de un modelo para el manejo de inventarios. Tesis de grado, Universidad de los Andes Colombia, 2012.
REFERENCIAS 36
[13] L. Maya and J. Reinel. Modelo de inventario manejado por el proveedor par auna cadena de suministros compuesta por un productor y multiples minoristas. Tesis de grado, Universidad de los Andes Colombia, 2013.
[14] RopeSoapNDope. Inventory management technology. [online] disponible en:
https://www.reposoapndope.com, Febrero 2014.
[15] J. C. Saldarriaga. Modelo de responsabilidad compartida para manejo de inventarios en bares y discotecas. Tesis de grado, Universidad de los Andes Colombia, 2004.
