Borrador Final Después de La Defensa

ESCUELA MILITAR DE INGENIERÍA MCAL. ANTONIO JOSÉ DE SUCRE “BOLIVIA”

TRABAJO DE GRADO BORRADOR FINAL

SISTEMA DE GESTIÓN DE ABASTECIMIENTO DE PRODUCTOS Y SERVICIOS DE CATERING INTEGRADO CON UNA APLICACIÓN MOVIL ANDROID.

CASO DE ESTUDIO: SERVICIOS DE CATERING “VALENCIA”

GIOVANA EDITH YUJRA NINA

COCHABAMBA, 2016.

ESCUELA MILITAR DE INGENIERÍA MCAL. ANTONIO JOSÉ DE SUCRE BOLIVIA

TRABAJO DE GRADO BORRADOR FINAL

SISTEMA DE GESTIÓN DE ABASTECIMIENTO DE PRODUCTOS Y SERVICIOS DE CATERING INTEGRADO CON UNA APLICACIÓN MOVIL ANDROID.

CASO DE ESTUDIO: SERVICIOS DE CATERING “VALENCIA”

GIOVANA EDITH YUJRA NINA

Modalidad: Proyecto de Grado, presentado como requisito parcial para optar al título de Licenciado en Ingeniería de Sistemas

TUTOR: ING. JHOMIL ZAMBRANA BURGOS

COCHABAMBA, 2016.

ÍNDICE DE CONTENIDO 1.

GENERALIDADES. ...................................................................................... 1

1.1.

INTRODUCCIÓN. ......................................................................................... 1

1.3.1.

Identificación del problema. .......................................................................... 4

1.3.1.1. Identificación de la situación problemática. .................................................. 4 1.3.1.2. Identificación de las causas. ......................................................................... 5 1.3.2.

Formulación del problema. ........................................................................... 5

1.3.3.

Análisis causa efecto. ................................................................................... 5

1.4.

OBJETIVOS Y ACCIONES. ......................................................................... 5

1.4.1.

Objetivo general. .......................................................................................... 5

1.4.2.

Objetivo específicos y Acciones. .................................................................. 6

1.5.

JUSTIFICACIÓN. ......................................................................................... 8

1.5.1.

Justificación técnica. ..................................................................................... 9

1.5.2.

Justificación económica. ............................................................................... 9

1.5.3.

Justificación operativa. ................................................................................. 9

1.6.

ALCANCE..................................................................................................... 9

1.6.1.

Alcance Temático. ........................................................................................ 9

1.6.2.

Alcance Institucional. .................................................................................... 9

1.6.3.

Alcance temporal. ....................................................................................... 10

1.7.

HIPÓTESIS. ............................................................................................... 10

i

1.7.1.

Análisis de variables. .................................................................................. 10

1.7.2.

Definición conceptual. ................................................................................ 10

1.7.3.

Operativización de variables....................................................................... 11

1.8.

MATRIZ DE CONSISTENCIA. ................................................................... 12

2.

MARCO TEÓRICO. .................................................................................... 13

2.1.

TÉCNICAS DE RECOPILACIÓN DE DATOS ............................................ 13

2.1.1.

Entrevistas. ................................................................................................. 13

2.1.2.

Observación. .............................................................................................. 14

2.1.3.

Cuestionario. .............................................................................................. 14

2.2.

INGENIERÍA DE SOFTWARE.................................................................... 15

2.2.1.

Proceso del Software. ................................................................................ 15

2.2.2.

Patrón de Arquitectura de Modelo Vista Controlador. ................................ 16

2.2.3.

Metodología de desarrollo de software. ...................................................... 18

2.2.3.1. Programación Extrema XP ......................................................................... 18 2.2.3.2. ICONIX. ...................................................................................................... 21 2.2.3.3. El proceso unificado ágil (PUA) .................................................................. 24 2.2.4.

Herramienta para el desarrollo de las metodologías .................................. 26

2.2.5.

Lenguaje de modelado Unificado. .............................................................. 29

2.2.6.

Pruebas de software. .................................................................................. 32

2.2.6.1. Pruebas Funcionales. ................................................................................. 32

ii

2.2.6.2. Pruebas de caja negra. .............................................................................. 32 2.2.6.3. Prueba de Usabilidad. ................................................................................ 34 2.3.

ARQUITECTURA DE SOFTWARE. ........................................................... 34

2.3.1.

Cliente Servidor Móvil. ................................................................................ 34

2.3.2.

Smart Client. ............................................................................................... 36

2.3.3.

Thin Client. ................................................................................................. 37

2.4.

HERRAMIENTAS DE SOFTWARE. ........................................................... 39

2.4.1.

Entornos de desarrollo Android (IDE). ........................................................ 39

2.4.1.1. Apache Cordova. ........................................................................................ 39 2.4.1.2. Sublime text 3 ............................................................................................. 40 2.4.1.3. Android developer tools. ............................................................................. 43 2.4.2.

Kit de desarrollo de software (SDK). .......................................................... 44

2.5.

TECNOLOGÍAS DE DESARROLLO DE APLICACIONES MÓVILES ........ 45

2.5.1.

APLICACIÓN MÓVIL .................................................................................. 45

2.5.1.1. Aplicaciones móviles nativas ...................................................................... 46 2.5.1.2. Aplicaciones móviles web ........................................................................... 48 2.5.1.3. Aplicaciones móviles hibridas ..................................................................... 49 2.5.2.

Framework.................................................................................................. 51

2.5.2.1. jQuery Mobile. ............................................................................................ 51 2.5.2.2. AppCelerator .............................................................................................. 53 iii

2.5.2.3. PhoneGap. ................................................................................................. 54 2.5.3.

Lenguajes de programación ....................................................................... 56

2.5.3.1. Python ........................................................................................................ 56 2.5.3.2. Ruby ........................................................................................................... 58 2.5.3.3. Java. ........................................................................................................... 59 2.5.4.

Servicios web de intercambio de datos con Android. ................................. 60

2.5.3.1. Servicio Web RESTful Para Android .......................................................... 61 2.5.3.2. Lenguaje de Descripción de Servicios Web (WSDL). ................................. 63 2.5.3.2. REST API ................................................................................................... 66 2.5.5.

JavaScript ................................................................................................... 68

2.5.6.

HTML .......................................................................................................... 70

2.5.6.

CSS ............................................................................................................ 71

2.5.7.

Intercambio de datos JSON........................................................................ 73

2.5.8.

Gestores de Bases de datos ...................................................................... 74

2.5.8.1. My Structured Query Language (MySQL). ................................................. 74 2.5.8.2. Microsoft Structured Query Language Server (SQL server). ...................... 76 2.5.6.3. SQLite Sistema de Gestión de Base de Datos ........................................... 77 2.5.9

Herramientas de gestión............................................................................. 79

2.5.9.1. Google App Engine .................................................................................... 79 2.5.9.2. Cloud computing......................................................................................... 82 iv

3.

MARCO PRÁCTICO. .................................................................................. 77

3.1.

DISEÑO DEL MODELADO DE NEGOCIO ACTUAL PARA EL ABASTECIMIENTO DE PRODUCTOS. ..................................................... 77

3.1.3.

Identificar las deficiencias del proceso actual. ............................................ 79

3.2.

DISEÑAR EL MODELO DE NEGOCIO PROPUESTO PARA EL ABASTECIMIENTO DE PRODUCTOS ...................................................... 79

3.2.1.

Elaboración del modelado del negocio alternativo basado en el sistema propuesto.................................................................................................... 79

3.2.2.

Selección de la metodología de desarrollo de software. ............................ 80

3.2.3.

Planificar el proyecto según el flujo de trabajo de modelo de software seleccionado............................................................................................... 82

3.3.

DESARROLLAR EL MÓDULO DE GESTIÓN DE DISTINTOS TIPOS DE USUARIOS. ................................................................................................ 84

3.3.1.

Seleccionar lenguaje de programación ...................................................... 84

3.3.2.

Requerimientos de gestión de distintos tipos de usuarios. ......................... 86

3.3.3.

Identificación de actores de gestión de distintos tipos de usuarios. ........... 86

3.3.4.

Diagramas de casos de uso de alto nivel y expandido. .............................. 88

3.3.4.1. Diagrama de caso de uso de alto nivel ....................................................... 88 3.3.4.2. Diagramas de casos de uso expandido ...................................................... 89 3.3.5.

Diagrama de robustez de gestión de distintos tipos de usuarios. ............... 94

3.3.6.

Modelado del dominio, incremento de diagrama de dominio, culminación de diagrama de dominio. ................................................................................. 96

v

3.3.7.

Codificar el módulo de gestión de cuentas de usuario. .............................. 97

3.3.8.

Realizar pruebas al módulo de usuarios .................................................. 100

3.4.

DESARROLLAR EL MÓDULO DE CONTROL DE STOCK DE PRODUCTOS........................................................................................... 101

3.4.1.

Requerimientos. ....................................................................................... 102

3.4.2.

Identificar actores involucrados en el módulo. .......................................... 102

3.4.3.

Diagramas de casos de uso expandido de control de stock. .................... 103

3.4.4.

Diagrama de robustez control de stock. ................................................... 104

3.4.5.

Diseñar el modelo del dominio. ................................................................ 105

3.4.6.

Codificar el módulo de control de stock de productos. ............................. 105

3.4.7.

Realizar pruebas al módulo. ..................................................................... 107

3.5.

IMPLEMENTAR EL MÓDULO DE SERVICIOS DE CATERING. ............. 107

3.5.1.

Tabla de requerimientos. .......................................................................... 107

3.5.2.

Identificar tipos de usuario. ....................................................................... 108

3.5.3.

Diseñar los diagramas de casos de uso ................................................... 108

3.5.4.

Diagramas de robustez ............................................................................ 110

3.5.5.

Diseñar el modelo del dominio, incremento de diagrama de dominio, culminación de diagrama de dominio. ...................................................... 111

3.5.6.

Codificar el módulo de Servicios de catering ............................................ 112

3.5.7.

Realizar pruebas de funcionamiento. ....................................................... 114

3.6.

DESARROLLAR LA APLICACIÓN MÓVIL ANDROID PARA LA GESTIÓN vi

DE ABASTECIMIENTO DE PRODUCTOS. ............................................. 114 3.6.1.

Realizar análisis de requerimientos. ......................................................... 114

3.6.2.

Identificar tipos de usuario. ....................................................................... 115

3.6.3.

Diseñar los diagramas de casos de uso ................................................... 115

3.6.4.

Diagramas de robustez ............................................................................ 119

3.6.5.

Diseñar el modelo del dominio, incremento de diagrama de dominio, culminación de diagrama de dominio. ...................................................... 121

3.6.6.

Implementar el módulo para la gestión de abastecimiento de productos. 122

3.6.7.

Realizar pruebas de funcionamiento. ....................................................... 124

3.7.

SINCRONIZACIÓN DE LA APLICACIÓN CLIENTE CON LA APLICACIÓN SERVIDOR HACIENDO USO DE DATA STORAGE EN LA NUBE. ........ 125

3.7.1.

Diagrama del proceso de sincronización. ................................................. 125

3.7.2.

Realizar las pruebas de funcionalidad. ..................................................... 126

3.8.

REALIZAR PRUEBAS DEL SISTEMA TERMINADO. .............................. 126

3.8.1.

Identificar los tipos de pruebas adecuados............................................... 126

3.8.2.

Realizar pruebas a los diferentes módulos. .............................................. 127

3.8.3.

Documentar las pruebas........................................................................... 130

3.9.

DEMOSTRACIÓN DE LA HIPOTESIS. .................................................... 131

3.9.1.

Demostración de la primera variable dependiente. .................................. 132

3.9.2.

Demostración de la segunda variable. ..................................................... 133

3.9.3.

Demostración de la variable independiente. ............................................. 134 vii

4.

ANÁLISIS DE VIABILIDAD ....................................................................... 141

4.1.

VIABILIDAD TÉCNICA. ............................................................................ 141

4.2.

VIABILIDAD ECONÓMICA. ...................................................................... 143

4.2.1.

Costo de implementación del proyecto. .................................................... 143

4.2.2.

Costo del proyecto .................................................................................... 144

4.2.3.

Análisis de beneficio costo ....................................................................... 152

4.3.

VIABILIDAD OPERATIVA. ....................................................................... 154

5.

CONCLUSIONES Y RECOMENDACIONES............................................ 156

5.1.

CONCLUSIONES ..................................................................................... 156

5.2.

RECOMENDACIONES ............................................................................ 158

BIBLIOGRAFÍA ....................................................................................................... 159 ANEXOS ANEXO A: Servicio de Catering ANEXO B: Licitación del Servicio de Catering ANEXO C: Entrevista al gerente de la empresa ANEXO D: Diagrama ISHIKAWA ANEXO E: Conformidad y aceptación de interfaces ANEXO F: Justificación de los factores de COCOMO

viii

ÍNDICE DE TABLAS Tabla 1: Objetivos y acciones ..................................................................................... 6 Tabla 2: Operativización de variables ....................................................................... 11 Tabla 3: Descripción de las Ventajas y Desventajas de los Modelos de Desarrollo de Software. ................................................................................................................... 81 Tabla 4: Plan de desarrollo de software según ICONIX ........................................... 82 Tabla 5: Tabla de comparación de lenguajes de programación ............................... 84 Tabla 6: Tabla de requerimientos de Gestión de usuarios ....................................... 86 Tabla 7: Identificación de usuarios de Gestión de usuarios ...................................... 87 Tabla 8: Descripción de caso de uso de alto nivel .................................................... 89 Tabla 9: Descripción de caso de uso expandido “Registro de datos” ....................... 90 Tabla 10: Descripción de acción de actores “Registro de datos” .............................. 90 Tabla 11: Descripción de caso de uso expandido “Iniciar sesión” ............................ 92 Tabla 12: Descripción de acción de actores “Iniciar sesión” ..................................... 92 Tabla 13: Descripción de caso de uso expandido “Gestión de usuarios” ................. 93 Tabla 14: Descripción de acción de actores “Gestión de usuarios” .......................... 93 Tabla 15: Prueba funcional del caso de uso registro de datos. .............................. 100 Tabla 16: Prueba funcional del caso de uso ingresar al sistema. ........................... 100 Tabla 17: Prueba funcional del caso de uso de gestión de usuarios. ..................... 101 Tabla 18: Tabla de requerimientos de control de stock de productos ..................... 102

ix

Tabla 19: Identificación de actores involucrados en el módulo. .............................. 102 Tabla 20: Descripción de caso de uso expandido control de stock. ....................... 103 Tabla 21: Prueba funcional del caso de uso de control de stock. ........................... 107 Tabla 22: Tabla de requerimientos de servicios de catering ................................... 107 Tabla 23: Tabla de requerimientos ......................................................................... 114 Tabla 24: Identificación de tipos de usuario. ........................................................... 115 Tabla 25: Descripción de caso de uso expandido de Administrar producto ........... 109 Tabla 26: Descripción de acción de actores de Administrar producto .................... 109 Tabla 27: Descripción de caso de uso expandido Registrar pedido ....................... 116 Tabla 28: Descripción de acción de actores Registrar pedido ................................ 116 Tabla 29: Descripción de caso de uso expandido de Visualiza pedido y registra compra .................................................................................................................... 118 Tabla 30: Descripción de acción de actores de Visualiza pedido y registra compra118 Tabla 31: Autentificación de usuario de usuario ..................................................... 127 Tabla 32: Registro de producto ............................................................................... 128 Tabla 33: Registro de producto............................................................................... 129 Tabla 34: Demostración de la segunda variable dependiente ................................ 133 Tabla 35: Demostración de la segunda variable dependiente ................................ 135 Tabla 36: Requerimientos de hardware .................................................................. 141 Tabla 37: Requerimientos de Software ................................................................... 142

x

Tabla 38: Costos de Hardware y Software del servidor .......................................... 143 Tabla 39: Costos de Hardware y Software del cliente ............................................ 144 Tabla 40: Valores COCOMO .................................................................................. 145 Tabla 41: Ecuación básica del esfuerzo en COCOMO (Modelo intermedio y Detallado). ............................................................................................................... 146 Tabla 42: Ecuación básica del tiempo en COCOMO (Modelo intermedio). ............ 146 Tabla 43: Factores de Costo en COCOMO ............................................................ 147 Tabla 44: Costos totales mínimos e ideales ........................................................... 152 Tabla 45: Costo con sistema y sin sistema ............................................................. 152 Tabla 46: Nivel de complejidad según funciones de cargo ..................................... 154

xi

ÍNDICE DE FIGURAS Figura 1: Matriz de consistencia ............................................................................... 12 Figura 2: Modelo Vista Controlador. ......................................................................... 17 Figura 3: Metodología XP ......................................................................................... 18 Figura 4: Proceso de desarrollo incremental para ICONIX ...................................... 22 Figura 5: Fases de la metodología ICONIX .............................................................. 23 Figura 6: El proceso unificado ágil (PUA). ................................................................ 25 Figura 7: Manifiesto Ágil ........................................................................................... 27 Figura 8: Diagrama de casos de uso ........................................................................ 30 Figura 9: Diagrama de robustez ............................................................................... 30 Figura 10: Diagrama de secuencia........................................................................... 31 Figura 11: Diagrama de dominio .............................................................................. 31 Figura 12: Arquitectura cliente/servidor móvil........................................................... 35 Figura 13: Smart Client............................................................................................. 36 Figura 14: thin client. ................................................................................................ 38 Figura 15: Arquitectura de aplicación móvil nativa ................................................... 47 Figura 16: Arquitectura de aplicación móvil web ...................................................... 49 Figura 17: Arquitectura de aplicación móvil hibrida .................................................. 50 Figura 18: Servicios Web. ........................................................................................ 61 Figura 19: REST API ................................................................................................ 66 xii

Figura 20: Diagrama de Modelado de Negocio Actual ............................................. 78 Figura 21: Diagrama de Modelado de Negocio Alternativo del proceso de gestión de abastecimiento de productos y servicios de catering. ............................................... 80 Figura 22: Diagrama de Caso de Uso de Alto Nivel del Sistema ............................. 88 Figura 23: Registro de datos .................................................................................... 90 Figura 24: Iniciar sesión ........................................................................................... 91 Figura 25: Gestión de usuarios ................................................................................ 93 Figura 26: Diagrama de robustez de registro de datos ............................................ 95 Figura 27: Diagrama de robustez de Iniciar sesión .................................................. 95 Figura 28: Diagrama de robustez de Gestión de usuarios ....................................... 96 Figura 29: Modelado del dominio ............................................................................. 96 Figura 30: Codificación de gestión de cuentas de usuarios ..................................... 97 Figura 31: Interfaz de registro de usuario ................................................................. 98 Figura 32: Interfaz de iniciar sesión .......................................................................... 98 Figura 33: Interfaz del administrador ........................................................................ 99 Figura 34: Interfaz de control de personal ................................................................ 99 Figura 35: Diagrama de caso de uso expandido de control de stock. .................... 103 Figura 36: Diagrama de robustez de control de stock. ........................................... 105 Figura 37: Diseño del dominio de control de stock. ................................................ 105 Figura 38: Codificación de control de stock ............................................................ 106

xiii

Figura 39: Interfaz de control de stock. .................................................................. 106 Figura 40: Administrar producto ............................................................................. 109 Figura 41: Diagrama de robustez de Administrar producto .................................... 111 Figura 42: Diseño del dominio de la aplicación móvil Android de gestión de abastecimiento de productos................................................................................... 112 Figura 43: Codificación de Servicios de catering .................................................... 113 Figura 44: Registrar un producto ............................................................................ 113 Figura 45: Prueba funcional Servicios de catering. ................................................ 114 Figura 46: Registrar pedido .................................................................................... 116 Figura 47: Visualiza pedido y registra compra........................................................ 118 Figura 48: Diagrama de robustez de registrar pedido ............................................ 120 Figura 49: Diagrama de robustez de Visualiza pedido y registra compras ............. 121 Figura 50: Diseño del dominio de la aplicación móvil Android de gestión de abastecimiento de productos................................................................................... 122 Figura 51: Interfaces para el registro de pedidos ................................................... 123 Figura 52: Interfaces para enviar pedido ................................................................ 123 Figura 53: Interfaces para el encargado de compras ............................................. 124 Figura 54: Prueba funcional del caso de uso registro de datos. ............................. 125 Figura 55: Proceso de sincronización ..................................................................... 125 Figura 56: Sistema en ejecución ............................................................................ 126 Figura 57: Conexión activa ..................................................................................... 126 xiv

Figura 58: Autentificación de usuarios ................................................................... 130 Figura 59: Registrar un producto ............................................................................ 130 Figura 60: Registrar un pedido ............................................................................... 131 Figura 61: Campana de gauss ............................................................................... 139

xv

ESCUELA MILITAR DE INGENIERÍA MCAL. ANTONIO JOSÉ DE SUCRE BOLIVIA

CAPÍTULO 1 GENERALIDADES.

1. GENERALIDADES. 1.1. INTRODUCCIÓN. En la actualidad es de mucha importancia la sistematización de procesos para poder acceder a diferente tipo de información, muchas empresas realizan diferentes procesos y recolección de datos manualmente ya que no cuentan con un sistema que pueda ayudar, agilizar y facilitar dicha información. Las aplicaciones móviles inteligentes han ayudado a los usuarios a mantenerse conectados a las redes sociales y cargar la información de manera más rápida, asimismo permitieron al usuario ser menos dependiente de una computadora portátil, a su vez es importante mencionar que las aplicaciones móviles ayudan a mejorar la comunicación entre los diferentes niveles de administración en una organización; por ejemplo en caso de que un encargado del departamento de una empresa no se encuentra en el lugar de trabajo, puede comunicarse con sus dependientes por medio de envío de órdenes de trabajo con el objetivo de coadyuvar a la continuidad de labores que se deben realizar. El sistema operativo Android se emplea en dispositivos móviles, por lo general con pantalla táctil, de este modo, es posible encontrar tabletas (Tablet), teléfonos móviles (Smartphone) y relojes equipados con Android, aunque el software también se usa en automóviles, televisores y otros dispositivos electrónicos. Es importante mencionar que gracias al desarrollo de la tecnología, ahora es posible contar con sistemas que facilitan el trabajo diario, los sistemas que ofrecen, trabajan en entorno cliente–servidor; permiten concentrar en el servidor tareas de almacenamiento de datos y brindan servicios entre usuarios. Existe una gran variedad de sistemas de gestión dentro de las empresas. Estos sistemas son muy útiles en una empresa al manejar información diaria, para diferentes empresas, ya sean mini-empresas, tiendas, restaurantes, farmacias etc. Con frecuencia, en el área de sistemas de control de registros existen determinados 1 - 162

reportes que describen cantidad de productos, fecha de compra, tipo de producto, etc. Los sistemas de control se pueden aplicar en una empresa que se dedica al servicio de catering, tomando en cuenta los datos que ésta conlleva se puede pronosticar la cantidad de productos que se debe adquirir para abastecimiento y la preparación de alimentos. El servicio de catering ofrece servicio de suministros de comida preparada como desayunos, almuerzos, platos especiales, postres y refrescos a diferentes empresas que solicitan el servicio, donde el cliente hace un contrato con el propietario acordando el tipo de servicio para un determinado tiempo. La propuesta de la sistematización consiste en el desarrollo de un sistema de gestión de abastecimiento de productos el cual permitirá realizar un seguimiento de productos que abastecerán el servicio de catering para satisfacer a los comensales, en el cuál el dueño se incluirá en el proceso teniendo información rápida de las tareas que se realizarán diariamente entre el chef y el empleado de compras. Implementando una aplicación móvil Android se tendrá comunicación directa entre el chef y el empleado de compras al momento de solicitar productos y adquirir los mismos sin requerir un encuentro físico.

1.2. ANTECEDENTES. La empresa de Servicio de Catering “VALENCIA” inicio su actividad en el departamento de Cochabamba un 11 de agosto del año 2012 como empresa unipersonal a cargo del Sr: Álvaro Valencia Miranda quién además es el propietario de la empresa, que está dedicada a proporcionar servicios de catering (ANEXO A) a diferentes empresas como ser: TAQUIÑA S.A., DURALIT S.A., SIGMA S.A., LA PAPELERA S.A., MADEPA S.A. (ANEXO B). Actualmente la empresa cuenta con un gerente (quién es el dueño), empleados que se reparten en los cargos de: encargados de cocina, preparadores del alimento, encargadas de preparación de ensaladas, personal de limpieza de vajillas y meseros, 2 - 162

también se cuenta con dos ayudantes dependiendo a la cantidad de los comensales, y un encargado de compras quién es el que realiza la compra de los ingredientes que solicita el chef. Para poder abastecerse con los ingredientes, el encargado de compras debe dirigirse a un supermercado (o mercado local), con las listas proporcionadas por el dueño, solicitadas por el chef, por consiguiente realiza la adquisición de los ingredientes requeridos para cubrir el servicio de catering solicitado en la empresa, posteriormente realizadas las compras de las listas, el encargado debe llevar los ingredientes al almacén, a continuación el chef recoge los ingredientes en presencia del dueño mediante las listas solicitadas en papel para posteriormente preparar los productos, organizando a todo personal, verificando que todo esté en orden en el debido tiempo y no falte ningún producto. Las compras de los ingredientes que realiza el encargado la realiza diariamente, en caso de escases o ausencia de algún ingrediente en almacén el chef debe comunicar al dueño mediante llamada solicitando el ingrediente, el dueño debe comunicarse con el encargado de compras para poder satisfacer ésta necesidad, en caso de no poder contactarse con el encargado de compras, la compra del producto debe realizarla personalmente el dueño. Para poder tener un control, el dueño debe realizar una lista de los ingredientes que se solicitaron y compraron por el personal, lo cuál conlleva un registro manual diario que dificulta las actividades del dueño ya que desperdicia el tiempo en tareas repetitivas. Por otra parte los encargados de cocina del preparado de los alimentos empiezan con la preparación de acuerdo al menú que se les proporcionó para el día, poniéndose de acuerdo con los encargados de ensaladas y empleados de limpieza de vajillas. Entre otro servicio los meseros están encargados de la organización de las mesas y de proveer los utensilios para cada mesa. Una vez preparado el servicio de alimentos los comensales ingresan en una hora específica sirviéndose los alimentos preparados, todo este servicio se realiza diariamente, una vez cumplido el mes el encargado de la empresa que contrata el 3 - 162

servicio de catering realiza el pago mediante tarjeta bancaria o un depósito al dueño de la empresa de catering así sucesivamente hasta cumplir el año de contrato. Para notificar el pago realizado por el servicio de catering, el dueño de la empresa verifica en su cuenta el depósito mensual de las empresas y entrega una factura por el servicio realizado.

1.3. PLANTEAMIENTO DEL PROBLEMA. A continuación se mencionan los siguientes puntos para poder determinar el problema de manera clara. 1.3.1. Identificación del problema. Actualmente para el abastecimiento de alimento a las diferentes empresas se deben realizar las compras con un registro manual, por otro lado el procedimiento de la adquisición de ingredientes se realiza en un supermercado específico (o mercado local) e implica una demora al tomar nota y desorganización de registros, ya que cada encargado del comedor requiere diferentes productos. 1.3.1.1.

Identificación de la situación problemática.

A continuación se detallan los aspectos identificados de la situación problemática. 

El proceso manual de confección de listas de ingredientes ocasiona tareas de registro repetitivas para el dueño.



El registro de los datos de las empresas que adquieren el Servicio de Catering se realiza de forma manual, esto ocasiona ilegibilidad en algunos casos por la prisa empleada en la toma de datos.



La verificación de productos que deben abastecerse es muy morosa debido a que se debe revisar un gran volumen de toma de pedidos.



La lista de ingredientes faltantes puede contener errores, lo cual provoca que se realicen compras de innecesarios o se omitan algunos que se requisan.

4 - 162

1.3.1.2.

Identificación de las causas.



El proceso manual de confección de listas de productos.



El registro de los datos de las empresas que adquieren el servicio de catering se realiza de forma manual.



La verificación de productos que deben abastecerse es muy morosa.



La lista de ingredientes faltantes puede contener errores.

1.3.2. Formulación del problema. Los actuales procedimientos morosos empleados en la gestión de abastecimiento de productos y Servicios de Catering provocan tareas repetitivas de confección de listas diarias de productos faltantes, pérdida de tiempo en la revisión de los pedidos realizados por las empresas para determinar los productos que deben abastecerse y gastos innecesarios en la adquisición de productos que se tienen disponibles. 1.3.3. Análisis causa efecto. Causa: 

Los actuales procedimientos morosos empleados en la gestión de abastecimiento de productos y Servicios de Catering.

