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
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
i
Í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
ii 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
iii
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
iv 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
v
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
vi
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
vii
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
viii
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
ix
Í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
x
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
xi
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
xii
Í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
xiii
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
xiv
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
xv
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
ESCUELA MILITAR DE INGENIERÍA MCAL. ANTONIO JOSÉ DE SUCRE BOLIVIA
CAPÍTULO 1
1 - 162
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
2 - 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,
3 - 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
4 - 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.
5 - 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.
6 - 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 modelado de
negocio actual para el abastecimiento de productos
Analizar el modelado del negocio.
Realizar entrevistas con el involucrado principal. Analizar la información obtenida.
Diseñar el negocio del modelo actual.
Identificar las deficiencias del proceso actual.
Diseñar el modelo de negocio
propuesto para el abastecimiento de
Elaborar el modelado del negocio alternativo que se 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
7 - 162
OBJETIVOS
ESPECÍFICOS ACCIONES
productos modelo de software seleccionado.
Desarrollar módulo de gestión de usuarios.
Seleccionar lenguaje de programación. Realizar tabla de requerimientos. Identificar tipos de actores.
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 gestión de cuentas de usuario. Realizar pruebas al módulo de usuarios.
Desarrollar módulo de control de stock de productos.
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 módulo de Servicios de Catering.
Realizar tabla de requerimientos.
Diseñar las interfaces para el módulo de Servicios de Catering
Desarrollar la aplicación móvil Android para la
Realizar análisis de requerimientos. Identificar tipos de usuario.
8 - 162 OBJETIVOS ESPECÍFICOS ACCIONES gestión de abastecimiento de productos.
robustez y diagramas de secuencia.
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.
Realizar pruebas de funcionamiento. Sincronización de la aplicación cliente con la aplicación servidor haciendo uso de Data Storage en la nube.
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.
Realizar pruebas del sistema terminado.
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.
9 - 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”.
10 - 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.
11 - 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
VARIABLE
DIMENSIÓN
INDICADOR
Variable Independiente El sistema de gestión de
abastecimientos de productos y servicios de catering integrado con una aplicación
móvil Android.
Sistema implementado y
probado
Comparación de beneficios obtenidos sin el
uso del sistema y con el uso del sistema.
Variables dependientes Errores en la elaboración de la
lista de productos que se deben comprar.
12 - 162
VARIABLE
DIMENSIÓN
INDICADOR
Variable dependiente Tiempo en la organización del
Servicio de Catering para las empresas.
Tiempo requerido para optimizar la entrega en base a los
pedidos registrados.
Tiempo
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
ESCUELA MILITAR DE INGENIERÍA MCAL. ANTONIO JOSÉ DE SUCRE BOLIVIA
CAPÍTULO 2
13 - 162
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.
14 - 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.
15 - 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)
16 - 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-Vista-Controlador) 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)
17 - 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.
18 - 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
19 - 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)
20 - 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
21 - 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:
1RUP, 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.
22 - 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
23 - 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.
24 - 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.
25 - 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.
26 - 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)
27 - 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.
28 - 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.
29 - 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
30 - 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
31 - 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
32 - 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
33 - 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
34 - 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)
35 - 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 Base de datos