Efecto: 

Tareas repetitivas de confección de listas diarias de productos faltantes.



Pérdida de tiempo en la revisión de los pedidos realizados por las empresas para determinar los productos que deben abastecerse.



Gastos innecesarios en la adquisición de productos que se tienen disponibles.

1.4. OBJETIVOS Y ACCIONES. 1.4.1. Objetivo general. Desarrollar un sistema de gestión de abastecimiento de productos y Servicios de 5 - 162

Catering integrado con una aplicación móvil Android para garantizar la disponibilidad de productos. 1.4.2. Objetivo específicos y Acciones. 

Diseñar el modelado de negocio actual para el abastecimiento de productos.



Diseñar el modelo de negocio propuesto para el abastecimiento de productos.



Desarrollar módulo de gestión de usuarios.



Desarrollar módulo de control de stock de productos.



Implementar el módulo de Servicios de Catering.



Desarrollar la aplicación móvil Android para la gestión de abastecimiento de productos.



Sincronización de la aplicación cliente con la aplicación servidor haciendo uso de Data Storage en la nube.



Realizar pruebas del sistema terminado. Tabla 1: Objetivos y acciones

OBJETIVOS ESPECÍFICOS

ACCIONES

Diseñar el



Analizar el modelado del negocio.

modelado de



Realizar entrevistas con el involucrado principal.

negocio actual para



Analizar la información obtenida.

el abastecimiento



Diseñar el negocio del modelo actual.

de productos



Identificar las deficiencias del proceso actual.



Elaborar el modelado del negocio alternativo que se

Diseñar el modelo de negocio propuesto para el abastecimiento de

base en el sistema propuesto. 

Validar con los involucrados la propuesta.



Seleccionar metodología de desarrollo de software.



Planificar el proyecto según el flujo de trabajo de 6 - 162

OBJETIVOS ESPECÍFICOS

ACCIONES

productos

modelo de software seleccionado. 

Seleccionar lenguaje de programación.



Realizar tabla de requerimientos.

Desarrollar módulo



Identificar tipos de actores.

de gestión de



Diseñar los diagramas de casos de uso, diagramas de robustez, y diagramas de secuencia

usuarios. 

Diseñar el modelo del dominio, incremento de diagrama de dominio, culminación de diagrama de dominio.

Desarrollar módulo de control de stock de productos.



Codificar el módulo de gestión de cuentas de usuario.



Realizar pruebas al módulo de usuarios.



Realizar tabla de requerimientos.



Identificar actores involucrados en el módulo.



Diseñar los diagramas de casos de uso, diagramas de robustez y diagramas de secuencia,



Diseñar el modelo del dominio, incremento de diagrama de dominio, culminación de diagrama de dominio.



Codificar el módulo de control de stock de productos.



Realizar pruebas al módulo.

Implementar el



Realizar tabla de requerimientos.

módulo de Servicios



Diseñar las interfaces para el módulo de Servicios de

de Catering.

Catering



Realizar análisis de requerimientos.

aplicación móvil



Identificar tipos de usuario.

Android para la



Diseñar los diagramas de casos de uso, diagramas de

Desarrollar la

7 - 162

OBJETIVOS ESPECÍFICOS

ACCIONES

gestión de abastecimiento de

robustez y diagramas de secuencia. 

productos.

Diseñar el modelo del dominio, incremento de diagrama de dominio, culminación de diagrama de dominio.



Implementar el módulo para la gestión de abastecimiento de productos.

Sincronización de la aplicación cliente con la aplicación servidor haciendo uso de Data Storage en la nube.

Realizar pruebas del sistema terminado.



Realizar pruebas de funcionamiento.



Establecer tipos de mecanismos para conexión.



Realizar análisis de requerimientos.



Modelar la relación de conexión entre el sistema desarrollado y el servidor en la nube.



Aplicar los mecanismos necesarios para realizar la comunicación entre el sistema y el servidor en la nube.



Realizar las pruebas de funcionalidad.



Identificar los tipos de pruebas adecuados.



Diseñar escenarios de casos de pruebas con usuarios finales.



Obtener retroalimentación de los usuarios.



Realizar pruebas a los diferentes módulos.



Documentar las pruebas. Fuente: Elaboración Propia

1.5. JUSTIFICACIÓN. Se describen las justificaciones siguientes:

8 - 162

1.5.1. Justificación técnica. Es importante mencionar que una aplicación móvil Android contiene elementos que permitirán una comunicación activa entre los usuarios para mejorar el rendimiento en sus funciones, esto permite que se comparta información de modo interactivo, por otra parte la aplicación móvil Android en la actualidad es eficiente, accesible y fácil de usar. Por tanto la combinación de ambas tecnologías brindará la versatilidad necesaria para que los participantes del proceso puedan realizar la gestión de productos y servicios de una manera más sencilla y con libertad de acceso. 1.5.2. Justificación económica. La aplicación móvil Android ayudará a reducir los errores en los registros por tanto se evitará la compra de ingredientes ya existentes e innecesarios en el almacén. 1.5.3. Justificación operativa. Una vez implementado la aplicación móvil Android será capaz de obtener información de datos actuales sobre los productos necesarios para el abastecimiento de la empresa por medio de un servidor que permitirá al dueño llevar un registro controlado.

1.6. ALCANCE. A continuación se describen los alcances del proyecto: 1.6.1. Alcance Temático. 

Ingeniería de software



Lenguajes de programación



Sistema de gestión de base de datos



Tecnologías móviles

1.6.2. Alcance Institucional. El proyecto será desarrollado para cubrir las áreas de registro y adquisición de productos en la empresa de servicios de catering “Valencia”. 9 - 162

1.6.3. Alcance temporal. El sistema tendrá una proyección de vida útil hasta que necesite una nueva actualización teniendo un tiempo de vida estimado de 5 años. Así mismo el sistema será desarrollado en las gestiones I y II del año 2016.

1.7. HIPÓTESIS. El sistema de gestión de abastecimiento de productos y servicios de catering integrado con una aplicación móvil Android permitirá reducir el número de errores en la elaboración de la lista de productos que se deben comprar, así mismo reducir el tiempo en la organización del Servicio de Catering para las empresas. 1.7.1. Análisis de variables. Variable Independiente 

El sistema de gestión de abastecimiento de productos y Servicios de Catering integrado con una aplicación móvil Android.

Variables Dependientes 

Errores en la elaboración de la lista de productos que se deben comprar.



Tiempo en la organización del Servicio de Catering para las empresas.

1.7.2. Definición conceptual. Variable independiente 

El sistema de gestión de abastecimientos de productos y servicios de catering integrado con una aplicación móvil Android.

Ésta variable se refiere al sistema implementado y probado durante la gestión de abastecimiento con la cual se obtendrá información actualizada de los productos en el proceso de adquisición de servicios de catering.

10 - 162

Variable dependiente 

Errores en la elaboración de la lista de productos que se deben comprar.

Ésta variable se refiere a los posibles errores humanos que se presentan al momento de realizar las listas de pedidos para el abastecimiento de productos. 

Tiempo en la organización del Servicio de Catering para las empresas.

Los procedimientos que se llevan a cabo de registros de productos y solicitud de ingredientes del chef al encargado de compras generan una demora para el servicio de catering. 1.7.3. Operativización de variables. En la tabla 2 se puede observar las tres variables existentes, la variable independiente y las variables dependientes, se puede apreciar la dimensión y el indicador de cada variable. Tabla 2: Operativización de variables

DIMENSIÓN

VARIABLE

INDICADOR

Variable Independiente El sistema de gestión de abastecimientos de productos y servicios de catering integrado con una aplicación

Sistema

Comparación de

implementado y

beneficios obtenidos sin el

probado

uso del sistema y con el uso del sistema.

móvil Android. Variables dependientes Errores en la elaboración de la lista de productos que se

Contador de errores

deben comprar.

11 - 162

Porcentaje de error

DIMENSIÓN

VARIABLE

INDICADOR

Variable dependiente Tiempo en la organización del

Tiempo requerido

Servicio de Catering para las

para optimizar la

empresas.

entrega en base a los

Tiempo

pedidos registrados. Fuente: Elaboración propia.

1.8. MATRIZ DE CONSISTENCIA. En la matriz de consistencia se observa la asociación entre el problema, objetivo e hipótesis, esto nos permite observar de manera sintetizada las generalidades. Figura 1: Matriz de consistencia

Fuente: Elaboración Propia 12 - 162

ESCUELA MILITAR DE INGENIERÍA MCAL. ANTONIO JOSÉ DE SUCRE BOLIVIA

CAPÍTULO 2 MARCO TEÓRICO.

2. MARCO TEÓRICO. 2.1. TÉCNICAS DE RECOPILACIÓN DE DATOS Dentro de las técnicas de recopilación de datos existen 3 métodos interactivos que se pueden utilizar para la obtención de los requerimientos de información de los miembros de la organización. Dichos métodos son la entrevistas, la observación y la realización de encuestas mediantes cuestionarios. La base de los métodos está en preguntas formuladas cuidadosamente. Cada uno de los métodos para la recuperación de información tiene su propio proceso para interactuar con los usuarios. (Manilla Derbez & Torres Villafaña, 2009) 2.1.1. Entrevistas. Una entrevista es una conversación dirigida con un propósito específico que utiliza un formato de preguntas y respuestas. En la entrevista necesitamos obtener las opciones de los entrevistados y su parecer acerca del estado actual del sistema, metas organizacionales y personales y procedimientos informales. (Manilla Derbez & Torres Villafaña, 2009) Los mismos actores sociales son los que proporcionan los datos relativos a sus conductas, opiniones deseos, actitudes, expectativas, etc. Cosas que por su misma naturaleza es casi imposible observar desde afuera. Algunas limitantes en la aplicación de las entrevistas son: 

La expresión oral por parte del entrevistador y entrevistado.



Algunas personas no responden seguridad y fluidez a una serie de preguntas

Los pasos para preparar una entrevista se mencionan a continuación: 

Leer los antecedentes.



Establecer los objetivos de la entrevista.



Decidir a quién entrevistar.



Decidir el tipo de preguntas. 13 - 162

2.1.2. Observación. La observación consiste en observar atentamente el hecho o caso, tomar información y registrarla para su posterior análisis. Es un elemento fundamental de todo proceso investigativo, en ella se apoya el investigador para obtener el mayor número de datos. (Manilla Derbez & Torres Villafaña, 2009) Entre las ventajas que posee se puede decir: 

Se pueden describir procesos naturales y sociales con ella.



Se acerca a la realidad de lo que realmente acontece.

Dentro de las limitantes se mencionan: 

Se torna solo desde la perspectiva del investigador.



Al observarse desde afuera, se puede perder un poco de información que los actores consideran importante en la práctica social.

Los pasos que se deben tener en cuenta son: 

Determinar el objeto, situación, caso etc.



Determinar los objetos de la observación.



Determinar la forma en que se van a registrar los datos.



Observar cuidadosamente y críticamente.



Registrar los datos observados.



Analizar e interpretar los datos.



Elaborar conclusiones.



Elaborar un informe.

2.1.3. Cuestionario. La técnica del cuestionario se puede aplicar en la entrevista, esta técnica define una serie de preguntas que permiten medir una o más variables.

14 - 162

Es un eficaz auxiliar en la observación científica, las cuales son preguntas formuladas por escrito y no es necesario la presencia del investigador llevándose a cabo mediante: cuestionario por correo, cuestionario administrado por el entrevistado o cuestionario administrado por el entrevistador. (Manilla Derbez & Torres Villafaña, 2009) Entre las ventajas se tienen: 

Facilitan la recopilación de información y no se necesitan muchas explicaciones ni una gran preparación para aplicarlos.



Evitan la dispersión de la información, porque se concentran en preguntas de elección forzosa.

Sus limitantes son: 

La falta de profundidad en las respuestas y no pueden ir más allá del cuestionario.



Puede provocar la obtención de datos equivocados, si las preguntas son formuladas de forma deficiente, así como también si se distorsionan o si se utilizan términos ilegibles, poco usados.

2.2. INGENIERÍA DE SOFTWARE. La Ingeniería de Software es una disciplina que integra el proceso, los métodos, y las herramientas para el desarrollo de software. Esta disciplina no solamente implica todos los procesos para el desarrollo de software, sino también implica toda la documentación llevada a cabo en base a un enfoque sistemático y organizado para su trabajo. (Pressman R. , 2005) 2.2.1. Proceso del Software. El proceso de software es el conjunto de actividades y resultados que producen un producto de software, existen cuatro actividades en el proceso de software las cuales son: (Sommerville I. , 2005) 

Especificación del software: Se define el software a producir y sus restricciones.

15 - 162



Desarrollo de software: Se diseña y programa el software.



Validación de software: Se asegura que se cumplen los requisitos del cliente.



Evolución del software: El software es modificado para adaptar cambios.

2.2.2. Patrón de Arquitectura de Modelo Vista Controlador. MVC es una propuesta de diseño de software utilizada para implementar sistemas donde se requiere el uso de interfaces de usuario. Surge de la necesidad de crear software más robusto con un ciclo de vida más adecuado, donde se potencie la facilidad de mantenimiento, reutilización del código y la separación de conceptos. Su fundamento es la separación del código en tres capas diferentes, acotadas por su responsabilidad, MVC son las siglas de Model View Controller (Modelo-VistaControlador) y es un patrón de la arquitectura del software descrito en 1979 por el Noruego Trygve Reenskaug. (Compilando.ES., 2011) El punto principal de MVC es dividir la aplicación en tres capas reales, una para datos, otra para la lógica y otra para la presentación consiguiendo que sea mantenible, escalable y reutilizable, separa presentación e interacción de los datos del sistema. (Compilando.ES., 2011) El "Modelo", o capa de datos, es el conjunto de clases que representan la información con la que trabaja y su lógica de negocio. Un ejemplo serían las clases en las que consultan a la base de datos mediante el Framework que se va usar. (Compilando.ES., 2011) La "Vista", o capa de presentación, define el modo en el que el usuario ve los datos y como interactúa con ellos. Una página HTML con formularios sería un ejemplo claro de este tipo de capa. (Compilando.ES., 2011) El "Controlador", o capa de lógica, es la que gestiona las peticiones de la Vista solicitando los datos necesarios al Modelo y adaptándolos para su correcta visualización. (Compilando.ES., 2011)

16 - 162

El sistema se estructura en tres componentes lógicos que interactúan entre sí. El componente Modelo maneja los datos del sistema y las operaciones asociadas a esos datos. El componente Vista define y gestiona cómo se presentan los datos al usuario. El componente Controlador dirige la interacción del usuario (por ejemplo, teclas oprimidas, clics del mouse, etcétera) y pasa estas interacciones a Vista y Modelo. (Sommerville I. , 2011) Figura 2: Modelo Vista Controlador.

Fuente: (Compilando.ES., 2011). La característica principal es: 

Se usa cuando existen múltiples formas de ver e interactuar con los datos. También se utiliza al desconocerse los requerimientos futuros para la interacción y presentación.

Las ventajas que ofrece son: 

Permite que los datos cambien de manera independiente de su representación y viceversa.



Soporta en diferentes formas la presentación de los mismos datos, y los cambios en una representación se muestran en todos ellos.

La desventaja que tiene: 

Puede implicar código adicional y complejidad de código cuando el modelo de datos y las interacciones son simples. 17 - 162

2.2.3. Metodología de desarrollo de software. A continuación se desarrolla los diferentes tipos de metodología de desarrollo de software. 2.2.3.1. Programación Extrema XP La programación Extrema o XP es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay alrededor de la programación Los ingredientes utilizados en esta metodología son conocidos desde el principio de la informática, donde, los autores de la metodología XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en cómo se refuerzan los unos con los otros. El resultado de esta selección ha sido esta metodología única y compacta. Aunque no está basada en principios nuevos, el resultado es una nueva manera de desarrollo de software. (Kniberg, 2007) Figura 3: Metodología XP

Fuente: (Kniberg, 2007) 18 - 162

Fases de la Metodología XP: A continuación se describe las cuatro fases de la programación Extrema. 1ª Fase: Planificación del proyecto. En esta primera fase se debe hacer una recopilación de todos los requerimientos del proyecto, también debe haber una interacción con el usuario, y se debe planificar bien entre los desarrolladores del proyecto que es lo que se quiere para el proyecto para así lograr los objetivos finales. (Kniberg, 2007) 2ª Fase: Diseño. En esta fase se sugiere conseguir diseños simples y sencillos. Para procurar hacerlo todo lo menos complicado posible para el usuario o cliente, para conseguir un diseño fácilmente entendible e implementable que a la larga costará menos tiempo y esfuerzo para desarrollarlo. En esta fase se logrará crear parte del proyecto la parte física (lo bonito) la interfaz que tendrá el usuario o cliente con el proyecto. (Kniberg, 2007) 3ª Fase: Codificación. En la fase de codificación, el cliente es una parte más del equipo de desarrollo, su presencia es indispensable en las distintas fases de XP. A la hora de codificar una historia de usuario su presencia es aún más necesaria. No olvidemos que los clientes son los que crean las historias de usuario y negocian los tiempos en los que serán implementadas. Antes del desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo que ésta hará y también tendrá que estar presente cuando se realicen los test que verifiquen que la historia implementada cumple la funcionalidad especificada. En esta fase de la codificación los clientes y los desarrolladores del proyecto deben estar en comunicación para que los desarrolladores puedan codificar todo los necesario para el proyecto que se requiere, en esta fase esta incluido todo lo de codificación o programación por parte de los desarrolladores del proyecto. (Kniberg, 2007)

19 - 162

4ª Fase: Pruebas. Uno de los pilares de la metodología XP es el uso de test para comprobar el funcionamiento de los códigos que vaya implementando. Para esta fase lo que se implementa es el uso de test que son pruebas que se le hacen al proyecto o como ya se dijo a los códigos que se vayan implementando. (Kniberg, 2007) Las características que presenta son: (Gutierrez, 2011) 

Diseño simple: se basa en la filosofía de que el mayor valor de negocio es entregado por el programa más sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseños obsoletos de forma sencilla.



Metáfora: desarrollada por los programadores al inicio del proyecto, define una historia de cómo funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified Modeling Language). La metáfora expresa la visión evolutiva del proyecto que define el alcance y propósito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboración) también ayudarán al equipo a definir actividades durante el diseño del sistema. Cada tarjeta representa una clase en la programación orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cómo se comunica con ellas).



Propiedad colectiva del código: un código con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Este método difiere en mucho a los métodos tradicionales en los que un simple programador posee un conjunto de código. Los defensores de XP argumentan que mientras haya más gente trabajando en una pieza, menos errores aparecerán.



Estándar de codificación: define la propiedad del código compartido así como las reglas para escribir y documentar el código y la comunicación entre diferentes piezas de código desarrolladas por diferentes equipos. Los programadores las han 20 - 162

de seguir de tal manera que el código en el sistema se vea como si hubiera estado escrito por una sola persona. Las ventajas que tiene son: 

Programación organizada.



Menor taza de errores.



Satisfacción del programador.

Las desventajas son: 

Es recomendable emplearlo solo en proyectos a corto plazo.



Altas comisiones en caso de fallar.

2.2.3.2. ICONIX. ICONIX es la metodología que está de moda por su fácil aplicación y rápida producción de software de calidad. ICONIX es un proceso simplificado en comparación con otros procesos más tradicionales, híbrido entre RUP1 y XP, que unifica un conjunto de métodos de orientación a objetos con el objetivo de abarcar todo el ciclo de vida de un proyecto. Fue elaborado por Doug Rosenberg y Kendall Scott a partir de una síntesis del proceso unificado de los “tres amigos” Booch, Rumbaugh y Jacobson y que ha dado soporte y conocimiento a la metodología ICONIX desde 1993. Presenta claramente las actividades de cada fase y exhibe una secuencia de pasos que deben ser seguidos. Además ICONIX está adaptado a los patrones y ofrece el soporte de UML, dirigido por casos de uso y es un proceso iterativo. (Scott & Rosenberg, 2001) Las tres características fundamentales de ICONIX son:

1

RUP, Rational Unified Process en español Proceso Unificado Racional es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo. Su meta es asegurar la producción del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos.

21 - 162



Iterativo e Incremental: Varias iteraciones ocurren entre el desarrollo del modelo del dominio y la identificación de los casos de uso. El modelo estático es incrementalmente refinado por los modelos dinámicos.



Trazabilidad: Cada paso está referenciado por algún requisito. Se define trazabilidad como la capacidad de seguir una relación entre los diferentes artefactos producidos.



Dinámica del UML: La metodología ofrece un uso “dinámico del UML” como los diagramas del caso de uso, diagramas de secuencia y de colaboración. Figura 4: Proceso de desarrollo incremental para ICONIX

Fuente: (Scott & Rosenberg, 2001) Fases de ICONIX ICONIX propone 4 fases o tareas para el desarrollo del sistema: Fase 1: Análisis de requisitos Dentro de esta fase se realizan las siguientes tareas: 

Revisión de los requerimientos



Modelo de casos de usos

Fase 2: Análisis y diseño preliminar 22 - 162

Dentro de esta fase se realizan las siguientes tareas: 

Descripción de los casos de uso



Diagramas de robustez

Fase 3: Diseño Dentro de esta fase se realiza la siguiente tarea: 

Diagramas de secuencia



Elaboración rápida de prototipos

Fase 4: Implementación Dentro de esta fase se realiza la siguiente tarea: 

Escribir y generar código Figura 5: Fases de la metodología ICONIX

Fuente: (Scott & Rosenberg, 2001) Las ventajas del proceso ICONIX son: 

Proceso ágil para obtener un sistema informático.



Dedicada a la construcción de sistemas de gestión de pequeña y mediana complejidad con la participación de los usuarios finales. 23 - 162

Las desventajas de ICONIX son: 

Ésta metodología necesita información rápida y puntual de los requisitos, del diseño y de las estimaciones.



Es una metodología que no debe ser usada en proyectos de larga duración.

2.2.3.3. El proceso unificado ágil (PUA) El proceso unificado ágil (PUA) adopta una filosofía “en serie para lo grande” e “iterativa para lo pequeño” a fin de construir sistemas basados en computadora. Al adoptar las actividades en fase clásicas del PU: concepción, elaboración, construcción y transición; el PUA brinda un revestimiento en serie (por ejemplo, una secuencia lineal de actividades de ingeniería de software) que permite que el equipo visualice el flujo general del proceso de un proyecto de software. (Pressman R. , 2010) Sin embargo, dentro de cada actividad, el equipo repite con objeto de alcanzar la agilidad y entregar tan rápido como sea posible incrementos de software significativos a los usuarios finales. Cada iteración del PUA aborda las actividades siguientes:



Modelado. Se crean representaciones de UML de los dominios del negocio y el problema. No obstante, para conservar la agilidad, estos modelos deben ser “sólo suficientemente buenos para permitir que el equipo avance.



Implementación. Los modelos se traducen a código fuente.



Pruebas. Igual que con la XP, el equipo diseña y ejecuta una serie de pruebas para detectar errores y garantizar que el código fuente cumple sus requerimientos.



Despliegue. El despliegue en este contexto se centra en la entrega de un incremento de software y en la obtención de retroalimentación de los usuarios finales.



Configuración y administración del proyecto. En el contexto del PUA, la administración de la configuración incluye la administración del cambio y el riesgo, y el control de cualquier producto del trabajo persistente que produzca el equipo. La administración del proyecto da seguimiento y controla el avance del equipo y coordina sus actividades. 24 - 162



Administración del ambiente. La administración del ambiente coordina una infraestructura del proceso que incluye estándares, herramientas y otra tecnología de apoyo de la que dispone el equipo.

Aunque el PUA tiene conexiones históricas y técnicas con el lenguaje unificado de modelado, es importante observar que el modelado UML puede usarse junto con cualquiera de los modelos de proceso ágil. (Pressman R. , 2010) Figura 6: El proceso unificado ágil (PUA).

Fuente: (Pressman R. , 2010) Las características de la metodología UP son: 

Iterativo e incremental



Manejo de los Casos de Uso



Centrado en la Arquitectura



Enfocado en los Riesgos

Las ventajas que se pueden encontrar son: 

El personal necesita saber lo que está haciendo. La gente no va a leer la documentación de los procesos en detalle, sino que quieren una orientación de alto nivel y/o formación de vez en cuando. El producto AUP proporciona enlaces a muchos de los detalles si uno está interesado pero no obliga seguir los detalles. 25 - 162



Simplicidad. Todo se describe concisamente usando unas páginas, no miles de páginas.



Agilidad. El PUA se ajusta a los valores y principios de la Alianza Ágil.



Centrarse en las actividades importantes. La atención se centra en las actividades que realmente cuentan.



Herramienta de la independencia. Poder usar cualquier herramienta que desee utilizar con la PUA. Es recomendable utilizar herramientas que mejor se adapten para el trabajo, que a menudo son herramientas simples o incluso herramientas de código abierto.



Querer adaptar este producto para satisfacer sus propias necesidades. El producto AUP es fácil de manejar a través de cualquier herramienta de edición de HTML. Usted no necesita comprar una herramienta especial, o tomar un curso, para adaptar el AUP

Las Desventajas que presenta son: 

El AUP es un producto muy pesado en relación al RUP.



Como es un proceso simplificado, muchos desarrolladores eligen trabajar con el RUP, por tener a disposición mas detalles en el proceso.

2.2.4. Herramienta para el desarrollo de las metodologías A continuación se describe el Agile manifesto una herramienta para el desarrollo de las metodologías donde se basa primordialmente en el producto y no así en la documentación tradicional que seguían metodologías tradicionales. Agile Manifesto En español: Manifiesto para el desarrollo ágil de software, fue creado en 2001 y define una herramienta de trabajo que puede mejorar los resultados en la construcción de software, principalmente el que se desarrolla en modo colaboracional ésta que se basa en 4 valores y doce principios que se caracteriza para el soporte del desarrollo de software. (Páez, 2014) 26 - 162

Figura 7: Manifiesto Ágil

Fuente: (Scientia, 2007) Valores del Manifiesto Ágil El manifiesto hace énfasis en cuatro valores principales que deben soportar el desarrollo de software (Scientia, 2007) 

Valorar más a los individuos y su interacción que a los procesos y las herramientas.

Este es posiblemente el principio más importante del manifiesto. Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero sin personas con conocimiento técnico y actitud adecuada, no producen resultados. Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al revés. 

Valorar más el software que funciona que la documentación exhaustiva

Poder ver anticipadamente cómo se comportan las funcionalidades esperadas sobre prototipos o sobre las partes ya elaboradas del sistema final ofrece una retroalimentación muy estimulante y enriquecedor que genera ideas imposibles de concebir en un primer momento; difícilmente se podrá conseguir un documento que contenga requisitos detallados antes de comenzar el proyecto. 27 - 162

El manifiesto no afirma que no hagan falta. Los documentos son soporte de la documentación, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan. Menos trascendentales para aportar valor al producto. Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse, y reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto. 

Valorar más la colaboración con el cliente que la negociación contractual

En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. 

Valorar más la respuesta al cambio que el seguimiento de un plan

Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan. Principios del manifiesto ágil son: Bajo el concepto de principio se hace referencia a las características que hacen la diferencian entre un proceso ágil y uno tradicional, y constituyen las ideas centrales del desarrollo ágil. (Scientia, 2007) 

La satisfacción del cliente a través de la entrega rápida y continua de paquetes de software útiles y de valor.



Nuevos requisitos son bienvenidos incluso en la etapa final del desarrollo.



Entrega con frecuencia de software que funcione, preferentemente en semanas en vez de meses. 28 - 162



El software que funciona es la prueba fehaciente de que se puede medir el progreso del proyecto.



Desarrollo sostenible, capaz de mantener un ritmo constante.



Trabajo cercano de forma cotidiana entre las personas de negocio y desarrollares.



La conversación cara a cara es la mejor forma de comunicación.



Los proyectos están construidos en torno de personas motivadas, a los cuales se les tiene que dar la confianza necesaria para que realicen la tarea.



Atención continúa a la excelencia técnica y al buen diseño.



Simplicidad.



Equipos que se auto organizan.



Adaptación regular a las circunstancias cambiantes

Las desventajas que tiene son: 

Falta de documentación.



Problemas derivados de la comunicación oral.



Falta de reusabilidad.



Restricciones en cuanto a tamaño de los proyectos abordables.



Mayor complejidad en la gestión del contrato con el cliente en caso de proyectos de precio cerrado.

2.2.5. Lenguaje de modelado Unificado. El lenguaje unificado de diagrama o notación (UML) sirve para especificar, visualizar y documentar esquemas de sistemas de software orientado a objetos. UML no es un método de desarrollo, lo que significa que no sirve para determinar qué hacer en primer lugar o cómo diseñar el sistema, sino que simplemente le ayuda a visualizar el diseño y a hacerlo más accesible para otros. UML está controlado por el grupo de administración de objetos (OMG) y es el estándar de descripción de esquemas de software. UML se compone de muchos elementos de esquematización que representan las diferentes partes de un sistema de software. Los elementos UML se utilizan para crear diagramas, que representa alguna parte o punto 29 - 162

de vista del sistema. Umbrello UML Modeller soporta los siguientes tipos de diagramas: (Fowler & Kendall, 1999) 

Diagrama de casos de uso: Muestra a los actores (otros usuarios del sistema), los casos de uso (las situaciones que se producen cuando utilizan el sistema) y sus relaciones. Figura 8: Diagrama de casos de uso

Fuente: (Pressman R. , 2005) 

Diagrama de robustez: Es un hibrido entre un diagrama de clases y un diagrama de actividad. Figura 9: Diagrama de robustez

Fuente: (Perdita Stevens, 2002) 

Diagrama de secuencia: Es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. 30 - 162

Figura 10: Diagrama de secuencia

Fuente: (Perdita Stevens, 2002) 

Diagrama de dominio: Es un modelo conceptual de todos los temas relacionados con un problema específico. . Figura 11: Diagrama de dominio

Fuente: (Perdita Stevens, 2002)

31 - 162

2.2.6. Pruebas de software. Una vez generado el código fuente, es necesario probar el software para descubrir (y corregir) la mayor cantidad de errores posible antes de entregarlo al cliente. Su objetivo es diseñar una serie de casos de prueba que tengan una alta probabilidad de encontrar errores. (Pressman R. , 2005) Las técnicas proporcionan directrices sistemáticas para pruebas de diseño que comprueben la lógica interna y las interfaces de todo componente del software y comprueben los dominios de entrada y salida del programa para descubrir errores en su función, comportamiento y desempeño. Durante las etapas iníciales del proceso, el desarrollador realiza todas las pruebas, sin embargo, a medida que avanza este proceso se irán incorporando especialistas en pruebas. A continuación se describen algunos tipos de pruebas utilizados para realizar pruebas al software. (Angela, s.f.) 2.2.6.1. Pruebas Funcionales. Este tipo de prueba se realiza sobre el sistema funcionando, comprobando que cumpla con la especificación (normalmente a través de los casos de uso). Para estas pruebas, se utilizan las especificaciones de casos de prueba. (Pressman R. , 2005) 

La prueba funcional se refiere a las pruebas que verifican una acción o función específica del código.



Las pruebas funcionales tienden a responder a la pregunta de "el usuario puede hacer esto" o "se adapta esta función particular“.

2.2.6.2.

Diseño de casos de prueba

Se trata de diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y de tiempo. Cualquier producto de ingeniería se puede probar de dos formas: 

Caja negra



Caja blanca 32 - 162

Pruebas de caja negra. Las pruebas de caja negra, también llamadas pruebas de comportamiento, se enfocan en los requerimientos funcionales del software; es decir, las técnicas de prueba de caja negra le permiten derivar conjuntos de condiciones de entrada que revisarán por completo todos los requerimientos funcionales para un programa. Las pruebas de caja negra no son una alternativa para las técnicas de caja blanca. En vez de ello, es un enfoque complementario que es probable que descubra una clase de errores diferente que los métodos de caja blanca. (Pressman R. , 2005) Las pruebas de caja negra intentan encontrar errores en las categorías siguientes: 

Funciones incorrectas o faltantes.



Errores de interfaz.



Errores en las estructuras de datos o en el acceso a bases de datos externas.



Errores de comportamiento o rendimiento.



Errores de inicialización y terminación.

Prueba de la caja blanca La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar los casos de prueba. Las pruebas de caja blanca intentan garantizar que: 

Se ejecutan al menos una vez todos los caminos independientes de cada módulo



Se utilizan las decisiones en su parte verdadera y en su parte falsa



Se ejecuten todos los bucles en sus límites



Se utilizan todas las estructuras de datos internas

33 - 162

2.2.6.3. Prueba de Usabilidad. Determina la usabilidad del sistema, determina cuán bien el usuario podrá usar y entender la aplicación. Identifica las áreas de diseño que hacen al sistema de difícil uso para el usuario. La prueba de usabilidad detecta problemas relacionados con la conveniencia y practicidad del sistema desde el punto de vista del usuario. (Pressman R. , 2010) Verifica que la aplicación no presenta los siguientes problemas de usabilidad típicos: 

El sistema es demasiado complejo y difícil de usar.



Es difícil instalar y entender el sistema



La recuperación de errores es pobre y los mensajes de error no tienen significado



La sintaxis de los comandos es difícil de aprender y recordar



El sistema obliga al usuario a recordar formatos y secuencias fijas



Los procedimientos no son simples ni obvios



El sistema no tiene instrucciones de ayuda por computadora y tiene manuales pobres.



Los diagramas, pantallas, reportes y gráficos son de calidad y apariencia pobre.

Se deben crear casos de prueba para comprobar que se puede operar en el sistema de forma adecuada

2.3. ARQUITECTURA DE SOFTWARE. 2.3.1. Cliente Servidor Móvil. Es el modelo de desarrollo que se ha utilizado con éxito en las denominadas “aplicaciones web”, y ha sido retomado con algunas adaptaciones en los ambientes móviles inalámbricos. (Alonso, 2004)

34 - 162

Figura 12: Arquitectura cliente/servidor móvil.

Fuente: (Geospatial, 2013). Éste modelo arquitectónico de software está compuesto por 3 capas o niveles: Presentación: Provee la interfaz de usuario, a través de la cual se realizan operaciones como el ingreso de datos y la presentación de las respuestas enviadas desde el servidor. Lógica de negocio: Implementa las reglas que rigen la organización (reglas del negocio), se proveer servicios como la ejecución de aplicaciones (procedimientos). Datos: Provee el acceso a las BD 2, y se puede realizar utilizando un SGBD3. Debe asegurar la integridad, la seguridad de los datos y el acceso concurrente. (Alonso, 2004) La característica es: La característica principal de esta arquitectura son las capas o niveles de organización.

2 3

Base de datos Sistema Gestor de base de datos

35 - 162

2.3.2. Smart Client. La arquitectura Smart Client o cliente ligero en español, también llamado terminal tonto, es una computadora en una arquitectura de red cliente-servidor carente de disco duro, lector de CD y disquetera, con muy poca o ninguna lógica interna, limitándose a presentar por pantalla un interfaz, y realizándose las operaciones en un servidor que manda los resultados a los terminales a través de la red. (Mora, 2011) Cliente-servidor. Los datos capturados en el cliente son enviados al servidor de datos. Nota: en el dispositivo móvil normalmente se encuentra solo un “subconjunto” de los datos debido a las limitaciones de memoria. Figura 13: Smart Client.

Fuente: (Davis & Steven, 2002) Los clientes inteligentes se distinguen por las características clave: 

Los clientes inteligentes pueden trabajar con datos, incluso cuando no están conectados a Internet (que las distingue de las aplicaciones basadas en navegador, que no funcionan cuando el dispositivo no está conectado a Internet)

36 - 162



Las aplicaciones cliente inteligentes tienen la capacidad de ser desplegadas y actualizadas en tiempo real a través de la red desde un servidor centralizado



Las aplicaciones cliente inteligentes de apoyo de múltiples plataformas e idiomas, ya que se basan en servicios Web.



Las aplicaciones cliente inteligentes pueden funcionar en casi cualquier dispositivo que tenga conexión a Internet, incluidas computadoras de escritorio, estaciones de trabajo, portátiles, tablet PCs, PDAs, y teléfonos móviles.

Las ventajas que se tienen son: 

Reduce la transferencia de datos a través de la red (datos distribuidos) reduce costos.



Reduce la carga de trabajo de los servidores (aplicaciones y datos).



Acceso permanente a los datos.

Las desventajas que presenta son: 

Desarrollo complejo en los clientes debido a la heterogeneidad de dispositivos móviles.



Diversidad de aplicaciones comerciales para sincronización ligadas a los Sistemas de Gestión de Bases de Datos (SGBD) propietarios.

2.3.3. Thin Client. La arquitectura Thin Client o slim client que traducido es cliente liviano o cliente delgado es una computadora cliente o un software de cliente en una arquitectura de red cliente-servidor que depende del servidor central para las tareas de procesamiento, y se enfoca principalmente en transportar la entrada y la salida entre el usuario y el servidor remoto. (Davis & Steven, 2002) Muchos dispositivos de cliente liviano ejecutaban solamente navegadores web o programas de escritorio remoto, todo el procesamiento significativo ocurría en el servidor. Algunos clientes livianos también son llamados "terminales de acceso".

37 - 162

A continuación se describen gráficamente el proceso que realiza la arquitectura Thin Client o slim client. Figura 14: thin client.

Fuente: (Davis & Steven, 2002) Las características que presenta son: 

Facilidad para escalar: Modificando únicamente las características del servidor.



Facilidad de administración: Control centralizado en el servidor.



Información centralizada: Facilita el acceso y el control de esta.



Sin valor para los ladrones: Solo funcionan bajo gestión del servidor.

Las ventajas que presenta son: (Davis & Steven, 2002) 

Información Centralizada. Como la información se encuentra en un solo lugar facilita la realización de backups y evita que se guarden archivos que no sean del negocio.



Menor coste de hardware. El hardware de los Clientes Livianos es generalmente más barato ya que estos no cuentan con disco duro, memoria para las aplicaciones, o un procesador poderoso.



También tienen un periodo de funcionamiento más largo antes de necesitar actualizarse o quedar obsoletos.

38 - 162

Las desventajas que se tiene son: (Davis & Steven, 2002) 

Su servidor, ya que los clientes no procesan o almacenan ninguna información por su cuenta, necesitan de una conexión a un servidor que realice estas tareas por ellas



A medida que los clientes requieren de una conexión a un servidor, también necesitan de una infraestructura de red.



Las aplicaciones con contenido enriquecido como audio y vídeo necesita una gran repartición de recursos de redes así como potencia de cómputo para reproducir.

2.4. HERRAMIENTAS DE SOFTWARE. A continuación se describe las herramientas de software: 2.4.1. Entornos de desarrollo Android (IDE). Los IDE proveen un marco de trabajo amigable para la mayoría de los lenguajes de programación tales como C++, PHP, Python, Java, C#, Delphi, Visual Basic, etc. En algunos lenguajes, un IDE puede funcionar como un sistema en tiempo de ejecución, en donde se permite utilizar el lenguaje de programación en forma interactiva, sin necesidad de trabajo orientado a archivos de texto. (Rehman, Paul, & Paul., 2002) 2.4.1.1. Apache Cordova. Apache Cordova (anteriormente PhoneGap ) es un popular entorno de desarrollo de aplicaciones móviles creado originalmente por Nitobi . Adobe Systems comprado Nitobi en 2011, rebautizado como PhoneGap, y posteriormente liberado una versión de código abierto del software llamado Apache Córdoba. Apache Cordova permite software programadores construir aplicaciones para dispositivos móviles utilizando CSS3 , HTML5 y JavaScript en lugar de depender específicas de la plataforma API como los de Android , iOS o Windows Phone . Se permite concluir de CSS, HTML y código JavaScript dependiendo de la plataforma del dispositivo. Se extiende las características de HTML y JavaScript para funcionar con el dispositivo. Las aplicaciones resultantes son híbrido, lo que significa que son de aplicación móvil ni 39 - 162

verdaderamente nativo (porque todos representación diseño se realiza a través de puntos de vista Web en lugar de marco interfaz de usuario nativa de la plataforma) ni puramente (porque no son aplicaciones simplemente Web, pero se empaquetan basado en la Web como aplicaciones para la distribución y el acceso a las API nativas de los dispositivos). Mezclando fragmentos de código nativo e híbridos ha sido posible desde la versión 1.9. La característica principal es: 

Apoya el desarrollo de los sistemas operativos de Apple iOS , Bada , BlackBerry, Firefox OS , Google Android , LG webOS , MicrosoftWindows Phone (7 y 8), Nokia Symbian OS, Tizen (2.x SDK ), y Ubuntu táctil .

Las ventajas que ofrece son: 

Flujo de trabajo multiplataforma (CLI): se usa este flujo de trabajo si se quiere que la aplicación ejecute en los sistemas operativos móviles como sea posible, con poco necesidad específica de la plataforma desarrollo



Flujo de trabajo centrado en plataforma: se usa este flujo de trabajo si se desea concentrarse en construir una aplicación para una sola plataforma y necesitan poder modificarlo en un nivel inferior.

La desventaja principal es: 

Que tienes que dominar muchos lenguajes y herramientas y que el tiempo de desarrollo se multiplica mucho, pues es necesario crear desde cero tres versiones diferentes de la misma aplicación (una para cada plataforma).

2.4.1.2. Sublime text 3 Es un editor de código multiplataforma, ligero y con pocas concesiones a las florituras. Es una herramienta concebida para programar sin distracciones. Su interfaz de color oscuro y la riqueza de coloreado de la sintaxis, centra nuestra atención completamente. (Rehman, Paul, & Paul., 2002)

40 - 162

Sublime Text permite tener varios documentos abiertos mediante pestañas, e incluso emplear varios paneles para aquellos que utilicen más de un monitor. Dispone de modo de pantalla completa, para aprovechar al máximo el espacio visual disponible de la pantalla. El sistema de resaltado de sintaxis de Sublime Text soporta un gran número de lenguajes (C, C++, C#, CSS, D, Erlang, HTML, Groovy, Haskell, HTML, Java, JavaScript, LaTeX, Lisp, Lua, Markdown, Matlab, OCaml, Perl, PHP, Python, R, Ruby, SQL, TCL, Textile and XML). (Rodríguez, 2009) Las características son: 

Minimapa: consiste en una previsualización de la estructura del código, es muy útil para desplazarse por el archivo cuando se conoce bien la estructura de este.



Multi Selección: Hace una selección múltiple de un término por diferentes partes del archivo.



Multi Cursor: Crea cursores con los que podemos escribir texto de forma arbitraria en diferentes posiciones del archivo.



Multi Layout: Trae siete configuraciones de plantilla podemos elegir editar en una sola ventana o hacer una división de hasta cuatro ventanas verticales o cuatro ventanas en cuadrícula.



Soporte nativo para infinidad de lenguajes: Soporta de forma nativa 43 lenguajes de programación y texto plano.



Syntax Highlight configurable: El remarcado de sintaxis es completamente configurable a través de archivos de configuración del usuario.



Búsqueda Dinámica: Se puede hacer búsqueda de expresiones regulares o por archivos, proyectos, directorios, una conjunción de ellos o todo a la vez.



Auto completado y marcado de llaves: Se puede ir a la llave que cierra o abre un bloque de una forma sencilla.



Soporte de Snippets y Plugins: Los snippets son similares a las macros o los bundles además de la existencia de multitud de plugins.

41 - 162



Configuración total de Keybindings: Todas las teclas pueden ser sobrescritas a nuestro gusto.



Acceso rápido a línea o archivo: Se puede abrir un archivo utilizando el conjunto de teclas Cmd+P en Mac OS X o Ctrl+P en Windows y Linux y escribiendo el nombre del mismo o navegando por una lista. También se puede ir a una línea utilizando los dos puntos ":" y el número de línea.



Paleta de Comandos: Un intérprete de Python diseñado solo para el programa con el cual se puede realizar infinidad de tareas.



Coloreado y envoltura de sintaxis: Si se escribe en un lenguaje de programación o marcado, resalta las expresiones propias de la sintaxis de ese lenguaje para facilitar su lectura.



Pestañas: Se pueden abrir varios documentos y organizarlos en pestañas.



Resaltado de paréntesis e indentación: Cuando el usuario coloca el cursor en un paréntesis, corchete o llave, resalta ésta y el paréntesis, corchete o llave de cierre o apertura correspondiente.

Las ventajas son: 

Un editor de texto que poco a poco suplantó a TextMate en Mac y que se ha ido expandiendo en otras plataformas a ritmo acelerado.



Esta aplicación es bastante personalizable al punto que podemos cambiar el comportamiento del editor, el tamaño y tipo de tipografía, los atajos de teclado, los esquemas de colores y otras series de opciones para acomodar la aplicación a nuestras necesidades.

La desventaja es: 

Sublime Text no es gratis, sin embargo podemos usar la versión de prueba por tiempo indefinido, solo que nos saldrá un popUp cada vez que guardemos nuestros archivos una determinada cantidad de veces, recordándonos que sería bueno para su desarrollador, el pagar por usarlo

42 - 162

2.4.1.3. Android developer tools. Herramientas de desarrollo de Android (ADT) es un plugin para el IDE Eclipse que está diseñado para darle un entorno potente, integrado en el que construir aplicaciones de Android. ADT amplía las capacidades de Eclipse para que pueda configurar rápidamente nuevos proyectos Android, crear una interfaz de usuario de la aplicación, agregar paquetes basados en la API del marco de Android, depurar sus aplicaciones utilizando las herramientas del SDK de Android, e incluso exportar firmados (o sin firmar) los archivos .apk con el fin de distribuir su aplicación. (Ducrohet, 2013) El desarrollo en Eclipse con ADT es muy recomendable y es la manera más rápida de comenzar. Con la configuración guiada proyecto que ofrece, así como la integración de herramientas, editores XML personalizados, y el panel de resultados de depuración, ADT le da un impulso increíble en el desarrollo de aplicaciones para Android. (Warnnez, 2013) Las características son: 

Las características de depuración constituyen el núcleo de Dev Tools. Con esta aplicación, puedes seleccionar cualquier aplicación a depurar.



Dev Tools también puede mostrar un medidor de CPU en la parte superior de la pantalla para controlar el uso de CPU actual, lo cual ayuda a los desarrolladores realizar un seguimiento de los efectos de la aplicación en el rendimiento del sistema.

Las ventajas que tiene son: 

Dev Tools evita que el sistema operativo genere mensajes de error, incluso cuando estás detenido en un punto de interrupción durante largos períodos.



Dev Tools envía señales a través de actualizaciones de pantalla. La aplicación hace parpadear un rectángulo de color rosa brevemente en cualquier pantalla para indicar las secciones que están siendo rediseñadas. 43 - 162

La desventaja es: 

Para poder usar Dev Tool en un dispositivo de desarrollo real, se debe copiar la imagen del sistema que va por defecto dentro del Kit de desarrollo de software Android y copiarlo desde un emulador ejecutando el comando “adb-e pull /system/app/Development.apk ./Development.apk”, el cual copia la aplicación, un archivo tipo .apk, en el directorio actual. Para instalar la aplicación, se usa el comando “adb -d install Development.apk”.

2.4.2. Kit de desarrollo de software (SDK). Un SDK es Software Development Kit, o kit de desarrollo de software, es un conjunto de herramientas que ayudan a la programación de aplicaciones para un entorno tecnológico particular. Es decir, las aplicaciones desarrolladas sobre el SDK estarán destinadas a algún sistema operativo, plataforma hardware, consola de videojuegos o paquete de software en especial. (Shane Conder, 2012) Las características son: 

Una interfaz de programación de aplicaciones (API). Puede verse como una abstracción del funcionamiento interno del entorno sobre el que se va a trabajar. Se trata de un conjunto de funciones, rutinas, estructuras de datos, clases y variables que permiten manipular el mecanismo de la plataforma sin conocerlo internamente.



Un entorno de desarrollo integrado (IDE). Un editor que ayuda a escribir fácilmente el código fuente del programa. Generalmente, también brinda una interfaz amigable para dos aplicaciones fundamentales:



Debugger. Permite “testear” el programa en cada paso de su ejecución.



Compilador. Traduce el código fuente a lenguaje de máquina, obteniendo así un programa ejecutable.



Código de ejemplo y otra documentación. Como punto de partida para empezar a desarrollar aplicaciones.

44 - 162



Un emulador del entorno. si se desarrolla una aplicación para móviles desde una computadora de escritorio, permite saber cómo la vería el usuario final.

Actualmente, plataformas como los sistemas operativos Android, iOS y Windows Phone ofrecen kits para desarrollar software que funcione sobre sus entornos, y muchas redes sociales tienen SDK específicos para desarrollar todo tipo de aplicaciones en diferentes lenguajes. (Shane Conder, 2012) Las ventajas son: 

las aplicaciones desarrolladas sobre el SDK estarán destinadas a algún sistema operativo, plataforma hardware, consola de videojuegos o paquete de software en especial.



Una interfaz de programación de aplicaciones (API).

La desventaja: 

Diferentes habilidades/idiomas/herramientas para cada plataforma de destino.

2.5. TECNOLOGÍAS DE DESARROLLO DE APLICACIONES MÓVILES A continuación se mencionan las tecnologías necesarias para el desarrollo de aplicaciones móviles: 2.5.1. APLICACIÓN MÓVIL Aplicaciones móviles o App son aplicaciones desarrolladas para los dispositivos móviles, Smartphone o PDAS4. Estas aplicaciones pueden ser preinstaladas en el dispositivo o descargadas por los usuarios desde las tiendas de aplicaciones en Internet. Una aplicación móvil es una aplicación informática diseñada para ser ejecutada en teléfonos inteligentes, tabletas y otros dispositivos móviles. Por lo general se

4

Agenda electrónica de bolsillo

45 - 162

encuentran disponibles a través de plataformas de distribución, operadas por las compañías propietarias de los sistemas operativos móviles como Android, iOS, BlackBerry5, Windows Phone6, entre otros. (Petrazzini, 2012) Existen tres tipos de aplicaciones móviles: 

Aplicaciones móviles nativas



Aplicaciones móviles Web



Aplicaciones móviles hibridas

2.5.1.1.

Aplicaciones móviles nativas

Este tipo de aplicaciones están hechas para ejecutarse en un dispositivo y sistema operativo específico. Así, la mayor parte de las aplicaciones descargadas de la App store de Apple son aplicaciones que solo van a correr sobre iPhone e iPad. Este tipo de aplicaciones se crean con distintos tipos de lenguajes. Las desarrolladas para iOS (el sistema operativo para iPhone e iPad) lo hacen con los lenguajes: Objetive C, C 7, C++8. Las aplicaciones desarrolladas para el sistema operativo Android lo hacen con lenguaje Java. Este tipo de aplicaciones corren de forma más eficiente sobre estos dispositivos ya que sus componentes están diseñados de forma específica para este sistema operativo. Además, este tipo de aplicaciones pueden emplear todos los censores y elementos del teléfono: cámara, GPS9, acelerómetro, agenda, etc. Esta es una diferencia fundamental con respecto a las aplicaciones web. El código fuente de estas aplicaciones se escribe en función del dispositivo para el que se trabaje. Este código fuente se compila a un ejecutable. Es un proceso similar al de las tradicionales aplicaciones de escritorio. Todos aquellos recursos (imágenes, iconos, etc.) que la aplicación necesita para ejecutarse quedan en el archivo compilado. Este archivo esta ya listo para ser distribuido y subido a las App stores 5

Sistema operativo móvil BlackBerry. Sistema operativo móvil desarrollado por Microsoft. 7 Lenguaje de programación basado en el lenguaje de programación B 8 Lenguaje de programación hibrido orientado a objetos 9 Sistema de posicionamiento global, utiliza triangulación para determinar en todo el globo la posición con una precisión de metros. 6

46 - 162

(tienda de aplicaciones) especificas del dispositivo para el que se trabaja. Una vez subido el ejecutable, las App stores tiene un proceso de auditoria de la aplicación para evaluar si se adecua a los requerimientos del sistema. Figura 15: Arquitectura de aplicación móvil nativa

Fuente: (Geospatial, 2013) Son programadas usando, por ejemplo, Objetive C en el iPhone o el uso de Java en los dispositivos Android. Pueden ser de varios tipos: 

Aplicaciones nativas que hacen uso de todas las funciones del teléfono, tales como la cámara del teléfono móvil, geolocalización, o a la agenda de direcciones de usuarios.



Aplicaciones nativas que no necesitan estar conectados a Internet para ser utilizadas.



Aplicaciones nativas especificas para el teléfono móvil en el que se ejecutan, ya que utilizan las características de ese teléfono en particular.

47 - 162



Aplicaciones nativas que pueden ser distribuidos en el mercado de forma gratuita o no. (por ejemplo, Apple Store para iPhone o tienda Ovi10 de Nokia para los teléfonos).

2.5.1.2.

Aplicaciones móviles web

Las aplicaciones web móviles, a diferencia de las aplicaciones nativas, se ejecutan dentro del navegador del teléfono. Por ejemplo, en la plataforma iOS, se ejecutan en el navegador Safari. Estas aplicaciones están desarrolladas con HTML11, CSS12 y Java script13. Esto significa que la aplicación funciona en todos los dispositivos, y se asegura la compatibilidad entre plataformas siendo el testing de la aplicación web en cada plataforma y navegador totalmente requerido. El mismo código base se puede utilizar para todos los dispositivos, incluyendo iPhone y Android. Sin embargo, como inconveniente, las aplicaciones web no hacen uso de características nativas del teléfono, tales como la cámara o la geolocalización. Las aplicaciones web no se pueden vender en tiendas virtuales. Las aplicaciones web hacen uso de las tecnologías web existentes, tales como Java script y CSS, lo que significa que las barreras técnicas de entrega son bajas. Los desarrolladores pueden usar sus habilidades anteriores para desarrollar una aplicación web, mientras que las aplicaciones nativas pueden necesitar una formación adicional, dado que las tecnologías son mas recientes.

10

Tienda de Nokia que ofrece servicios de compra de aplicaciones para usuarios. HyperTextMarkupLanguaje (Lenguaje de marcas de hipertextos). 12 Cascading Style Sheets (Hojas de estilo en cascada). 13 Es un lenguaje de programación interpretado. 11

48 - 162

Figura 16: Arquitectura de aplicación móvil web

Fuente: (Geospatial, 2013) 2.5.1.3.

Aplicaciones móviles hibridas

Una aplicación móvil hibrida es una aplicación móvil nativa con HTML incrustado. Usando un framework de desarrollo común, las empresas pueden desarrollar aplicaciones multiplataforma que utilizan tecnologías web (como HTML, Java script y CSS), haciendo uso de las funciones del teléfono, determinadas partes de la aplicación se programan utilizando tecnologías web. Las porciones de web se puede descargar desde la web, o embebidas dentro de la aplicación. Esta opción permite a las empresas cosechar todos los beneficios de las aplicaciones nativas al tiempo que garantiza la longevidad de los proyectos asociados con las tecnologías web establecidas previamente. Se trata de aplicaciones nativas que utilizan el navegador. Utilizan el mismo procedimiento de instalación que las aplicaciones nativas (a través de una tienda de aplicaciones), pero gran parte de estas aplicaciones se diseña utilizando paginas web. 49 - 162

Se utilizan este tipo de aplicaciones como contenedores de aplicaciones web existentes, es una manera económica y rápida de lograr presencia en las tiendas de aplicaciones. Figura 17: Arquitectura de aplicación móvil hibrida

Fuente: (Geospatial, 2013) Las aplicaciones hibridas aúnan lo mejor de los dos anteriores modelos. Este tipo de aplicaciones permite el uso de tecnologías multiplataforma como HTML, Java script y CSS pero permiten acceder a una buena parte de los dispositivos y sensores del teléfono. Buena parte de la infraestructura es tipo web y la comunicación son los elementos del teléfono se hace mediante comunicadores tales como Phonegap 14. Un buen ejemplo de aplicaciones hibridas es Facebook. Se descarga de la App store y cuenta con todas las características de una aplicación nativa pero requiere ser actualizada ocasionalmente.

14

Framwork de código abierto para crear aplicaciones móviles.

50 - 162

El proceso de desarrollo para este tipo de aplicaciones es algo mas complicado. Al igual que para las aplicaciones nativas, el código una vez creado se compila a un ejecutable. Además, también como en las aplicaciones web se genera código HTML, CSS y Java script a ejecutar en un navegador. Ambos códigos se compilan para ser subidos mediante un paquete distribuible a la App store. 2.5.2. Framework Un Framework (Marco de trabajo), define en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar. (Sosinformatico, 2012) En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de software concretos, que puede servir de base para la organización y desarrollo de software. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto. (Sosinformatico, 2012) Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio, y provee una estructura y una especial metodología de trabajo, la cual extiende o utiliza las aplicaciones del dominio. (Sosinformatico, 2012) 2.5.2.1. jQuery Mobile. JQuery Mobile es un Framework optimizado para dispositivos táctiles (también conocido como Framework móvil) que está siendo desarrollado actualmente por el equipo de proyectos de jQuery. El desarrollo se centra en la creación de un Framework compatible con la gran variedad de smartphones y tablets, algo necesario en el creciente y heterogéneo mercado de tablets y smartphones. (Chaffer & Swedberg, 2007) Las características que presenta son: 51 - 162



Manipulación de la hoja de estilos CSS.



Efectos y animaciones.



Animaciones personalizadas.



AJAX.



Soporta extensiones.

Las ventajas son: 

Compatible con la mayoría de las plataformas móviles como la mayoría de los navegadores: iOS, Android, BlackBerry, Web OS, Symbian, Windows Phone 7.



Construido sobre el núcleo jQuery, para que la curva de aprendizaje sea mínima para desarrolladores familiarizados con la sintaxis de jQuery.



Un framework de temas que permite personalizar uno rápidamente.



Dependencias limitadas y ligero que optimizan su velocidad.



El mismo código de base escalará el tamaño automáticamente a cualquier pantalla.



Posibilidad de navegación entre páginas por AJAX con animaciones en las transiciones de página.



UI widgets optimizados para táctil y para quien desconozca la plataforma. (Chaffer & Swedberg, 2007)

Las desventajas son: 

Las funciones que ofrece son muchas, pero resultan difíciles de personalizar. Su aspecto visual es estandarizado y no se integra con el de la plataforma. En algunos casos, no queda otra opción que usar JavaScript simple para adaptar la aplicación a nuestras necesidades.



Como es necesario invocar a un archivo para utilizar sus funciones, ralentiza levemente la carga de la página.



Su manejo de CSS suele resultar innecesariamente complejo. A veces cuesta saber qué clases utilizar.

52 - 162



No existen muchas plantillas prediseñadas sobre las cuales empezar a construir nuestra aplicación. (Chaffer & Swedberg, 2007)

2.5.2.2. AppCelerator AppCelerator es un framework que permite crear aplicaciones nativas para móviles basándonos en Javascript. Además, no sólo incluye esto, sino automatización de test y una gran comunidad detrás. (Zamora, 2015) AppCelerator es un proveedor líder de tecnologías de código abierto para desarrollar, probar y comercializar móviles, de escritorio y aplicaciones web. (Zamora, 2015) AppCeleator hizo público la disponibilidad de una versión beta de su programa estrella Appcelerator Titanio. Esta nueva versión incluye un nueva funcionalidad que permite entrar a desarrollar para la plataforma móvil la tecnología web, para desarrollar aplicaciones nativas para el iPhone y Android a la vez sin necesidad de conocer los lenguajes de programación (Objective-C o Java ) sino tener conocimientos de lenguajes web (Html, javascript, css, flash etc.). AppCeleator presta apoyo a las tecnologías tradicionales de la web tales como HTML, CSS y JavaScript, pero soporta aplicaciones desarrolladas con Adobe Flash, Microsoft Silverlight, AJAX, en Mac OSX, Windows, Linux, iPhone o Android plataformas, con lo que se abre más el marco de desarrolladores web para las plataformas móviles. Además de enfocarse al mundo móvil, también se enfoca en las plataforma escritorio con lo que hace competencia con el AIR de Adobe, pero teniendo la ventaja que se ha introducido en el mundo móvil antes que este. (AndroidGuys, 2009) Las características que tiene son: 

Soporta el desarrollo de aplicaciones móviles multiplataforma



Con una sola base de código, pueden producir aplicaciones móviles Web, Android y iOS



Se desarrolla utilizando un lenguaje basado en JavaScript en un entorno de desarrollo integrado basado en Eclipse (Aptana Studio) 53 - 162



Aumenta en más de un 70 % la productividad al escribir aplicaciones



Permite utilizar la experiencia de los desarrolladores en tecnologías y estándares Web

Las ventajas que presenta son: 

Multiplataforma móvil y también de escritorio.



Aspecto y controles nativos. El mejor rendimiento.



Gratis, soporte de pago. Licencia Apache.

Las desventajas que tiene son: 

Requiere Mac y Xcode para empaquetar aplicaciones IOS.



Definición de componentes visuales y controles “a mano” (PhoneGap es HTML y Flex es MXML)



Mucha documentación pero poco actualizada y descolocada, tutoriales desfasados, poco profesional (en mi opinión)



Las aplicaciones de escritorio se distribuyen con el código fuente en claro (html, js, css, imágenes, etc.)

2.5.2.3. PhoneGap. PhoneGap es un framework para el desarrollo de aplicaciones móviles producido por Nitobi, y comprado posteriormente por Adobe Systems. PhoneGap permite a los programadores desarrollar aplicaciones para dispositivos móviles utilizando herramientas genéricas tales como JavaScript, HTML5 yCSS3. Las aplicaciones resultantes son híbridas, es decir que no son realmente aplicaciones nativas al dispositivo (ya que el renderizado se realiza mediante vistas web y no con interfaces gráficas específicas de cada sistema), pero no se tratan tampoco de aplicaciones web (teniendo en cuenta que son aplicaciones que son empaquetadas para poder ser desplegadas en el dispositivo incluso trabajando con el API del sistema nativo). (Zamora, 2015)

54 - 162

PhoneGap maneja API que permiten tener acceso a elementos como el acelerómetro, la cámara, los contactos en el dispositivo, la red, el almacenamiento, las notificaciones, etc. Estas API se conectan al sistema operativo usando el código nativo del sistema huésped a través de una Interfaz de funciones foráneas en Javascript. PhoneGap permite el desarrollo ya sea ejecutando las aplicaciones en nuestro navegador web, sin tener que utilizar un simulador dedicado a esta tarea, y brinda la posibilidad de soportar funciones sobre frameworks como Sencha Touch o JQuery Mobile. (Marin, 2014) Las características que presenta son: 

Phonegap permite crear actualmente aplicaciones móviles para: iPhone, Android, Windows Phone, Blackerry, Blackberry 10, webOS, Symbian y Bada.



Las aplicaciones creadas con PhoneGap sólo pueden nutrirse de HTML, CSS y Javascript. Si requieren lógica generada por otros lenguajes de programación, deberán conseguirla de un backend a través de APIs o webservices



Ofrece un servicio en la nube llamado PhoneGap Build que permite construir rápidamente apps móviles y compilarlas con facilidad sin necesidad de SDKs, compiladores o hardware específico.

Las ventajas que tiene son: 

Es la solución que más plataformas móviles soporta, ya que corre dentro de un navegador web. Además de Iphone/Ipad y Android, funciona también en Palm, Symbian, WebOS, W7 y BlackBerry,



Es muy fácil de desarrollar y proporciona una gran libertad a los que tienen conocimientos de HTML y Javascript.



Hay buena documentación y bastantes ejemplos.



Es gratis,

Los Inconvenientes que presenta son: 

Requiere Mac con Xcode para empaquetar aplicaciones IOS. 55 - 162



La aplicación no es más que una página web, por lo que el aspecto dependerá del framework web utilizado. Necesitaremos el uso de frameworks HTML móviles como Sencha Touch, jQuery mobile, Jo, Sproutcore, XUI, jQTouch si queremos que parezca una aplicación nativa.



No llega al rendimiento de una aplicación nativa, pues el HTML, CSS y Javascript debe ser leido e interpretado por el engine del navegador cada vez arranca.

2.5.3. Lenguajes de programación Un lenguaje de programación es un idioma artificial, diseñado para expresar procesos que pueden ser llevadas a cabo por máquinas, como las computadoras. Pueden usarse para crear programas que controlen el comportamiento físico y lógico de una máquina, para expresar algoritmos con precisión, o como modo de comunicación humana. Está formado por un conjunto de símbolos y reglas sintácticas y semánticas que definen su estructura y el significado de sus elementos y expresiones. La programación es el proceso por el cual se escribe, se prueba, se depura, se compila y se mantiene el código fuente de un programa informático. (MINGUET, 2008) 2.5.3.1. Python Python es un lenguaje de programación interpretado cuya filosofía hace hincapié en una sintaxis que favorezca un código legible. Se trata de un lenguaje de programación multiparadigma, ya que soporta orientación a objetos, programación imperativa y, en menor medida, programación funcional. Es un lenguaje interpretado, usa tipado dinámico y es multiplataforma. Es administrado por la Python Software Foundation. Posee una licencia de código abierto, denominada Python Software Foundation License, que es compatible con la Licencia pública general de GNU a partir de la versión 2.1.1, e incompatible en ciertas versiones anteriores. Python es un lenguaje de programación multiparadigma. Esto significa que más que forzar a los programadores a adoptar un estilo particular de programación, permite 56 - 162

varios estilos: programación orientada a objetos, programación imperativa y programación funcional. Otros paradigmas están soportados mediante el uso de extensiones.Python usa tipado dinámico y conteo de referencias para la administración de memoria. La característica principal es: 

Python es la resolución dinámica de nombres; es decir, lo que enlaza un método y un nombre de variable durante la ejecución del programa (también llamado enlace dinámico de métodos).



El diseño del lenguaje es la facilidad de extensión. Se pueden escribir nuevos módulos fácilmente en C o C++. Python puede incluirse en aplicaciones que necesitan una interfaz programable.

Aunque la programación en Python podría considerarse en algunas situaciones hostiles a la programación funcional tradicional del Lisp, existen bastantes analogías entre Python y los lenguajes minimalistas de la familia Lisp como puede ser Scheme. (Martínez, Ceceñas, & Leyva, 2015) Las ventajas son: 

Simplificado y rápido: es que simplifica mucho la programación “hace que te ciñas a un modo de lenguaje de programación, python te propone un patrón”.



Elegante y flexible: el lenguaje da muchas herramientas “si quiero listas de varios datos, no hace falta que declares cada cosa” y que al ser tan flexible no te preocupas tanto por los detalles.



Programación sana y productiva: programar en python se convierte en un estilo muy sano de programar: “es sencillo de aprender, direccionado a las reglas perfectas, te haces como dependiente de mejorar, cumplir las reglas, el uso de las lineas, de variables”.



Ordenado y limpio: el orden que mantiene python “es muy leible, cualquier otro programador lo puede leer y trabajar sobre el.

57 - 162



Portable: es un lenguaje muy portable (ya sea en mac, linux o windows) en comparación con otros lenguajes.

La desventaja es: 

Los programas interpretados son más lentos que los compilados.

2.5.3.2.

Ruby

El lenguaje Ruby está diseñado para la productividad y la diversión del desarrollador, siguiendo los principios de una buena interfaz de usuario Sostiene que el diseño de sistemas necesita enfatizar las necesidades humanas más quelas de la máquina: Ruby sigue el "principio de la menor sorpresa", lo que significa que el lenguaje debe comportarse de tal manera que minimice la confusión de los usuarios experimentados. Combina una sintaxis inspirada en Python, Perl con características de programación orientada a objetos similares a Smalltalk, Comparte también funcionalidad con otros lenguajes de programación como Lisp, Lua, Dylan y CLU. Ruby es un lenguaje de programación interpretado en una sola pasada y su implementación oficial es distribuida bajo una licencia de software libre (Dewit O. , 2003) Las características que posee son: • Orientado a objetos • Existe diferencia entre mayúsculas y minúsculas. • Múltiples expresiones por líneas, separadas por punto y coma “;”. • Dispone de manejo de excepciones. • Librerías de extensiones dinámicamente si el (Sistema Operativo) lo permite. • Dinámico • Entiende expresiones regulares • Multiplataforma • Recolector de basura inteligente • Sintaxis flexible • Sobre carga de operadores 58 - 162

• Puede cargar librerías de extensiones dinámicamente si el (Sistema Operativo) lo permite. • Portátil Las ventajas de Ruby son: 

Es un lenguaje sencillo y fácil de leer.



Soportado por la mayoría de las plataformas web.



Se trata de un software libre u opensource.



Integra comandos de manejo de bases de datos.

Desventajas de Ruby: 

Rendimiento comparable a Perl o Python, pero lejos de C o C++



No existen muchas frameworksdesarrolladas en Ruby



No existe una framework de GUI multi-plataforma ampliamente aceptada

2.5.3.3.

Java.

El lenguaje de programación Java fue originalmente desarrollado por James Gosling de Sun Microsystems (la cual fue adquirida por la compañía Oracle) y publicado en 1995 como un componente fundamental de la plataforma Java de Sun Microsystems. Las aplicaciones de Java son generalmente compiladas a bytecode (clase Java) que puede ejecutarse en cualquier máquina virtual Java (JVM) sin importar la arquitectura de la computadora subyacente. Java es un lenguaje de programación de propósito general, concurrente, orientado a objetos y basado en clases que fue diseñado específicamente para tener tan pocas dependencias de implementación como fuera posible. Su intención es permitir que los desarrolladores de aplicaciones escriban el programa una vez y lo ejecuten en cualquier dispositivo, lo que quiere decir que el código que es ejecutado en una plataforma no tiene que ser recompilado para correr en otra.

59 - 162

Las características son: 

Es sencillo de utilizar.



Tiene soporte dado por Sun.



Es dinámico.



Java ha sido diseñado para aplicaciones distribuidas.



Es “Interpretado” y necesita “interprete” para ejecutar programas.



Es robusto, es decir fiable.



Es de arquitectura neutral, independiente de cualquier plataforma.



De alto rendimiento, permite que los programas se ejecuten en tiempo de ejecución.



Es multihilo, ejecuta varias tareas de forma simultánea.

Las ventajas son: 

Lenguaje orientado a objeto.



La sintaxis básica deriva del lenguaje C/C++.



Es independiente de la plataforma, tanto en código fuente como en binario.



Es Multi-plataforma (funciona en celulares, computadoras, etc.).

La desventaja: Java es un lenguaje de programación el cual no tiene muchas desventajas, sin embargo una de las mayores desventajas sobre este lenguaje es la velocidad ya que los programas hechos en Java no tienden a ser muy rápidos. 2.5.4. Servicios web de intercambio de datos con Android. Existen múltiples definiciones sobre lo que son los Servicios Web, lo que muestra su complejidad a la hora de dar una adecuada definición que englobe todo lo que son e implican. Una posible sería hablar de ellos como un conjunto de aplicaciones o de tecnologías con capacidad para interpretar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios

60 - 162

solicitan un servicio llamando a estos procedimientos a través de la Web. (Gironés, 2013) Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes aplicaciones, que interactúan entre sí para presentar información dinámica al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al mismo tiempo sea posible su combinación para realizar operaciones complejas, es necesaria una arquitectura de referencia estándar. (Revelo, 2015) Figura 18: Servicios Web.

Fuente: (Gironés, 2013) 2.5.3.1. Servicio Web RESTful Para Android Un servicio web RESTful es una aplicación que se crea a partir de los principios de REST, el cual es un conjunto de ideas para transferir recursos de una forma elegante. La sigla REST significa Representational State Transfer y traduciendo al español significaría Transferencia De Estado Representacional. (Revelo, 2015) REST utiliza formatos de url para hacerlas más amigables a la vista de quienes desean acceder a la API. Esto con el fin de que sean predecibles y claras ante la vista de un 61 - 162

humano, lo que permite navegar a través de los recursos de forma intuitiva. Este estilo se enfoca en el recurso como unidad fundamental de los servicios web y estandariza de forma amigable su transferencia entre aplicaciones. Las características son: 

Configuración para desarrollo web



Diseño e implementación de la base de datos



Creación de los modelos de datos

Las ventajas son: 

Los servicios Web RESTful son completamente sin estado, ello puede ser comprobado mediante el reinicio el servidor y comprobando si las interacciones son capaces de sobrevivir.



Rest es muy ligero, sus respuestas contienen exactamente la información que se necesita



Servicios RESTful proporcionan una buena infraestructura de almacenamiento en caché a través de HTTP método GET (para la mayoría de los servidores), esto mejorará el rendimiento, si los datos que devuelve el servicio Web no se altera con frecuencia y no son de naturaleza dinámica.



Servicios REST son fáciles de integrar con los sitios web existentes y están expuestos a XML para que las páginas HTML pueden consumir la misma con facilidad. Casi no hay necesidad de refactorizar la arquitectura de sitio web existente. Esto hace que los desarrolladores sean más productivos y cómodo, ya que no tendrán que volver a escribir todo desde cero y sólo hay que añadir la funcionalidad existente.

Las desventajas son: 

A mi parecer la seguridad es una deficiencia y puede llegar a ser una tarea muy difícil de implementarla correctamente. 62 - 162



No hay un estándar en sus respuestas por lo que no se definen tipos de datos.

a) Formato de datos para la transferencia Es muy común que un servicio web RESTful ofrezca distintos formatos para la comunicación de datos. Los más frecuentes son Json y XML, sin embargo pueden usarse distintas variedades como HTML, CSV, PDF, etc (Revelo, 2015) b) Planificación Del Servicio Web RESTful La aplicación Android que construiremos requiere que el servicio web le posibilite centralizar la base de datos en un servidor remoto y que permita realizar las 4 operaciones básicas sobre estos datos. (Revelo, 2015) También es necesario que el usuario cree primero una cuenta y luego se loguee para poder obtener una clave de acceso a la API. Sin estas condiciones el usuario no tendrá acceso a la información. (Revelo, 2015) En cuanto a la estructura del servicio, nos guiaremos en un estilo sencillo MVC para manejar las peticiones del cliente. Así que los pasos de desarrollo quedarían de la siguiente forma: 

Configuración para desarrollo web



Diseño e implementación de la base de datos



Realización de conexión Mysql con Php



Creación de los modelos de datos



Definición de las vistas



Manejo de las llamadas al servicio web RESTful (CRUD)



Realizar pruebas al servicio web

2.5.3.2.

Lenguaje de Descripción de Servicios Web (WSDL).

Los protocolos de comunicación y formatos de mensaje están estandarizados en la comunidad web, se hace cada vez más posible e importante ser capaz de describir las comunicaciones de alguna manera estructurada. WSDL aborda esta necesidad 63 - 162

definiendo una gramática XML15 para describir servicios de red como colecciones de puntos finales de comunicación capaces de intercambiar mensajes. Definiciones de servicio WSDL proporcionan documentación para sistemas distribuidos y sirven como una receta para la automatización de los detalles involucrados en las aplicaciones de comunicación. (Gironés, 2013) Un documento WSDL define los servicios como colecciones de puntos finales de red o puertos. En WSDL, la definición abstracta de puntos finales y los mensajes se separa de su despliegue de red o formato de datos de enlaces concretos. Esto permite la reutilización de definiciones abstractas: mensajes, que son descripciones abstractas de los datos que se intercambian, y los tipos de puertos que son colecciones abstractas de operaciones. El protocolo concreto y especificaciones de formato de datos para un tipo de puerto en particular constituyen una unión reutilizable. Un puerto se define mediante la asociación de una dirección de red con una unión reutilizable, y una colección de puertos define un servicio. Por lo tanto, un documento WSDL utiliza los siguientes elementos en la definición de servicios de red: (Gironés, 2013) 

Tipos: un contenedor para definiciones de tipos de datos utilizando algún tipo de sistema (como XSD28).



Mensaje: definición abstracta escrito de que los datos sean comunicados.



Operación: una descripción abstracta de una acción admitida por el servicio.



Tipo de puerto: un conjunto abstracto de operaciones soportadas por uno o más puntos finales.



Encuadernación: un protocolo concreto y especificación de formato de datos para un tipo de puerto en particular.



Puerto: un único punto final se define como una combinación de un enlace y una dirección de red.



Servicio: un conjunto de criterios de valoración relacionados.

15

XML, eXtensible Markup Language ('lenguaje de marcasextensible'), es un lenguaje de marcas desarrollado por el World Wide Web Consortium (W3C) utilizado para almacenar datos en forma legible.

64 - 162

Es importante observar que WSDL no introduce un lenguaje de definición de nuevo tipo. WSDL reconoce la necesidad de sistemas de tipo rico para describir formatos de mensaje, y es compatible con la especificación de esquemas XML (XSD), como su sistema de tipo canónico. Sin embargo, ya que es razonable esperar que una gramática sistema de tipo único que se utiliza para describir todos los formatos de los mensajes presentes y futuros, WSDL permite el uso de lenguajes de definición de otro tipo a través de la extensibilidad. (Gironés, 2013) Además, WSDL define un mecanismo de unión común. Esto se utiliza para conectar un formato o estructura de datos de protocolo específico a un resumen del mensaje, el funcionamiento, o de punto final. Se permite la reutilización de definiciones abstractas. (Gironés, 2013) Además del marco de definición de servicio básico, esta especificación incluye las extensiones de unión específicos para los siguientes protocolos y formatos de mensaje: 

SOAP.



HTTP GET / POST.



MIME16

Las características son: 

Permite especificar en XML las operaciones y tipos de datos de un servicio web



Estandarizado por el W3C



Analogía con CORBA: WSDL/IDL

Las ventajas son: 

Describe un servicio Web a partir de los mensajes que acepta y las operaciones que se pueden ejecutar sobre ellos.

16

MIME, Multipurpose Internet Mail Extensions o MIME (en español "extensiones multipropósito de correo de internet") son una serie de convenciones o especificaciones dirigidas al intercambio a través de Internet de todo tipo de archivos (texto, audio, vídeo, etc.)

65 - 162



WSDL es extensible y se pude utilizar para describir, prácticamente, cualquier servicio de red, incluyendo SOAP sobre HTTP



Tener perfectamente definida la interfaz del servicio web ⇒ nombre de la función, parámetros y orden.

Las desventajas son: 

No hay manera de ver si el proveedor del servicio ha realizado cambios en la interfaz de entrada ⇒ enviar mensajes a los clientes avisando de dichos cambios.



Define completamente la semántica de los servicios web.

2.5.3.2. REST API REST (Transferencia de estado representacional) es un estilo arquitectónico, y una aproximación a las comunicaciones que se utilizan a menudo en el desarrollo de servicios Web. El uso de REST frecuencia, se prefiere el más pesado de SOAP de estilo (Simple Object Access Protocol) porque el descanso no aprovecha todo el ancho de banda, lo que hace que sea un mejor ajuste para su uso a través de Internet. El enfoque de SOAP requiere escribir o usando un programa de servidor proporcionado (para servir de datos) y un programa de cliente (para solicitar datos). Figura 19: REST API

Fuente: (Gironés, 2013)

66 - 162

REST desacopla la arquitectura, y las comunicaciones de menor peso entre productor y consumidor, hacer descansar un estilo de construcción popular para los basados en la nube API, tales como los proporcionados por Amazon, Microsoft y Google. Cuando los servicios Web utilizan la arquitectura REST, se les llama API REST (Application Programming Interfaces) o APIs REST. Arquitectura REST implica la lectura de una página Web designada que contiene unXML archivo. El archivo XML describe e incluye el contenido deseado. Una vez definido de forma dinámica, los consumidores pueden acceder a la interfaz. REST, que normalmente se ejecuta a través de HTTP (Hypertext Transfer Protocol), tiene varias limitaciones arquitectónicas: 

Desacopla los consumidores a los productores



Sin Estado existencia



Capaz de aprovechar una caché



aprovecha un sistema de capas



aprovecha una interfaz uniforme

Rest se utiliza a menudo en aplicaciones móviles, redes sociales sitios web, mashupherramientas y procesos de negocio automatizados. El estilo Rest hace hincapié en que las interacciones entre clientes y servicios se ve reforzada por tener un número limitado de operaciones (verbos). La flexibilidad se proporciona mediante la asignación de recursos (sustantivos) sus propias únicas Identificadores Universales de Recursos (URI). Debido a que cada verbo tiene un significado específico (GET, POST, PUT y DELETE), REST evita la ambigüedad.. (Naresh & Toral, 2002) Las características que tiene: 

Es independiente, se puede tener un servidor que trabaja con PHP, Java, Python, NodeJS o lo que se prefiera, o te imponga el proyecto.



El servidor y el cliente web se comunican en un formato de intercambio de información como puede ser JSON, aunque podría ser otro lenguaje como XML.

67 - 162

Las ventajas que presenta son: 

Separación cliente/servidor



Independencia de tecnologías / lenguajes



Fiabilidad, escalabilidad, flexibilidad



Experiencia de usuario

Las desventajas que tiene son: 

API REST no mantiene estado y eso hace que se tenga que montar una infraestructura propia para poder conservar el conjunto de la aplicación.



Puede producirse en determinadas circunstancias mayor rigidez en el desarrollo

2.5.5. JavaScript JavaScript (abreviado comúnmente JS) es un lenguaje de programación interpretado, dialecto del estándarECMAScript. Se define como orientado a objetos, basado en prototipos, imperativo, débilmente tipado y dinámico. Se utiliza principalmente en su forma del lado del cliente (client-side), implementado como parte de unnavegador web permitiendo mejoras en la interfaz de usuario y páginas web dinámicas aunque existe una forma de JavaScript del lado del servidor (Server-side JavaScript o SSJS). Su uso en aplicaciones externas a la web, por ejemplo en documentos PDF, aplicaciones de escritorio (mayoritariamente widgets) es también significativo. JavaScript se diseñó con una sintaxis similar a C, aunque adopta nombres y convenciones del lenguaje de programación Java. Sin embargo, Java y JavaScript tienen semánticas y propósitos diferentes. Todos los navegadores modernos interpretan el código JavaScript integrado en las páginas web. Para interactuar con una página web se provee al lenguaje JavaScript de una implementación del Document Object Model (DOM).

68 - 162

Tradicionalmente se venía utilizando en páginas web HTML para realizar operaciones y únicamente en el marco de la aplicación cliente, sin acceso a funciones del servidor. Actualmente es ampliamente utilizado para enviar y recibir información del servidor junto con ayuda de otras tecnologías como AJAX. JavaScript se interpreta en el agente de usuario al mismo tiempo que las sentencias van descargándose junto con el código HTML. (Shafer, 2003) La característica que presenta: 

La característica principal de Javascript, de hecho, es la de ser un lenguaje de scripting, pero, sobre todo, la de ser el lenguaje de scripting por excelencia y, sin lugar a dudas, el más usado.

Las ventajas son: 

JavaScript es una excelente solución para poner en práctica la validación de datos de un formulario en el lado del cliente. Si un usuario omite escribir su nombre en un formulario, una función de validación en JavaScript puede desplegar en pantalla un mensaje popup para hacerle saber al usuario acerca de la omisión. Este tipo de funcionalidades son más ventajosas que tener una rutina de validación del lado del servidor para controlar el error, dado que el servidor en éste caso no tiene que hacer ningún tipo procesamiento de información adicional. Una rutina de ASP o PHP podría ser escrita para lograr la misma tarea pero un formulario desarrollado en JavaScript no permitiría que la información se enviase a menos que se complete correctamente el formulario.



Una de las áreas en la que sobresale radicalmente JavaScript es en la creación de efectos dinámicos tales como imágenes dinámicas y presentaciones de diapositivas, donde su uso se ha convertido algo común hoy en día. Debido a que JavaScript se ejecuta dentro del navegador de los clientes, se puede utilizar para cambiar el aspecto de la pantalla en el dispositivo de los usuarios después que la página ha sido enviada por el servidor. Esto le permite al desarrollador web crear efectos dinámicos muy impresionantes mejorando así la experiencia que recibe un usuario momento de entrar a un sitio web. 69 - 162

La desventaja es: 

La seguridad sigue siendo el talon de aquiles de Javascript. Los fragmentos de código de JavaScript una vez añadidos a las páginas web en los servidores, estos son descargados y ejecutados en el navegador del cliente permitiendo así que cierto código malicioso pueda ser ejecutado en la máquina del cliente con el objetivo de explotar alguna vulnerabilidad de seguridad conocida en una de las aplicaciones, navegadores o el mismo sistema operativo. Es verdad que hoy día existen estándares de seguridad que restringen la ejecución de código por parte de los navegadores, pero aún así, se puede ejecutar código que dañe, robe o destruya información del lado del cliente.

2.5.6. HTML El lenguaje HTML basa su filosofía de desarrollo en la diferenciación. Para añadir un elemento externo a la página (imagen, vídeo, script, entre otros.), este no se incrusta directamente en el código de la página, sino que se hace una referencia a la ubicación de dicho elemento mediante texto. De este modo, la página web contiene solamente texto mientras que recae en el navegador web (interpretador del código) la tarea de unir todos los elementos y visualizar la página final. Al ser un estándar, HTML busca ser un lenguaje que permita que cualquier página web escrita en una determinada versión, pueda ser interpretada de la misma forma (estándar) por cualquier navegador web actualizado. HTML, sigla en inglés de HyperText Markup Language (lenguaje de marcas de hipertexto), hace referencia al lenguaje de marcado para la elaboración de páginas web. Es un estándar que sirve de referencia del software que conecta con la elaboración de páginas web en sus diferentes versiones, define una estructura básica y un código (denominado código HTML) para la definición de contenido de una página web, como texto, imágenes, videos, juegos, entre otros. Es un estándar a cargo del World Wide Web Consortium (W3C) o Consorcio WWW, organización dedicada a la estandarización de casi todas las tecnologías ligadas a la web, sobre todo en lo referente a su escritura e interpretación. Se considera el lenguaje web más importante 70 - 162

siendo su invención crucial en la aparición, desarrollo y expansión de la World Wide Web (WWW). Es el estándar que se ha impuesto en la visualización de páginas web y es el que todos los navegadores actuales han adoptado. Las características son: 

HTML es un lenguaje de etiquetas (también llamado lenguaje de marcado) y las páginas web habituales están formadas por cientos o miles de pares de etiquetas



Puede ser creado y editado con cualquier editor de textos básico.



Cada elemento de un documento HTML consta de una etiqueta de comienzo, un bloque de texto y una etiqueta de fin.

Las ventajas que ofrece son: 

Fácil de usar



Permite la comunicación rápida y directa con una o varias personas que se encuentren en cualquier parte del mundo.



Desarrollo de diferentes proyectos y propuestas para darlos a conocer a través de la red.



Se puede contactar con diferentes personas para realizar negocios, trabajos, proyectos, etc.

Las desventajas son: 

Es muy básico



No ofrece diversidad de opciones



No es muy completo

2.5.6. CSS CSS es un lenguaje de hojas de estilos creado para controlar el aspecto o presentación de los documentos electrónicos definidos con HTML y XHTML. CSS es la mejor forma de separar los contenidos y su presentación y es imprescindible para crear páginas web complejas. 71 - 162

Separar la definición de los contenidos y la definición de su aspecto presenta numerosas ventajas, ya que obliga a crear documentos HTML/XHTML bien definidos y con significado completo (también llamados "documentos semánticos"). Además, mejora la accesibilidad del documento, reduce la complejidad de su mantenimiento y permite visualizar el mismo documento en infinidad de dispositivos diferentes. Al crear una página web, se utiliza en primer lugar el lenguaje HTML/XHTML para marcar los contenidos, es decir, para designar la función de cada elemento dentro de la página: párrafo, titular, texto destacado, tabla, lista de elementos, etc. Una vez creados los contenidos, se utiliza el lenguaje CSS para definir el aspecto de cada elemento: color, tamaño y tipo de letra del texto, separación horizontal y vertical entre elementos, posición de cada elemento dentro de la página, etc. Las características que tiene: 

Lograr una apariencia uniforme de todo el sitio al activar una sola definición de estilo en cada página,



Cambiar un aspecto en todo el sitio web con tan sólo editar unas pocas líneas,



Hacer que los códigos html sean más fáciles de leer ya que los estilos se definen por separado,



Permitir que las páginas se carguen más rápido ya que hay menos cantidad de html en cada página,



Posicionar los elementos de la página de una manera más uniforme.

Las ventajas son: 

Control centralizado de la presentación de un sitio web completo con lo que se agiliza de forma considerable la actualización del mismo.



Optimización del ancho de banda de la conexión, pues pueden definirse los mismos estilos para muchos elementos con un sólo selector; o porque un mismo archivo CSS puede servir para una multitud de documentos.

72 - 162

Las desventajas son: 

Si hay problemas o limitaciones de compatibilidades, el navegador aplicará el formato predeterminado y nuestro trabajo de composición habrá sido inútil.



Algunas propiedades de las CSS pueden provocar que una parte del contenido de nuestra página resulte inaccesible desde algunos navegadores.

2.5.7. Intercambio de datos JSON. JSON (JavaScript Object Notation - Notación de Objetos de JavaScript) es un formato ligero de intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras que para las máquinas es simple interpretarlo y generarlo. Está basado en un subconjunto del Lenguaje de Programación JavaScript, Standard ECMA-262 3rd Edition - Diciembre 1999. JSON es un formato de texto que es completamente independiente del lenguaje pero utiliza convenciones que son ampliamente conocidos por los programadores de la familia de lenguajes C, incluyendo C, C++, C#, Java, JavaScript, Perl, Python, y muchos otros. Estas propiedades hacen que JSON sea un lenguaje ideal para el intercambio de datos. Con la creciente popularidad de los servicios Web, XML se ha convertido prácticamente de facto en el estándar para transmisión de datos. Pero se necesita transmitir a través de Internet muchos más bytes de información para realizar una tarea que se podría llevar a cabo con un flujo de información mucho más pequeño. (Sacristán & Fernández, 2012) Así se han desarrollado nuevas formas de compresión XML e, incluso, nuevos formatos XML completos, tales como Binary XML (XML binario). Todas estas soluciones funcionan ampliando o añadiéndose a XML, conviniendo los aspectos de compatibilidad descendente en un asunto a tener en cuenta. Douglas Crockford, un experimentado ingeniero software, propuso un nuevo formato de datos construido sobre JavaScript llamado JSON, JavaScript Object Notation (notación de objetos JavaScript). (Sacristán & Fernández, 2012) La característica que tiene: 73 - 162



JSON es un formato de datos muy ligero basado en un subconjunto de la sintaxis de JavaScript: literales de matrices y objetos. Como usa la sintaxis JavaScript, las definiciones JSON pueden incluirse dentro de archivos JavaScript y acceder a ellas sin ningún análisis adicional como los necesarios con lenguajes basados en XML.

Las ventajas que presenta: 

Formato sumamente simple



Velocidad de procesamiento alta



Archivos de menor tamaño

La desventaja que tiene: 

Tiene una estructura enredosa y difícil de interpretar a simple vista

2.5.8. Gestores de Bases de datos A continuación se describen los gestores de base de datos: 2.5.8.1. My Structured Query Language (MySQL). MySQL es un sistema de administración de bases de datos. Dado que los computadores son muy buenos manejando grandes cantidades de información, los administradores de bases de datos juegan un papel central en computación, como aplicaciones independientes o como parte de otras aplicaciones. (Gutiérrez, 2010) Permite escoger entre múltiples motores de almacenamiento para cada tabla. En MySQL 5.0 éstos debían añadirse en tiempo de compilación, a partir de MySQL 5.1 se pueden añadir dinámicamente en tiempo de ejecución. Agrupación de transacciones, reuniendo múltiples transacciones de varias conexiones para incrementar el número de transacciones por segundo. (Gutiérrez, 2010) El tipo de compilación es binario por lo que ha sido compilado con información de depuración extra. No debe ser usada en sistemas en producción porque el código de 74 - 162

depuración puede reducir el rendimiento. MySQL está escrito en una mezcla de C y C++. (Piattini, 1993) (Gutiérrez, 2010) La característica es: 

Aprovecha la potencia de sistemas multiprocesador, gracias a su implementación multihilo.



Soporta gran cantidad de tipos de datos para las columnas.



Dispone de API's en gran cantidad de lenguajes (C, C++, Java, PHP, etc).



Gran portabilidad entre sistemas.



Soporta hasta 32 índices por tabla.



Gestión de usuarios y passwords, manteniendo un muy buen nivel de seguridad en los datos.

Las ventajas son: 

Velocidad al realizar las operaciones, lo que le hace uno de los gestores con mejor rendimiento.



Bajo costo en requerimientos para la elaboración de bases de datos, ya que debido a su bajo consumo puede ser ejecutado en una máquina con escasos recursos sin ningún problema.



Facilidad de configuración e instalación.



Soporta gran variedad de Sistemas Operativos



Su conectividad, velocidad, y seguridad hacen de MySQL Server altamente apropiado para acceder bases de datos en Internet

Las desventajas que presenta son: 

Un gran porcentaje de las utilidades de MySQL no están documentadas.



No es intuitivo, como otros programas.

75 - 162

2.5.8.2. Microsoft Structured Query Language Server (SQL server). Microsoft SQL Server es un sistema para la gestión de bases de datos producido por Microsoft basado en el modelo relacional. Los lenguajes para consultas de Microsoft SQL Server son T-SQL y ANSI SQL. Microsoft SQL Server constituye la alternativa de Microsoft a otros potentes sistemas gestores de bases de datos como son Oracle o PostgreSQL o MySQL. (Petkovic, 2008) SQL Server permite trabajar en modo cliente-servidor, donde la información y datos se alojan en el servidor y los terminales o clientes de la red sólo acceden a la información. Además permite administrar información de otros servidores de datos. 89 de 223 (Morales, 2010) En el manejo de SQL mediante líneas de comando se utiliza el SQLCMD. Para el desarrollo de aplicaciones más complejas (tres o más capas), Microsoft SQL Server incluye interfaces de acceso para varias plataformas de desarrollo, entre ellas .NET, pero el servidor sólo está disponible para Sistemas Operativos (Morales, 2010) Este sistema incluye una versión reducida, llamada MSDE con el mismo motor de base de datos pero orientado a proyectos más pequeños, que en sus versiones 2005 y 2008 pasa a ser el SQL Express Edition, que se distribuye en forma gratuita. (Petkovic, 2008) Las características son: 

Compatibilidad con la mayoría de las tareas administrativas de SQL Server.



Un entorno único integrado para la administración del Motor de base de datos de SQL Server y la creación.



Cuadros de diálogo para administrar objetos de Motor de base de datos de SQL Server, Analysis Services y Reporting Services, lo que permite ejecutar las acciones inmediatamente, enviarlas a un editor de código o escribirlas en script para ejecutarlas posteriormente.



Cuadros de diálogo no modales y de tamaño variable que permiten obtener acceso a varias herramientas mientras un cuadro de diálogo está abierto.

76 - 162



Un cuadro de diálogo común de programación que permite realizar acciones de los cuadros de diálogo de administración en otro momento.

Las ventajas que presenta son: 

Es un sistema de gestión de base de datos.



Es útil para manejar y obtener datos de la red de redes.



Nos permite olvidarnos de los ficheros que forman la base de datos.

Las desventajas son: 

Utiliza mucho la memoria RAM para las instalaciones y utilización de software.



No se puede utilizar como practicas porque se prohíben muchas cosas, tiene restricciones en lo particular.



La relación, calidad y el precio esta muy debajo comparado con Oracle.



Tiene muchos bloqueos a nivel de página, un tamaño de página fijo y demasiado pequeño, una pésima implementación de los tipos de datos variables.

2.5.6.3.

SQLite Sistema de Gestión de Base de Datos

SQLite es software libre, es posible encontrar una gran cantidad de componentes, librerías y drivers para interactuar con SQLite desde una gran diversidad de lenguajes y plataformas de programación. Ya sea que estemos utilizando lenguajes modernos como Java, Perl, Python, PHP, Ruby, C#, lenguajes más antiguos como Pascal, SmallTalk, Clipper, o lenguajes poco conocidos como Suneido, REXX, S-Lang, para todos podemos encontrar librerías y ejemplos de código para SQLite. (Rómmel, 2007) Las características son: (Rómmel, 2007) 

La base de datos completa se encuentra en un solo archivo.



Puede funcionar enteramente en memoria, lo que la hace muy rápida.



Tiene un footprint menor a 230KB.



Es totalmente auto contenida (sin dependencias externas).



Cuenta con librerías de acceso para muchos lenguajes de programación.



Soporta texto en formato UTF-8 y UTF-16, así como datos numéricos de 64 bits. 77 - 162



Soporta funciones SQL definidas por el usuario (UDF).



El código fuente es de dominio público y se encuentra muy bien documentado.

Las ventajas son: 

No requiere configuración.



No se requiere uso de servidor (proceso activo para atender las peticiones).



Fácilmente portable (multiplataforma windows, linux, mac, dispositivos móviles, tablet´s, etc.).



En su versión 3, SQLite permite bases de datos de hasta 2 Terabytes de tamaño, y también permite la inclusión de campos tipo BLOB.



Acceso mucho más rápido.



Prácticamente cualquier lenguaje y SO lo soportan.



Registros de Longitud Variable

Las desventajas son: 

Limitaciones en Where: esta limitación está dada por el soporte para clausuras anidadas.



Falta de Clave Foránea: se hace caso omiso de las claves foráneas; esto quiere decir, cuando se realice la creación de la tabla desde el modo consola, está permitiendo el uso de la clausura, aunque no realizara el chequeo de la misma.



Falta de documentación en español: si bien ya contamos con una comunidad latino

americana

de

SQLite,

sería

importante

encontrar

mucha

más

documentación, libros, review, etc. como muchos otros motores de bases de datos cuentan hoy en día.

Una Base de Datos SQLite es un único archivo de disco ordinario y que además puede estar situado en cualquier parte del directorio dentro de las jerarquías de directorios. Esto trae como ventaja que el archivo de Base de Datos puede ser fácilmente copiado en algún dispositivo de memoria por ejemplo en USB o por correo electrónico. (Rómmel, 2007) 78 - 162

2.5.9 Herramientas de gestión Se entiende que las herramientas de gestión son todos los sistemas, aplicaciones, controles, soluciones de cálculo, metodología, etc., que ayudan a la gestión de una empresa. 2.5.9.1. Google App Engine Google App Engine es un servicio de alojamiento web que presta Google de forma gratuita hasta determinadas cuotas. Este servicio permite ejecutar aplicaciones sobre la infraestructura de Google. Si no se cuenta con un dominio propio, Google proporciona uno con la siguiente estructura, midominio.appspot.com. También permite implementar un dominio propio a través de Google Apps. Por el momento las cuentas gratuitas tienen un límite de 500 megabyte de almacenamiento permanente y la suficiente cantidad de ancho de banda y CPU para cinco millones de visitas mensuales, y si la aplicación supera estas cuotas, se pueden comprar cuotas adicionales. Actualmente las aplicaciones Google App Engine se implementan mediante los lenguajes de programación Python, Java, Go y PHP. Las características son: 

Almacén de datos

App engine proporciona un potente servicio de almacenamiento de datos distribuido que además incluye un motor de búsqueda y de transacciones. A medida que vuestra app aumenta con el tráfico, el almacén de datos crece. El almacén de datos es de consistencia fuerte y utiliza el control de concurrencia optimista. Por encima de todo se garantiza la integridad de tus datos. 

Google accounts

Evidentemente app engine admite la integración de las aplicaciones con google accounts para la autenticación de usuarios. Acceder a tus aplicaciones con las cuentas

79 - 162

de google accounts es una avance ya que permite a los usuarios acceder a las aplicaciones de una forma más rápida. También mirando el desarrollo, evitar el desarrollo e implementación de un sistema de cuentas de usuario, es un ahorro importante en tiempo (y en dinero). 

Servicios

Otro de los puntos a destacar son algunas características que app engine proporciona y que nos facilitan el trabajo al administrar nuestra aplicación: -

Extracción de url: recupera recursos web mediante la misma infraestructura de alta velocidad de google.

-

Correo: la app puede enviar correos electrónicos a los usuarios por medio de las herramientas de google.

-

Memcache: app engine proporciona una memoria caché de valores-claves de alto rendimiento accesible desde varias instancias de tu aplicación. Resulta útil para datos que no necesitan las funciones de persistencia y transacciones del almacén de datos. Velocidad.

-

Manipular imágenes: recortar, girar o ajustar imágenes desde tu aplicación de una forma sencilla.



Cron

Además de las lógicas solicitudes web, tu aplicación puede realizar tareas programadas según el desarrollador configure (cada día, cada hora..). Las tareas programadas se conocen como ‘tareas cron’ ya que el servicio ‘cron’ es el que las gestiona. Existe una documentación muy útil sobre la utilización de dicho servicio para python y para java. Las colas de tareas aún están incluidas de forma experimental, sólo están disponibles para en lenguaje python, pero google app engine evoluciona rápido y pronto estará disponible para java y para php posteriormente. 

Desarrollo local

80 - 162

Google app engine permite que generes en local un entorno idéntico al de google app engine en la nube. Es decir, podrás realizar tu app y probarla con la máxima seguridad que una vez la subas, todas las ‘features’ de tu app funcionarán a la perfección. 

Control

Puedes registrar 10 apps por cuenta de desarrollador. Si estás pensando en destruir las cuotas o hacer un mal uso de ellas creando apps en varias cuentas que trabajen conjuntamente, google ya lo ha pensado antes que tú. Si google encuentra algún tipo de infracción puede inhabilitar tu cuenta o cerrarla definitivamente. 

Python

Google app engine también permite aplicaciones desarrolladas en python. Además incluye varias api y herramientas para el desarrollo, así como una api de modelado de datos detallado, un marco de aplicaciones web fácil de utilizar. 

Zona de pruebas

La zona de pruebas aísla la aplicación en su propio entorno seguro de confianza, totalmente independiente del hardware, del sistema operativo y de la ubicación física del servidor web. Tu aplicación solo podrá acceder a otros equipos de internet a través de los servicios de correo y extracción de url proporcionados por app engine. El resto de equipos solo podrán conectarse a vuestra app por medio de los protocolos http y https.

Las ventajas son: 

Espacio de almacenamiento 50 veces superior a la media del sector



Cumplimiento de las normativas y seguridad de la información



Ahorros en costos probados



Control total administrativo y de los datos

Las desventajas que presenta: 81 - 162



Google App Engine funciona únicamente para aplicaciones interactivas, del tipo “petición web”-“respuesta”, proceso que debe ser completado en pocos segundos.



Los accesos a otros sitios web se realizan a través de un API específico de Google, que impide que se puedan modificar determinadas cabeceras HTTP

2.5.9.2. Cloud computing La computación en la nube, conocida también como servicios en la nube, informática en la nube, nube de cómputo o nube de conceptos (del inglés cloud computing), es un paradigma que permite ofrecer servicios de computación a través de una red, que usualmente es Internet. La computación en nube presenta las siguientes características clave: 

Agilidad: Capacidad de mejora para ofrecer recursos tecnológicos al usuario por parte del proveedor.



Costo: los proveedores de computación en la nube afirman que los costos se reducen. Un modelo de prestación pública en la nube convierte los gastos de capital en gastos de funcionamiento. Ello reduce barreras de entrada, ya que la infraestructura se proporciona típicamente por una tercera parte y no tiene que ser adquirida por una sola vez o tareas informáticas intensivas infrecuentes.



Escalabilidad y elasticidad: aprovisionamiento de recursos sobre una base de autoservicio en casi en tiempo real, sin que los usuarios necesiten cargas de alta duración.



Independencia entre el dispositivo y la ubicación: permite a los usuarios acceder a los sistemas utilizando un navegador web, independientemente de su ubicación o del dispositivo que utilice (por ejemplo, PC, teléfono móvil).



La tecnología de virtualización permite compartir servidores y dispositivos de almacenamiento y una mayor utilización. Las aplicaciones pueden ser fácilmente migradas de un servidor físico a otro.



Rendimiento: Los sistemas en la nube controlan y optimizan el uso de los recursos de manera automática, dicha característica permite un seguimiento, control y notificación del mismo. Esta capacidad aporta transparencia tanto para el 82 - 162

consumidor o el proveedor de servicio. 

Seguridad: puede mejorar debido a la centralización de los datos. La seguridad es a menudo tan bueno o mejor que otros sistemas tradicionales, en parte porque los proveedores son capaces de dedicar recursos a la solución de los problemas de seguridad que muchos clientes no pueden permitirse el lujo de abordar. El usuario de la nube es responsable de la seguridad a nivel de aplicación. El proveedor de la nube es responsable de la seguridad física.5



Mantenimiento: en el caso de las aplicaciones de computación en la nube, es más sencillo, ya que no necesitan ser instalados en el ordenador de cada usuario y se puede acceder desde diferentes lugares.

Las ventajas son: 

Integración probada de servicios Red. Por su naturaleza, la tecnología de cloud computing se puede integrar con mucha mayor facilidad y rapidez con el resto de las aplicaciones empresariales (tanto software tradicional como Cloud Computing basado en infraestructuras), ya sean desarrolladas de manera interna o externa.



Prestación de servicios a nivel mundial. Las infraestructuras de cloud computing proporcionan mayor capacidad de adaptación, recuperación completa de pérdida de datos (con copias de seguridad) y reducción al mínimo de los tiempos de inactividad



Actualizaciones automáticas que no afectan negativamente a los recursos de TI. Al actualizar a la última versión de las aplicaciones, el usuario se ve obligado a dedicar tiempo y recursos para volver a personalizar e integrar la aplicación. Con el cloud computing no hay que decidir entre actualizar y conservar el trabajo, dado que esas personalizaciones e integraciones se conservan automáticamente durante la actualización.

Las desventajas del cloud computing son: 

La disponibilidad de las aplicaciones está sujeta a la disponibilidad de acceso a Internet.



La centralización de las aplicaciones y el almacenamiento de los datos origina una 83 - 162

interdependencia de los proveedores de servicios.

84 - 162

ESCUELA MILITAR DE INGENIERÍA MCAL. ANTONIO JOSÉ DE SUCRE BOLIVIA

CAPÍTULO 3 MARCO PRÁCTICO.

3. MARCO PRÁCTICO. El capítulo corresponde a la elaboración e implementación del sistema de gestión de abastecimiento de productos y servicios de catering integrado con una aplicación móvil Android partiendo de la situación actual de la empresa de servicios de catering “VALENCIA” (caso de estudio), se elaborará la herramienta de apoyo que permita mejorar dichos procesos.

3.1. DISEÑO DEL MODELADO DE NEGOCIO ACTUAL PARA EL ABASTECIMIENTO DE PRODUCTOS. Para el desarrollo del sistema, se realizará el modelado del negocio actual, mediante el cual se va describir detalladamente el estado de los procedimientos y actividades actuales para el proceso de abastecimiento de productos, en el cual se visualizará la secuencia de acciones y de personas involucradas. Posteriormente se propondrá un modelado de negocio alternativo, en el cual se pretende mejorar el proceso que se lleva a cabo, mediante la automatización de varios de los procesos mencionados. 3.1.1 Análisis del modelado del negocio Para planificar el desarrollo del presente proyecto en la elaboración de un sistema de gestión de abastecimiento de productos y servicios de catering inicialmente es necesario obtener la información necesaria que describa el proceso y las actividades que actualmente se realizan para el proceso de gestión de abastecimiento de productos y Servicios de Catering. Establecer los casos de negocio que tienen que interactuar con el sistema, evaluar y planificar la estructura futura que se va plantear para poder resolver los problemas actuales que tiene la empresa. 3.1.2 Diseñar el negocio del modelo actual. Se representa la información recolectada por medio de las entrevistas realizadas al personal de la Empresa VALENCIA (Ver Anexo C), en base a la elaboración de un diagrama de flujo que muestra el trabajo actual de la empresa, donde se pretende representar detalladamente los procedimientos y actividades tal como se realizan 77 - 162

actualmente en el proceso de gestión de abastecimiento de productos y Servicios de Catering. Figura 20: Diagrama de Modelado de Negocio Actual Modelado del negocio actual ENCARGADO DE COMPRAS

DUEÑO DE LA EMPRESA

CHEF

INICIO

Realiza el menú del día con el encargado de la empre

Recibe lista de ingredientes Confirma contrato de la empresa que requiere el servicio de catering

Se comunica con el dueño de la empresa para entregarle el pedido de productos e ingredientes

Se dirige al mercado Firma contrato para un determinado tiempo Realiza compras

Se comunica con el chef mediante llamada o sms

Se dirige al almacen del dueño

Manda al chef a la empresa para que registre el pedido de productos

Espera a que se le entregue el pedido

No

Entrega los ingredientes solicitados

Recibe lista de pedido Si

No

Revisa si hay algunos ingredientes en almacén de la lista

Realiza nuevamente la lista de ingredientes

Si

Elimina de la lista de pedido

Se comunica con el encargado de compras mediante llamada o sms

Recoge los ingredientes

Entrega lista de ingredientes que debe comprar

Se dirige a la empresa que se le asignó

Recibe los ingredientes

Prepara los alimentos

Almacena todos los ingredientes en el almacén

Despacha los productos en envases a los comensales

Entrega ingredientes bajo lista al chef

FIN

Fuente: Elaboración propia 78 - 162

3.1.3. Identificar las deficiencias del proceso actual. Las principales deficiencias que se presenta son: 

No cuenta con un registro de control automatizado de productos que la empresa ofrece.



Maneja cantidades de material de escritorio para los pedidos de ingredientes que hace el chef.



Los reportes de pedidos que solicita el chef, ingredientes que solicita el dueño y compras que realiza el encargado de compras se almacenan en archivos.



Se emplea tiempos descoordinados para la comunicación de los involucrados.



La comunicación de los involucrados se las realiza mediante mensajes o llamadas.



El dueño no lleva un control claro de los reportes de compras realizadas.



No se tiene un registro eficiente de los ingredientes que existe en almacén.



El registro de menú se realiza cada día y conlleva a una perdida de tiempo.

3.2. DISEÑAR EL MODELO DE NEGOCIO PROPUESTO PARA EL ABASTECIMIENTO DE PRODUCTOS Mediante la recolección de información por medio de entrevistas, se ha analizado y se ha modelado la situación actual para el proceso de abastecimiento de productos. 3.2.1. Elaboración del modelado del negocio alternativo basado en el sistema propuesto. Considerando las posibilidades que puede brindar el uso de Tecnologías de Información, se ha elaborado una propuesta cómo solución descrita en la Figura 18 del nuevo conjunto de procedimientos basados en el uso del sistema a desarrollarse en el presente proyecto donde se reduce tiempo y mejor organización.

79 - 162

Figura 21: Diagrama de Modelado de Negocio Alternativo del proceso de gestión de abastecimiento de productos y servicios de catering. Modelado del negocio alternativo DUEÑO DE LA EMPRESA

CHEF

INICIO

Ingresa a la aplicación

Ingresa a la aplicación

Registra sus datos y tipo de usuario

Registra sus datos y tipo de usuario

Ingresa a la aplicación con usuario y contraseña

Ingresa a la aplicación con usuario y contraseña

Servicio Web en la nube

ENCARGADO DE COMPRAS

Se almacena los datos en la base de datos del Google Cloud Storage

Ingresa a la aplicación

Registra sus datos y tipo de usuario Reportes

Registra pedidos de productos por fechas

Administra porducto

Control de personal

Envía pedido

Registra producto precio e ingredientes

Asigna encargado de compras y empresa al chef

Ingresa a la aplicación con usuario y contraseña

FIn

Recibe lista de ingredientes que deberán ser comprados

Control de stock Registra compras realizadas

Registra todos los ingredientes de almacén

Envía registro

Guarda los formularios

Fuente: Elaboración propia 3.2.2. Selección de la metodología de desarrollo de software. Para seleccionar la metodología para el desarrollo del sistema propuesto se debe realizar un análisis de las metodologías de desarrollo de software planteadas anteriormente. Las metodologías de desarrollo de software es un marco de trabajo para estructurar, planificar y controlar el proceso de desarrollo de sistemas de información, presenta ventajas y desventajas que se han extraído de la bibliografía indicada en el marco teórico. A continuación se muestra una tabla de comparación de las metodologías ágiles propuestas para el desarrollo del sistema.

80 - 162

Tabla 3: Descripción de las Ventajas y Desventajas de los Modelos de Desarrollo de Software.

MODELO

XP

VENTAJAS



Programación organizada



Menor taza de errores



Satisfacción del

DESVENTAJAS



Es recomendable emplearlo solo en proyectos a corto plazo.



Altas comisiones en caso de fallar.



Ésta metodología necesita

programador.  Proceso ágil para obtener un

información rápida y puntual de los

sistema informático. ICONIX

requisitos, del diseño y de las

 Dedicada a la construcción de sistemas de gestión de

estimaciones. 

pequeña y mediana

Es una metodología que no debe ser usada en proyectos de larga

complejidad con la

duración.

participación de los usuarios finales. 



Simplicidad. Todo se describe concisamente

en relación al RUP.

usando unas páginas, no El proceso



unificado ágil (PUA)



El AUP es un producto muy pesado



Como es un proceso simplificado,

miles de páginas.

muchos

Agilidad. El AUP se ajusta a

trabajar con el RUP, por tener a

los valores y principios de la

disposición mas detalles en el

Alianza Ágil.

proceso.

Centrarse en las actividades importantes.



Querer adaptar este producto para satisfacer sus propias necesidades.

Fuente: Elaboración propia 81 - 162

desarrolladores

eligen

Realizando la comparación de las distintas metodologías de desarrollo que se proponen se tomó la decisión de aplicar en el desarrollo del presente proyecto la metodología de desarrollo ágil ICONIX debido que es un proceso simple, abierto y ágil que está dirigido a grupos de trabajo pequeños y trabajos de corta duración. De igual manera por que utiliza como base fundamental los diagramas de modelado de UML y su orientación a objetos, y finalmente por el enfoque iterativo e incremental que lleva a cabo en cada fase del proceso de desarrollo del software. Se descartará la metodología de XP y AUP ya que presenta demora al momento de desarrollar las fases que no favorecerán para el desarrollo de éste proyecto pero se tomará como base el proceso de manifestó ágil por los valores y principios que ayudan a desarrollar la metodología de software. 3.2.3. Planificar el proyecto según el flujo de trabajo de modelo de software seleccionado. A continuación se desarrolla la tabla de planificación para el desarrollo de software. Tabla 4: Plan de desarrollo de software según ICONIX OBJETIVOS

FASES

ELABORACIÓN 

Seleccionar lenguaje de programación y sistema gestor de base de datos.



Análisis de requisitos

Desarrollar el



módulo de gestión de distintos tipos



Realizar tabla de requerimientos.



Identificar tipos de actores.



Diseñar los diagramas de casos de

Diseño

uso, diagramas de robustez, y

preliminar 

de usuarios.

diagramas de secuencia

Revisión critica



del diseño 

Diseñar el modelo del dominio, incremento de diagrama de dominio,

Implementación

culminación de diagrama de dominio. 

Codificar el módulo de gestión de cuentas de usuario.

82 - 162

OBJETIVOS

FASES

ELABORACIÓN 

Realizar pruebas al módulo de usuarios.



módulo de control de stock de productos.

 

Realizar tabla de requerimientos.



Identificar actores involucrados en el módulo.

Análisis de 

requisitos Desarrollar el



Diseño

uso, diagramas de robustez y

preliminar

diagramas de secuencia,

Revisión critica



Diseñar el modelo del dominio, incremento de diagrama de dominio,

del diseño 

Diseñar los diagramas de casos de

culminación de diagrama de dominio.

Implementación 

Codificar el módulo de control de stock de productos.

 Implementar el módulo de Servicios de Catering.



Realizar pruebas al módulo.

Diseño



Realizar tabla de requerimientos.

preliminar



Diseñar la interfaz para el módulo de

Análisis de requisitos

 

Servicios de Catering

Revisión critica del diseño Implementación

Desarrollar la Aplicación móvil Android para la gestión de abastecimiento de productos.

  

Análisis de



Realizar análisis de requerimientos.

requisitos



Identificar tipos de usuario.

Diseño



Diseñar los diagramas de casos de

preliminar

uso, diagramas de robustez y

Revisión critica

diagramas de secuencia.

del diseño 



Implementación

Diseñar el modelo del dominio, incremento de diagrama de dominio,

83 - 162

OBJETIVOS

FASES

ELABORACIÓN culminación de diagrama de dominio. 

Implementar el módulo para la gestión de abastecimiento de productos.

Implementar

 

el servidor y la aplicación móvil

Realizar pruebas de funcionamiento.



Seleccionar mecanismos de conexión

Análisis de requisitos

mecanismos de conectividad entre



Diseño

y sincronización.

preliminar 

Revisión critica

Android (offline-

del diseño

online)

Implementación



Realizar las pruebas de funcionalidad.

Fuente: Elaboración propia 3.3.

DESARROLLAR EL MÓDULO DE GESTIÓN DE DISTINTOS TIPOS DE USUARIOS.

Para empezar a construir el sistema, primero se debe desarrollar el modulo de gestión de usuarios para tener el control del personal de la empresa. 3.3.1. Seleccionar lenguaje de programación A continuación se describe los lenguajes de programación que fueron utilizados para el desarrollo del sistema de la cual se muestra las ventajas y desventajas de cada una de ellas. Tabla 5: Tabla de comparación de lenguajes de programación

Lenguajes de

Ventajas

Desventajas

programación

84 - 162

Python



Simplificado y rápido



Elegante y flexible: el

Los programas interpretados

lenguaje da muchas

son más lentos que los

herramientas

compilados.



Ordenado y limpio



Portable: Ya sea en mac, linux o windows

Ruby 

Orientado a objetos



Dinámico



Multiplataforma



Portátil



Rendimiento comparable a Perl o Python, pero lejos de C o C++



No existen muchas frameworks desarrolladas en Ruby



No existe una framework de GUI multi-plataforma ampliamente aceptada

Java

  



Lenguaje orientado a



Java es un lenguaje de

objeto.

programación el cual no

La sintaxis básica deriva

tiene muchas desventajas,

del lenguaje C/C++.

sin embargo una de las

Es independiente de la

mayores desventajas sobre

plataforma, tanto en

este lenguaje es la

código fuente como en

velocidad ya que los

binario.

programas hechos en Java

Es Multi-plataforma

no tienden a ser muy

(funciona en celulares,

rápidos.

computadoras, etc.). Fuente: Elaboración propia

85 - 162

Como el proyecto está orientada al desarrollo de una aplicación móvil se considera Python debido a que está es una excelente solución para poner en práctica la validación de datos de un formulario en el lado del cliente y además permite la creación de efectos dinámicos tales como imágenes dinámicas combinada con HTML, JavaScript y CSS por lo tanto se convierte en la mejor opción para más funcionalidades a comparación de otros lenguajes de programación por lo tanto se descarta los lenguajes de programación Java y Ruby. 3.3.2. Requerimientos de gestión de distintos tipos de usuarios. En base al análisis y teniendo en cuenta el sistema actual de acuerdo a los procesos que se realiza se logró determinar los siguientes requerimientos. Tabla 6: Tabla de requerimientos de Gestión de usuarios Nro.

Requisito

Evidente/Oculto

1

Registro de Usuarios

Evidente

2

Iniciar sesión

Evidente

3

Control de personal

Evidente

4

Editar y eliminar usuario

Oculto

Fuente: Elaboración propia 3.3.3. Identificación de actores de gestión de distintos tipos de usuarios. Un actor es una persona que tiene la capacidad de interactuar con el sistema, este cumple un determinado rol de acuerdo a las tareas que realiza. Cada uno de estos actores tiene tareas distintas que cumplir en el sistema, por lo tanto se le asignan distintos privilegios en el sistema, por ejemplo el administrador tiene más privilegios que el chef y encargado de compras.

86 - 162

La siguiente tabla describe la actividad de los actores en el sistema en el módulo de Gestión de usuarios:

Tabla 7: Identificación de usuarios de Gestión de usuarios

ACTORES

TAREAS Administrador

uc Modelo de...

El administrador podrá ingresar al sistema registrar sus datos e interactuar con el mismo teniendo el acceso también a Administrador

uc Modelo ...

gestión de usuarios.

Chef El chef podrá ingresar al sistema para registrar sus datos personales, ingresar

Chef

usuario, contraseña y seleccionar tipo de usuario.

Encargado de compras uc Modelo de casos d...

El encargado de comprar ingresará al sistema Encargado de compras

para

registrar

sus

datos

personales, ingresar usuario, contraseña y seleccionar tipo de usuario.

Fuente: Elaboración propia 87 - 162

3.3.4. Diagramas de casos de uso de alto nivel y expandido. Los casos de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar en proceso para ello se diseñará el Caso de uso de alto nivel y los casos expandidos. 3.3.4.1.

Diagrama de caso de uso de alto nivel

El siguiente diagrama de caso de uso de alto nivel representa la estructura global del sistema propuesto de procesos y funciones que se llevarán a cabo con los involucrados de la empresa Figura 22: Diagrama de Caso de Uso de Alto Nivel del Sistema

Fuente: Elaboración propia

88 - 162

Tabla 8: Descripción de caso de uso de alto nivel Casos de uso:

Diagrama de Caso de Uso de Alto Nivel del Sistema

Actores:

Administrador, Chef, Encargado de compras

Tipo:

Primario

Descripción: Los actores deberán registrar sus datos personales para poder acceder al sistema e iniciar sesión con su usuario y contraseña. El administrador es el actor principal del proceso ya que hará un control de stock en el almacén también registrará los productos que ofrece la empresa para que el chef tenga referencia al momento de hacer el pedido, una vez realizado dicho pedido el encargado de compras podrá ver el pedido y realizar compras de los ingredientes.

Fuente: Elaboración propia 3.3.4.2.

Diagramas de casos de uso expandido

En los siguientes diagramas se muestran los casos de uso expandido de cada caso de uso que se graficó en el Diagrama de Casos de uso de alto nivel a) Registro de Datos El siguiente diagrama describe el caso de uso muestra los pasos a seguir para el registro de datos.

89 - 162

Figura 23: Registro de datos

Fuente: Elaboración propia Tabla 9: Descripción de caso de uso expandido “Registro de datos” Casos de uso:

Registro de datos

Actores:

Administrador, Chef, Encargado de compras

Tipo:

Primario

Descripción:

Los actores deberán ingresar sus datos personales para poder registrarse e ingresar al sistema. Fuente: Elaboración propia

Tabla 10: Descripción de acción de actores “Registro de datos” Acción de Actores

Respuesta del sistema

1.- Los actores deben registrar sus datos personales y seleccionar el rol que tiene en la empresa. 90 - 162

Acción de Actores

Respuesta del sistema 2.-El

sistema

registrará

todos

campos llenados y si no están llenados

todos

los

campos

mostrará un mensaje de “El campo no puede estar vacío” 3.- Una vez llenado todos los campos del formulario el usuario debe presionar el botón registrar 4.- El sistema inmediatamente registrará sus datos y volverá a la pantalla principal. Fuente: Elaboración propia b) Iniciar sesión El siguiente diagrama describe el caso de uso muestra los pasos a seguir para el ingreso al sistema. Figura 24: Iniciar sesión

Fuente: Elaboración propia 91 - 162

Tabla 11: Descripción de caso de uso expandido “Iniciar sesión” Casos de uso:

Iniciar sesión

Actores:

Administrador, Chef, Encargado de compras

Tipo:

Primario

Descripción:

El administrador, Chef y encargado de compras podrán ingresar al sistema introduciendo su usuario y contraseña. Fuente: Elaboración propia

Tabla 12: Descripción de acción de actores “Iniciar sesión” Acción de Actores 1.-

El

Respuesta del sistema

administrador,

chef

y

encargado de compras ingresan al sistema, introducen sus datos de usuario y contraseña 2.

El sistema valida datos de usuario,

contraseña

y

da

acceso al sistema. 3.- Después de tener acceso al sistema cada actor podrá realizar su respectivo trabajo. Fuente: Elaboración propia c) Gestión de usuarios El siguiente diagrama describe el caso de uso muestra los pasos a seguir para la gestión de usuarios que el administrador podrá realizar.

92 - 162

Figura 25: Gestión de usuarios

Fuente: Elaboración propia Tabla 13: Descripción de caso de uso expandido “Gestión de usuarios” Casos de uso:

Gestión de usuarios

Actores:

Administrador

Tipo:

Primario

Descripción:

El administrador tendrá acceso al control de personal. Fuente: Elaboración propia

Tabla 14: Descripción de acción de actores “Gestión de usuarios” Acción de Actores

Respuesta del sistema

1.- El administrador ingresará a control de personal.

93 - 162

Acción de Actores

Respuesta del sistema 2.-El

sistema

mostrará

una

pantalla de distintas opciones de: Chef y encargado de compras 3.-

El

administrador

deberá

presionar en “Chef” 4.- El sistema mostrará una lista de chef registrados con la opción asignar. 5.-El

administrador

deberá

presionar el botón “asignar” para poder

asignar

empresa

y

encargado de compras al chef. 6.- El sistema mostrará botón “ASIGNAR”

para

concretar

el

proceso. 7.- El administrador debe presionar el botón “Asignar”. 8.-

El

sistema

automáticamente

guardará los

datos

registrados Fuente: Elaboración propia 3.3.5. Diagrama de robustez de gestión de distintos tipos de usuarios. Los diagramas de robustez nos sirven para hacer una comprobación de validez, es decir, comprobar si el texto caso de uso es correcto. Éste es un diagrama que no tiene que mantenerse al día ya que se utiliza sólo para la transición.

94 - 162

a) Registro de datos A continuación se describe gráficamente el proceso para el registro de datos de los involucrados. Figura 26: Diagrama de robustez de registro de datos analysis Diagrama de robustez 2:Ingresa datos de usuario nuevo

1:Seleccionar opción IU aplicación

3:Enviar datos

Gestor usuario

IU Registro de usuarios

Usuario

4:Selecciona rol de usuario

Tipo_usuario

Fuente: Elaboración propia b) Iniciar sesión. A continuación se describe gráficamente el proceso para iniciar sesión Figura 27: Diagrama de robustez de Iniciar sesión analysis Diagrama de robustez 2:Ingresa datos de usuario

1:Seleccionar opción IU: Aplicación

IU Iniciar sesión

4:Confirmación de usuario y contraseña

3:Enviar datos de usuario

IU Usuario y contraseña

Gestor usuario

Usuario

5:Menú de acuerdo al rol de usuario

IU Menú usuario

Fuente: Elaboración propia c) Gestión de usuarios A continuación se describe gráficamente el proceso para la gestión de usuarios. 95 - 162

Figura 28: Diagrama de robustez de Gestión de usuarios analysis Diagrama de robustez 3:Enviar dato de empresa 1:Seleccionar opción IU:Menú de administrador

2:Enviar datos

IU:Asignar Empresa y Encargado de compras

Gestor empresa

6:Devuelve datos guardados

Chef

4:Seleccionar encargado de compras

Gestor Control de personal

Gestor usuario

5:Envía datos de usuario

Usuario

Fuente: Elaboración propia 3.3.6. Modelado del dominio, incremento de diagrama de dominio, culminación de diagrama de dominio. A continuación se describe gráficamente el diagrama del modelado del dominio, incremento de diagrama de dominio, culminación de diagrama de dominio para el modulo gestión de distintos tipos de usuarios. Figura 29: Modelado del dominio

Usuario

n

-Nombre -Apellido1 -Apellido2 -CI -Celular -Dirección -Usuario -Contraseña -Tipo_de_usuario +Editar() +Eliminar()

1

1 Chef

1

-id_usuario -encargado -pedido -empresa +Eliminar() +editar() 1 Encargado -id_usuario +Eliminar() +Editar()

tipo_usuario -t_usuario 1

+Editar () +eliminar()

Fuente: Elaboración propia

96 - 162

3.3.7. Codificar el módulo de gestión de cuentas de usuario. A continuación se muestra una parte del código empleado en la gestión de cuentas de usuario. Figura 30: Codificación de gestión de cuentas de usuarios

Fuente: Elaboración propia a) Interfaz de registro de usuarios A continuación se muestra la interfaz de registro de usuario.

97 - 162

Figura 31: Interfaz de registro de usuario

Fuente: Elaboración propia b) Interfaz de Iniciar sesión A continuación se muestra la interfaz para iniciar sesión. Figura 32: Interfaz de iniciar sesión

Fuente: Elaboración propia

98 - 162

c) Interfaz de registro de administrador. A continuación se muestra la interfaz para el administrador. Figura 33: Interfaz del administrador

Fuente: Elaboración propia Figura 34: Interfaz de control de personal

Fuente: Elaboración propia

99 - 162

3.3.8. Realizar pruebas al módulo de usuarios Para cumplir con la validación y verificación del sistema en esta sección se realizará las pruebas funcionales la cual se aplica por casos de uso. A continuación se presenta las pruebas funcionales del módulo de usuarios. a) Prueba funcional de registro de datos. A continuación se muestra las pruebas funcionales de registro de datos del usuario. Tabla 15: Prueba funcional del caso de uso registro de datos. Caso de uso

Descripción

Prueba

Resultado

El formulario consiste en llenar los datos personales Controlar llenado del usuario en todos los de datos en vacío Registro de datos

Exitoso

campos que se solicita. Los

campos

deben

ser

llenados con sólo números en caso del CI y Celular.

Controlar llenado de sólo números.

El sistema no acepta un Verificación doble usuario ya registrado.

de

usuario existente

Exitoso

Exitoso

Fuente: Elaboración propia b) Prueba funcional de ingresar al sistema. A continuación se muestra las pruebas funcionales de inicio de sesión de los usuarios. Tabla 16: Prueba funcional del caso de uso ingresar al sistema. Caso de uso

Descripción

100 - 162

Prueba

Resultado

El formulario solicita llenar datos Ingresar al

de

usuario

y

contraseña.

Controlar llenado de datos en vacío

Exitoso

sistema Los datos ingresados en el formulario

deben

ser

correctos

Verificar

datos

correctos

Exitoso

Fuente: Elaboración propia c) Prueba funcional de gestión de usuarios. A continuación se muestra las pruebas funcionales de control de usuarios. Tabla 17: Prueba funcional del caso de uso de gestión de usuarios. Caso de uso

Descripción

Prueba

Resultado

El formulario muestra lista de chef

registrados

asignar Gestión de usuarios

y

encargado

sin Controlar llenado de de Formulario

Exitoso

compras ni empresa. En

la

asignación

encargado

de

de

compras

generar una lista de los usuarios registrados como

Controlar lista de encargados.

Exitoso

“encargado de compras” Fuente: Elaboración propia

3.4. DESARROLLAR EL MÓDULO DE CONTROL DE STOCK DE PRODUCTOS Para poder abastecerse con ingredientes necesarios para el servicio de catering se debe desarrollar el modulo de gestión de control de stock de productos. 101 - 162

3.4.1. Requerimientos. En base al análisis y teniendo en cuenta el sistema actual de acuerdo a los procesos que se realiza se logró determinar los siguientes requerimientos para el modulo control de stock. Tabla 18: Tabla de requerimientos de control de stock de productos

Nro.

Requisito

Evidente/Oculto

1

Iniciar sesión como administrador

Evidente

2

Registrar ingrediente para el almacén

Evidente

3

Editar y eliminar ingrediente de almacén

Oculto

Fuente: Elaboración propia 3.4.2. Identificar actores involucrados en el módulo. La siguiente tabla describe la actividad de del involucrado en el sistema. Tabla 19: Identificación de actores involucrados en el módulo. ACTORES

TAREAS

uc Modelo de...

Administrador El administrador podrá ingresar al sistema y revisar un control de stock de los Administrador

ingredientes almacenados en bodega.

Fuente: Elaboración propia 102 - 162

3.4.3. Diagramas de casos de uso expandido de control de stock. A continuación se desarrollará el diagrama de caso de uso expandido de control de stock. d) Control de stock A continuación se muestra la figura del diagrama de caso de uso expandido de control de stock. Figura 35: Diagrama de caso de uso expandido de control de stock.

Fuente: Elaboración propia. Tabla 20: Descripción de caso de uso expandido control de stock. Casos de uso:

Control de stock

Actores:

Administrador

Tipo:

Primario

Descripción:

El

administrador

deberá

llenar

datos

del

ingrediente para el almacén como: nombre del ingrediente y la cantidad. Fuente: Elaboración propia Tabla N° 20: Descripción de acción de actores control de stock

103 - 162

Acción de Actores 1.-

El

Respuesta del sistema

administrador

deberá

ingresar al sistema con su nombre de usuario y contraseña. 2.-El sistema verificará dato y dará acceso para el ingreso al sistema. 3.-

El

administrador

debe

seleccionar la opción “control de stock” para poder ingresar al formulario de control de stock y registrar el ingrediente para el producto. 4.- El sistema una vez llenado los campos

definidos

guardará

la

información automáticamente. Fuente: Elaboración propia 3.4.4. Diagrama de robustez control de stock. A continuación se desarrollará el diagrama de robustez para el control de stock de productos. d) Control de stock A continuación se describe gráficamente el proceso para el control de stock.

104 - 162

Figura 36: Diagrama de robustez de control de stock. analysis Diagrama de robustez 1:Selecciona opción IU:Menú de administrador

3:Envía dato

2:Ingresa datos

IU: Control de stock

Gestor stock

stock

7:Envia datos 6:Selecciona ingrediente

IU:Modificar cantidad

Fuente: Elaboración propia 3.4.5. Diseñar el modelo del dominio. A continuación se describe gráficamente el diagrama del modelado del dominio del control de stock. Figura 37: Diseño del dominio de control de stock.

Usuario

n

-Nombre -Apellido1 -Apellido2 -CI -Celular -Dirección -Usuario -Contraseña -Tipo_de_usuario +Editar() +Eliminar()

1

1 Chef

1

-id_usuario -encargado -pedido -empresa +Eliminar() +editar() 1 Encargado -id_usuario +Eliminar() +Editar()

stock -ingredientes -cantidad +modificar()

tipo_usuario -t_usuario 1

+Editar () +eliminar()

Fuente: Elaboración propia 3.4.6. Codificar el módulo de control de stock de productos. A continuación se muestra una parte del código empleado en el módulo. 105 - 162

Figura 38: Codificación de control de stock

Fuente: Elaboración propia d) Interfaz de control de stock. A continuación se muestra la interfaz de control de stock. Figura 39: Interfaz de control de stock.

Fuente: Elaboración propia 106 - 162

3.4.7. Realizar pruebas al módulo. A continuación se presenta las pruebas funcionales del módulo control de stock. Tabla 21: Prueba funcional del caso de uso de control de stock. Caso de uso

Descripción

Prueba

Resultado

El formulario consiste en llenar datos del ingrediente Controlar llenado Control de stock

que se va almacenar en la de datos en vacío

Exitoso

bodega. El sistema no acepta un Verificación

de

doble

ya

ingrediente

ya ingrediente

registrado.

Exitoso

existente.

Fuente: Elaboración propia

3.5. IMPLEMENTAR EL MÓDULO DE SERVICIOS DE CATERING. 3.5.1. Tabla de requerimientos. En base al análisis y de acuerdo a los procesos descritos anteriormente se logró determinar los siguientes requerimientos para el modulo Servicios de catering.

Tabla 22: Tabla de requerimientos de servicios de catering Nro.

Requisito

Evidente/Oculto

1

Interfaz principal servicios de catering VALENCIA

Evidente

3

Interfaz de iniciar sesión

Evidente

107 - 162

Nro.

Requisito

Evidente/Oculto

4

Interfaz de administrador

Evidente

5

Interfaz de registrar producto

Oculto

Fuente: Elaboración propia 3.5.2. Identificar tipos de usuario. La siguiente tabla describe la actividad de cada usuario que interactuará con el sistema mediante un móvil. Tabla 23: Identificación de tipos de usuario. ACTORES

TAREAS Administrador

uc Modelo de...

Controla los procesos que se hace en el sistema y se encarga de registrar el producto y los ingredientes de cada Administrador

producto.

Fuente: Elaboración propia 3.5.3. Diseñar los diagramas de casos de uso A continuación se desarrollará los distintos diagramas de caso de uso expandido para el modulo de la aplicación móvil para la gestión de abastecimiento de productos para el servicio de catering. e) Administrar producto.

108 - 162

El siguiente diagrama describe el caso de uso muestra los pasos a seguir para administrar producto Figura 40: Administrar producto

Fuente: Elaboración propia Tabla 24: Descripción de caso de uso expandido de Administrar producto Casos de uso:

Administrar producto

Actores:

Administrador

Tipo:

Primario

Descripción:

El administrador tendrá acceso para administrar el producto creando nuevo producto, editarlo o eliminar dicho producto. Fuente: Elaboración propia

Tabla 25: Descripción de acción de actores de Administrar producto Acción de Actores

Respuesta del sistema

1.- El administrador ingresará a administrar saldrán

producto

dos

donde

opciones

le

“Nuevo

producto” y “Editar o eliminar producto”, deberá escoger “nuevo 109 - 162

Acción de Actores producto”

para

Respuesta del sistema registrar

el

producto. 2.-El

sistema

mostrará

una

pantalla donde podrá llenar datos de dicho producto el cual podrá ser almacenado presionando el botón “guardar” 3.-

El

administrador

deberá

presionar el botón “editar o eliminar producto” si desea una de estas acciones. 4.- El sistema mostrará las dos opciones por separado “editar” y “eliminar”. 5.-El administrador tendrá que escoger una de las opciones. 6.- El sistema realizará dicha acción y saldrá a la página principal automáticamente. Fuente: Elaboración propia 3.5.4. Diagramas de robustez Los diagramas de robustez nos sirven para hacer una comprobación de validez, es decir, comprobar si el texto caso de uso es correcto. Éste es un diagrama que no tiene que mantenerse al día ya que se utiliza sólo para la transición. e) Administrar producto. A continuación se describe gráficamente el proceso para administrar producto

110 - 162

Figura 41: Diagrama de robustez de Administrar producto analysis Diagrama de robustez 3:Envía datos 2:Selecciona tipo Gestor tipo

Tipo_Producto

1:Seleccionar opción

IU: Menú administrador

IU:Registrar prodcuto

4:Registra datos

5:Envía datos

7:Envía datos

Gestor producto

Producto

6:Selecciona producto

IU: Modificar/Eliminar

Fuente: Elaboración propia 3.5.5. Diseñar el modelo del dominio, incremento de diagrama de dominio, culminación de diagrama de dominio. A continuación se describe gráficamente el diagrama del modelado del dominio de la aplicación móvil Android de gestión de abastecimiento de productos.

111 - 162

Figura 42: Diseño del dominio de la aplicación móvil Android de gestión de abastecimiento de productos

Usuario

n

-Nombre -Apellido1 -Apellido2 -CI -Celular -Dirección -Usuario -Contraseña -Tipo_de_usuario +Editar() +Eliminar()

1

1 Chef

1

-id_usuario -encargado -pedido -empresa +Eliminar() +editar() 1

n Encargado -id_usuario +Eliminar() +Editar()

tipo_usuario -t_usuario 1

stock -ingredientes -cantidad +modificar()

tipo_producto

1

-tipo_producto

+Editar () +eliminar()

Producto -nombre_producto -ingredientes -precio -tipo +Eliminar() +Editar() +Agregar()

Fuente: Elaboración propia 3.5.6. Codificar el módulo de Servicios de catering A continuación se muestra una parte del código empleado en el módulo.

112 - 162

Figura 43: Codificación de Servicios de catering

Fuente: Elaboración propia Figura 44: Registrar un producto

Fuente: Elaboración propia

113 - 162

3.5.7. Realizar pruebas de funcionamiento. A continuación se presenta las pruebas funcionales del módulo de la aplicación móvil Android para el Servicios de catering. Figura 45: Prueba funcional Servicios de catering. Caso de uso

Descripción

Prueba

Resultado

El formulario consiste en Controlar llenado llenar datos del producto

de datos en vacío

Exitoso

Registrar producto El sistema muestra la opción de editar eliminar producto

Verificación

de

editar y eliminar

Exitoso

producto

Fuente: Elaboración propia

3.6. DESARROLLAR LA APLICACIÓN MÓVIL ANDROID PARA LA GESTIÓN DE ABASTECIMIENTO DE PRODUCTOS. A continuación se describen los procesos para desarrollar el modulo de la aplicación para la gestión de abastecimiento de productos. 3.6.1. Realizar análisis de requerimientos. En base al análisis de los procesos que se lleva a cabo en la empresa se logró determinar una tabla de requerimientos para cumplir el servicio de catering mediante la gestión de abastecimiento de productos donde se involucran el administrador, chef y encargado de compras. Tabla 26: Tabla de requerimientos

114 - 162

Fuente: Elaboración propia 3.6.2. Identificar tipos de usuario. La siguiente tabla describe la actividad de cada usuario que interactuará con el sistema mediante un móvil. Tabla 27: Identificación de tipos de usuario. ACTORES uc Modelo ...

TAREAS Chef El chef tendrá las distintas opciones para realizar el pedido de diferentes productos y así generar un menú diario.

Chef

uc Modelo de casos d...

Encargado de compras Recibirá

información

de

la

lista

de

ingredientes solicitados para poder realizar Encargado de compras

la compra y registrará compras realizadas.

Fuente: Elaboración propia 3.6.3. Diseñar los diagramas de casos de uso A continuación se desarrollará los distintos diagramas de caso de uso expandido para el modulo de la aplicación móvil para la gestión de abastecimiento de productos para el servicio de catering. f)

Registrar pedido

El siguiente diagrama describe el caso de uso muestra los pasos a seguir para registrar el pedido. 115 - 162

Figura 46: Registrar pedido

Fuente: Elaboración propia Tabla 28: Descripción de caso de uso expandido Registrar pedido Casos de uso:

Registrar pedido

Actores:

Chef

Tipo:

Segundo

Descripción:

El Chef debe realizar los pedidos que requiere para la empresa tomando en cuenta los diferentes productos

que

ofrece

el

servicio

catering

VALENCIA. Fuente: Elaboración propia Tabla 29: Descripción de acción de actores Registrar pedido Acción de Actores

Respuesta del sistema

1.- El Chef deberá ingresar a Registrar

pedido

para

poder

116 - 162

Acción de Actores

Respuesta del sistema

seleccionar los productos que se van a solicitar. 2.-El sistema mostrará los distintos productos con la fecha actualizada. 3.- El Chef al seleccionar producto deberá registrar cantidad y enviar la lista, para ello deberá presionar el botón “pedir” 4.- El sistema mostrará la opción “enviar” 5.-El Chef deberá presionar el botón

“enviar”

para

poder

confirmar el pedido. 6.- El sistema mostrará un mensaje “Su

pedido

ha

sido

enviado

correctamente” Fuente: Elaboración propia g) Visualiza pedido y registra compra El siguiente diagrama describe el caso de uso expandido de lo que el comprador puede ver y realizar.

117 - 162

Figura 47: Visualiza pedido y registra compra

Fuente: Elaboración propia Tabla 30: Descripción de caso de uso expandido de Visualiza pedido y registra compra Casos de uso:

Registrar pedido

Actores:

Encargado de compras

Tipo:

Tercero

Descripción:

El encargado de compras tendrá que ver los pedidos

para

realizar

las

compras

de

los

ingredientes solicitados.

Fuente: Elaboración propia Tabla 31: Descripción de acción de actores de Visualiza pedido y registra compra Acción de Actores Respuesta del sistema 1.- El Encargado de compras después de ingresar al sistema tendrá dos opciones “ver pedido” y “compras

realizadas”

presionar

primeramente

deberá “ver

118 - 162

Acción de Actores Respuesta del sistema pedido” para poder ver la solicitud de ingredientes que debe comprar. 2.-El sistema mostrará la lista de ingredientes que debe comprar con la opción de tickear las compras que ya realizó. 3.- El encargado de compras deberá

presionar

el

botón

“compras realizadas” para poder visualizar las compras ya hechas. 4.- El sistema mostrará una lista de los

ingredientes

que

fueron

registrados como comprados.

Fuente: Elaboración propia 3.6.4. Diagramas de robustez Los diagramas de robustez nos sirven para hacer una comprobación de validez, es decir, comprobar si el texto caso de uso es correcto. Éste es un diagrama que no tiene que mantenerse al día ya que se utiliza sólo para la transición. f)

Registrar pedido.

A continuación se describe gráficamente el proceso para registrar pedido

119 - 162

Figura 48: Diagrama de robustez de registrar pedido analysis Diagrama de robustez 3:Envía datos

1:Ingresar a tipo de producto

IU:Menú de chef

2:Seleccina tipo de producto

IU:Tipos de productos

Producto

Gestor producto

4:Registra datos de pedido 5:Enviar datos

6:Lista de pedidos registrados

Gestor pedido

Pedido

IU:Pedidos

Fuente: Elaboración propia g) Visualiza pedido y registra compras. A continuación se describe gráficamente el proceso de Visualiza pedido y registra compras

120 - 162

Figura 49: Diagrama de robustez de Visualiza pedido y registra compras analysis Diagrama de robustez

4:Envia datos de cantidad

Stock

Gestor stock 3:Envía datos

1:Selecciona fecha IU:Menú encargado de compras

5:Envía ingredientes del producto

2:Envia datos

IU:Pedidos

Gestor compras

6:Envía datos del producto

Gestor producto

Producto

7:Registra compras

IU:Compras realizadas

Fuente: Elaboración propia

3.6.5. Diseñar el modelo del dominio, incremento de diagrama de dominio, culminación de diagrama de dominio. A continuación se describe gráficamente el diagrama del modelado del dominio de la aplicación móvil Android de gestión de abastecimiento de productos.

121 - 162

Figura 50: Diseño del dominio de la aplicación móvil Android de gestión de abastecimiento de productos

Usuario

n

-Nombre -Apellido1 -Apellido2 -CI -Celular -Dirección -Usuario -Contraseña -Tipo_de_usuario +Editar() +Eliminar()

1

1 Chef

1

-id_usuario -encargado -pedido -empresa +Eliminar() +editar()

1

1

n Encargado -id_usuario +Eliminar() +Editar()

1 tipo_usuario -t_usuario 1

stock -ingredientes -cantidad +modificar()

tipo_producto

1

-tipo_producto

+Editar () +eliminar()

n n 1

Pedido -tipo_producto -producto -cantidad -fecha +editar()

1

Producto -nombre_producto -ingredientes -precio -tipo +Eliminar() +Editar() +Agregar()

Fuente: Elaboración propia 3.6.6. Implementar el módulo para la gestión de abastecimiento de productos. A continuación se mostrarán las interfaces requeridas para el módulo de gestión de abastecimiento de productos para el servicio de catering.

122 - 162

Figura 51: Interfaces para el registro de pedidos

Fuente: Elaboración propia Figura 52: Interfaces para enviar pedido

Fuente: Elaboración propia 123 - 162

Figura 53: Interfaces para el encargado de compras

Fuente: Elaboración propia 3.6.7. Realizar pruebas de funcionamiento. A continuación se presenta las pruebas funcionales del módulo de la aplicación móvil Android para la gestión de abastecimiento de productos.

124 - 162

Figura 54: Prueba funcional del caso de uso registro de datos. Caso de uso

Descripción

Prueba

Resultado

Registra pedido y cantidad Ingresar cantidad Aplicación

de personas

de pedido

móvil Android

El

para la gestión

operaciones

de

ingredientes con la cantidad visualiza

sistema

realiza Ingresa cantidad de

los de

abastecimiento de pedido de productos

El

Exitoso

pedido

y los

Exitoso

ingredientes

encargado

visualiza

pedido del chef

Registra compras

Exitoso

Fuente: Elaboración propia

3.7. SINCRONIZACIÓN DE LA APLICACIÓN CLIENTE CON LA APLICACIÓN SERVIDOR HACIENDO USO DE DATA STORAGE EN LA NUBE. 3.7.1. Diagrama del proceso de sincronización. Figura 55: Proceso de sincronización Sincronización

BD API REST Servidor web

Fuente: Elaboración propia 125 - 162

3.7.2. Realizar las pruebas de funcionalidad. A continuación se muestran las capturas de pantalla del sistema en ejecución. Figura 56: Sistema en ejecución

Fuente: Elaboración propia Figura 57: Conexión activa

Fuente: Elaboración propia

3.8. REALIZAR PRUEBAS DEL SISTEMA TERMINADO. A continuación se detalla el tipo de prueba adecuado para el sistema. 3.8.1. Identificar los tipos de pruebas adecuados. Existen varios métodos para evaluar el funcionamiento de un sistema. Para cumplir con la validación y verificación del sistema, se eligieron las pruebas de caja negra 126 - 162

debido a que se basan en la evaluación de las salidas del sistema una vez ingresados los datos de entrada sin tomar en cuenta el proceso. 3.8.2. Realizar pruebas a los diferentes módulos. A continuación se presenta las pruebas de caja negra del sistema. En la tabla 31 se presenta la ficha de caso de prueba de caja negra, para la autenticación de usuario del sistema. Tabla 32: Autentificación de usuario de usuario Caso de prueba # 1

Autenticación de usuario

Propósito

Autenticarse en el sistema ingresando los datos de usuario que son el usuario y la contraseña.

Pre-requisitos

Ninguno

Datos de entrada central

Entrada

Salida

Usuario: Giovana

Usuario correcto:

Contraseña: Giovana

Mostrar la pantalla para el administrador.

Usuario: Giovan

Usuario incorrecto:

Contraseña: Giovana

Mostrar mensaje de error “Sus

datos

incorrectos” Pasos

1. Ingresar datos de usuario: usuario y contraseña 2. Presionar el botón de ingresar

Resultados esperados

- Los datos son ingresados

127 - 162

son

- Ingresar a la pantalla principal - Devolver valor de error “Sus datos son incorrectos”

Fuente: Elaboración propia En la tabla 32 se presenta la ficha de caso de prueba de caja negra, para el administrador Tabla 33: Registro de producto Caso de prueba # 2

Registro de producto

Propósito

Registrar un producto con todos los datos que se requiere para tener una información clara y efectiva.

Pre-requisitos

Recetas definidas

Datos de entrada central

Entrada

Salida

Nombre del producto:

Datos correctos:

Precio del producto:

Mostrar pantalla con nuevo

Selección

de

tipo

de formulario

producto: Agregar ingredientes: Nombre

del

producto: Usuario incorrecto:

XXXX

Mostrar mensaje de error

Precio del producto: XXXX “Todos los campos deben Selección

de

tipo

de estar llenados”

producto: XXXX Agregar

ingredientes:

XXXX Pasos

1. Ingresar datos del producto 2. Presionar el botón de Guardar producto

Resultados esperados

- Los datos son ingresados

128 - 162

- Ingresar a la pantalla de nuevo producto - Devolver valor de error “Todos los campos deben estar llenados” Fuente: Elaboración propia En la tabla 33 se presenta la ficha de caso de prueba de caja negra, para el administrador Tabla 34: Registro de producto Caso de prueba # 3

Registro de pedido

Propósito

Registrar un pedido de acuerdo a la solicitud de la empresa

Pre-requisitos

Ninguno

Datos de entrada central

Entrada

Salida

Seleccione un producto:

Datos correctos:

Cantidad:

Mostrar pantalla principal de pedido

Seleccione un producto: Usuario incorrecto: XXXX

Mostrar mensaje de error

Cantidad: 5

“Debe

llenar

todos

los

campos” Pasos

1. Ingresar datos del pedido 2. Presionar el botón de Enviar

Resultados esperados

- Los datos son ingresados - Ingresar a la pantalla principal de pedido - Devolver valor de error “Debe llenar todos los campos” Fuente: Elaboración propia

129 - 162

3.8.3. Documentar las pruebas. A continuación se muestran las capturas de las pruebas descritas anteriormente. Figura 58: Autentificación de usuarios

Fuente: Elaboración propia Figura 59: Registrar un producto

Fuente: Elaboración propia 130 - 162

Figura 60: Registrar un pedido

Fuente: Elaboración propia

3.9. DEMOSTRACIÓN DE LA HIPOTESIS. El sistema de gestión de abastecimiento de productos y servicios de catering integrado con una aplicación móvil Android permitirá reducir el número de errores en la elaboración de la lista de productos que se deben comprar, así mismo reducir el tiempo en la organización del Servicio de Catering para las empresas. Para demostrar la hipótesis es necesario analizar las variables dependientes de la hipótesis 

Errores en la elaboración de la lista de productos que se deben comprar.

Ésta variable se refiere a los posibles errores humanos que se presentan al momento de realizar las listas de pedidos para el abastecimiento de productos. 

Tiempo en la organización del Servicio de Catering para las empresas.

131 - 162

Los procedimientos que se llevan a cabo de registros generan una demora al momento de la organización fundamentalmente para la entrega de productos a cada chef encargado del Servicio de Catering de la empresa. 3.9.1. Demostración de la primera variable dependiente. A continuación de elabora el calculo de un promedio de errores que se cometen manualmente en el registro de ingredientes. 2 𝑒𝑟𝑟𝑜𝑟𝑒𝑠 𝑝𝑜𝑟 𝑙𝑖𝑠𝑡𝑎 ∗ 5 𝑒𝑛𝑐𝑎𝑟𝑔𝑎𝑑𝑜𝑠 ∗ 12 𝑚𝑒𝑠𝑒𝑠 = 120 𝑒𝑟𝑟𝑜𝑟𝑒𝑠 𝑝𝑜𝑟 𝑎ñ𝑜 𝑐𝑜𝑚𝑒𝑡𝑖𝑑𝑜𝑠 𝑝𝑜𝑟 𝑒𝑙 𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑙 Considerando el uso del sistema se evitaran tareas de transcripción de pedidos de ingredientes y solamente serán registrados en el sistema el cual hará un cálculo automático de la cantidad que se requiere, en este caso se supone que se considera un mínimo de error al momento de realizar el pedido se calcula con el sistema: 1 error ------ 1 lista X errores-----5 listas 5

𝑋 = 1 ∗ 1 = 5 𝑒𝑟𝑟𝑜𝑟𝑒𝑠 𝑝𝑜𝑟 𝑎ñ𝑜 𝑐𝑜𝑚𝑒𝑡𝑖𝑑𝑜𝑠 𝑝𝑜𝑟 𝑒𝑙 𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑙 Teniendo los resultados de los errores que se cometen sin el sistema es de 120 errores por parte del personal y con el sistema propuesto se cometen un mínimo de 5 errores por año. Verificando que porcentaje se redujo en errores con el sistema propuesto 120 errores----- 100% 5 errores-----------X% 𝑋=

5 ∗ 100 = 4.17% 120

132 - 162

Por lo tanto: 100% - 4.17% = 95.83% En conclusión obtenemos un 95.83% de reducción de errores utilizando el sistema propuesto. 3.9.2. Demostración de la segunda variable. Para la demostración de la segunda variable dependiente donde el tiempo invertido en el proceso se realiza una comparación con el sistema actual y con el sistema propuesto que se describe en la siguiente tabla: Tabla 35: Demostración de la segunda variable dependiente

Actividad

Registro de ingredientes que se solicita para la preparación de los productos

Pasos sin

Tiempo sin

Pasos con

Tiempo con

sistema

sistema.

sistema

sistema.

El chef realiza la lista de

El chef ingresa

ingredientes

al sistema y

que se

registra

requieren para

50 min

la preparación

cantidad de

20 min.

pedidos

de productos que fueron solicitados Se realiza la

El encargado

Proceso de

revisión de

ingresa al

verificación

pedidos de

sistema y

de pedidos

ingredientes

solicitados

por el

pedidos de

por el chef

encargado de

ingredientes

30min

compras

133 - 162

visualiza los

5 min.

Actividad

Pasos sin

Tiempo sin

Pasos con

Tiempo con

sistema

sistema.

sistema

sistema.

Proceso de

El chef envía

entrega de

Se realiza una

pedido por

pedidos al

comunicación

medio de la

chef para

vía llamadas o

aplicación sin

que se

mensajes para

realice las

la entrega de

contacto

compras de

listas de

personal con

los

pedidos

el encargado

180 min

ingredientes Total tiempo

tener un

5 min

de compras 260 min

Total tiempo

30 min

Fuente: Elaboración propia Después de haber analizado el tiempo en la realización del proceso de control de asistencias al personal, se concluye que el tiempo invertido sin el uso del sistema es aproximadamente 4 horas y 35 minutos con el uso del sistema se realiza aproximadamente en 30 minutos, por lo tanto el tiempo invertido con el uso del sistema es mucho menor que sin el uso del sistema lo cual significa que se reduce el tiempo en 230 minutos. 3.9.3. Demostración de la variable independiente. En la demostración de la variable independiente, se realiza el análisis a través de una muestra de todos los beneficios que tiene el sistema propuesto, y los procedimientos manuales empleados sin el uso del sistema, calificando como un beneficio con “Si”, y rechazando el beneficio con “No” en la siguiente tabla:

134 - 162

Tabla 36: Demostración de la segunda variable dependiente Nro

de Requerimientos

Actual

Sistema

Factores 1

Permite registrar datos del personal.

SI

SI

2

Permite administrar cuentas de usuario para

NO

SI

sus

SI

SI

Permite la registrar los ingredientes que se

NO

SI

NO

SI

NO

SI

una

NO

SI

Permite obtener los registros del control del

NO

SI

SI

SI

3 (SI)

9 (SI)

el personal. 3

Permite

registrar

producto

con

respectivos ingredientes. 4

almacenan en la bodega 5

Permite visualizar el stock de productos almacenado en la bodega

6

Permite verificar las compras realizadas de los ingredientes

7

Permite

registrar

pedidos

desde

aplicación móvil 8

personal del dispositivo biométrico. 9

Permite registrar menú de la semana

TOTAL Fuente: Elaboración propia

Teniendo como resultado del análisis de estas muestras, se concluye que el total de beneficios por el proceso manual tiene la cantidad de 3, y con el proceso del sistema es de 9. Estos resultados se tomarán en cuenta en el cálculo de estadístico T student para realizar la aceptación o rechazo de la hipótesis.

135 - 162

Para la definir la hipótesis se considera el análisis de aceptación y rechazo de la misma, haciendo referencia a un 𝑃𝑛 que representa una probabilidad, en nuestro caso tenemos que:  𝑃1 = Número de errores cometidos en la elaboración de pedidos.  𝑃2 = El tiempo en la verificación de ingredientes comprados. Y para los factores que influyen en la Operativización son:  Hipótesis nula: Los factores de éxito de antes son iguales a los factores de éxito posteriores: 𝐻0 : 𝑃1 = 𝑃2  Hipótesis alternativa: Los factores de éxito de antes son distintos a los factores de éxito posteriores: 𝐻1 : 𝑃1 ≠ 𝑃2 Presenta dos casos, los cuales son: o Los factores de éxito anteriores son mayores a los posteriores: 𝑃1 > 𝑃2 o Los factores de éxito anteriores son menores a los posteriores: 𝑃1 < 𝑃2 en el proyecto se tiene que:  H0 : P1 = P2 : (Los procedimientos manuales utilizados para realizar el proceso de pedidos de ingredientes, control de stock, registro de compras, son iguales, al sistema de gestión de abastecimiento y servicio de catering).  H1 : P1 ≠ P2 : (Los procedimientos manuales utilizados para realizar el proceso de pedidos de ingredientes, control de stock, registro de compras, son diferentes, al sistema de gestión de abastecimiento y servicio de catering). o 𝑃1 > 𝑃2 : (Los procedimientos manuales utilizados para realizar el proceso de pedidos de ingredientes, control de stock, registro de compras, tienen mayores beneficios que el sistema de gestión de abastecimiento y servicio de catering). o 𝑃1 < 𝑃2 : (Los procedimientos manuales utilizados para realizar el proceso de pedidos de ingredientes, control de stock, registro de compras, tienen menores beneficios que el sistema de gestión de abastecimiento y servicio de catering). 136 - 162

Cálculo del estadístico T. Este cálculo permite conocer la aceptación de la hipótesis, teniendo en cuenta que existe un rango de aceptación. Luego con el dato encontrado con las probabilidades se ubica si está dentro del rango de aceptación o rechazo. Para ello se realiza los cálculos con las siguientes fórmulas: 𝑷𝒏 =

𝑿𝒏 𝑻𝒂𝒎𝒂ñ𝒐 𝒅𝒆 𝒍𝒂 𝒎𝒖𝒆𝒔𝒕𝒓𝒂 𝑸𝒏 = 𝟏 − 𝑷𝒏

𝑷𝒄 =

(𝒏𝟏 ∗ 𝑷𝟏 ) + (𝒏𝟐 ∗ 𝑷𝟐 ) 𝒏𝟏 + 𝒏𝟐

𝒈𝒍 = 𝒏 − 𝟏

𝑷 𝟏 − 𝑷𝟐

𝒕=

𝑷𝟏 ∗ 𝑸𝟏 𝑷𝟐 ∗ 𝑸𝟐 𝒏𝟏 + 𝒏𝟐

√ Dónde:

 𝑷𝒏 = Probabilidad de ocurrencia de uno de los casos  𝑿

= Número de aciertos en la muestra de la probabilidad 𝑷𝒏

 𝒏

= Número de muestras (beneficios analizados)

 𝒕

= Valor estadístico para la aceptación o rechazo de la hipótesis

 𝑸𝒏 = Probabilidad de concurrencia de uno de los casos  ∞ = nivel de significancia  𝒈𝒍 = Grado de libertad 137 - 162

𝒏=𝟗 3

𝑃1 = 9 = 0,3333𝑃1 Alcanzó un 33% de los beneficios de la muestra. 9

𝑃2 = 9 = 1𝑃2 Alcanzó un 100% de los beneficios de la muestra. 𝑃1 < 𝑃2  Por lo tanto 𝑃2 es mejor que 𝑃1 . Según el cálculo t-student se considera el valor de α de acuerdo con el número de muestras que se tiene. En este caso, considerándose de una muestra menor a 100, el valor es de 0.05 para hacer el cálculo del grado de error. ∞=

0,05 = 0,025 2 𝐺𝑙 = 8

De acuerdo al cálculo de 𝑃1 y 𝑃2 se acepta la hipótesis 𝐻1 y se rechaza la 𝐻2 ya que el sistema propuesto ofrece mayores beneficios que el sistema actual. Para los rangos de rechazo de la hipótesis se calcula por el valor del grado de libertad obtienen el nivel de significancia; se busca en la tabla y se tienen los rangos, en este caso es de -2.3060y 2.3060, es decir, cualquier valor dentro de este rango demostrará que la hipótesis es nula (𝐻0 ) y la aceptación (hipótesis alternativa 𝐻1 ) de la hipótesis se encuentra fuera de estos rangos 3

𝑃1 = 9 = 0,3333 9

𝑃2 = 9 = 1 𝑡=

Entonces Entonces

𝑄1 = 1 − 0,3333 = 0,6667

𝑄2 = 1 − 1 = 0

0,3333 − 1 √0,3333 ∗ 0,6667 + 1 ∗ 0 9 9

= −4,2429

Campana de Gauss para la aceptación de la hipótesis

138 - 162

Figura 61: Campana de gauss 𝐻0

𝐻1 𝐻1 𝐻1 : 𝑃1 < 𝑃2

𝐻1 : 𝑃1 > 𝑃2

−4,2429 − 2,3060

2,3060

Fuente: Elaboración propia Después de realizar el análisis del cálculo de T-Student se puede indicar que se rechaza la hipótesis nula H0 y se acepta la alternativa H1, lo cual significa que el sistema planteado, ofrece mejores servicios que el proceso que se emplea manualmente en la actualidad. Como el estadístico t se encuentra al lado izquierdo de la campana de Gauss, entonces se acepta que 𝑃1 < 𝑃2 lo que significa que el sistema desarrollado ofrece más beneficios que el sistema actualmente existente permitiendo un proceso óptimo del servicio de catering.

139 - 162

ESCUELA MILITAR DE INGENIERÍA MCAL. ANTONIO JOSÉ DE SUCRE BOLIVIA

CAPÍTULO 4 ANÁLISIS DE VIABILIDAD.

4. ANÁLISIS DE VIABILIDAD A continuación se realizará un análisis en tres aspectos que son viabilidad técnica, económica y operativa.

4.1. VIABILIDAD TÉCNICA. Para el desarrollo del presente proyecto y funcionamiento de la aplicación móvil se debe cumplir con los siguientes requerimientos en cuanto Software y Hardware, en la tabla que se muestra a continuación se muestra a detalle los requerimientos de Hardware para el servidor web y el móvil. Tabla 37: Requerimientos de hardware HARDWARE

REQUERIMIENTO MÍNIMO - Procesador Pentium IV

REQUERIMIENTO IDEAL -

1.2Ghz.

SERVIDOR WEB

3.7Ghz.

- Memoria RAM 1GB.

-

Memoria RAM 4GB.

- Disco duro 100GB.

-

Disco duro 180GB

- Monitor resolución

-

Monitor resolución

1024x768.

1024x768.

- Teclado y mouse

-

Teclado y mouse.

- Procesador Broadcom

-

Procesador 1.9Ghz. (Quad-

BCM21654G/ARM CortexA5. CLIENTE MÓVIL

Procesador CORE i7

Core). -

RAM 2GB.

- RAM 768MB

-

Memoria interna 16GB

- Memoria interna 4GB

-

Pantalla 136.6x69.8x7.9

(2GB accesible al

mm.

usuario). - Pantalla 58.6x109.4 mm. Fuente: Elaboración propia

141 - 162

A continuación se muestra una tabla a detalle los requerimientos mínimos e ideales para el servidor web y cliente en cuanto a software para el correcto funcionamiento de la aplicación móvil. Tabla 38: Requerimientos de Software HARDWARE

REQUERIMIENTO MÍNIMO - Sistema operativo XP.

REQUERIMIENTO IDEAL - Sistema operativo

- Navegador Explorer.

SERVIDOR WEB

Windows7.

- Cuenta de Gmail.

- Navegador Google Chrome.

- Gestor de base de datos

-

Cuenta de Gmail.

MySQL almacenados en

-

Gestor de base de datos

Google cloud Platform.

MySQL almacenados en

- Banda ancha 128kbps.

Google cloud Platform. -

- Sistema operativo Android CLIENTE MÓVIL

Banda ancha 1Mbps.

- Sistema operativo Android

4.0.

5.0.

- Plan de datos 3G.

-

Plan de datos 4G.

Fuente: Elaboración propia Después del análisis de requerimientos de Hardware y Software que la herramienta desarrollada necesita para su funcionamiento y con el detalle de las tablas anteriores se pudo verificar que la adquisición o cumplimiento de cada requerimiento puede ser cubierto. En caso del servidor web teniendo un almacenamiento de la base de datos en la nube no es necesario de un servidor físico simplemente una cuenta de Gmail para asociarla con un servicio de Google cloud Platform, en cuanto al cliente móvil la mayoría de las personas en general e involucrados en la empresa Servicios de catering VALENCIA cuentan con un Smartphone que cumple con los requisitos mencionados anteriormente, además que estos se encuentran disponibles en el mercado, concluyendo así que el proyecto es técnicamente viable.

142 - 162

4.2. VIABILIDAD ECONÓMICA. El presente proyecto se realizó con la utilización de diferentes herramientas programación y base de datos las herramientas del servidor no tiene costo por que es un servicio que brinda Google, de la misma manera MySQL no tiene costo porque se integra al servicio en la nube de Google y solamente se paga si se desea el mantenimiento del mismo. 4.2.1. Costo de implementación del proyecto. A continuación se describe los precios de los requerimientos mínimos y requerimientos ideales tanto en hardware como en software para el servidor. Tabla 39: Costos de Hardware y Software del servidor HERRAMIENTA

COSTO MÍNIMO Bs.

COSTO IDEAL

2150

4020

0

0

Pc incluyendo Procesador Memoria Disco duro Monitor Teclado y mouse Sistema operativo XP. Navegador Explorer. Cuenta de Gmail. Gestor de base de datos MySQL almacenados en Google cloud Platform. Banda ancha 128kbps. TOTAL

Bs 2150.-

Fuente: Elaboración propia

143 - 162

Bs 4020.-

En la siguiente tabla se muestra el análisis de costos del hardware y software del para el cliente móvil. Tabla 40: Costos de Hardware y Software del cliente HERRAMIENTA

COSTO MÍNIMO Bs.

COSTO IDEAL

300

1750

0

0

Requerimiento Técnico (Móvil de reserva en la empresa) Sistema operativo Android 4.0. Plan de datos 3G. TOTAL

Bs 300.-

Bs 1750.-

Fuente: Elaboración propia 4.2.2. Costo del proyecto En COCOMO o Modelo Constructivo de Costes (Constructive Cost Model) fue desarrollado por B. W. Boehm a finales de los 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981). COCOMO es una jerarquía de modelos de estimación de costos que hace referencia al modo de desarrollo del proyecto, que influye directamente en el costo y duración del mismo, y que puede ser: A. Modelo orgánico: cuando el proyecto es desarrollado en un ambiente familiar y estable, en el que el producto es similar a otros desarrollados previamente. Son además productos pequeños y poco novedosos, con unos requerimientos definidos y poco rígidos.

144 - 162

B. Modelo semiacoplado: es un modelo para proyectos que presentan características intermedias entre el orgánico y el empotrado, con un equipo formado por miembros de distintos niveles de experiencia, que trabajan sobre un conjunto de requisitos más o menos flexibles. C. Modelo Empotrado: para proyectos caracterizados por unos requerimientos y restricciones poco flexibles, que requieren un gran esfuerzo de innovación. También poseen un elevado nivel de complejidad en hardware. Tabla 41: Valores COCOMO Modo Orgánico Semiacoplado Empotrado

ai

bi

ai

bi

3.20

1.05

2.50

0.38

3.00

1.12

2.50

0.35

2.80

1.20

2.50

0.32

Fuente: (Boehm, 1981) Para el siguiente proyecto se utilizará el modo orgánico, porque se tienen los requerimientos bien definidos. COCOMO está definido en términos de tres modelos diferentes: modelo básico, modelo intermedio y modelo detallado, que reflejan el nivel de detalle considerado a la hora de realizar la estimación del coste. Según la teoría, el modelo intermedio y el detallado, usan un “Factor de ajuste del esfuerzo” (EAF), cuyos valores se pueden obtener en base a la ecuación determinada para cada tipo de modelo como se puede apreciar continuación en la siguiente tabla:

145 - 162

Tabla 42: Ecuación básica del esfuerzo en COCOMO (Modelo intermedio y Detallado).

MODO DE DESARROLLO

ECUACIÓN BÁSICA

ORGÁNICO

𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 = 𝐸𝐴𝐹 ∗ 3,2 ∗ 𝐾𝑆𝐿𝑂𝐶 1,05

SEMIACOPLADO

𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 = 𝐸𝐴𝐹 ∗ 3.0 ∗ 𝐾𝑆𝐿𝑂𝐶 1,12

EMPOTRADO

𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 = 𝐸𝐴𝐹 ∗ 3.8 ∗ 𝐾𝑆𝐿𝑂𝐶 1.2

Fuente: (Boehm, 1981) Para determinar el tiempo de desarrollo se tiene: Tabla 43: Ecuación básica del tiempo en COCOMO (Modelo intermedio). MODO DE DESARROLLO

ECUACIÓN BÁSICA

ORGÁNICO

𝑇𝑖𝑒𝑚𝑝𝑜 𝐷𝑒𝑠𝑎𝑟𝑟𝑜𝑙𝑙𝑎𝑑𝑜 = 2,5 ∗ 𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜0,38

SEMIACOPLADO

𝑇𝑖𝑒𝑚𝑝𝑜 𝐷𝑒𝑠𝑎𝑟𝑟𝑜𝑙𝑙𝑎𝑑𝑜 = 2,5 ∗ 𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜0,32

EMPOTRADO

𝑇𝑖𝑒𝑚𝑝𝑜 𝐷𝑒𝑠𝑎𝑟𝑟𝑜𝑙𝑙𝑎𝑑𝑜 = 2,5 ∗ 𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜0,35

Fuente: (Boehm, 1981) La ecuación del esfuerzo y del tiempo de Desarrollo que se utilizarán será para el Modelo de desarrollo Orgánico, a continuación se describen las variables y sus unidades.

146 - 162

𝐸 = 𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 𝑒𝑛 𝑢𝑛𝑖𝑑𝑎𝑑𝑒𝑠 𝑑𝑒 [

𝑃𝑒𝑟𝑠𝑜𝑛𝑎 ] 𝑚𝑒𝑠

𝐾𝑆𝐿𝑂𝐶 = 𝐾𝑖𝑙𝑜𝑙í𝑛𝑒𝑎𝑠 𝑜 𝑀𝑖𝑙𝑒𝑠 𝑑𝑒 𝑙í𝑛𝑒𝑎 𝑑𝑒 𝑐𝑜𝑑𝑖𝑔𝑜 𝑓𝑢𝑒𝑛𝑡𝑒 𝐸𝐴𝐹 = 𝑀𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑐𝑖𝑜𝑚𝑛 𝑑𝑒 15 𝑓𝑎𝑐𝑡𝑜𝑟𝑒𝑠 𝑑𝑒 𝑐𝑜𝑠𝑜 𝑇 = 𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑑𝑢𝑟𝑎𝑐𝑖𝑜𝑛 𝑑𝑒𝑙 𝑑𝑒𝑠𝑎𝑟𝑟𝑜𝑙𝑙𝑜 𝑒𝑛 𝑢𝑛𝑖𝑑𝑎𝑑𝑒𝑠 𝑑𝑒 [𝑚𝑒𝑠𝑒𝑠] Para determinar el valor del factor de ajuste del Esfuerzo se emplea el producto de 15 factores de costo, que determinan la duración y el coste del proyecto, a continuación se pueden apreciar los valores seleccionados para cada factor: Tabla 44: Factores de Costo en COCOMO Conductores del coste CUALIDADES DE PRODUCTO Fiabilidad requerida del software Tamaño de la base de datos del uso Complejidad del producto CUALIDADES DEL HARDWARE Restricciones del tiempo de ejecución Restricciones del almacenamiento principal Volatilidad del ambiente virtual de la máquina Tiempo de respuesta de ordenador

Grados Medio Alto

Muy bajo

Bajo

0.75

0.88

1.00

0.94 0.85

-

0.70

Muy alto

Extra altor

1.15

1.40

-

1.00

1.08

1.16

-

1.00

1.15

1.30

1.65

-

-

1.00

1.11

1.30

1.66

-

-

1.00

1.06

1.21

1.56

-

0.87

1.00

1.15

1.30

-

-

0.87

1.00

1.07

1.15

-

147 - 162

Conductores del coste CUALIDADES DEL PERSONAL Capacidad del analista Experiencia de los usos Capacidad de los programadores Experiencia en sistema operativo utilizado Experiencia del lenguaje de programación CUALIDADES DEL PROYECTO Uso de las herramientas del software Uso de los métodos de la tecnología de dotación lógica Horario requerido del desarrollo

Grados Medio Alto

Muy bajo

Bajo

Muy alto

Extra altor

1.46

1.19

1.00

0.86

0.71

-

1.29

1.13

1.00

0.91

0.82

-

1.42

1.17

1.00

0.86

0.70

-

1.21

1.10

1.00

0.90

-

-

1.14

1.07

1.00

0.95

-

-

1.24

1.10

1.00

0.91

0.82

-

1.24

1.10

1.00

0.91

0.83

-

1.23

1.08

1.00

1.04

1.10

-

Fuente: (Boehm, 1981) La justificación de la selección de los factores de costo se puede encontrar en la tabla del Anexo F En la tabla descrita anteriormente de factores de costo de COCOMO se ha seleccionado los valores para cada uno de los factores de costos los cuales se multiplicarán y se obtendrán el valor del EAF. 𝐸𝐴𝐹 = 1.15 ∗ 1.00 ∗ 0.85 ∗ − ∗ − ∗ 0.87 ∗ 1.00 ∗ 1.00 ∗ 1.00 ∗ 1.00 ∗ 1.00 ∗ 1.07 ∗ 1.10 ∗ 0.91 ∗ 1.00 148 - 162

𝐸𝐴𝐹 = 0.910 Para determinar la cantidad total de líneas de código fuente se ha contado las líneas de cada clase de la arquitectura MVC, para lo cual se utiliza la herramienta Code Line Counter Pro Versión 6.5.

Archivo

MODELO

SLOC

(Clases

de

723

cada tabla de la base de datos)

VISTA

(Dentro

de

la

2104

carpeta vista se crean las carpetas para cada controlador.)

CONTROLADOR (Clases

3025

de cada modelo)

TOTAL

5852

Para determinar el valor de la variable KSLOC se van a usar unidades de SLOC (líneas de código fuente), con las siguientes restricciones. Sumar las líneas de código creadas por el personal del proyecto. Se considera que una instrucción es una línea de código. Las declaraciones se toman como instrucciones. Los comentarios no se cuentan como instrucciones. Se determina que: 149 - 162

𝑆𝐿𝑂𝐶 = 5852 𝐾𝑆𝐿𝑂𝐶 =

𝑆𝐿𝑂𝐶 1000

𝐾𝑆𝐿𝑂𝐶 = 5,852 Una vez encontrado los valores de EAF y KSLOC, se procede a calcular el esfuerzo: 𝐸 = 𝐸𝐴𝐹 ∗ 3,2 ∗ 𝐾𝑆𝐿𝑂𝐶 1,05 𝐸 = 0,910 ∗ 3,2 ∗ 5,8521,05 𝐸 = 16,4056 [

𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑠 ] 𝑚𝑒𝑠

Obteniendo el valor del esfuerzo se procede a calcular el tiempo de desarrollo: 𝑇 = 2,5 ∗ 𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 0,38 𝑇 = 2,5 ∗ 16,40560,38 𝑇 = 7,2383[𝑚𝑒𝑠𝑒𝑠] Ahora se procede a calcular el “Personal promedio” requerido para desarrollar el proyecto: 𝑃𝑒𝑟𝑠𝑜𝑛𝑎𝑙 =

𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑑𝑒𝑠𝑎𝑟𝑟𝑜𝑙𝑙𝑜

𝑃𝑒𝑟𝑠𝑜𝑛𝑎𝑙 =

16,4056 7,2373

𝑃𝑒𝑟𝑠𝑜𝑛𝑎𝑙 = 2,2664 [𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑠] Ahora se calcula la productividad: 𝑃𝑅 =

𝑆𝐿𝑂𝐶 𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜

150 - 162

𝑃𝑅 =

7283 16,4056

𝑃𝑅 = 356.7074 [

𝑆𝐿𝑂𝐶 ∗ 𝑚𝑒𝑠] 𝑃𝑒𝑟𝑠𝑜𝑛𝑎

Obteniendo los resultados anteriores se determina que para el proyecto se han escrito 5852 líneas de código, lo que se traducen en un esfuerzo de 16 personas por mes, el proyecto se desarrolla en 7 meses y lo ideal para desarrollar el proyecto es contar con 2 programadores. Pero la situación en éste caso, el proyecto ha sido desarrollado por una sola persona. Se ha considerado el trabajo en días laborales de lunes a sábado, 2 horas al día, lo que supone unas 40 horas al mes. Y según el tiempo estimado multiplicado por la cantidad de horas al mes, se obtiene un total de 289,532 horas. 2[

ℎ𝑜𝑟𝑎𝑠 ℎ𝑜𝑟𝑎𝑠 ] → 40 [ ] 𝑑í𝑎 𝑚𝑒𝑠

𝑇𝑜𝑡𝑎𝑙 ℎ𝑜𝑟𝑎𝑠 𝑑𝑒 𝑡𝑟𝑎𝑏𝑎𝑗𝑜 = 40 ∗ 7,2383 𝑇𝑜𝑡𝑎𝑙 ℎ𝑜𝑟𝑎𝑠 𝑑𝑒 𝑡𝑟𝑎𝑏𝑎𝑗𝑜 = 289532 [ℎ𝑜𝑟𝑎𝑠] Para determinar una aproximación del costo de desarrollo del proyecto se ha averiguado que el sueldo para el área de programación en Bolivia oscila entre los valores de Bs. 30 a Bs. 40 por lo tanto se toma en cuenta el costo mínimo Bs. 30 por hora promedio. Por tanto ajustando el horario de trabajo del autor del proyecto (2 horas al día), y considerando el pago por hora de Bs. 35 se procede a calcular el costo estimado del proyecto, multiplicando la cantidad de horas a trabajar en el lapso de tiempo estimado por el pago por hora determinado según el horario: 289,532[ℎ𝑜𝑟𝑎𝑠] ∗ 35 [

𝐵𝑠 ] = 10.133,62[𝐵𝑠. ] ℎ𝑜𝑟𝑎

Obteniendo el resultado de la ecuación se determina que el costo estimado del proyecto es de Bs. 10.133,62 (Pesos Bolivianos). 151 - 162

Finalmente se puede indicar que los costos totales mínimos e ideales son: Tabla 45: Costos totales mínimos e ideales COSTO MÍNIMO Bs.

COSTO IDEAL

2150

4020

300

1750

10.133,62

10.133,62

Costo de hardware y software del servidor Costo de hardware y software del cliente móvil Costo desarrollo del proyecto TOTAL

Bs 12.583,62.-

Bs 15903.62.-

Fuente: Elaboración propia De esta manera, se ha empleado el método de estimación de costos COCOMO, calculando los valores para medir el esfuerzo (E), cantidad de líneas de código (KSLOC), el ajuste de los factores de esfuerzo (EAF) y el tiempo para el desarrollo del proyecto, determinando así que el costo mínimo de desarrollo del proyecto es de Bs 12583,62 y el costo ideal es de Bs 15903,62 considerando que el proyecto ha sido desarrollado por una persona. 4.2.3. Análisis de beneficio costo A continuación de determina el análisis Beneficio/costo detalladamente, para desarrollar el análisis se realiza una tabla en el cual de describen los costos con sistema, y los costos sin sistemas. Tabla 46: Costo con sistema y sin sistema DESCRIPCIÓN

Costo en material de escritorio.

MONTO SIN SISTEMA

MONTO CON SISTEMA

372 Bs.-

0,00 Bs.-

152 - 162

DESCRIPCIÓN

MONTO SIN SISTEMA

MONTO CON SISTEMA

1440 Bs.-

0,00 Bs.-

7200 Bs.-

2400 bs.-

Costo de llamadas para la comunicación entre usuarios Costo del tiempo invertido el proceso de elaboración de reportes TOTAL

Bs.-12312

Bs.-3550

Fuente: Elaboración propia Para el cálculo de la estimación Beneficio/Costo se tiene: Si B/C > 1  el proyecto es viable económicamente ya que los beneficios superan a los costos. Si B/C < 1  el proyecto no es viable económicamente ya que los beneficios son superados Para el cálculo de la estimación Beneficio/Costo se tiene: 𝑌𝑛 (1 + 𝑖)𝑛 𝐵/𝐶 = 𝐶𝑛 𝐼0 + ∑𝑛𝑛=1 (1 + 𝑖)𝑛 ∑𝑛𝑛=1

𝑌 = 𝐵𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑜 𝑛𝑒𝑡𝑜 𝐶𝑛 = 𝐶𝑜𝑠𝑡𝑜𝑠 𝑒𝑛 𝑐𝑎𝑑𝑎 𝑝𝑒𝑟𝑖𝑜𝑑𝑜 𝑛 = 𝑡𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑣𝑖𝑑𝑎 𝑑𝑒 𝑑𝑢𝑟𝑎𝑐𝑖ó𝑛 𝑑𝑒𝑙 𝑝𝑟𝑜𝑦𝑒𝑐𝑡𝑜 𝑖 = 𝑇𝑎𝑠𝑎 𝑑𝑒 𝑖𝑛𝑡𝑒𝑟é𝑠 2.31%

Basado en el Banco Nacional de Bolivia (BNB)

Alcance temporal = 5 años

153 - 162

8762 8762 8762 8762 8762 + 2 + (1 + 0,0231)3 + (1 + 0,0231)4 + (1 + 0,0231)5 (1 + 0,0231) (1 + 0,0231) 𝐵⁄ = 𝐶 3550 3550 3550 3550 3550 14381,84 + ( + + + + ) 1 + 0,0231 (1 + 0,0231)2 (1 + 0,0231)3 (1 + 0,0231)4 (1 + 0,0231)5

40930.35 𝐵⁄ = 𝐶 14381.84 + 16583.28 𝐵⁄ = 1.32 𝐶 Al obtener el resultado mayor a 1 se puede concluir que los beneficios que se obtienen con la implantación del proyecto son justificables respecto al costo invertido para su desarrollo del sistema. Por lo tanto el proyecto es económicamente viable.

4.3. VIABILIDAD OPERATIVA. El proceso actual de administración de pedidos y compras se realiza de forma manual, esto puede generar perdida de tiempo y errores de registro de pedidos por no tener la información de manera oportuna. Una vez implementado la aplicación móvil Android será capaz de obtener información de datos actuales sobre los productos necesarios para el abastecimiento de la empresa por medio de un servidor que permitirá al dueño llevar un registro controlado mediante un diseño de interfaces amigables para los distintos tipos de usuarios. El nivel de complejidad en base a las funcionalidades que se realizan en el uso del sistema, se detallan en el siguiente orden: Tabla 47: Nivel de complejidad según funciones de cargo CARGO

NIVEL DE COMPLEJIDAD

Administrador

Alto

Chef

Medio

Encargado de compras

Bajo

154 - 162

Fuente: Elaboración propia Para el uso de la aplicación móvil se tienen los siguientes roles: Administrador, vendedor por mayor. Administrador: El administrador es el dueño de la empresa, el tiene la ponderación de realizar todas las tareas en cuanto al control de stock, gestión de usuarios, registrar productos, tiene que estar al tanto de toda la información y los procesos que se realizan. Chef: El chef es el encargado de realizar los pedidos y registrar el menú diario de acuerdo a la solicitud de la empresa que está a cargo. Encargado de compras: El encargado de compras es el tercer involucrado en el sistema quien debe realizar las compras de los ingredientes solicitados por el chef y también podrá registrar las compras realizadas.

155 - 162

ESCUELA MILITAR DE INGENIERÍA MCAL. ANTONIO JOSÉ DE SUCRE BOLIVIA

CAPÍTULO 5 CONCLUSIONES Y RECOMENDACIONES.

5. CONCLUSIONES Y RECOMENDACIONES. A continuación se describen conclusiones y recomendaciones acerca del sistema de gestión de abastecimiento y servicio de catering integrado con una aplicación móvil Android.

5.1. CONCLUSIONES A continuación se detallarán las conclusiones que se obtuvieron en base al proyecto terminado: 

Para iniciar el desarrollo del proyecto ha sido necesario elaborar el modelo del negocio actual, a través de una serie de entrevistas al administrador de la empresa servicios de catering VALENCIA. Estas actividades han permitido elaborar flujos de trabajo que representan de manera detallada las actividades que implica el proceso de gestión de abastecimiento, pedido y compras de productos para el servicio de catering lo cual llevo a la comprensión de la lógica de negocio y la identificación de los aspectos que pueden mejorar el uso de la tecnología y respectivo desarrollo del sistema.



Con el diseño del modelado de negocio alternativo se logro elaborar la propuesta de una nueva lógica de negocio en la cual los procedimientos están basados en la utilización de la aplicación móvil, permitiendo de esta manera solucionar los problemas que actualmente enfrenta la empresa e identificar las funcionalidades principales que debe tener el sistema propuesto.



El desarrollo del módulo de gestión de usuarios para el personal de la empresa permite la introducción y almacenamiento de información básica requerida de cada involucrado en el proceso de trabajo que realiza la empresa así mismo asigna a cada participante la labor que debe desempeñar dentro la empresa servicios de catering VALENCIA.



Se desarrolló un módulo de control de stock para el usuario el cual permite de manera fácil interactuar con una interfaz amigable, donde se llena un formulario con los datos del producto que ingresa a la bodega y así llevar a cabo el control 156 - 162

de productos automatizado dando a conocer el stock de ingredientes existentes de diferentes tipos. 

La implementación del módulo de servicios de catering permite tener un registro de todos lo productos que ofrece la empresa y así facilitar el proceso para los pedidos que se registran diariamente. Estas funcionalidades se presentan de manera interactiva y mas atractiva al alcance de cualquier móvil de los empleados de la empresa.



Se desarrolló un módulo de gestión de abastecimiento el cual permite registrar la cantidad de personas que requieren el servicio y así automatizar el total de ingredientes que se requieren para facilitar la elaboración de productos del menú diario y facilitar una lista de ingredientes al encargado de compras quien deberá cumplir su labor de adquirir todos y cada uno de los ingredientes faltantes.



Para lograr la conectividad entre el servicio Web y la aplicación móvil se decidió utilizar los servicios REST API e intercambio de datos aplicando JSON que reducen el tiempo de intercambio de datos y sincronización entre ambos.



Finalmente se han realizado pruebas con usuarios finales verificando que el sistema concluye con los requisitos solicitados por el administrador y dueño de la empresa

Con la hipótesis planteada en el proyecto se ha demostrado que los beneficios principales del sistema desarrollado están relacionados con las disminución de tiempo invertido en el proceso de organización del servicio de catering para las empresas disminuyendo la probabilidad del riesgo de errores en la información al registrar la lista de ingredientes que se deben comprar, por lo cual se concluye que la aplicación puesta en marcha permitirá a la empresa reemplazar procedimientos manuales y llegar a un proceso mas eficiente. Finalmente se concluye que se logró alcanzar los objetivos establecidos al desarrollar un Sistema de gestión de abastecimiento de productos y servicios de catering integrado con una aplicación móvil Android, logrando obtener información confiable y rápida, reduciendo el tiempo invertido en el proceso de elaboración de pedidos y

157 - 162

compra de ingredientes y disminuyendo los errores en la elaboración de listas de productos y gastos económicos por este motivo.

5.2. RECOMENDACIONES Las recomendaciones de funcionamiento son: 

Para un buen funcionamiento del sistema se recomienda cumplir con los requerimientos mínimos de hardware establecidos en la viabilidad técnica.



Se recomienda la capacitación previa a la implantación del sistema en la empresa, considerando los actores involucrados en la empresa, de esta manera reducir los errores humanos que se puedan cometer.

Las recomendaciones a futuro son: 

Se recomienda implementar una página web para los clientes, donde se pueda promocionar productos, compartir los servicios que brinda la empresa y todas las características de la empresa para permitir llegar a mayor cantidad de clientes.



Desarrollar un modulo para clientes que quieran adquirir el servicio de catering y puedan realizar sus pedidos, evitando que los trabajadores hagan visitas constantes.

158 - 162

BIBLIOGRAFÍA 

Alonso, G. (2004). Web Services Concepts, Architectures and Applications. Springer.



AndroidGuys. (2009). Appcelerator, un nuevo concepto « iSuriv's Weblog – Dame Tonos - Telefonía Móvil en su más puro estado. Retrieved from https://isuriv.wordpress.com/2009/06/15/appcelerator-un-nuevo-concepto/



Angela, M. (n.d.). GForce Softwar. Retrieved from https://forja.linex.org/docman/view.php/121/1052/ASI_10.odt.



Chaffer, J., & Swedberg, K. (2007). Aprender jQuery.



Compilando.ES. (2011). Modelo-Vista-Controlador. Retrieved from http://www.compilando.es/



Davis, B., & Steven, D. (2002). Benefits Thin client-Smart client. Newburn.



Ducrohet. (2013). Android Studio: Un IDE incorporado para Android. Retrieved from http://android-developers.blogspot.com/2013/05/android-studio-ide-built-forandroid.html.



Fowler, M., & Kendall, S. (1999). UML gota a gota. Mexico: Person Educacion.



Friesen. (2010). Java para desarrollo Android. Retrieved from https://www.java.com/es/download/faq/develop



Gironés, J. T. (2013). El gran libro de Android. marcombo, S.A.



Gutierrez, D. (2011). Métodos de desarrollo de software. Venezuela: Universidad de los Andes.



Gutiérrez, G. J. (2010). My Structured Query Language. Retrieved from http://dev.mysql.com/doc

159 - 162



Kniberg, H. (2007). Scrum y XP desde las trincheras. Estados Unidos de America: C4Media Inc.



Manilla Derbez, J. A., & Torres Villafaña, H. (2009). Ingeniería en sistemas computacionales. Instituto Tecnológico de Toluca.



Marin, d. l. (2014). Phonegap y Titanium Appcelerator. Retrieved from http://www.marindelafuente.com.ar/phonegap-y-titanium-appcelerator/



Martínez, H. L., Ceceñas, T. P., & Leyva, A. M. (2015). Lo que se de computación. México : Universidad Juárez del Estado de Durango.



MINGUET, M. J. (2008). nformática Fundamental. Ramón Areces.



Morales, U. A. (2010). Sql, server. Retrieved from http://www.uaem.mx/posgrado/mcruz/cursos/miic/sql.pdf



Naresh, A., & Toral, M. (2002). UDDI: Building Registry-based Web Services Solutions. Retrieved from http://uddi.xml.org/.



Newman, C. (2009). SQLite. Universidad de California: Sams, 2005.



Núñez Mori, J. G. (2010). Usabilidad en metodologías agiles. España: Universidad Politécnica de Madrid.



Páez, N. (2014). Construcción de software: una mirada ágil. Retrieved from http://dominointernet.com/el-manifiesto-agile/



Perdita Stevens, R. P. (2002). Utilización de UML en Ingeniería del Software con Objetos y Componentes.



Petkovic, D. (2008). MICROSOFT SQL SERVER. Germany: Mcgraw-hill.



Pressman, R. (2005). Ingeniería de Software: Un Enfoque Práctico (Sexta ed.). McGraw-Hill.

160 - 162



Pressman, R. (2010). Ingeniería de Software: Un Enfoque Práctico (Séptima ed.). McGraw-Hill.



Pressman, R. (2010). Ingeniería de Software: Un Enfoque Práctico (Séptima ed.). McGraw-Hill.



Rehman, Paul, C., & Paul., C. R. (2002). The Linux Development Platform: Configuring, Using and Maintaining a Complete Programming Environment.



Revelo, J. (2015). Desarrollo Android. Retrieved from http://www.hermosaprogramacion.com/2015/10/servicio-web-restful-android-phpmysql-json/



Ribas, L. J. (2011). Desarrollo de aplicaciones para Android. En J. R. Lequerica.



Rodríguez, A. (2009). ENTORNO DE DESARROLLO (IDE) JAVA. Retrieved from http://www.aprenderaprogramar.com/index.php?option=com_attachments&task= download&id=345



Rómmel, F. (2007). Base de Datos SQLite. Retrieved from http://sg.com.mx/revista/17/sqlite-la-base-datos-embebida#.VD27zfmG8T8



Sacristán, C. R., & Fernández, D. R. (2012). Programación en Android. España: Mentor.



Scientia, e. T. (2007). Universidad Tecnológica de Pereira. ISSN 0122-1701.



Scott, K., & Rosenberg, D. (2001). ICONIX Software Engineering.



Shafer, D. (2003). Revolución : Software a la velocidad del pensamiento. Tiempo de ejecución revolución Ltd, Volumen 1.



Shane Conder, L. D. (2012). Android Wireless Application Development. Retrieved from http://www.4rsoluciones.com/que-es-un-kit-de-desarrollo-desoftware-sdk/ 161 - 162



Sommerville, I. (2005). Ingeniería de Software. Madrid, España: Pearson Educación S.A.



Sommerville, I. (2011). Ingeniería de Software. (novena edición). México: Pearson Educación S.A.



Sosinformatico. (2012). Desarrollo y Programación. Retrieved from http://www.sosinformatico.tk



Tairon. (2012). NetBeans. Retrieved from http://netbeansaccesible.blogspot.com/.



Torres, M. &. (2009).



Warnnez. (2013). Ide Android Studio. Retrieved from http://androcode.es/2013/05/android-studio-el-nuevo-ide-para-android/.



Zamora, A. (2015). Android libre. Retrieved from http://www.elandroidelibre.com/2015/10/los-mejores-frameworks-paradesarrolladores-android.html

162 - 162

ANEXOS

ANEXO A: Servicio de Catering

ANEXO B: Licitación del Servicio de Catering

ANEXO C: Entrevista al gerente de la empresa

ANEXO D: Diagrama Ishikawa.

Proceso manual de registro de productos.

Registro manual de empresas que solicitan Servicio de Catering.

Ilegibilidad.

Ilegibilidad. Proceso moroso en la toma de datos.

Revisión de compras realizadas.

La verificación de productos es moroso.

Demora en la toma de datos.

Revisión de productos faltantes. Registro de cantidad de productos incorrecto.

Elaboración de una sola lista común.

Lista de productos puede contener errores.

Tareas repetitivas de confección de listas diarias de productos faltantes, pérdida de tiempo en la revisión de los pedidos realizados por las empresas para determinar los productos que deben abastecerse y gastos innecesarios en la adquisición de productos que se tienen disponibles.

ANEXO E: Conformidad y aceptación de interfaces

Anexo F: Tabla de justificaciones Factores de costo

Valor escogido

Justificacion

Fiabilidad requerida del software

alto

El software maneja varios datos los cuales deben ser fiables y disponibles para su correcto funcionamiento.

Tamaño de la base de datos del uso

medio

Es medio porque la empresa aún no cuenta con una gran cantidad de datos ya que trabaja con pocas empresas.

Complejidad del producto

bajo

Es bajo dado que el proyecto no demanda procesos complejos o de seguridad de datos.

Restricciones del tiempo de ejecución

bajo

No se tiene tiempo de restricción de tiempo de ejecución.

Restricciones del almacenamiento principal

bajo

Se toma bajo dado que no se tiene restricciones de almacenamiento.

Volatilidad del ambiente virtual de la máquina

bajo

Esta característica no se aplica al proyecto pero como es requerida para los cálculos se toma bajo.

Tiempo de respuesta de ordenador

medio

No se tiene una exigencia de tiempo de respuesta rápida, sin embargo eso no quiere decir que no importe.

Capacidad del analista

medio

La capacidad del analista es medio dado que no tiene mucha experiencia en trabajos similares.

Experiencia de los usos

medio

La experiencia en aplicaciones es media dado que el desarrollador tiene conocimientos medios sobre aplicaciones.

Capacidad de los programadores

medio

Es bajo dado que es la primera vez que el desarrollador realiza un proyecto con aplicación móvil y de esa magnitud.

Experiencia en sistema operativo utilizado

medio

Es alto dado que el sistema operático se usa a diario.

Experiencia del lenguaje de programación

bajo

Es medio ya que el desarrollador tiene conocimientos básicos acerca de los lenguajes de programación.

Uso de las herramientas del software

bajo

Es baja dado que se utiliza herramientas de programación modernas de los cuales no se tenía experiencia.

Uso de los métodos de la tecnología de dotación lógica

alto

Se tenia base acerca de la utilización de herramientas de software por lo tanto es alto.

Horario requerido del desarrollo

medio

Es medio dado que si fuera bajo, se cumpliría con la planificación de desarrollo para el proyecto sin exigencia del cliente, por otro si el cliente exigiera su propia planificación.