Borrador Final Después de La Defensa

ESCUELA MILITAR DE INGENIERA
MCAL. ANTONIO JOS DE SUCRE

BOLIVIA
TRABAJO DE GRADO
BORRADOR FINAL
SISTEMA DE GESTIN DE ABASTECIMIENTO DE PRODUCTOS Y

SERVICIOS DE CATERING INTEGRADO CON UNA APLICACIN
MOVIL ANDROID.
CASO DE ESTUDIO: SERVICIOS DE CATERING VALENCIA
GIOVANA EDITH YUJRA NINA
COCHABAMBA, 2016.
BOLIVIA
TRABAJO DE GRADO
BORRADOR FINAL
SISTEMA DE GESTIN DE ABASTECIMIENTO DE PRODUCTOS Y

SERVICIOS DE CATERING INTEGRADO CON UNA APLICACIN
MOVIL ANDROID.
CASO DE ESTUDIO: SERVICIOS DE CATERING VALENCIA
GIOVANA EDITH YUJRA NINA
Modalidad: Proyecto de Grado,

presentado como requisito parcial
para optar al ttulo de Licenciado en
Ingeniera de Sistemas
TUTOR: ING. JHOMIL ZAMBRANA BURGOS
COCHABAMBA, 2016.
NDICE DE CONTENIDO
1. GENERALIDADES. ...................................................................................... 1
1.1. INTRODUCCIN. ......................................................................................... 1
1.3.1. Identificacin del problema. .......................................................................... 4
1.3.1.1. Identificacin de la situacin problemtica. .................................................. 4
1.3.1.2. Identificacin de las causas. ......................................................................... 5
1.3.2. Formulacin del problema. ........................................................................... 5
1.3.3. Anlisis causa efecto. ................................................................................... 5
1.4. OBJETIVOS Y ACCIONES. ......................................................................... 5
1.4.1. Objetivo general. .......................................................................................... 5
1.4.2. Objetivo especficos y Acciones. .................................................................. 6
1.5. JUSTIFICACIN. ......................................................................................... 8
1.5.1. Justificacin tcnica. ..................................................................................... 9
1.5.2. Justificacin econmica. ............................................................................... 9
1.5.3. Justificacin operativa. ................................................................................. 9
1.6. ALCANCE..................................................................................................... 9
1.6.1. Alcance Temtico. ........................................................................................ 9
1.6.2. Alcance Institucional. .................................................................................... 9
1.6.3. Alcance temporal. ....................................................................................... 10
1.7. HIPTESIS. ............................................................................................... 10
i
1.7.1. Anlisis de variables. .................................................................................. 10
1.7.2. Definicin conceptual. ................................................................................ 10
1.7.3. Operativizacin de variables....................................................................... 11
1.8. MATRIZ DE CONSISTENCIA. ................................................................... 12
2. MARCO TERICO. .................................................................................... 13
2.1. TCNICAS DE RECOPILACIN DE DATOS ............................................ 13
2.1.1. Entrevistas. ................................................................................................. 13
2.1.2. Observacin. .............................................................................................. 14
2.1.3. Cuestionario. .............................................................................................. 14
2.2. INGENIERA DE SOFTWARE.................................................................... 15
2.2.1. Proceso del Software. ................................................................................ 15
2.2.2. Patrn de Arquitectura de Modelo Vista Controlador. ................................ 16
2.2.3. Metodologa de desarrollo de software. ...................................................... 18
2.2.3.1. Programacin 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 metodologas .................................. 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 Mvil. ................................................................................ 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. TECNOLOGAS DE DESARROLLO DE APLICACIONES MVILES ........ 45
2.5.1. APLICACIN MVIL .................................................................................. 45
2.5.1.1. Aplicaciones mviles nativas ...................................................................... 46
2.5.1.2. Aplicaciones mviles web ........................................................................... 48
2.5.1.3. Aplicaciones mviles 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 programacin ....................................................................... 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 Descripcin 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 Gestin de Base de Datos ........................................... 77
2.5.9 Herramientas de gestin............................................................................. 79
2.5.9.1. Google App Engine .................................................................................... 79
2.5.9.2. Cloud computing......................................................................................... 82
iv
3. MARCO PRCTICO. .................................................................................. 77
3.1. DISEO DEL MODELADO DE NEGOCIO ACTUAL PARA EL

ABASTECIMIENTO DE PRODUCTOS. ..................................................... 77
3.1.3. Identificar las deficiencias del proceso actual. ............................................ 79
3.2. DISEAR EL MODELO DE NEGOCIO PROPUESTO PARA EL

ABASTECIMIENTO DE PRODUCTOS ...................................................... 79
3.2.1. Elaboracin del modelado del negocio alternativo basado en el sistema

propuesto.................................................................................................... 79
3.2.2. Seleccin de la metodologa de desarrollo de software. ............................ 80
3.2.3. Planificar el proyecto segn el flujo de trabajo de modelo de software

seleccionado............................................................................................... 82
3.3. DESARROLLAR EL MDULO DE GESTIN DE DISTINTOS TIPOS DE

USUARIOS. ................................................................................................ 84
3.3.1. Seleccionar lenguaje de programacin ...................................................... 84
3.3.2. Requerimientos de gestin de distintos tipos de usuarios. ......................... 86
3.3.3. Identificacin de actores de gestin 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 gestin de distintos tipos de usuarios. ............... 94
3.3.6. Modelado del dominio, incremento de diagrama de dominio, culminacin de

diagrama de dominio. ................................................................................. 96
v
3.3.7. Codificar el mdulo de gestin de cuentas de usuario. .............................. 97
3.3.8. Realizar pruebas al mdulo de usuarios .................................................. 100
3.4. DESARROLLAR EL MDULO DE CONTROL DE STOCK DE

PRODUCTOS........................................................................................... 101
3.4.1. Requerimientos. ....................................................................................... 102
3.4.2. Identificar actores involucrados en el mdulo. .......................................... 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. Disear el modelo del dominio. ................................................................ 105
3.4.6. Codificar el mdulo de control de stock de productos. ............................. 105
3.4.7. Realizar pruebas al mdulo. ..................................................................... 107
3.5. IMPLEMENTAR EL MDULO DE SERVICIOS DE CATERING. ............. 107
3.5.1. Tabla de requerimientos. .......................................................................... 107
3.5.2. Identificar tipos de usuario. ....................................................................... 108
3.5.3. Disear los diagramas de casos de uso ................................................... 108
3.5.4. Diagramas de robustez ............................................................................ 110
3.5.5. Disear el modelo del dominio, incremento de diagrama de dominio,

culminacin de diagrama de dominio. ...................................................... 111
3.5.6. Codificar el mdulo de Servicios de catering ............................................ 112
3.5.7. Realizar pruebas de funcionamiento. ....................................................... 114
3.6. DESARROLLAR LA APLICACIN MVIL ANDROID PARA LA GESTIN
vi
DE ABASTECIMIENTO DE PRODUCTOS. ............................................. 114
3.6.1. Realizar anlisis de requerimientos. ......................................................... 114
3.6.2. Identificar tipos de usuario. ....................................................................... 115
3.6.3. Disear los diagramas de casos de uso ................................................... 115
3.6.4. Diagramas de robustez ............................................................................ 119

culminacin de diagrama de dominio. ...................................................... 121
3.6.6. Implementar el mdulo para la gestin de abastecimiento de productos. 122
3.6.7. Realizar pruebas de funcionamiento. ....................................................... 124
3.7. SINCRONIZACIN DE LA APLICACIN CLIENTE CON LA APLICACIN

SERVIDOR HACIENDO USO DE DATA STORAGE EN LA NUBE. ........ 125
3.7.1. Diagrama del proceso de sincronizacin. ................................................. 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 mdulos. .............................................. 127
3.8.3. Documentar las pruebas........................................................................... 130
3.9. DEMOSTRACIN DE LA HIPOTESIS. .................................................... 131
3.9.1. Demostracin de la primera variable dependiente. .................................. 132
3.9.2. Demostracin de la segunda variable. ..................................................... 133
3.9.3. Demostracin de la variable independiente. ............................................. 134
vii
4. ANLISIS DE VIABILIDAD ....................................................................... 141
4.1. VIABILIDAD TCNICA. ............................................................................ 141
4.2. VIABILIDAD ECONMICA. ...................................................................... 143
4.2.1. Costo de implementacin del proyecto. .................................................... 143
4.2.2. Costo del proyecto .................................................................................... 144
4.2.3. Anlisis de beneficio costo ....................................................................... 152
4.3. VIABILIDAD OPERATIVA. ....................................................................... 154
5. CONCLUSIONES Y RECOMENDACIONES............................................ 156
5.1. CONCLUSIONES ..................................................................................... 156
5.2. RECOMENDACIONES ............................................................................ 158
BIBLIOGRAFA ....................................................................................................... 159
ANEXOS
ANEXO A: Servicio de Catering
ANEXO B: Licitacin del Servicio de Catering
ANEXO C: Entrevista al gerente de la empresa
ANEXO D: Diagrama ISHIKAWA
ANEXO E: Conformidad y aceptacin de interfaces
ANEXO F: Justificacin de los factores de COCOMO
viii
NDICE DE TABLAS
Tabla 1: Objetivos y acciones ..................................................................................... 6
Tabla 2: Operativizacin de variables ....................................................................... 11
Tabla 3: Descripcin de las Ventajas y Desventajas de los Modelos de Desarrollo de

Software. ................................................................................................................... 81
Tabla 4: Plan de desarrollo de software segn ICONIX ........................................... 82
Tabla 5: Tabla de comparacin de lenguajes de programacin ............................... 84
Tabla 6: Tabla de requerimientos de Gestin de usuarios ....................................... 86
Tabla 7: Identificacin de usuarios de Gestin de usuarios ...................................... 87
Tabla 8: Descripcin de caso de uso de alto nivel .................................................... 89
Tabla 9: Descripcin de caso de uso expandido Registro de datos ....................... 90
Tabla 10: Descripcin de accin de actores Registro de datos .............................. 90
Tabla 11: Descripcin de caso de uso expandido Iniciar sesin ............................ 92
Tabla 12: Descripcin de accin de actores Iniciar sesin ..................................... 92
Tabla 13: Descripcin de caso de uso expandido Gestin de usuarios ................. 93
Tabla 14: Descripcin de accin de actores Gestin 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 gestin de usuarios. ..................... 101
Tabla 18: Tabla de requerimientos de control de stock de productos ..................... 102
ix
Tabla 19: Identificacin de actores involucrados en el mdulo. .............................. 102
Tabla 20: Descripcin 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: Identificacin de tipos de usuario. ........................................................... 115
Tabla 25: Descripcin de caso de uso expandido de Administrar producto ........... 109
Tabla 26: Descripcin de accin de actores de Administrar producto .................... 109
Tabla 27: Descripcin de caso de uso expandido Registrar pedido ....................... 116
Tabla 28: Descripcin de accin de actores Registrar pedido ................................ 116
Tabla 29: Descripcin de caso de uso expandido de Visualiza pedido y registra

compra .................................................................................................................... 118
Tabla 30: Descripcin de accin de actores de Visualiza pedido y registra compra118
Tabla 31: Autentificacin de usuario de usuario ..................................................... 127
Tabla 32: Registro de producto ............................................................................... 128
Tabla 33: Registro de producto............................................................................... 129
Tabla 34: Demostracin de la segunda variable dependiente ................................ 133
Tabla 35: Demostracin 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: Ecuacin bsica del esfuerzo en COCOMO (Modelo intermedio y

Detallado). ............................................................................................................... 146
Tabla 42: Ecuacin bsica del tiempo en COCOMO (Modelo intermedio). ............ 146
Tabla 43: Factores de Costo en COCOMO ............................................................ 147
Tabla 44: Costos totales mnimos e ideales ........................................................... 152
Tabla 45: Costo con sistema y sin sistema ............................................................. 152
Tabla 46: Nivel de complejidad segn funciones de cargo ..................................... 154
xi
NDICE DE FIGURAS
Figura 1: Matriz de consistencia ............................................................................... 12
Figura 2: Modelo Vista Controlador. ......................................................................... 17
Figura 3: Metodologa XP ......................................................................................... 18
Figura 4: Proceso de desarrollo incremental para ICONIX ...................................... 22
Figura 5: Fases de la metodologa 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 mvil........................................................... 35
Figura 13: Smart Client............................................................................................. 36
Figura 14: thin client. ................................................................................................ 38
Figura 15: Arquitectura de aplicacin mvil nativa ................................................... 47
Figura 16: Arquitectura de aplicacin mvil web ...................................................... 49
Figura 17: Arquitectura de aplicacin mvil 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 gestin 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 sesin ........................................................................................... 91
Figura 25: Gestin de usuarios ................................................................................ 93
Figura 26: Diagrama de robustez de registro de datos ............................................ 95
Figura 27: Diagrama de robustez de Iniciar sesin .................................................. 95
Figura 28: Diagrama de robustez de Gestin de usuarios ....................................... 96
Figura 29: Modelado del dominio ............................................................................. 96
Figura 30: Codificacin de gestin de cuentas de usuarios ..................................... 97
Figura 31: Interfaz de registro de usuario ................................................................. 98
Figura 32: Interfaz de iniciar sesin .......................................................................... 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: Diseo del dominio de control de stock. ................................................ 105
Figura 38: Codificacin 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: Diseo del dominio de la aplicacin mvil Android de gestin de

abastecimiento de productos................................................................................... 112
Figura 43: Codificacin 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

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 sincronizacin ..................................................................... 125
Figura 56: Sistema en ejecucin ............................................................................ 126
Figura 57: Conexin activa ..................................................................................... 126
xiv
Figura 58: Autentificacin de usuarios ................................................................... 130
Figura 59: Registrar un producto ............................................................................ 130
Figura 60: Registrar un pedido ............................................................................... 131
Figura 61: Campana de gauss ............................................................................... 139
xv
BOLIVIA
CAPTULO 1
GENERALIDADES.
1. GENERALIDADES.
1.1. INTRODUCCIN.
En la actualidad es de mucha importancia la sistematizacin de procesos para poder

acceder a diferente tipo de informacin, muchas empresas realizan diferentes
procesos y recoleccin de datos manualmente ya que no cuentan con un sistema que
pueda ayudar, agilizar y facilitar dicha informacin.
Las aplicaciones mviles inteligentes han ayudado a los usuarios a mantenerse

conectados a las redes sociales y cargar la informacin de manera ms rpida,
asimismo permitieron al usuario ser menos dependiente de una computadora porttil,
a su vez es importante mencionar que las aplicaciones mviles ayudan a mejorar la
comunicacin entre los diferentes niveles de administracin en una organizacin; 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 envo 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 mviles, por lo general con

pantalla tctil, de este modo, es posible encontrar tabletas (Tablet), telfonos mviles
(Smartphone) y relojes equipados con Android, aunque el software tambin se usa en
automviles, televisores y otros dispositivos electrnicos.
Es importante mencionar que gracias al desarrollo de la tecnologa, ahora es posible

contar con sistemas que facilitan el trabajo diario, los sistemas que ofrecen, trabajan
en entorno clienteservidor; permiten concentrar en el servidor tareas de
almacenamiento de datos y brindan servicios entre usuarios.
Existe una gran variedad de sistemas de gestin dentro de las empresas. Estos
sistemas son muy tiles en una empresa al manejar informacin 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 preparacin 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 sistematizacin consiste en el desarrollo de un sistema de gestin

de abastecimiento de productos el cual permitir realizar un seguimiento de productos
que abastecern el servicio de catering para satisfacer a los comensales, en el cul el
dueo se incluir en el proceso teniendo informacin rpida de las tareas que se
realizarn diariamente entre el chef y el empleado de compras.
Implementando una aplicacin mvil Android se tendr comunicacin directa entre el

chef y el empleado de compras al momento de solicitar productos y adquirir los mismos
sin requerir un encuentro fsico.
1.2. ANTECEDENTES.
La empresa de Servicio de Catering VALENCIA inicio su actividad en el

departamento de Cochabamba un 11 de agosto del ao 2012 como empresa
unipersonal a cargo del Sr: lvaro Valencia Miranda quin adems es el propietario de
la empresa, que est dedicada a proporcionar servicios de catering (ANEXO A) a
diferentes empresas como ser: TAQUIA S.A., DURALIT S.A., SIGMA S.A., LA
PAPELERA S.A., MADEPA S.A. (ANEXO B).
Actualmente la empresa cuenta con un gerente (quin es el dueo), empleados que

se reparten en los cargos de: encargados de cocina, preparadores del alimento,
encargadas de preparacin de ensaladas, personal de limpieza de vajillas y meseros,
2 - 162
tambin se cuenta con dos ayudantes dependiendo a la cantidad de los comensales,
y un encargado de compras quin 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 dueo,
solicitadas por el chef, por consiguiente realiza la adquisicin 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
almacn, a continuacin el chef recoge los ingredientes en presencia del dueo
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 ningn producto. Las compras de los ingredientes que realiza el encargado
la realiza diariamente, en caso de escases o ausencia de algn ingrediente en almacn
el chef debe comunicar al dueo mediante llamada solicitando el ingrediente, el dueo
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 dueo.
Para poder tener un control, el dueo debe realizar una lista de los ingredientes que
se solicitaron y compraron por el personal, lo cul conlleva un registro manual diario
que dificulta las actividades del dueo ya que desperdicia el tiempo en tareas
repetitivas.
Por otra parte los encargados de cocina del preparado de los alimentos empiezan con
la preparacin de acuerdo al men que se les proporcion para el da, ponindose de
acuerdo con los encargados de ensaladas y empleados de limpieza de vajillas. Entre
otro servicio los meseros estn encargados de la organizacin de las mesas y de
proveer los utensilios para cada mesa.
Una vez preparado el servicio de alimentos los comensales ingresan en una hora
especfica sirvindose 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 depsito al dueo
de la empresa de catering as sucesivamente hasta cumplir el ao de contrato.
Para notificar el pago realizado por el servicio de catering, el dueo de la empresa

verifica en su cuenta el depsito mensual de las empresas y entrega una factura por
el servicio realizado.
1.3. PLANTEAMIENTO DEL PROBLEMA.
A continuacin se mencionan los siguientes puntos para poder determinar el

problema de manera clara.
1.3.1. Identificacin 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
adquisicin de ingredientes se realiza en un supermercado especfico (o mercado
local) e implica una demora al tomar nota y desorganizacin de registros, ya que cada
encargado del comedor requiere diferentes productos.
1.3.1.1. Identificacin de la situacin problemtica.
A continuacin se detallan los aspectos identificados de la situacin problemtica.
El proceso manual de confeccin de listas de ingredientes ocasiona tareas de

registro repetitivas para el dueo.
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 verificacin 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. Identificacin de las causas.
El proceso manual de confeccin de listas de productos.

El registro de los datos de las empresas que adquieren el servicio de catering se
realiza de forma manual.
La verificacin de productos que deben abastecerse es muy morosa.
La lista de ingredientes faltantes puede contener errores.
1.3.2. Formulacin del problema.
Los actuales procedimientos morosos empleados en la gestin de abastecimiento de

productos y Servicios de Catering provocan tareas repetitivas de confeccin de listas
diarias de productos faltantes, prdida de tiempo en la revisin de los pedidos
realizados por las empresas para determinar los productos que deben abastecerse y
gastos innecesarios en la adquisicin de productos que se tienen disponibles.
1.3.3. Anlisis causa efecto.
Causa:
Los actuales procedimientos morosos empleados en la gestin de abastecimiento

de productos y Servicios de Catering.
Efecto:
Tareas repetitivas de confeccin de listas diarias de productos faltantes.

Prdida de tiempo en la revisin de los pedidos realizados por las empresas para
determinar los productos que deben abastecerse.
Gastos innecesarios en la adquisicin de productos que se tienen disponibles.
1.4. OBJETIVOS Y ACCIONES.
1.4.1. Objetivo general.
Desarrollar un sistema de gestin de abastecimiento de productos y Servicios de
5 - 162
Catering integrado con una aplicacin mvil Android para garantizar la disponibilidad
de productos.
1.4.2. Objetivo especficos y Acciones.
Disear el modelado de negocio actual para el abastecimiento de productos.

Disear el modelo de negocio propuesto para el abastecimiento de productos.
Desarrollar mdulo de gestin de usuarios.
Desarrollar mdulo de control de stock de productos.
Implementar el mdulo de Servicios de Catering.
Desarrollar la aplicacin mvil Android para la gestin de abastecimiento de
productos.
Sincronizacin de la aplicacin cliente con la aplicacin servidor haciendo uso
de Data Storage en la nube.
Realizar pruebas del sistema terminado.
Tabla 1: Objetivos y acciones
OBJETIVOS
ACCIONES
ESPECFICOS
Disear el Analizar el modelado del negocio.

modelado de Realizar entrevistas con el involucrado principal.
negocio actual para Analizar la informacin obtenida.
el abastecimiento Disear el negocio del modelo actual.
de productos Identificar las deficiencias del proceso actual.
Elaborar el modelado del negocio alternativo que se

Disear el modelo
base en el sistema propuesto.
de negocio
Validar con los involucrados la propuesta.
propuesto para el
Seleccionar metodologa de desarrollo de software.
abastecimiento de
Planificar el proyecto segn el flujo de trabajo de
6 - 162
OBJETIVOS
ACCIONES
ESPECFICOS
productos modelo de software seleccionado.
Seleccionar lenguaje de programacin.

Realizar tabla de requerimientos.
Desarrollar mdulo Identificar tipos de actores.
de gestin de Disear los diagramas de casos de uso, diagramas de
usuarios. robustez, y diagramas de secuencia

Disear el modelo del dominio, incremento de diagrama
de dominio, culminacin de diagrama de dominio.
Codificar el mdulo de gestin de cuentas de usuario.
Realizar pruebas al mdulo de usuarios.
Identificar actores involucrados en el mdulo.
Disear los diagramas de casos de uso, diagramas de
Desarrollar mdulo
robustez y diagramas de secuencia,
de control de stock
Disear el modelo del dominio, incremento de diagrama
de productos.
de dominio, culminacin de diagrama de dominio.
Codificar el mdulo de control de stock de productos.
Realizar pruebas al mdulo.
Implementar el Realizar tabla de requerimientos.

mdulo de Servicios Disear las interfaces para el mdulo de Servicios de
de Catering. Catering
Realizar anlisis de requerimientos.

Desarrollar la
aplicacin mvil Identificar tipos de usuario.
Android para la Disear los diagramas de casos de uso, diagramas de
7 - 162
OBJETIVOS
ACCIONES
ESPECFICOS
gestin de robustez y diagramas de secuencia.

abastecimiento de Disear el modelo del dominio, incremento de diagrama
productos. de dominio, culminacin de diagrama de dominio.
Implementar el mdulo para la gestin de
abastecimiento de productos.
Realizar pruebas de funcionamiento.
Establecer tipos de mecanismos para conexin.

Sincronizacin de la
Realizar anlisis de requerimientos.
aplicacin cliente
Modelar la relacin de conexin entre el sistema
con la aplicacin
desarrollado y el servidor en la nube.
servidor haciendo
Aplicar los mecanismos necesarios para realizar la
uso de Data
comunicacin entre el sistema y el servidor en la nube.
Storage en la nube.
Realizar las pruebas de funcionalidad.
Identificar los tipos de pruebas adecuados.

Disear escenarios de casos de pruebas con usuarios
Realizar pruebas
finales.
del sistema
Obtener retroalimentacin de los usuarios.
terminado.
Realizar pruebas a los diferentes mdulos.
Documentar las pruebas.
Fuente: Elaboracin Propia
1.5. JUSTIFICACIN.
Se describen las justificaciones siguientes:
8 - 162
1.5.1. Justificacin tcnica.
Es importante mencionar que una aplicacin mvil Android contiene elementos que
permitirn una comunicacin activa entre los usuarios para mejorar el rendimiento en
sus funciones, esto permite que se comparta informacin de modo interactivo, por otra
parte la aplicacin mvil Android en la actualidad es eficiente, accesible y fcil de usar.
Por tanto la combinacin de ambas tecnologas brindar la versatilidad necesaria para
que los participantes del proceso puedan realizar la gestin de productos y servicios
de una manera ms sencilla y con libertad de acceso.
1.5.2. Justificacin econmica.
La aplicacin mvil Android ayudar a reducir los errores en los registros por tanto se
evitar la compra de ingredientes ya existentes e innecesarios en el almacn.
1.5.3. Justificacin operativa.
Una vez implementado la aplicacin mvil Android ser capaz de obtener informacin
de datos actuales sobre los productos necesarios para el abastecimiento de la
empresa por medio de un servidor que permitir al dueo llevar un registro controlado.
1.6. ALCANCE.
A continuacin se describen los alcances del proyecto:
1.6.1. Alcance Temtico.
Ingeniera de software
Lenguajes de programacin
Sistema de gestin de base de datos
Tecnologas mviles
1.6.2. Alcance Institucional.
El proyecto ser desarrollado para cubrir las reas de registro y adquisicin de

productos en la empresa de servicios de catering Valencia.
9 - 162
1.6.3. Alcance temporal.
El sistema tendr una proyeccin de vida til hasta que necesite una nueva
actualizacin teniendo un tiempo de vida estimado de 5 aos. As mismo el sistema
ser desarrollado en las gestiones I y II del ao 2016.
1.7. HIPTESIS.
El sistema de gestin de abastecimiento de productos y servicios de catering integrado

con una aplicacin mvil Android permitir reducir el nmero de errores en la
elaboracin de la lista de productos que se deben comprar, as mismo reducir el tiempo
en la organizacin del Servicio de Catering para las empresas.
1.7.1. Anlisis de variables.
Variable Independiente
El sistema de gestin de abastecimiento de productos y Servicios de Catering

integrado con una aplicacin mvil Android.
Variables Dependientes
Errores en la elaboracin de la lista de productos que se deben comprar.

Tiempo en la organizacin del Servicio de Catering para las empresas.
1.7.2. Definicin conceptual.
Variable independiente
El sistema de gestin de abastecimientos de productos y servicios de catering

integrado con una aplicacin mvil Android.
sta variable se refiere al sistema implementado y probado durante la gestin de

abastecimiento con la cual se obtendr informacin actualizada de los productos en el
proceso de adquisicin de servicios de catering.
10 - 162
Variable dependiente
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.
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. Operativizacin de variables.
En la tabla 2 se puede observar las tres variables existentes, la variable independiente

y las variables dependientes, se puede apreciar la dimensin y el indicador de cada
variable.
Tabla 2: Operativizacin de variables
VARIABLE DIMENSIN INDICADOR
Variable Independiente
El sistema de gestin de
Sistema Comparacin de
abastecimientos de productos
implementado y beneficios obtenidos sin el
y servicios de catering
probado uso del sistema y con el
integrado con una aplicacin
uso del sistema.
mvil Android.
Variables dependientes
Errores en la elaboracin de la
lista de productos que se Contador de errores Porcentaje de error
deben comprar.
11 - 162
VARIABLE DIMENSIN INDICADOR
Variable dependiente
Tiempo en la organizacin del Tiempo requerido
Servicio de Catering para las para optimizar la Tiempo

empresas. entrega en base a los
pedidos registrados.
Fuente: Elaboracin propia.
1.8. MATRIZ DE CONSISTENCIA.
En la matriz de consistencia se observa la asociacin entre el problema, objetivo e

hiptesis, esto nos permite observar de manera sintetizada las generalidades.
Figura 1: Matriz de consistencia
Fuente: Elaboracin Propia

12 - 162
BOLIVIA
CAPTULO 2
MARCO TERICO.
2. MARCO TERICO.
2.1. TCNICAS DE RECOPILACIN DE DATOS
Dentro de las tcnicas de recopilacin de datos existen 3 mtodos interactivos que se

pueden utilizar para la obtencin de los requerimientos de informacin de los miembros
de la organizacin. Dichos mtodos son la entrevistas, la observacin y la realizacin
de encuestas mediantes cuestionarios. La base de los mtodos est en preguntas
formuladas cuidadosamente. Cada uno de los mtodos para la recuperacin de
informacin tiene su propio proceso para interactuar con los usuarios. (Manilla Derbez
& Torres Villafaa, 2009)
2.1.1. Entrevistas.
Una entrevista es una conversacin dirigida con un propsito especfico 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
Villafaa, 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 aplicacin de las entrevistas son:
La expresin 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 continuacin:
Leer los antecedentes.

Establecer los objetivos de la entrevista.
Decidir a quin entrevistar.
Decidir el tipo de preguntas.
13 - 162
2.1.2. Observacin.
La observacin consiste en observar atentamente el hecho o caso, tomar informacin

y registrarla para su posterior anlisis. Es un elemento fundamental de todo proceso
investigativo, en ella se apoya el investigador para obtener el mayor nmero de datos.
(Manilla Derbez & Torres Villafaa, 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 informacin que los
actores consideran importante en la prctica social.
Los pasos que se deben tener en cuenta son:
Determinar el objeto, situacin, caso etc.

Determinar los objetos de la observacin.
Determinar la forma en que se van a registrar los datos.
Observar cuidadosamente y crticamente.
Registrar los datos observados.
Analizar e interpretar los datos.
Elaborar conclusiones.
Elaborar un informe.
2.1.3. Cuestionario.
La tcnica del cuestionario se puede aplicar en la entrevista, esta tcnica define una
serie de preguntas que permiten medir una o ms variables.
14 - 162
Es un eficaz auxiliar en la observacin cientfica, las cuales son preguntas formuladas
por escrito y no es necesario la presencia del investigador llevndose a cabo mediante:
cuestionario por correo, cuestionario administrado por el entrevistado o cuestionario
administrado por el entrevistador. (Manilla Derbez & Torres Villafaa, 2009)
Entre las ventajas se tienen:
Facilitan la recopilacin de informacin y no se necesitan muchas explicaciones ni

una gran preparacin para aplicarlos.
Evitan la dispersin de la informacin, porque se concentran en preguntas de
eleccin forzosa.
Sus limitantes son:
La falta de profundidad en las respuestas y no pueden ir ms all del cuestionario.

Puede provocar la obtencin de datos equivocados, si las preguntas son
formuladas de forma deficiente, as como tambin si se distorsionan o si se utilizan
trminos ilegibles, poco usados.
2.2. INGENIERA DE SOFTWARE.
La Ingeniera de Software es una disciplina que integra el proceso, los mtodos, y las
herramientas para el desarrollo de software. Esta disciplina no solamente implica todos
los procesos para el desarrollo de software, sino tambin implica toda la
documentacin llevada a cabo en base a un enfoque sistemtico 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)
Especificacin del software: Se define el software a producir y sus restricciones.
15 - 162
Desarrollo de software: Se disea y programa el software.
Validacin de software: Se asegura que se cumplen los requisitos del cliente.
Evolucin del software: El software es modificado para adaptar cambios.
2.2.2. Patrn de Arquitectura de Modelo Vista Controlador.
MVC es una propuesta de diseo de software utilizada para implementar sistemas

donde se requiere el uso de interfaces de usuario. Surge de la necesidad de crear
software ms robusto con un ciclo de vida ms adecuado, donde se potencie la
facilidad de mantenimiento, reutilizacin del cdigo y la separacin de conceptos.
Su fundamento es la separacin del cdigo en tres capas diferentes, acotadas por su

responsabilidad, MVC son las siglas de Model View Controller (Modelo-Vista-
Controlador) y es un patrn de la arquitectura del software descrito en 1979 por el
Noruego Trygve Reenskaug. (Compilando.ES., 2011)
El punto principal de MVC es dividir la aplicacin en tres capas reales, una para datos,
otra para la lgica y otra para la presentacin consiguiendo que sea mantenible,
escalable y reutilizable, separa presentacin e interaccin de los datos del sistema.
(Compilando.ES., 2011)
El "Modelo", o capa de datos, es el conjunto de clases que representan la informacin

con la que trabaja y su lgica de negocio. Un ejemplo seran 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 presentacin, define el modo en el que el usuario ve los datos y

como interacta con ellos. Una pgina HTML con formularios sera un ejemplo claro
de este tipo de capa. (Compilando.ES., 2011)
El "Controlador", o capa de lgica, es la que gestiona las peticiones de la Vista

solicitando los datos necesarios al Modelo y adaptndolos para su correcta
visualizacin. (Compilando.ES., 2011)
16 - 162
El sistema se estructura en tres componentes lgicos que interactan entre s. El
componente Modelo maneja los datos del sistema y las operaciones asociadas a esos
datos. El componente Vista define y gestiona cmo se presentan los datos al usuario.
El componente Controlador dirige la interaccin del usuario (por ejemplo, teclas
oprimidas, clics del mouse, etctera) y pasa estas interacciones a Vista y Modelo.
(Sommerville I. , 2011)
Figura 2: Modelo Vista Controlador.
Fuente: (Compilando.ES., 2011).
La caracterstica principal es:
Se usa cuando existen mltiples formas de ver e interactuar con los datos.
Tambin se utiliza al desconocerse los requerimientos futuros para la interaccin
y presentacin.
Las ventajas que ofrece son:
Permite que los datos cambien de manera independiente de su representacin y

viceversa.
Soporta en diferentes formas la presentacin de los mismos datos, y los cambios
en una representacin se muestran en todos ellos.
La desventaja que tiene:
Puede implicar cdigo adicional y complejidad de cdigo cuando el modelo de

datos y las interacciones son simples.
17 - 162
2.2.3. Metodologa de desarrollo de software.
A continuacin se desarrolla los diferentes tipos de metodologa de desarrollo de

software.
2.2.3.1. Programacin Extrema XP
La programacin Extrema o XP es una metodologa de desarrollo ligera (o gil) basada

en una serie de valores y de prcticas de buenas maneras que persigue el objetivo de
aumentar la productividad a la hora de desarrollar programas.
Este modelo de programacin se basa en una serie de metodologas 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 programacin
Los ingredientes utilizados en esta metodologa son conocidos desde el principio de la

informtica, donde, los autores de la metodologa XP han seleccionado aquellos que
han considerado mejores y han profundizado en sus relaciones y en cmo se refuerzan
los unos con los otros. El resultado de esta seleccin ha sido esta metodologa nica
y compacta. Aunque no est basada en principios nuevos, el resultado es una nueva
manera de desarrollo de software. (Kniberg, 2007)
Figura 3: Metodologa XP
Fuente: (Kniberg, 2007)

18 - 162
Fases de la Metodologa XP:
A continuacin se describe las cuatro fases de la programacin Extrema.
1 Fase: Planificacin del proyecto.
En esta primera fase se debe hacer una recopilacin de todos los requerimientos del
proyecto, tambin debe haber una interaccin 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: Diseo.
En esta fase se sugiere conseguir diseos simples y sencillos. Para procurar hacerlo
todo lo menos complicado posible para el usuario o cliente, para conseguir un diseo
fcilmente 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 fsica (lo
bonito) la interfaz que tendr el usuario o cliente con el proyecto. (Kniberg, 2007)
3 Fase: Codificacin.
En la fase de codificacin, el cliente es una parte ms 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 an ms necesaria. No olvidemos que los clientes
son los que crean las historias de usuario y negocian los tiempos en los que sern
implementadas. Antes del desarrollo de cada historia de usuario el cliente debe
especificar detalladamente lo que sta har y tambin tendr que estar presente
cuando se realicen los test que verifiquen que la historia implementada cumple la
funcionalidad especificada. En esta fase de la codificacin los clientes y los
desarrolladores del proyecto deben estar en comunicacin para que los
desarrolladores puedan codificar todo los necesario para el proyecto que se requiere,
en esta fase esta incluido todo lo de codificacin o programacin por parte de los
desarrolladores del proyecto. (Kniberg, 2007)
19 - 162
4 Fase: Pruebas.
Uno de los pilares de la metodologa XP es el uso de test para comprobar el

funcionamiento de los cdigos 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 cdigos que se vayan implementando. (Kniberg, 2007)
Las caractersticas que presenta son: (Gutierrez, 2011)
Diseo simple: se basa en la filosofa de que el mayor valor de negocio es

entregado por el programa ms sencillo que cumpla los requerimientos. Simple
Design se enfoca en proporcionar un sistema que cubra las necesidades
inmediatas del cliente, ni ms ni menos. Este proceso permite eliminar
redundancias y rejuvenecer los diseos obsoletos de forma sencilla.
Metfora: desarrollada por los programadores al inicio del proyecto, define una
historia de cmo 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 metfora expresa la
visin evolutiva del proyecto que define el alcance y propsito del sistema. Las
tarjetas CRC (Clase, Responsabilidad y Colaboracin) tambin ayudarn al equipo
a definir actividades durante el diseo del sistema. Cada tarjeta representa una
clase en la programacin orientada a objetos y define sus responsabilidades (lo
que ha de hacer) y las colaboraciones con las otras clases (cmo se comunica con
ellas).
Propiedad colectiva del cdigo: un cdigo con propiedad compartida. Nadie es
el propietario de nada, todos son el propietario de todo. Este mtodo difiere en
mucho a los mtodos tradicionales en los que un simple programador posee un
conjunto de cdigo. Los defensores de XP argumentan que mientras haya ms
gente trabajando en una pieza, menos errores aparecern.
Estndar de codificacin: define la propiedad del cdigo compartido as como
las reglas para escribir y documentar el cdigo y la comunicacin entre diferentes
piezas de cdigo desarrolladas por diferentes equipos. Los programadores las han
20 - 162
de seguir de tal manera que el cdigo en el sistema se vea como si hubiera estado
escrito por una sola persona.
Las ventajas que tiene son:
Programacin organizada.
Menor taza de errores.
Satisfaccin 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 metodologa que est de moda por su fcil aplicacin y rpida produccin
de software de calidad. ICONIX es un proceso simplificado en comparacin con otros
procesos ms tradicionales, hbrido entre RUP1 y XP, que unifica un conjunto de
mtodos de orientacin 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 sntesis
del proceso unificado de los tres amigos Booch, Rumbaugh y Jacobson y que ha
dado soporte y conocimiento a la metodologa ICONIX desde 1993. Presenta
claramente las actividades de cada fase y exhibe una secuencia de pasos que deben
ser seguidos. Adems 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 caractersticas fundamentales de ICONIX son:
1
RUP, Rational Unified Process en espaol Proceso Unificado Racional es un producto del proceso de ingeniera de software que
proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo. Su meta es
asegurar la produccin 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 identificacin de los casos de uso. El modelo esttico es
incrementalmente refinado por los modelos dinmicos.
Trazabilidad: Cada paso est referenciado por algn requisito. Se define
trazabilidad como la capacidad de seguir una relacin entre los diferentes
artefactos producidos.
Dinmica del UML: La metodologa ofrece un uso dinmico del UML como los
diagramas del caso de uso, diagramas de secuencia y de colaboracin.
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: Anlisis de requisitos
Dentro de esta fase se realizan las siguientes tareas:
Revisin de los requerimientos

Modelo de casos de usos
Fase 2: Anlisis y diseo preliminar
22 - 162
Dentro de esta fase se realizan las siguientes tareas:
Descripcin de los casos de uso

Diagramas de robustez
Fase 3: Diseo
Dentro de esta fase se realiza la siguiente tarea:
Diagramas de secuencia
Elaboracin rpida de prototipos
Fase 4: Implementacin
Dentro de esta fase se realiza la siguiente tarea:
Escribir y generar cdigo
Figura 5: Fases de la metodologa ICONIX
Fuente: (Scott & Rosenberg, 2001)
Las ventajas del proceso ICONIX son:
Proceso gil para obtener un sistema informtico.

Dedicada a la construccin de sistemas de gestin de pequea y mediana
complejidad con la participacin de los usuarios finales.
23 - 162
Las desventajas de ICONIX son:
sta metodologa necesita informacin rpida y puntual de los requisitos, del

diseo y de las estimaciones.
Es una metodologa que no debe ser usada en proyectos de larga duracin.
2.2.3.3. El proceso unificado gil (PUA)
El proceso unificado gil (PUA) adopta una filosofa en serie para lo grande e
iterativa para lo pequeo a fin de construir sistemas basados en computadora. Al
adoptar las actividades en fase clsicas del PU: concepcin, elaboracin, construccin
y transicin; el PUA brinda un revestimiento en serie (por ejemplo, una secuencia lineal
de actividades de ingeniera 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 rpido como sea posible incrementos de software significativos
a los usuarios finales. Cada iteracin 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 slo
suficientemente buenos para permitir que el equipo avance.
Implementacin. Los modelos se traducen a cdigo fuente.
Pruebas. Igual que con la XP, el equipo disea y ejecuta una serie de pruebas
para detectar errores y garantizar que el cdigo fuente cumple sus requerimientos.
Despliegue. El despliegue en este contexto se centra en la entrega de un
incremento de software y en la obtencin de retroalimentacin de los usuarios
finales.
Configuracin y administracin del proyecto. En el contexto del PUA, la
administracin de la configuracin incluye la administracin del cambio y el riesgo,
y el control de cualquier producto del trabajo persistente que produzca el equipo.
La administracin del proyecto da seguimiento y controla el avance del equipo y
coordina sus actividades.
24 - 162
Administracin del ambiente. La administracin del ambiente coordina una
infraestructura del proceso que incluye estndares, herramientas y otra tecnologa
de apoyo de la que dispone el equipo.
Aunque el PUA tiene conexiones histricas y tcnicas 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 caractersticas de la metodologa 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

documentacin de los procesos en detalle, sino que quieren una orientacin de
alto nivel y/o formacin 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 pginas, no miles de
pginas.
Agilidad. El PUA se ajusta a los valores y principios de la Alianza gil.
Centrarse en las actividades importantes. La atencin 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 cdigo abierto.
Querer adaptar este producto para satisfacer sus propias necesidades. El producto
AUP es fcil de manejar a travs de cualquier herramienta de edicin 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 relacin al RUP.

Como es un proceso simplificado, muchos desarrolladores eligen trabajar con el
RUP, por tener a disposicin mas detalles en el proceso.
2.2.4. Herramienta para el desarrollo de las metodologas
A continuacin se describe el Agile manifesto una herramienta para el desarrollo de

las metodologas donde se basa primordialmente en el producto y no as en la
documentacin tradicional que seguan metodologas tradicionales.
Agile Manifesto
En espaol: Manifiesto para el desarrollo gil de software, fue creado en 2001 y define
una herramienta de trabajo que puede mejorar los resultados en la construccin 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. (Pez, 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 ms a los individuos y su interaccin que a los procesos y las

herramientas.
Este es posiblemente el principio ms importante del manifiesto. Por supuesto que los
procesos ayudan al trabajo. Son una gua de operacin. Las herramientas mejoran la
eficiencia, pero sin personas con conocimiento tcnico y actitud adecuada, no
producen resultados.
Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse
a la organizacin, a los equipos y a las personas; y no al revs.
Valorar ms el software que funciona que la documentacin exhaustiva
Poder ver anticipadamente cmo se comportan las funcionalidades esperadas sobre

prototipos o sobre las partes ya elaboradas del sistema final ofrece una
retroalimentacin muy estimulante y enriquecedor que genera ideas imposibles de
concebir en un primer momento; difcilmente 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
documentacin, permiten la transferencia del conocimiento, registran informacin
histrica, 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 generacin de valor

que se logra con la comunicacin directa entre las personas y a travs de la interaccin
con los prototipos. Por eso, siempre que sea posible debe preferirse, y reducir al
mnimo indispensable el uso de documentacin, que genera trabajo que no aporta un
valor directo al producto.
Valorar ms la colaboracin con el cliente que la negociacin contractual
En el desarrollo gil el cliente es un miembro ms del equipo, que se integra y colabora

en el grupo de trabajo.
Valorar ms la respuesta al cambio que el seguimiento de un plan
Los principales valores de la gestin gil son la anticipacin y la adaptacin; diferentes

a los de la gestin de proyectos ortodoxa: planificacin y control para evitar
desviaciones sobre el plan.
Principios del manifiesto gil son:
Bajo el concepto de principio se hace referencia a las caractersticas que hacen la

diferencian entre un proceso gil y uno tradicional, y constituyen las ideas centrales
del desarrollo gil. (Scientia, 2007)
La satisfaccin del cliente a travs de la entrega rpida 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 conversacin cara a cara es la mejor forma de comunicacin.
Los proyectos estn construidos en torno de personas motivadas, a los cuales se
les tiene que dar la confianza necesaria para que realicen la tarea.
Atencin contina a la excelencia tcnica y al buen diseo.
Simplicidad.
Equipos que se auto organizan.
Adaptacin regular a las circunstancias cambiantes
Las desventajas que tiene son:
Falta de documentacin.
Problemas derivados de la comunicacin oral.
Falta de reusabilidad.
Restricciones en cuanto a tamao de los proyectos abordables.
Mayor complejidad en la gestin 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 notacin (UML) sirve para especificar, visualizar y

documentar esquemas de sistemas de software orientado a objetos. UML no es un
mtodo de desarrollo, lo que significa que no sirve para determinar qu hacer en primer
lugar o cmo disear el sistema, sino que simplemente le ayuda a visualizar el diseo
y a hacerlo ms accesible para otros.
UML est controlado por el grupo de administracin de objetos (OMG) y es el estndar

de descripcin de esquemas de software. UML se compone de muchos elementos de
esquematizacin 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 interaccin

entre objetos en un sistema segn UML.
30 - 162
Figura 10: Diagrama de secuencia
Diagrama de dominio: Es un modelo conceptual de todos los temas relacionados

con un problema especfico. .
Figura 11: Diagrama de dominio
31 - 162
2.2.6. Pruebas de software.
Una vez generado el cdigo fuente, es necesario probar el software para descubrir (y
corregir) la mayor cantidad de errores posible antes de entregarlo al cliente. Su objetivo
es disear una serie de casos de prueba que tengan una alta probabilidad de encontrar
errores. (Pressman R. , 2005)
Las tcnicas proporcionan directrices sistemticas para pruebas de diseo que

comprueben la lgica interna y las interfaces de todo componente del software y
comprueben los dominios de entrada y salida del programa para descubrir errores en
su funcin, comportamiento y desempeo. Durante las etapas inciales del proceso, el
desarrollador realiza todas las pruebas, sin embargo, a medida que avanza este
proceso se irn incorporando especialistas en pruebas. A continuacin 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 especificacin (normalmente a travs 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 accin o funcin
especfica del cdigo.
Las pruebas funcionales tienden a responder a la pregunta de "el usuario puede
hacer esto" o "se adapta esta funcin particular.
2.2.6.2. Diseo de casos de prueba
Se trata de disear pruebas que tengan la mayor probabilidad de encontrar el mayor

nmero de errores con la mnima cantidad de esfuerzo y de tiempo.
Cualquier producto de ingeniera se puede probar de dos formas:
Caja negra
Caja blanca
32 - 162
Pruebas de caja negra.
Las pruebas de caja negra, tambin llamadas pruebas de comportamiento, se enfocan

en los requerimientos funcionales del software; es decir, las tcnicas de prueba de caja
negra le permiten derivar conjuntos de condiciones de entrada que revisarn por
completo todos los requerimientos funcionales para un programa.
Las pruebas de caja negra no son una alternativa para las tcnicas de caja blanca. En
vez de ello, es un enfoque complementario que es probable que descubra una clase
de errores diferente que los mtodos de caja blanca. (Pressman R. , 2005)
Las pruebas de caja negra intentan encontrar errores en las categoras 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 inicializacin y terminacin.
Prueba de la caja blanca
La prueba de la caja blanca es un mtodo de diseo de casos de prueba que usa la

estructura de control del diseo 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 mdulo
Se utilizan las decisiones en su parte verdadera y en su parte falsa
Se ejecuten todos los bucles en sus lmites
Se utilizan todas las estructuras de datos internas
33 - 162
2.2.6.3. Prueba de Usabilidad.
Determina la usabilidad del sistema, determina cun bien el usuario podr usar y
entender la aplicacin. Identifica las reas de diseo que hacen al sistema de difcil
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 aplicacin no presenta los siguientes problemas de usabilidad tpicos:
El sistema es demasiado complejo y difcil de usar.

Es difcil instalar y entender el sistema
La recuperacin de errores es pobre y los mensajes de error no tienen
significado
La sintaxis de los comandos es difcil 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 grficos 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 Mvil.
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
mviles inalmbricos. (Alonso, 2004)
34 - 162
Figura 12: Arquitectura cliente/servidor mvil.
Fuente: (Geospatial, 2013).
ste modelo arquitectnico de software est compuesto por 3 capas o niveles:
Presentacin:
Provee la interfaz de usuario, a travs de la cual se realizan operaciones como el

ingreso de datos y la presentacin de las respuestas enviadas desde el servidor.
Lgica de negocio:
Implementa las reglas que rigen la organizacin (reglas del negocio), se proveer
servicios como la ejecucin 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 caracterstica es:
La caracterstica principal de esta arquitectura son las capas o niveles de organizacin.
2
Base de datos
3
Sistema Gestor de base de datos
35 - 162
2.3.2. Smart Client.
La arquitectura Smart Client o cliente ligero en espaol, tambin 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 lgica interna, limitndose a
presentar por pantalla un interfaz, y realizndose las operaciones en un servidor que
manda los resultados a los terminales a travs de la red. (Mora, 2011)
Cliente-servidor.
Los datos capturados en el cliente son enviados al servidor de datos.
Nota: en el dispositivo mvil 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 caractersticas clave:
Los clientes inteligentes pueden trabajar con datos, incluso cuando no estn
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 travs de la red desde un servidor centralizado
Las aplicaciones cliente inteligentes de apoyo de mltiples plataformas e idiomas,
ya que se basan en servicios Web.
Las aplicaciones cliente inteligentes pueden funcionar en casi cualquier dispositivo
que tenga conexin a Internet, incluidas computadoras de escritorio, estaciones
de trabajo, porttiles, tablet PCs, PDAs, y telfonos mviles.
Las ventajas que se tienen son:
Reduce la transferencia de datos a travs 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

mviles.
Diversidad de aplicaciones comerciales para sincronizacin ligadas a los Sistemas
de Gestin 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 ocurra en el
servidor. Algunos clientes livianos tambin son llamados "terminales de acceso".
37 - 162
A continuacin se describen grficamente el proceso que realiza la arquitectura Thin
Client o slim client.
Figura 14: thin client.
Fuente: (Davis & Steven, 2002)
Las caractersticas que presenta son:
Facilidad para escalar: Modificando nicamente las caractersticas del servidor.

Facilidad de administracin: Control centralizado en el servidor.
Informacin centralizada: Facilita el acceso y el control de esta.
Sin valor para los ladrones: Solo funcionan bajo gestin del servidor.
Las ventajas que presenta son: (Davis & Steven, 2002)
Informacin Centralizada. Como la informacin se encuentra en un solo lugar

facilita la realizacin 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
ms barato ya que estos no cuentan con disco duro, memoria para las
aplicaciones, o un procesador poderoso.
Tambin tienen un periodo de funcionamiento ms 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 informacin por

su cuenta, necesitan de una conexin a un servidor que realice estas tareas por
ellas
A medida que los clientes requieren de una conexin a un servidor, tambin
necesitan de una infraestructura de red.
Las aplicaciones con contenido enriquecido como audio y vdeo necesita una gran
reparticin de recursos de redes as como potencia de cmputo para reproducir.
2.4. HERRAMIENTAS DE SOFTWARE.
A continuacin se describe las herramientas de software:
2.4.1. Entornos de desarrollo Android (IDE).
Los IDE proveen un marco de trabajo amigable para la mayora de los lenguajes de
programacin tales como C++, PHP, Python, Java, C#, Delphi, Visual Basic, etc. En
algunos lenguajes, un IDE puede funcionar como un sistema en tiempo de ejecucin,
en donde se permite utilizar el lenguaje de programacin 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 mviles creado originalmente por Nitobi . Adobe Systems comprado
Nitobi en 2011, rebautizado como PhoneGap, y posteriormente liberado una versin
de cdigo abierto del software llamado Apache Crdoba. Apache Cordova permite
software programadores construir aplicaciones para dispositivos mviles utilizando
CSS3 , HTML5 y JavaScript en lugar de depender especficas de la plataforma API
como los de Android , iOS o Windows Phone . Se permite concluir de CSS, HTML y
cdigo JavaScript dependiendo de la plataforma del dispositivo. Se extiende las
caractersticas de HTML y JavaScript para funcionar con el dispositivo. Las
aplicaciones resultantes son hbrido, lo que significa que son de aplicacin mvil ni
39 - 162
verdaderamente nativo (porque todos representacin diseo se realiza a travs 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 distribucin y el acceso a las API nativas
de los dispositivos). Mezclando fragmentos de cdigo nativo e hbridos ha sido posible
desde la versin 1.9.
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 tctil .
Flujo de trabajo multiplataforma (CLI): se usa este flujo de trabajo si se quiere que
la aplicacin ejecute en los sistemas operativos mviles como sea posible, con
poco necesidad especfica de la plataforma desarrollo
Flujo de trabajo centrado en plataforma: se usa este flujo de trabajo si se desea
concentrarse en construir una aplicacin 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 aplicacin (una para cada plataforma).
2.4.1.2. Sublime text 3
Es un editor de cdigo 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 atencin
completamente. (Rehman, Paul, & Paul., 2002)
40 - 162
Sublime Text permite tener varios documentos abiertos mediante pestaas, e incluso
emplear varios paneles para aquellos que utilicen ms de un monitor. Dispone de
modo de pantalla completa, para aprovechar al mximo el espacio visual disponible de
la pantalla.
El sistema de resaltado de sintaxis de Sublime Text soporta un gran nmero 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). (Rodrguez, 2009)
Las caractersticas son:
Minimapa: consiste en una previsualizacin de la estructura del cdigo, es muy til

para desplazarse por el archivo cuando se conoce bien la estructura de este.
Multi Seleccin: Hace una seleccin mltiple de un trmino 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 divisin de hasta cuatro ventanas verticales o cuatro
ventanas en cuadrcula.
Soporte nativo para infinidad de lenguajes: Soporta de forma nativa 43 lenguajes
de programacin y texto plano.
Syntax Highlight configurable: El remarcado de sintaxis es completamente
configurable a travs de archivos de configuracin del usuario.
Bsqueda Dinmica: Se puede hacer bsqueda de expresiones regulares o por
archivos, proyectos, directorios, una conjuncin 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 adems de la existencia de multitud de plugins.
41 - 162
Configuracin total de Keybindings: Todas las teclas pueden ser sobrescritas a
nuestro gusto.
Acceso rpido a lnea 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. Tambin se puede ir a una lnea
utilizando los dos puntos ":" y el nmero de lnea.
Paleta de Comandos: Un intrprete de Python diseado 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 programacin o
marcado, resalta las expresiones propias de la sintaxis de ese lenguaje para
facilitar su lectura.
Pestaas: Se pueden abrir varios documentos y organizarlos en pestaas.
Resaltado de parntesis e indentacin: Cuando el usuario coloca el cursor en un
parntesis, corchete o llave, resalta sta y el parntesis, 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 aplicacin es bastante personalizable al punto que podemos cambiar el
comportamiento del editor, el tamao y tipo de tipografa, los atajos de teclado, los
esquemas de colores y otras series de opciones para acomodar la aplicacin a
nuestras necesidades.
La desventaja es:
Sublime Text no es gratis, sin embargo podemos usar la versin de prueba por
tiempo indefinido, solo que nos saldr un popUp cada vez que guardemos
nuestros archivos una determinada cantidad de veces, recordndonos que sera
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
diseado para darle un entorno potente, integrado en el que construir aplicaciones de
Android.
ADT ampla las capacidades de Eclipse para que pueda configurar rpidamente
nuevos proyectos Android, crear una interfaz de usuario de la aplicacin, 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 aplicacin. (Ducrohet, 2013)
El desarrollo en Eclipse con ADT es muy recomendable y es la manera ms rpida de

comenzar. Con la configuracin guiada proyecto que ofrece, as como la integracin
de herramientas, editores XML personalizados, y el panel de resultados de depuracin,
ADT le da un impulso increble en el desarrollo de aplicaciones para Android.
(Warnnez, 2013)
Las caractersticas de depuracin constituyen el ncleo de Dev Tools. Con esta

aplicacin, puedes seleccionar cualquier aplicacin a depurar.
Dev Tools tambin 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 aplicacin en el rendimiento del
sistema.
Dev Tools evita que el sistema operativo genere mensajes de error, incluso cuando
ests detenido en un punto de interrupcin durante largos perodos.
Dev Tools enva seales a travs de actualizaciones de pantalla. La aplicacin
hace parpadear un rectngulo de color rosa brevemente en cualquier pantalla para
indicar las secciones que estn siendo rediseadas.
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 aplicacin, un
archivo tipo .apk, en el directorio actual. Para instalar la aplicacin, 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 programacin de aplicaciones para un entorno
tecnolgico particular. Es decir, las aplicaciones desarrolladas sobre el SDK estarn
destinadas a algn sistema operativo, plataforma hardware, consola de videojuegos o
paquete de software en especial. (Shane Conder, 2012)
Una interfaz de programacin de aplicaciones (API). Puede verse como una

abstraccin 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 fcilmente
el cdigo fuente del programa. Generalmente, tambin brinda una interfaz
amigable para dos aplicaciones fundamentales:
Debugger. Permite testear el programa en cada paso de su ejecucin.
Compilador. Traduce el cdigo fuente a lenguaje de mquina, obteniendo as un
programa ejecutable.
Cdigo de ejemplo y otra documentacin. Como punto de partida para empezar a
desarrollar aplicaciones.
44 - 162
Un emulador del entorno. si se desarrolla una aplicacin para mviles desde una
computadora de escritorio, permite saber cmo la vera 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 especficos para desarrollar todo tipo de
aplicaciones en diferentes lenguajes. (Shane Conder, 2012)
Las ventajas son:
las aplicaciones desarrolladas sobre el SDK estarn destinadas a algn sistema

operativo, plataforma hardware, consola de videojuegos o paquete de software en
especial.
Una interfaz de programacin de aplicaciones (API).
La desventaja:
Diferentes habilidades/idiomas/herramientas para cada plataforma de destino.
2.5. TECNOLOGAS DE DESARROLLO DE APLICACIONES

MVILES
A continuacin se mencionan las tecnologas necesarias para el desarrollo de

aplicaciones mviles:
2.5.1. APLICACIN MVIL
Aplicaciones mviles o App son aplicaciones desarrolladas para los dispositivos

mviles, Smartphone o PDAS4. Estas aplicaciones pueden ser preinstaladas en el
dispositivo o descargadas por los usuarios desde las tiendas de aplicaciones en
Internet.
Una aplicacin mvil es una aplicacin informtica diseada para ser ejecutada en
telfonos inteligentes, tabletas y otros dispositivos mviles. Por lo general se
4
Agenda electrnica de bolsillo
45 - 162
encuentran disponibles a travs de plataformas de distribucin, operadas por las
compaas propietarias de los sistemas operativos mviles como Android, iOS,
BlackBerry5, Windows Phone6, entre otros. (Petrazzini, 2012)
Existen tres tipos de aplicaciones mviles:
Aplicaciones mviles nativas

Aplicaciones mviles Web
Aplicaciones mviles hibridas
2.5.1.1. Aplicaciones mviles nativas
Este tipo de aplicaciones estn hechas para ejecutarse en un dispositivo y sistema

operativo especfico. 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 ms eficiente sobre estos
dispositivos ya que sus componentes estn diseados de forma especfica para este
sistema operativo. Adems, este tipo de aplicaciones pueden emplear todos los
censores y elementos del telfono: cmara, GPS9, acelermetro, agenda, etc. Esta es
una diferencia fundamental con respecto a las aplicaciones web.
El cdigo fuente de estas aplicaciones se escribe en funcin del dispositivo para el que
se trabaje. Este cdigo fuente se compila a un ejecutable. Es un proceso similar al de
las tradicionales aplicaciones de escritorio. Todos aquellos recursos (imgenes,
iconos, etc.) que la aplicacin 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 mvil BlackBerry.
6
Sistema operativo mvil desarrollado por Microsoft.
7
Lenguaje de programacin basado en el lenguaje de programacin B
8
Lenguaje de programacin hibrido orientado a objetos
9
Sistema de posicionamiento global, utiliza triangulacin para determinar en todo el globo la posicin con una
precisin de metros.
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 aplicacin para
evaluar si se adecua a los requerimientos del sistema.
Figura 15: Arquitectura de aplicacin mvil 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 telfono, tales como
la cmara del telfono mvil, geolocalizacin, 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 telfono mvil en el que se ejecutan, ya
que utilizan las caractersticas de ese telfono 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
telfonos).
2.5.1.2. Aplicaciones mviles web
Las aplicaciones web mviles, a diferencia de las aplicaciones nativas, se ejecutan

dentro del navegador del telfono. Por ejemplo, en la plataforma iOS, se ejecutan en
el navegador Safari. Estas aplicaciones estn desarrolladas con HTML11, CSS12 y Java
script13.
Esto significa que la aplicacin funciona en todos los dispositivos, y se asegura la

compatibilidad entre plataformas siendo el testing de la aplicacin web en cada
plataforma y navegador totalmente requerido.
El mismo cdigo base se puede utilizar para todos los dispositivos, incluyendo iPhone
y Android. Sin embargo, como inconveniente, las aplicaciones web no hacen uso de
caractersticas nativas del telfono, tales como la cmara o la geolocalizacin. Las
aplicaciones web no se pueden vender en tiendas virtuales.
Las aplicaciones web hacen uso de las tecnologas web existentes, tales como Java
script y CSS, lo que significa que las barreras tcnicas de entrega son bajas. Los
desarrolladores pueden usar sus habilidades anteriores para desarrollar una aplicacin
web, mientras que las aplicaciones nativas pueden necesitar una formacin adicional,
dado que las tecnologas son mas recientes.
10
Tienda de Nokia que ofrece servicios de compra de aplicaciones para usuarios.
11
HyperTextMarkupLanguaje (Lenguaje de marcas de hipertextos).
12
Cascading Style Sheets (Hojas de estilo en cascada).
13
Es un lenguaje de programacin interpretado.
48 - 162
Figura 16: Arquitectura de aplicacin mvil web
2.5.1.3. Aplicaciones mviles hibridas
Una aplicacin mvil hibrida es una aplicacin mvil nativa con HTML incrustado.
Usando un framework de desarrollo comn, las empresas pueden desarrollar
aplicaciones multiplataforma que utilizan tecnologas web (como HTML, Java script y
CSS), haciendo uso de las funciones del telfono, determinadas partes de la aplicacin
se programan utilizando tecnologas web. Las porciones de web se puede descargar
desde la web, o embebidas dentro de la aplicacin.
Esta opcin permite a las empresas cosechar todos los beneficios de las aplicaciones
nativas al tiempo que garantiza la longevidad de los proyectos asociados con las
tecnologas web establecidas previamente.
Se trata de aplicaciones nativas que utilizan el navegador. Utilizan el mismo

procedimiento de instalacin que las aplicaciones nativas (a travs de una tienda de
aplicaciones), pero gran parte de estas aplicaciones se disea utilizando paginas web.
49 - 162
Se utilizan este tipo de aplicaciones como contenedores de aplicaciones web
existentes, es una manera econmica y rpida de lograr presencia en las tiendas de
aplicaciones.
Figura 17: Arquitectura de aplicacin mvil hibrida
Las aplicaciones hibridas anan lo mejor de los dos anteriores modelos. Este tipo de
aplicaciones permite el uso de tecnologas multiplataforma como HTML, Java script y
CSS pero permiten acceder a una buena parte de los dispositivos y sensores del
telfono. Buena parte de la infraestructura es tipo web y la comunicacin son los
elementos del telfono 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 caractersticas de una aplicacin nativa pero requiere ser
actualizada ocasionalmente.
14
Framwork de cdigo abierto para crear aplicaciones mviles.
50 - 162
El proceso de desarrollo para este tipo de aplicaciones es algo mas complicado. Al
igual que para las aplicaciones nativas, el cdigo una vez creado se compila a un
ejecutable. Adems, tambin como en las aplicaciones web se genera cdigo HTML,
CSS y Java script a ejecutar en un navegador. Ambos cdigos se compilan para ser
subidos mediante un paquete distribuible a la App store.
2.5.2. Framework
Un Framework (Marco de trabajo), define en trminos generales, un conjunto

estandarizado de conceptos, prcticas y criterios para enfocar un tipo de problemtica
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 tecnolgica de soporte definido, normalmente con artefactos o mdulos
de software concretos, que puede servir de base para la organizacin y desarrollo de
software. Tpicamente, 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 metodologa 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 tctiles (tambin

conocido como Framework mvil) que est siendo desarrollado actualmente por el
equipo de proyectos de jQuery. El desarrollo se centra en la creacin de un Framework
compatible con la gran variedad de smartphones y tablets, algo necesario en el
creciente y heterogneo mercado de tablets y smartphones. (Chaffer & Swedberg,
2007)
51 - 162
Manipulacin de la hoja de estilos CSS.
Efectos y animaciones.
Animaciones personalizadas.
AJAX.
Soporta extensiones.
Las ventajas son:
Compatible con la mayora de las plataformas mviles como la mayora de los

navegadores: iOS, Android, BlackBerry, Web OS, Symbian, Windows Phone 7.
Construido sobre el ncleo jQuery, para que la curva de aprendizaje sea mnima
para desarrolladores familiarizados con la sintaxis de jQuery.
Un framework de temas que permite personalizar uno rpidamente.
Dependencias limitadas y ligero que optimizan su velocidad.
El mismo cdigo de base escalar el tamao automticamente a cualquier
pantalla.
Posibilidad de navegacin entre pginas por AJAX con animaciones en las
transiciones de pgina.
UI widgets optimizados para tctil y para quien desconozca la plataforma. (Chaffer
& Swedberg, 2007)
Las funciones que ofrece son muchas, pero resultan difciles de personalizar. Su
aspecto visual es estandarizado y no se integra con el de la plataforma. En algunos
casos, no queda otra opcin que usar JavaScript simple para adaptar la aplicacin
a nuestras necesidades.
Como es necesario invocar a un archivo para utilizar sus funciones, ralentiza
levemente la carga de la pgina.
Su manejo de CSS suele resultar innecesariamente complejo. A veces cuesta
saber qu clases utilizar.
52 - 162
No existen muchas plantillas prediseadas sobre las cuales empezar a construir
nuestra aplicacin. (Chaffer & Swedberg, 2007)
2.5.2.2. AppCelerator
AppCelerator es un framework que permite crear aplicaciones nativas para mviles

basndonos en Javascript. Adems, no slo incluye esto, sino automatizacin de test
y una gran comunidad detrs. (Zamora, 2015)
AppCelerator es un proveedor lder de tecnologas de cdigo abierto para desarrollar,

probar y comercializar mviles, de escritorio y aplicaciones web. (Zamora, 2015)
AppCeleator hizo pblico la disponibilidad de una versin beta de su programa estrella

Appcelerator Titanio. Esta nueva versin incluye un nueva funcionalidad que permite
entrar a desarrollar para la plataforma mvil la tecnologa web, para desarrollar
aplicaciones nativas para el iPhone y Android a la vez sin necesidad de conocer los
lenguajes de programacin (Objective-C o Java ) sino tener conocimientos de
lenguajes web (Html, javascript, css, flash etc.).
AppCeleator presta apoyo a las tecnologas 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 ms el marco de desarrolladores web para las plataformas mviles.
Adems de enfocarse al mundo mvil, tambin 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 mvil antes que este. (AndroidGuys, 2009)
Las caractersticas que tiene son:
Soporta el desarrollo de aplicaciones mviles multiplataforma

Con una sola base de cdigo, pueden producir aplicaciones mviles 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 ms de un 70 % la productividad al escribir aplicaciones
Permite utilizar la experiencia de los desarrolladores en tecnologas y estndares
Web
Las ventajas que presenta son:
Multiplataforma mvil y tambin de escritorio.

Aspecto y controles nativos. El mejor rendimiento.
Gratis, soporte de pago. Licencia Apache.
Requiere Mac y Xcode para empaquetar aplicaciones IOS.

Definicin de componentes visuales y controles a mano (PhoneGap es HTML y
Flex es MXML)
Mucha documentacin pero poco actualizada y descolocada, tutoriales
desfasados, poco profesional (en mi opinin)
Las aplicaciones de escritorio se distribuyen con el cdigo fuente en claro (html,
js, css, imgenes, etc.)
2.5.2.3. PhoneGap.
PhoneGap es un framework para el desarrollo de aplicaciones mviles producido por

Nitobi, y comprado posteriormente por Adobe Systems.
PhoneGap permite a los programadores desarrollar aplicaciones para dispositivos

mviles utilizando herramientas genricas tales como JavaScript, HTML5 yCSS3. Las
aplicaciones resultantes son hbridas, es decir que no son realmente aplicaciones
nativas al dispositivo (ya que el renderizado se realiza mediante vistas web y no con
interfaces grficas especficas 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 acelermetro,
la cmara, los contactos en el dispositivo, la red, el almacenamiento, las notificaciones,
etc. Estas API se conectan al sistema operativo usando el cdigo nativo del sistema
husped a travs de una Interfaz de funciones forneas 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)
Phonegap permite crear actualmente aplicaciones mviles para: iPhone, Android,

Windows Phone, Blackerry, Blackberry 10, webOS, Symbian y Bada.
Las aplicaciones creadas con PhoneGap slo pueden nutrirse de HTML, CSS y
Javascript. Si requieren lgica generada por otros lenguajes de programacin,
debern conseguirla de un backend a travs de APIs o webservices
Ofrece un servicio en la nube llamado PhoneGap Build que permite construir
rpidamente apps mviles y compilarlas con facilidad sin necesidad de SDKs,
compiladores o hardware especfico.
Es la solucin que ms plataformas mviles soporta, ya que corre dentro de un

navegador web. Adems de Iphone/Ipad y Android, funciona tambin en Palm,
Symbian, WebOS, W7 y BlackBerry,
Es muy fcil de desarrollar y proporciona una gran libertad a los que tienen
conocimientos de HTML y Javascript.
Hay buena documentacin y bastantes ejemplos.
Es gratis,
Los Inconvenientes que presenta son:
Requiere Mac con Xcode para empaquetar aplicaciones IOS.
55 - 162
La aplicacin no es ms que una pgina web, por lo que el aspecto depender del
framework web utilizado. Necesitaremos el uso de frameworks HTML mviles
como Sencha Touch, jQuery mobile, Jo, Sproutcore, XUI, jQTouch si queremos
que parezca una aplicacin nativa.
No llega al rendimiento de una aplicacin 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 programacin
Un lenguaje de programacin es un idioma artificial, diseado para expresar procesos

que pueden ser llevadas a cabo por mquinas, como las computadoras. Pueden
usarse para crear programas que controlen el comportamiento fsico y lgico de una
mquina, para expresar algoritmos con precisin, o como modo de comunicacin
humana. Est formado por un conjunto de smbolos y reglas sintcticas y semnticas
que definen su estructura y el significado de sus elementos y expresiones. La
programacin es el proceso por el cual se escribe, se prueba, se depura, se compila y
se mantiene el cdigo fuente de un programa informtico. (MINGUET, 2008)
2.5.3.1. Python
Python es un lenguaje de programacin interpretado cuya filosofa hace hincapi en

una sintaxis que favorezca un cdigo legible.
Se trata de un lenguaje de programacin multiparadigma, ya que soporta orientacin

a objetos, programacin imperativa y, en menor medida, programacin funcional. Es
un lenguaje interpretado, usa tipado dinmico y es multiplataforma.
Es administrado por la Python Software Foundation. Posee una licencia de cdigo

abierto, denominada Python Software Foundation License, que es compatible con la
Licencia pblica general de GNU a partir de la versin 2.1.1, e incompatible en ciertas
versiones anteriores.
Python es un lenguaje de programacin multiparadigma. Esto significa que ms que

forzar a los programadores a adoptar un estilo particular de programacin, permite
56 - 162
varios estilos: programacin orientada a objetos, programacin imperativa y
programacin funcional. Otros paradigmas estn soportados mediante el uso de
extensiones.Python usa tipado dinmico y conteo de referencias para la administracin
de memoria.
Python es la resolucin dinmica de nombres; es decir, lo que enlaza un mtodo

y un nombre de variable durante la ejecucin del programa (tambin llamado
enlace dinmico de mtodos).
El diseo del lenguaje es la facilidad de extensin. Se pueden escribir nuevos
mdulos fcilmente en C o C++. Python puede incluirse en aplicaciones que
necesitan una interfaz programable.
Aunque la programacin en Python podra considerarse en algunas situaciones

hostiles a la programacin funcional tradicional del Lisp, existen bastantes analogas
entre Python y los lenguajes minimalistas de la familia Lisp como puede ser Scheme.
(Martnez, Ceceas, & Leyva, 2015)
Las ventajas son:
Simplificado y rpido: es que simplifica mucho la programacin hace que te cias

a un modo de lenguaje de programacin, python te propone un patrn.
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.
Programacin 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 comparacin con otros lenguajes.
La desventaja es:
Los programas interpretados son ms lentos que los compilados.
2.5.3.2. Ruby
El lenguaje Ruby est diseado para la productividad y la diversin del desarrollador,

siguiendo los principios de una buena interfaz de usuario Sostiene que el diseo de
sistemas necesita enfatizar las necesidades humanas ms quelas de la mquina:
Ruby sigue el "principio de la menor sorpresa", lo que significa que el lenguaje debe
comportarse de tal manera que minimice la confusin de los usuarios experimentados.
Combina una sintaxis inspirada en Python, Perl con caractersticas de programacin
orientada a objetos similares a Smalltalk, Comparte tambin funcionalidad con otros
lenguajes de programacin como Lisp, Lua, Dylan y CLU. Ruby es un lenguaje de
programacin interpretado en una sola pasada y su implementacin oficial es
distribuida bajo una licencia de software libre (Dewit O. , 2003)
Las caractersticas que posee son:
Orientado a objetos
Existe diferencia entre maysculas y minsculas.
Mltiples expresiones por lneas, separadas por punto y coma ;.
Dispone de manejo de excepciones.
Libreras de extensiones dinmicamente si el (Sistema Operativo) lo permite.
Dinmico
Entiende expresiones regulares
Multiplataforma
Recolector de basura inteligente
Sintaxis flexible
Sobre carga de operadores
58 - 162
Puede cargar libreras de extensiones dinmicamente si el (Sistema Operativo) lo
permite.
Porttil
Las ventajas de Ruby son:
Es un lenguaje sencillo y fcil de leer.

Soportado por la mayora 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 programacin Java fue originalmente desarrollado por James Gosling

de Sun Microsystems (la cual fue adquirida por la compaa 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 mquina virtual Java (JVM) sin importar la arquitectura
de la computadora subyacente.
Java es un lenguaje de programacin de propsito general, concurrente, orientado a

objetos y basado en clases que fue diseado especficamente para tener tan pocas
dependencias de implementacin como fuera posible. Su intencin es permitir que los
desarrolladores de aplicaciones escriban el programa una vez y lo ejecuten en
cualquier dispositivo, lo que quiere decir que el cdigo que es ejecutado en una
plataforma no tiene que ser recompilado para correr en otra.
59 - 162
Es sencillo de utilizar.
Tiene soporte dado por Sun.
Es dinmico.
Java ha sido diseado 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
ejecucin.
Es multihilo, ejecuta varias tareas de forma simultnea.
Las ventajas son:
Lenguaje orientado a objeto.

La sintaxis bsica deriva del lenguaje C/C++.
Es independiente de la plataforma, tanto en cdigo fuente como en binario.
Es Multi-plataforma (funciona en celulares, computadoras, etc.).
La desventaja:
Java es un lenguaje de programacin 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 rpidos.
2.5.4. Servicios web de intercambio de datos con Android.
Existen mltiples definiciones sobre lo que son los Servicios Web, lo que muestra su
complejidad a la hora de dar una adecuada definicin que englobe todo lo que son e
implican. Una posible sera hablar de ellos como un conjunto de aplicaciones o de
tecnologas con capacidad para interpretar en la Web. Estas aplicaciones o
tecnologas 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 travs de la Web. (Girons,
2013)
Estos servicios proporcionan mecanismos de comunicacin estndares entre

diferentes aplicaciones, que interactan entre s para presentar informacin dinmica
al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas
aplicaciones, y que al mismo tiempo sea posible su combinacin para realizar
operaciones complejas, es necesaria una arquitectura de referencia estndar. (Revelo,
2015)
Figura 18: Servicios Web.
Fuente: (Girons, 2013)
2.5.3.1. Servicio Web RESTful Para Android
Un servicio web RESTful es una aplicacin 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 espaol
significara Transferencia De Estado Representacional. (Revelo, 2015)
REST utiliza formatos de url para hacerlas ms 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 travs 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.
Configuracin para desarrollo web

Diseo e implementacin de la base de datos
Creacin 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 informacin que

se necesita
Servicios RESTful proporcionan una buena infraestructura de almacenamiento
en cach a travs de HTTP mtodo GET (para la mayora 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 dinmica.
Servicios REST son fciles de integrar con los sitios web existentes y estn
expuestos a XML para que las pginas 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 ms productivos y cmodo,
ya que no tendrn que volver a escribir todo desde cero y slo hay que aadir
la funcionalidad existente.
A mi parecer la seguridad es una deficiencia y puede llegar a ser una tarea

muy difcil de implementarla correctamente.
62 - 162
No hay un estndar en sus respuestas por lo que no se definen tipos de datos.
a) Formato de datos para la transferencia
Es muy comn que un servicio web RESTful ofrezca distintos formatos para la
comunicacin de datos. Los ms frecuentes son Json y XML, sin embargo pueden
usarse distintas variedades como HTML, CSV, PDF, etc (Revelo, 2015)
b) Planificacin Del Servicio Web RESTful
La aplicacin 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 bsicas sobre estos datos. (Revelo, 2015)
Tambin 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 informacin. (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 quedaran de la
siguiente forma:
Configuracin para desarrollo web

Diseo e implementacin de la base de datos
Realizacin de conexin Mysql con Php
Creacin de los modelos de datos
Definicin de las vistas
Manejo de las llamadas al servicio web RESTful (CRUD)
Realizar pruebas al servicio web
2.5.3.2. Lenguaje de Descripcin de Servicios Web (WSDL).
Los protocolos de comunicacin y formatos de mensaje estn estandarizados en la

comunidad web, se hace cada vez ms posible e importante ser capaz de describir las
comunicaciones de alguna manera estructurada. WSDL aborda esta necesidad
63 - 162
definiendo una gramtica XML15 para describir servicios de red como colecciones de
puntos finales de comunicacin capaces de intercambiar mensajes. Definiciones de
servicio WSDL proporcionan documentacin para sistemas distribuidos y sirven como
una receta para la automatizacin de los detalles involucrados en las aplicaciones de
comunicacin. (Girons, 2013)
Un documento WSDL define los servicios como colecciones de puntos finales de red
o puertos. En WSDL, la definicin abstracta de puntos finales y los mensajes se separa
de su despliegue de red o formato de datos de enlaces concretos. Esto permite la
reutilizacin 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 unin reutilizable. Un puerto se define
mediante la asociacin de una direccin de red con una unin reutilizable, y una
coleccin de puertos define un servicio. Por lo tanto, un documento WSDL utiliza los
siguientes elementos en la definicin de servicios de red: (Girons, 2013)
Tipos: un contenedor para definiciones de tipos de datos utilizando algn tipo de

sistema (como XSD28).
Mensaje: definicin abstracta escrito de que los datos sean comunicados.
Operacin: una descripcin abstracta de una accin admitida por el servicio.
Tipo de puerto: un conjunto abstracto de operaciones soportadas por uno o ms
puntos finales.
Encuadernacin: un protocolo concreto y especificacin de formato de datos para
un tipo de puerto en particular.
Puerto: un nico punto final se define como una combinacin de un enlace y una
direccin de red.
Servicio: un conjunto de criterios de valoracin 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 definicin de nuevo
tipo. WSDL reconoce la necesidad de sistemas de tipo rico para describir formatos de
mensaje, y es compatible con la especificacin de esquemas XML (XSD), como su
sistema de tipo cannico. Sin embargo, ya que es razonable esperar que una
gramtica 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 definicin de otro
tipo a travs de la extensibilidad. (Girons, 2013)
Adems, WSDL define un mecanismo de unin comn. Esto se utiliza para conectar
un formato o estructura de datos de protocolo especfico a un resumen del mensaje,
el funcionamiento, o de punto final. Se permite la reutilizacin de definiciones
abstractas. (Girons, 2013)
Adems del marco de definicin de servicio bsico, esta especificacin incluye las
extensiones de unin especficos para los siguientes protocolos y formatos de
mensaje:
SOAP.
HTTP GET / POST.
MIME16
Permite especificar en XML las operaciones y tipos de datos de un servicio web

Estandarizado por el W3C
Analoga 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 espaol "extensiones multipropsito de correo de
internet") son una serie de convenciones o especificaciones dirigidas al intercambio a travs de Internet de todo
tipo de archivos (texto, audio, vdeo, etc.)
65 - 162
WSDL es extensible y se pude utilizar para describir, prcticamente, cualquier
servicio de red, incluyendo SOAP sobre HTTP
Tener perfectamente definida la interfaz del servicio web nombre de la funcin,
parmetros y orden.
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 semntica de los servicios web.
2.5.3.2. REST API
REST (Transferencia de estado representacional) es un estilo arquitectnico, y una

aproximacin a las comunicaciones que se utilizan a menudo en el desarrollo de
servicios Web. El uso de REST frecuencia, se prefiere el ms 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 travs 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: (Girons, 2013)
66 - 162
REST desacopla la arquitectura, y las comunicaciones de menor peso entre productor
y consumidor, hacer descansar un estilo de construccin 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 pgina Web designada que contiene
unXML archivo. El archivo XML describe e incluye el contenido deseado. Una vez
definido de forma dinmica, los consumidores pueden acceder a la interfaz.
REST, que normalmente se ejecuta a travs de HTTP (Hypertext Transfer Protocol),

tiene varias limitaciones arquitectnicas:
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 mviles, 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 nmero limitado de operaciones (verbos). La flexibilidad se proporciona mediante
la asignacin de recursos (sustantivos) sus propias nicas Identificadores Universales
de Recursos (URI). Debido a que cada verbo tiene un significado especfico (GET,
POST, PUT y DELETE), REST evita la ambigedad.. (Naresh & Toral, 2002)
Las caractersticas 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
informacin como puede ser JSON, aunque podra ser otro lenguaje como XML.
67 - 162
Separacin cliente/servidor
Independencia de tecnologas / lenguajes
Fiabilidad, escalabilidad, flexibilidad
Experiencia de usuario
API REST no mantiene estado y eso hace que se tenga que montar una
infraestructura propia para poder conservar el conjunto de la aplicacin.
Puede producirse en determinadas circunstancias mayor rigidez en el desarrollo
2.5.5. JavaScript
JavaScript (abreviado comnmente JS) es un lenguaje de programacin interpretado,

dialecto del estndarECMAScript. Se define como orientado a objetos, basado en
prototipos, imperativo, dbilmente tipado y dinmico.
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
pginas web dinmicas 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
tambin significativo.
JavaScript se dise con una sintaxis similar a C, aunque adopta nombres y

convenciones del lenguaje de programacin Java. Sin embargo, Java y JavaScript
tienen semnticas y propsitos diferentes.
Todos los navegadores modernos interpretan el cdigo JavaScript integrado en las

pginas web. Para interactuar con una pgina web se provee al lenguaje JavaScript
de una implementacin del Document Object Model (DOM).
68 - 162
Tradicionalmente se vena utilizando en pginas web HTML para realizar operaciones
y nicamente en el marco de la aplicacin cliente, sin acceso a funciones del servidor.
Actualmente es ampliamente utilizado para enviar y recibir informacin del servidor
junto con ayuda de otras tecnologas como AJAX. JavaScript se interpreta en el agente
de usuario al mismo tiempo que las sentencias van descargndose junto con el cdigo
HTML. (Shafer, 2003)
La caracterstica que presenta:
La caracterstica 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 ms usado.
Las ventajas son:
JavaScript es una excelente solucin para poner en prctica la validacin de datos

de un formulario en el lado del cliente. Si un usuario omite escribir su nombre en
un formulario, una funcin de validacin en JavaScript puede desplegar en pantalla
un mensaje popup para hacerle saber al usuario acerca de la omisin. Este tipo
de funcionalidades son ms ventajosas que tener una rutina de validacin del lado
del servidor para controlar el error, dado que el servidor en ste caso no tiene que
hacer ningn tipo procesamiento de informacin adicional. Una rutina de ASP o
PHP podra ser escrita para lograr la misma tarea pero un formulario desarrollado
en JavaScript no permitira que la informacin se enviase a menos que se complete
correctamente el formulario.
Una de las reas en la que sobresale radicalmente JavaScript es en la creacin
de efectos dinmicos tales como imgenes dinmicas y presentaciones de
diapositivas, donde su uso se ha convertido algo comn hoy en da. 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 despus que la
pgina ha sido enviada por el servidor. Esto le permite al desarrollador web crear
efectos dinmicos 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

cdigo de JavaScript una vez aadidos a las pginas web en los servidores, estos
son descargados y ejecutados en el navegador del cliente permitiendo as que
cierto cdigo malicioso pueda ser ejecutado en la mquina 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 da
existen estndares de seguridad que restringen la ejecucin de cdigo por parte
de los navegadores, pero an as, se puede ejecutar cdigo que dae, robe o
destruya informacin del lado del cliente.
2.5.6. HTML
El lenguaje HTML basa su filosofa de desarrollo en la diferenciacin. Para aadir un

elemento externo a la pgina (imagen, vdeo, script, entre otros.), este no se incrusta
directamente en el cdigo de la pgina, sino que se hace una referencia a la ubicacin
de dicho elemento mediante texto. De este modo, la pgina web contiene solamente
texto mientras que recae en el navegador web (interpretador del cdigo) la tarea de
unir todos los elementos y visualizar la pgina final. Al ser un estndar, HTML busca
ser un lenguaje que permita que cualquier pgina web escrita en una determinada
versin, pueda ser interpretada de la misma forma (estndar) por cualquier navegador
web actualizado.
HTML, sigla en ingls de HyperText Markup Language (lenguaje de marcas de

hipertexto), hace referencia al lenguaje de marcado para la elaboracin de pginas
web. Es un estndar que sirve de referencia del software que conecta con la
elaboracin de pginas web en sus diferentes versiones, define una estructura bsica
y un cdigo (denominado cdigo HTML) para la definicin de contenido de una pgina
web, como texto, imgenes, videos, juegos, entre otros. Es un estndar a cargo del
World Wide Web Consortium (W3C) o Consorcio WWW, organizacin dedicada a la
estandarizacin de casi todas las tecnologas ligadas a la web, sobre todo en lo
referente a su escritura e interpretacin. Se considera el lenguaje web ms importante
70 - 162
siendo su invencin crucial en la aparicin, desarrollo y expansin de la World Wide
Web (WWW). Es el estndar que se ha impuesto en la visualizacin de pginas web y
es el que todos los navegadores actuales han adoptado.
HTML es un lenguaje de etiquetas (tambin llamado lenguaje de marcado) y las

pginas web habituales estn formadas por cientos o miles de pares de etiquetas
Puede ser creado y editado con cualquier editor de textos bsico.
Cada elemento de un documento HTML consta de una etiqueta de comienzo, un
bloque de texto y una etiqueta de fin.
Fcil de usar
Permite la comunicacin rpida 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 travs
de la red.
Se puede contactar con diferentes personas para realizar negocios, trabajos,
proyectos, etc.
Es muy bsico
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 presentacin

de los documentos electrnicos definidos con HTML y XHTML. CSS es la mejor forma
de separar los contenidos y su presentacin y es imprescindible para crear pginas
web complejas.
71 - 162
Separar la definicin de los contenidos y la definicin de su aspecto presenta
numerosas ventajas, ya que obliga a crear documentos HTML/XHTML bien definidos
y con significado completo (tambin llamados "documentos semnticos"). Adems,
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 pgina web, se utiliza en primer lugar el lenguaje HTML/XHTML para
marcar los contenidos, es decir, para designar la funcin de cada elemento dentro de
la pgina: prrafo, 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, tamao y tipo de letra del texto, separacin horizontal y vertical
entre elementos, posicin de cada elemento dentro de la pgina, etc.
Las caractersticas que tiene:
Lograr una apariencia uniforme de todo el sitio al activar una sola definicin de
estilo en cada pgina,
Cambiar un aspecto en todo el sitio web con tan slo editar unas pocas lneas,
Hacer que los cdigos html sean ms fciles de leer ya que los estilos se definen
por separado,
Permitir que las pginas se carguen ms rpido ya que hay menos cantidad de
html en cada pgina,
Posicionar los elementos de la pgina de una manera ms uniforme.
Las ventajas son:
Control centralizado de la presentacin de un sitio web completo con lo que se

agiliza de forma considerable la actualizacin del mismo.
Optimizacin del ancho de banda de la conexin, pues pueden definirse los
mismos estilos para muchos elementos con un slo selector; o porque un mismo
archivo CSS puede servir para una multitud de documentos.
72 - 162
Si hay problemas o limitaciones de compatibilidades, el navegador aplicar el

formato predeterminado y nuestro trabajo de composicin habr sido intil.
Algunas propiedades de las CSS pueden provocar que una parte del contenido de
nuestra pgina resulte inaccesible desde algunos navegadores.
2.5.7. Intercambio de datos JSON.
JSON (JavaScript Object Notation - Notacin de Objetos de JavaScript) es un formato

ligero de intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras
que para las mquinas es simple interpretarlo y generarlo. Est basado en un
subconjunto del Lenguaje de Programacin 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

prcticamente de facto en el estndar para transmisin de datos. Pero se necesita
transmitir a travs de Internet muchos ms bytes de informacin para realizar una tarea
que se podra llevar a cabo con un flujo de informacin mucho ms pequeo. (Sacristn
& Fernndez, 2012)
As se han desarrollado nuevas formas de compresin XML e, incluso, nuevos

formatos XML completos, tales como Binary XML (XML binario). Todas estas
soluciones funcionan ampliando o aadindose 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 (notacin de objetos
JavaScript). (Sacristn & Fernndez, 2012)
La caracterstica 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 ningn anlisis adicional como los necesarios con lenguajes basados en
XML.
Las ventajas que presenta:
Formato sumamente simple

Velocidad de procesamiento alta
Archivos de menor tamao
La desventaja que tiene:
Tiene una estructura enredosa y difcil de interpretar a simple vista
2.5.8. Gestores de Bases de datos
A continuacin se describen los gestores de base de datos:
2.5.8.1. My Structured Query Language (MySQL).
MySQL es un sistema de administracin de bases de datos. Dado que los

computadores son muy buenos manejando grandes cantidades de informacin, los
administradores de bases de datos juegan un papel central en computacin, como
aplicaciones independientes o como parte de otras aplicaciones. (Gutirrez, 2010)
Permite escoger entre mltiples motores de almacenamiento para cada tabla. En

MySQL 5.0 stos deban aadirse en tiempo de compilacin, a partir de MySQL 5.1 se
pueden aadir dinmicamente en tiempo de ejecucin. Agrupacin de transacciones,
reuniendo mltiples transacciones de varias conexiones para incrementar el nmero
de transacciones por segundo. (Gutirrez, 2010)
El tipo de compilacin es binario por lo que ha sido compilado con informacin de

depuracin extra. No debe ser usada en sistemas en produccin porque el cdigo de
74 - 162
depuracin puede reducir el rendimiento. MySQL est escrito en una mezcla de C y
C++. (Piattini, 1993) (Gutirrez, 2010)
La caracterstica es:
Aprovecha la potencia de sistemas multiprocesador, gracias a su implementacin

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.
Gestin 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 elaboracin de bases de datos, ya que debido
a su bajo consumo puede ser ejecutado en una mquina con escasos recursos sin
ningn problema.
Facilidad de configuracin e instalacin.
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 estn 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 gestin 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 informacin y datos se

alojan en el servidor y los terminales o clientes de la red slo acceden a la informacin.
Adems permite administrar informacin de otros servidores de datos. 89 de 223
(Morales, 2010)
En el manejo de SQL mediante lneas de comando se utiliza el SQLCMD. Para el

desarrollo de aplicaciones ms complejas (tres o ms capas), Microsoft SQL Server
incluye interfaces de acceso para varias plataformas de desarrollo, entre ellas .NET,
pero el servidor slo est disponible para Sistemas Operativos (Morales, 2010)
Este sistema incluye una versin reducida, llamada MSDE con el mismo motor de base
de datos pero orientado a proyectos ms pequeos, que en sus versiones 2005 y 2008
pasa a ser el SQL Express Edition, que se distribuye en forma gratuita. (Petkovic, 2008)
Compatibilidad con la mayora de las tareas administrativas de SQL Server.

Un entorno nico integrado para la administracin del Motor de base de datos de
SQL Server y la creacin.
Cuadros de dilogo 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 cdigo o escribirlas en script
para ejecutarlas posteriormente.
Cuadros de dilogo no modales y de tamao variable que permiten obtener acceso
a varias herramientas mientras un cuadro de dilogo est abierto.
76 - 162
Un cuadro de dilogo comn de programacin que permite realizar acciones de
los cuadros de dilogo de administracin en otro momento.
Es un sistema de gestin 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.
Utiliza mucho la memoria RAM para las instalaciones y utilizacin de software.

No se puede utilizar como practicas porque se prohben muchas cosas, tiene
restricciones en lo particular.
La relacin, calidad y el precio esta muy debajo comparado con Oracle.
Tiene muchos bloqueos a nivel de pgina, un tamao de pgina fijo y demasiado
pequeo, una psima implementacin de los tipos de datos variables.
2.5.6.3. SQLite Sistema de Gestin de Base de Datos
SQLite es software libre, es posible encontrar una gran cantidad de componentes,

libreras y drivers para interactuar con SQLite desde una gran diversidad de lenguajes
y plataformas de programacin. Ya sea que estemos utilizando lenguajes modernos
como Java, Perl, Python, PHP, Ruby, C#, lenguajes ms antiguos como Pascal,
SmallTalk, Clipper, o lenguajes poco conocidos como Suneido, REXX, S-Lang, para
todos podemos encontrar libreras y ejemplos de cdigo para SQLite. (Rmmel, 2007)
Las caractersticas son: (Rmmel, 2007)
La base de datos completa se encuentra en un solo archivo.

Puede funcionar enteramente en memoria, lo que la hace muy rpida.
Tiene un footprint menor a 230KB.
Es totalmente auto contenida (sin dependencias externas).
Cuenta con libreras de acceso para muchos lenguajes de programacin.
Soporta texto en formato UTF-8 y UTF-16, as como datos numricos de 64 bits.
77 - 162
Soporta funciones SQL definidas por el usuario (UDF).
El cdigo fuente es de dominio pblico y se encuentra muy bien documentado.
Las ventajas son:
No requiere configuracin.
No se requiere uso de servidor (proceso activo para atender las peticiones).
Fcilmente portable (multiplataforma windows, linux, mac, dispositivos mviles,
tablets, etc.).
En su versin 3, SQLite permite bases de datos de hasta 2 Terabytes de tamao,
y tambin permite la inclusin de campos tipo BLOB.
Acceso mucho ms rpido.
Prcticamente cualquier lenguaje y SO lo soportan.
Registros de Longitud Variable
Limitaciones en Where: esta limitacin est dada por el soporte para clausuras
anidadas.
Falta de Clave Fornea: se hace caso omiso de las claves forneas; esto quiere
decir, cuando se realice la creacin de la tabla desde el modo consola, est
permitiendo el uso de la clausura, aunque no realizara el chequeo de la misma.
Falta de documentacin en espaol: si bien ya contamos con una comunidad
latino americana de SQLite, sera importante encontrar mucha ms
documentacin, libros, review, etc. como muchos otros motores de bases de datos
cuentan hoy en da.
Una Base de Datos SQLite es un nico archivo de disco ordinario y que adems puede
estar situado en cualquier parte del directorio dentro de las jerarquas de directorios.
Esto trae como ventaja que el archivo de Base de Datos puede ser fcilmente copiado
en algn dispositivo de memoria por ejemplo en USB o por correo electrnico.
(Rmmel, 2007)
78 - 162
2.5.9 Herramientas de gestin
Se entiende que las herramientas de gestin son todos los sistemas, aplicaciones,
controles, soluciones de clculo, metodologa, etc., que ayudan a la gestin 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. Tambin permite
implementar un dominio propio a travs de Google Apps. Por el momento las cuentas
gratuitas tienen un lmite 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 aplicacin supera estas cuotas, se pueden comprar cuotas
adicionales.
Actualmente las aplicaciones Google App Engine se implementan mediante los

lenguajes de programacin Python, Java, Go y PHP.
Almacn de datos
App engine proporciona un potente servicio de almacenamiento de datos distribuido

que adems incluye un motor de bsqueda y de transacciones. A medida que vuestra
app aumenta con el trfico, el almacn de datos crece.
El almacn 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 integracin de las aplicaciones con google

accounts para la autenticacin 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 ms rpida.
Tambin mirando el desarrollo, evitar el desarrollo e implementacin 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 caractersticas que app engine proporciona
y que nos facilitan el trabajo al administrar nuestra aplicacin:
- Extraccin de url: recupera recursos web mediante la misma infraestructura de alta

velocidad de google.
- Correo: la app puede enviar correos electrnicos 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 aplicacin. Resulta til para
datos que no necesitan las funciones de persistencia y transacciones del almacn
de datos. Velocidad.
- Manipular imgenes: recortar, girar o ajustar imgenes desde tu aplicacin de una
forma sencilla.
Cron
Adems de las lgicas solicitudes web, tu aplicacin puede realizar tareas

programadas segn el desarrollador configure (cada da, cada hora..). Las tareas
programadas se conocen como tareas cron ya que el servicio cron es el que las
gestiona. Existe una documentacin muy til sobre la utilizacin de dicho servicio para
python y para java.
Las colas de tareas an estn incluidas de forma experimental, slo estn disponibles
para en lenguaje python, pero google app engine evoluciona rpido y pronto estar
disponible para java y para php posteriormente.
Desarrollo local
80 - 162
Google app engine permite que generes en local un entorno idntico al de google app
engine en la nube. Es decir, podrs realizar tu app y probarla con la mxima seguridad
que una vez la subas, todas las features de tu app funcionarn a la perfeccin.
Control
Puedes registrar 10 apps por cuenta de desarrollador. Si ests 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 algn tipo
de infraccin puede inhabilitar tu cuenta o cerrarla definitivamente.
Python
Google app engine tambin permite aplicaciones desarrolladas en python. Adems

incluye varias api y herramientas para el desarrollo, as como una api de modelado de
datos detallado, un marco de aplicaciones web fcil de utilizar.
Zona de pruebas
La zona de pruebas asla la aplicacin en su propio entorno seguro de confianza,

totalmente independiente del hardware, del sistema operativo y de la ubicacin fsica
del servidor web.
Tu aplicacin solo podr acceder a otros equipos de internet a travs de los servicios
de correo y extraccin de url proporcionados por app engine. El resto de equipos solo
podrn 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 informacin
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
peticin web-respuesta, proceso que debe ser completado en pocos segundos.
Los accesos a otros sitios web se realizan a travs de un API especfico de Google,
que impide que se puedan modificar determinadas cabeceras HTTP
2.5.9.2. Cloud computing
La computacin en la nube, conocida tambin como servicios en la nube, informtica

en la nube, nube de cmputo o nube de conceptos (del ingls cloud computing), es
un paradigma que permite ofrecer servicios de computacin a travs de una red, que
usualmente es Internet.
La computacin en nube presenta las siguientes caractersticas clave:
Agilidad: Capacidad de mejora para ofrecer recursos tecnolgicos al usuario por

parte del proveedor.
Costo: los proveedores de computacin en la nube afirman que los costos se
reducen. Un modelo de prestacin pblica en la nube convierte los gastos de
capital en gastos de funcionamiento. Ello reduce barreras de entrada, ya que la
infraestructura se proporciona tpicamente por una tercera parte y no tiene que ser
adquirida por una sola vez o tareas informticas 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
duracin.
Independencia entre el dispositivo y la ubicacin: permite a los usuarios acceder a
los sistemas utilizando un navegador web, independientemente de su ubicacin o
del dispositivo que utilice (por ejemplo, PC, telfono mvil).
La tecnologa de virtualizacin permite compartir servidores y dispositivos de
almacenamiento y una mayor utilizacin. Las aplicaciones pueden ser fcilmente
migradas de un servidor fsico a otro.
Rendimiento: Los sistemas en la nube controlan y optimizan el uso de los recursos
de manera automtica, dicha caracterstica permite un seguimiento, control y
notificacin del mismo. Esta capacidad aporta transparencia tanto para el
82 - 162
consumidor o el proveedor de servicio.
Seguridad: puede mejorar debido a la centralizacin 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 solucin 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 aplicacin. El proveedor de
la nube es responsable de la seguridad fsica.5
Mantenimiento: en el caso de las aplicaciones de computacin en la nube, es ms
sencillo, ya que no necesitan ser instalados en el ordenador de cada usuario y se
puede acceder desde diferentes lugares.
Las ventajas son:
Integracin probada de servicios Red. Por su naturaleza, la tecnologa 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.
Prestacin de servicios a nivel mundial. Las infraestructuras de cloud
computing proporcionan mayor capacidad de adaptacin, recuperacin completa
de prdida de datos (con copias de seguridad) y reduccin al mnimo de los
tiempos de inactividad
Actualizaciones automticas que no afectan negativamente a los recursos de TI.
Al actualizar a la ltima versin de las aplicaciones, el usuario se ve obligado a
dedicar tiempo y recursos para volver a personalizar e integrar la aplicacin. Con
el cloud computing no hay que decidir entre actualizar y conservar el trabajo, dado
que esas personalizaciones e integraciones se conservan automticamente
durante la actualizacin.
Las desventajas del cloud computing son:
La disponibilidad de las aplicaciones est sujeta a la disponibilidad de acceso

a Internet.
La centralizacin de las aplicaciones y el almacenamiento de los datos origina una
83 - 162
interdependencia de los proveedores de servicios.
84 - 162
BOLIVIA
CAPTULO 3
MARCO PRCTICO.
3. MARCO PRCTICO.
El captulo corresponde a la elaboracin e implementacin del sistema de gestin de

abastecimiento de productos y servicios de catering integrado con una aplicacin
mvil Android partiendo de la situacin 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. DISEO 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 automatizacin de varios de los procesos mencionados.
3.1.1 Anlisis del modelado del negocio
Para planificar el desarrollo del presente proyecto en la elaboracin de un sistema de

gestin de abastecimiento de productos y servicios de catering inicialmente es
necesario obtener la informacin necesaria que describa el proceso y las actividades
que actualmente se realizan para el proceso de gestin 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 Disear el negocio del modelo actual.
Se representa la informacin recolectada por medio de las entrevistas realizadas al

personal de la Empresa VALENCIA (Ver Anexo C), en base a la elaboracin 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 gestin de abastecimiento de productos y Servicios de
Catering.
Figura 20: Diagrama de Modelado de Negocio Actual
Modelado del negocio actual
CHEF DUEO DE LA EMPRESA ENCARGADO DE COMPRAS
INICIO
Realiza el men del
da con el Recibe lista de
encargado de la ingredientes
empre Confirma contrato
de la empresa que
requiere el servicio
Se comunica con el de catering
dueo de la Se dirige al mercado
empresa para
entregarle el pedido
de productos e Firma contrato para
ingredientes un determinado
tiempo
Realiza compras
Se comunica con el
chef mediante
llamada o sms
Se dirige al almacen
del dueo
Manda al chef a la
empresa para que
registre el pedido
de productos Entrega los
ingredientes
solicitados
Espera a que se le Recibe lista de

No
entregue el pedido pedido
Si
Revisa si hay algunos

ingredientes en
No Si
almacn de la lista
Realiza nuevamente
Elimina de la lista de
la lista de
pedido
ingredientes
Se comunica con el
encargado de
compras mediante
llamada o sms
Entrega lista de
Recoge los
ingredientes que
ingredientes
debe comprar
Se dirige a la
Recibe los
empresa que se le
ingredientes
asign
Almacena todos los

Prepara los
ingredientes en el
alimentos
almacn
Despacha los Entrega

productos en ingredientes bajo
envases a los lista al chef
comensales
FIN
Fuente: Elaboracin 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 dueo
y compras que realiza el encargado de compras se almacenan en archivos.
Se emplea tiempos descoordinados para la comunicacin de los involucrados.
La comunicacin de los involucrados se las realiza mediante mensajes o
llamadas.
El dueo no lleva un control claro de los reportes de compras realizadas.
No se tiene un registro eficiente de los ingredientes que existe en almacn.
El registro de men se realiza cada da y conlleva a una perdida de tiempo.
3.2. DISEAR EL MODELO DE NEGOCIO PROPUESTO PARA EL

ABASTECIMIENTO DE PRODUCTOS
Mediante la recoleccin de informacin por medio de entrevistas, se ha analizado y

se ha modelado la situacin actual para el proceso de abastecimiento de productos.
3.2.1. Elaboracin del modelado del negocio alternativo basado en el sistema

propuesto.
Considerando las posibilidades que puede brindar el uso de Tecnologas de

Informacin, se ha elaborado una propuesta cmo solucin 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 organizacin.
79 - 162
Figura 21: Diagrama de Modelado de Negocio Alternativo del proceso de gestin de
abastecimiento de productos y servicios de catering.
Modelado del negocio alternativo
CHEF DUEO DE LA EMPRESA Servicio Web en la nube ENCARGADO DE COMPRAS
Se almacena los
INICIO datos en la base de Ingresa a la
datos del Google aplicacin
Cloud Storage
Ingresa a la Ingresa a la
aplicacin aplicacin
Registra sus datos y
tipo de usuario
Reportes
Registra sus datos y Registra sus datos y
Ingresa a la
tipo de usuario tipo de usuario
aplicacin con
usuario y
contrasea
Ingresa a la Ingresa a la
aplicacin con aplicacin con
Recibe lista de
usuario y usuario y FIn ingredientes que
contrasea contrasea
debern ser
comprados
Registra pedidos de Administra

productos por Control de personal Control de stock
porducto
fechas Registra compras
realizadas
Registra producto Asigna encargado Registra todos los

Enva pedido de compras y ingredientes de
precio e
ingredientes empresa al chef almacn Enva registro
Guarda los
formularios
3.2.2. Seleccin de la metodologa de desarrollo de software.
Para seleccionar la metodologa para el desarrollo del sistema propuesto se debe

realizar un anlisis de las metodologas de desarrollo de software planteadas
anteriormente. Las metodologas de desarrollo de software es un marco de trabajo
para estructurar, planificar y controlar el proceso de desarrollo de sistemas de
informacin, presenta ventajas y desventajas que se han extrado de la bibliografa
indicada en el marco terico.
A continuacin se muestra una tabla de comparacin de las metodologas giles

propuestas para el desarrollo del sistema.
80 - 162
Tabla 3: Descripcin de las Ventajas y Desventajas de los Modelos de Desarrollo de
Software.
MODELO
VENTAJAS DESVENTAJAS
Programacin organizada Es recomendable emplearlo solo
XP
Menor taza de errores en proyectos a corto plazo.
Satisfaccin del Altas comisiones en caso de fallar.
programador.
sta metodologa necesita
Proceso gil para obtener un
informacin rpida y puntual de los
sistema informtico.
requisitos, del diseo y de las
Dedicada a la construccin
ICONIX estimaciones.
de sistemas de gestin de
Es una metodologa que no debe
pequea y mediana
ser usada en proyectos de larga
complejidad con la
duracin.
participacin de los usuarios
finales.
Simplicidad. Todo se El AUP es un producto muy pesado
describe concisamente en relacin al RUP.
usando unas pginas, no Como es un proceso simplificado,
El
miles de pginas. muchos desarrolladores eligen
proceso
Agilidad. El AUP se ajusta a trabajar con el RUP, por tener a
unificado
los valores y principios de la disposicin mas detalles en el
gil
Alianza gil. proceso.
(PUA)
Centrarse en las actividades
importantes.
Querer adaptar este
producto para satisfacer sus
propias necesidades.
81 - 162
Realizando la comparacin de las distintas metodologas de desarrollo que se
proponen se tom la decisin de aplicar en el desarrollo del presente proyecto la
metodologa de desarrollo gil ICONIX debido que es un proceso simple, abierto y gil
que est dirigido a grupos de trabajo pequeos y trabajos de corta duracin. De igual
manera por que utiliza como base fundamental los diagramas de modelado de UML y
su orientacin 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 metodologa de XP y AUP ya que presenta demora al momento de

desarrollar las fases que no favorecern 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 metodologa de software.
3.2.3. Planificar el proyecto segn el flujo de trabajo de modelo de software

seleccionado.
A continuacin se desarrolla la tabla de planificacin para el desarrollo de software.
Tabla 4: Plan de desarrollo de software segn ICONIX
OBJETIVOS FASES ELABORACIN
Seleccionar lenguaje de programacin

y sistema gestor de base de datos.
Anlisis de
Identificar tipos de actores.
requisitos
Desarrollar el Disear los diagramas de casos de
Diseo
mdulo de gestin uso, diagramas de robustez, y
preliminar
de distintos tipos diagramas de secuencia
Revisin critica
de usuarios. Disear el modelo del dominio,
del diseo
incremento de diagrama de dominio,
Implementacin
culminacin de diagrama de dominio.
Codificar el mdulo de gestin de
cuentas de usuario.
82 - 162
Realizar pruebas al mdulo de
usuarios.

Identificar actores involucrados en el
Anlisis de mdulo.
requisitos Disear los diagramas de casos de

Desarrollar el uso, diagramas de robustez y
Diseo
mdulo de control diagramas de secuencia,
preliminar
de stock de Disear el modelo del dominio,
Revisin critica
productos. incremento de diagrama de dominio,
del diseo
Implementacin
Codificar el mdulo de control de stock
de productos.
Realizar pruebas al mdulo.
Anlisis de
requisitos
Implementar el Realizar tabla de requerimientos.
Diseo
mdulo de
preliminar Disear la interfaz para el mdulo de
Servicios de
Revisin critica Servicios de Catering
Catering.
del diseo
Implementacin
Anlisis de Realizar anlisis de requerimientos.

Desarrollar la
requisitos Identificar tipos de usuario.
Aplicacin mvil
Diseo Disear los diagramas de casos de
Android para la
preliminar uso, diagramas de robustez y
gestin de
Revisin critica diagramas de secuencia.
abastecimiento de
del diseo Disear el modelo del dominio,
productos.
Implementacin incremento de diagrama de dominio,
83 - 162
Implementar el mdulo para la gestin
de abastecimiento de productos.
Realizar pruebas de funcionamiento.
Implementar Anlisis de
mecanismos de requisitos
conectividad entre Diseo Seleccionar mecanismos de conexin
el servidor y la preliminar y sincronizacin.
aplicacin mvil Revisin critica Realizar las pruebas de funcionalidad.
Android (offline- del diseo

online) Implementacin
3.3. DESARROLLAR EL MDULO DE GESTIN DE DISTINTOS TIPOS DE

USUARIOS.
Para empezar a construir el sistema, primero se debe desarrollar el modulo de gestin

de usuarios para tener el control del personal de la empresa.
3.3.1. Seleccionar lenguaje de programacin
A continuacin se describe los lenguajes de programacin 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 comparacin de lenguajes de programacin
Lenguajes de
Ventajas Desventajas
programacin
84 - 162
Python Simplificado y rpido
Elegante y flexible: el Los programas interpretados
lenguaje da muchas son ms lentos que los
herramientas compilados.
Ordenado y limpio
Portable: Ya sea en mac,
linux o windows
Ruby
Rendimiento comparable a
Orientado a objetos
Perl o Python, pero lejos de
Dinmico
C o C++
Multiplataforma
No existen muchas
Porttil
frameworks desarrolladas
en Ruby
No existe una framework
de GUI multi-plataforma
ampliamente aceptada
Java Lenguaje orientado a Java es un lenguaje de

objeto. programacin el cual no
La sintaxis bsica 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
cdigo fuente como en velocidad ya que los
binario. programas hechos en Java
Es Multi-plataforma no tienden a ser muy
(funciona en celulares, rpidos.
computadoras, etc.).
85 - 162
Como el proyecto est orientada al desarrollo de una aplicacin mvil se considera
Python debido a que est es una excelente solucin para poner en prctica la
validacin de datos de un formulario en el lado del cliente y adems permite la
creacin de efectos dinmicos tales como imgenes dinmicas combinada con
HTML, JavaScript y CSS por lo tanto se convierte en la mejor opcin para ms
funcionalidades a comparacin de otros lenguajes de programacin por lo tanto se
descarta los lenguajes de programacin Java y Ruby.
3.3.2. Requerimientos de gestin de distintos tipos de usuarios.
En base al anlisis 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 Gestin de usuarios
Nro. Requisito Evidente/Oculto
1 Registro de Usuarios Evidente
2 Iniciar sesin Evidente
3 Control de personal Evidente
4 Editar y eliminar usuario Oculto
3.3.3. Identificacin de actores de gestin 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 ms
privilegios que el chef y encargado de compras.
86 - 162
La siguiente tabla describe la actividad de los actores en el sistema en el mdulo de
Gestin de usuarios:
Tabla 7: Identificacin de usuarios de Gestin 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 tambin a
Administrador
gestin de usuarios.
uc Modelo ...
Chef
El chef podr ingresar al sistema para

registrar sus datos personales, ingresar
Chef
usuario, contrasea y seleccionar tipo de
usuario.
Encargado de compras
uc Modelo de casos d...
El encargado de comprar ingresar al

sistema para registrar sus datos
Encargado de compras personales, ingresar usuario, contrasea y
seleccionar tipo de usuario.
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 disear 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 llevarn a cabo con los
involucrados de la empresa
Figura 22: Diagrama de Caso de Uso de Alto Nivel del Sistema
88 - 162
Tabla 8: Descripcin 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
Descripcin:
Los actores debern registrar sus datos personales
para poder acceder al sistema e iniciar sesin con
su usuario y contrasea. El administrador es el
actor principal del proceso ya que har un control
de stock en el almacn tambin 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.
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
Tabla 9: Descripcin de caso de uso expandido Registro de datos
Casos de uso: Registro de datos

Tipo: Primario
Descripcin: Los actores debern ingresar sus datos personales
para poder registrarse e ingresar al sistema.
Tabla 10: Descripcin de accin de actores Registro de datos
Accin de Actores Respuesta del sistema

1.- Los actores deben registrar sus
datos personales y seleccionar el
rol que tiene en la empresa.
90 - 162
2.-El sistema registrar todos
campos llenados y si no estn
llenados todos los campos
mostrar un mensaje de El campo
no puede estar vaco
3.- Una vez llenado todos los
campos del formulario el usuario
debe presionar el botn registrar
4.- El sistema inmediatamente
registrar sus datos y volver a la
pantalla principal.
b) Iniciar sesin
El siguiente diagrama describe el caso de uso muestra los pasos a seguir para el
ingreso al sistema.
Figura 24: Iniciar sesin
91 - 162
Tabla 11: Descripcin de caso de uso expandido Iniciar sesin
Casos de uso: Iniciar sesin

Tipo: Primario
Descripcin: El administrador, Chef y encargado de compras
podrn ingresar al sistema introduciendo su
usuario y contrasea.
Tabla 12: Descripcin de accin de actores Iniciar sesin
1.- El administrador, chef y

encargado de compras ingresan al
sistema, introducen sus datos de
usuario y contrasea
2. El sistema valida datos de
usuario, contrasea y da
acceso al sistema.
3.- Despus de tener acceso al
sistema cada actor podr realizar
su respectivo trabajo.
c) Gestin de usuarios
El siguiente diagrama describe el caso de uso muestra los pasos a seguir para la
gestin de usuarios que el administrador podr realizar.
92 - 162
Figura 25: Gestin de usuarios
Tabla 13: Descripcin de caso de uso expandido Gestin de usuarios
Casos de uso: Gestin de usuarios

Actores: Administrador
Tipo: Primario
Descripcin: El administrador tendr acceso al control de
personal.
Tabla 14: Descripcin de accin de actores Gestin de usuarios

1.- El administrador ingresar a
control de personal.
93 - 162
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 opcin
asignar.
5.-El administrador deber
presionar el botn asignar para
poder asignar empresa y
encargado de compras al chef.
6.- El sistema mostrar botn
ASIGNAR para concretar el
proceso.
7.- El administrador debe presionar
el botn Asignar.
8.- El sistema guardar
automticamente los datos
registrados
3.3.5. Diagrama de robustez de gestin de distintos tipos de usuarios.
Los diagramas de robustez nos sirven para hacer una comprobacin de validez, es
decir, comprobar si el texto caso de uso es correcto. ste es un diagrama que no tiene
que mantenerse al da ya que se utiliza slo para la transicin.
94 - 162
a) Registro de datos
A continuacin se describe grficamente 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
1:Seleccionar datos de 3:Enviar datos
opcin usuario nuevo
IU aplicacin IU Registro de usuarios Gestor usuario Usuario

4:Selecciona rol de usuario
Tipo_usuario
b) Iniciar sesin.
A continuacin se describe grficamente el proceso para iniciar sesin
Figura 27: Diagrama de robustez de Iniciar sesin

4:Confirmacin
1:Seleccionar 2:Ingresa datos 3:Enviar datos
de usuario y
opcin de usuario de usuario
contrasea
IU: Aplicacin IU Iniciar sesin IU Usuario y contrasea Gestor usuario Usuario
5:Men de acuerdo al rol de usuario
IU Men usuario
c) Gestin de usuarios
A continuacin se describe grficamente el proceso para la gestin de usuarios.
95 - 162
Figura 28: Diagrama de robustez de Gestin de usuarios
3:Enviar dato
de empresa
1:Seleccionar 2:Enviar datos Gestor empresa Chef

opcin
IU:Men de 6:Devuelve datos 4:Seleccionar

IU:Asignar Empresa y Gestor Control de
administrador guardados encargado de
Encargado de compras personal
compras
5:Enva datos
Gestor usuario de usuario Usuario
3.3.6. Modelado del dominio, incremento de diagrama de dominio, culminacin

de diagrama de dominio.
A continuacin se describe grficamente el diagrama del modelado del dominio,

incremento de diagrama de dominio, culminacin de diagrama de dominio para el
modulo gestin de distintos tipos de usuarios.
Figura 29: Modelado del dominio
1 1
Usuario
Chef
-Nombre 1
-Apellido1 -id_usuario
-Apellido2 -encargado
-CI -pedido
-Celular -empresa
-Direccin +Eliminar()
n -Usuario +editar()
-Contrasea
-Tipo_de_usuario
1
+Editar() Encargado
+Eliminar()
-id_usuario
+Eliminar()
+Editar()
tipo_usuario
-t_usuario
+Editar ()
1
+eliminar()
96 - 162
3.3.7. Codificar el mdulo de gestin de cuentas de usuario.
A continuacin se muestra una parte del cdigo empleado en la gestin de cuentas

de usuario.
Figura 30: Codificacin de gestin de cuentas de usuarios
a) Interfaz de registro de usuarios
A continuacin se muestra la interfaz de registro de usuario.
97 - 162
Figura 31: Interfaz de registro de usuario
b) Interfaz de Iniciar sesin
A continuacin se muestra la interfaz para iniciar sesin.
Figura 32: Interfaz de iniciar sesin
98 - 162
c) Interfaz de registro de administrador.
A continuacin se muestra la interfaz para el administrador.
Figura 33: Interfaz del administrador
Figura 34: Interfaz de control de personal
99 - 162
3.3.8. Realizar pruebas al mdulo de usuarios
Para cumplir con la validacin y verificacin del sistema en esta seccin se realizar
las pruebas funcionales la cual se aplica por casos de uso. A continuacin se presenta
las pruebas funcionales del mdulo de usuarios.
a) Prueba funcional de registro de datos.
A continuacin 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 Descripcin Prueba Resultado
El formulario consiste en
llenar los datos personales Controlar llenado
Exitoso
del usuario en todos los de datos en vaco
campos que se solicita.
Registro de
datos
Los campos deben ser
Controlar llenado
llenados con slo nmeros Exitoso
de slo nmeros.
en caso del CI y Celular.
El sistema no acepta un Verificacin de
Exitoso
doble usuario ya registrado. usuario existente
b) Prueba funcional de ingresar al sistema.
A continuacin se muestra las pruebas funcionales de inicio de sesin de los usuarios.
Tabla 16: Prueba funcional del caso de uso ingresar al sistema.
100 - 162
El formulario solicita llenar
Controlar llenado
datos de usuario y Exitoso
de datos en vaco
Ingresar al contrasea.
sistema
Los datos ingresados en el
Verificar datos
formulario deben ser Exitoso
correctos
correctos
c) Prueba funcional de gestin de usuarios.
A continuacin se muestra las pruebas funcionales de control de usuarios.
Tabla 17: Prueba funcional del caso de uso de gestin de usuarios.

El formulario muestra lista de
chef registrados y sin Controlar llenado
Exitoso
asignar encargado de de Formulario
compras ni empresa.
Gestin de
En la asignacin de
usuarios
encargado de compras
Controlar lista de
generar una lista de los Exitoso
encargados.
usuarios registrados como
encargado de compras
3.4. DESARROLLAR EL MDULO DE CONTROL DE STOCK DE

PRODUCTOS
Para poder abastecerse con ingredientes necesarios para el servicio de catering se

debe desarrollar el modulo de gestin de control de stock de productos.
101 - 162
3.4.1. Requerimientos.
En base al anlisis 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
1 Iniciar sesin como administrador Evidente
2 Registrar ingrediente para el almacn Evidente
3 Editar y eliminar ingrediente de Oculto

almacn
3.4.2. Identificar actores involucrados en el mdulo.
La siguiente tabla describe la actividad de del involucrado en el sistema.
Tabla 19: Identificacin de actores involucrados en el mdulo.
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.
102 - 162
3.4.3. Diagramas de casos de uso expandido de control de stock.
A continuacin se desarrollar el diagrama de caso de uso expandido de control de

stock.
d) Control de stock
A continuacin 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: Elaboracin propia.

Tabla 20: Descripcin de caso de uso expandido control de stock.
Casos de uso: Control de stock

Tipo: Primario
Descripcin: El administrador deber llenar datos del
ingrediente para el almacn como: nombre del
ingrediente y la cantidad.
Tabla N 20: Descripcin de accin de actores control de stock
103 - 162
ingresar al sistema con su nombre
de usuario y contrasea.
2.-El sistema verificar dato y dar
acceso para el ingreso al sistema.
3.- El administrador debe
seleccionar la opcin 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
informacin automticamente.
3.4.4. Diagrama de robustez control de stock.
A continuacin se desarrollar el diagrama de robustez para el control de stock de

productos.
d) Control de stock
A continuacin se describe grficamente el proceso para el control de stock.
104 - 162
Figura 36: Diagrama de robustez de control de stock.
1:Selecciona 2:Ingresa datos 3:Enva dato

opcin
IU:Men de
IU: Control de stock Gestor stock stock
administrador
7:Envia datos
6:Selecciona
ingrediente
IU:Modificar cantidad
3.4.5. Disear el modelo del dominio.
A continuacin se describe grficamente el diagrama del modelado del dominio del

control de stock.
Figura 37: Diseo del dominio de control de stock.
1 1
Usuario
Chef
-Nombre 1
-CI -pedido
-Celular -empresa
-Contrasea
-Tipo_de_usuario
1
+Editar() Encargado stock
+Eliminar()
-id_usuario -ingredientes
+Eliminar() -cantidad
+Editar() +modificar()
tipo_usuario
-t_usuario
+Editar ()
1
+eliminar()
3.4.6. Codificar el mdulo de control de stock de productos.
A continuacin se muestra una parte del cdigo empleado en el mdulo.
105 - 162
Figura 38: Codificacin de control de stock
d) Interfaz de control de stock.
A continuacin se muestra la interfaz de control de stock.
Figura 39: Interfaz de control de stock.
106 - 162
3.4.7. Realizar pruebas al mdulo.
A continuacin se presenta las pruebas funcionales del mdulo control de stock.
Tabla 21: Prueba funcional del caso de uso de control de stock.
El formulario consiste en
llenar datos del ingrediente Controlar llenado
Exitoso
que se va almacenar en la de datos en vaco
Control de
bodega.
stock
El sistema no acepta un Verificacin de

doble ingrediente ya ingrediente ya Exitoso
registrado. existente.
3.5. IMPLEMENTAR EL MDULO DE SERVICIOS DE CATERING.
3.5.1. Tabla de requerimientos.
En base al anlisis 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
1 Interfaz principal servicios de catering VALENCIA Evidente
3 Interfaz de iniciar sesin Evidente
107 - 162
4 Interfaz de administrador Evidente
5 Interfaz de registrar producto Oculto
3.5.2. Identificar tipos de usuario.
La siguiente tabla describe la actividad de cada usuario que interactuar con el

sistema mediante un mvil.
Tabla 23: Identificacin 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.
3.5.3. Disear los diagramas de casos de uso
A continuacin se desarrollar los distintos diagramas de caso de uso expandido

para el modulo de la aplicacin mvil para la gestin 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
Tabla 24: Descripcin de caso de uso expandido de Administrar producto
Casos de uso: Administrar producto

Tipo: Primario
Descripcin: El administrador tendr acceso para administrar el
producto creando nuevo producto, editarlo o
eliminar dicho producto.
Tabla 25: Descripcin de accin de actores de Administrar producto

1.- El administrador ingresar a
administrar producto donde le
saldrn dos opciones Nuevo
producto y Editar o eliminar
producto, deber escoger nuevo
109 - 162
producto para registrar el
producto.
2.-El sistema mostrar una
pantalla donde podr llenar datos
de dicho producto el cual podr ser
almacenado presionando el botn
guardar
presionar el botn 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
accin y saldr a la pgina principal
automticamente.
3.5.4. Diagramas de robustez
decir, comprobar si el texto caso de uso es correcto. ste es un diagrama que no
tiene que mantenerse al da ya que se utiliza slo para la transicin.
e) Administrar producto.
A continuacin se describe grficamente el proceso para administrar producto
110 - 162
Figura 41: Diagrama de robustez de Administrar producto
3:Enva datos
2:Selecciona tipo
Gestor tipo Tipo_Producto
1:Seleccionar opcin
IU: Men administrador 4:Registra datos

IU:Registrar prodcuto
5:Enva datos
7:Enva datos Gestor producto Producto
6:Selecciona
producto
IU: Modificar/Eliminar

A continuacin se describe grficamente el diagrama del modelado del dominio de la

aplicacin mvil Android de gestin de abastecimiento de productos.
111 - 162
abastecimiento de productos
1 1
Usuario
Chef
-Nombre 1
-CI -pedido
-Celular -empresa
-Contrasea
-Tipo_de_usuario
1 n
+Eliminar()
+Editar() +modificar()
tipo_usuario tipo_producto 1
-t_usuario -tipo_producto
+Editar () Producto
1
+eliminar()
-nombre_producto
-ingredientes
-precio
-tipo
+Eliminar()
+Editar()
+Agregar()
3.5.6. Codificar el mdulo de Servicios de catering
A continuacin se muestra una parte del cdigo empleado en el mdulo.
112 - 162
Figura 43: Codificacin de Servicios de catering
Figura 44: Registrar un producto
113 - 162
3.5.7. Realizar pruebas de funcionamiento.
A continuacin se presenta las pruebas funcionales del mdulo de la aplicacin mvil

Android para el Servicios de catering.
Figura 45: Prueba funcional Servicios de catering.
El formulario consiste en Controlar llenado

Exitoso
llenar datos del producto de datos en vaco
Registrar
producto
Verificacin de
El sistema muestra la opcin
editar y eliminar Exitoso
de editar eliminar producto
producto
3.6. DESARROLLAR LA APLICACIN MVIL ANDROID PARA LA

GESTIN DE ABASTECIMIENTO DE PRODUCTOS.
A continuacin se describen los procesos para desarrollar el modulo de la aplicacin

para la gestin de abastecimiento de productos.
3.6.1. Realizar anlisis de requerimientos.
En base al anlisis 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 gestin de abastecimiento de productos donde se involucran el administrador, chef
y encargado de compras.
Tabla 26: Tabla de requerimientos
114 - 162
3.6.2. Identificar tipos de usuario.
La siguiente tabla describe la actividad de cada usuario que interactuar con el

sistema mediante un mvil.
Tabla 27: Identificacin de tipos de usuario.
ACTORES TAREAS
uc Modelo ... 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 informacin de la lista de
ingredientes solicitados para poder realizar
Encargado de compras
la compra y registrar compras realizadas.
3.6.3. Disear los diagramas de casos de uso
A continuacin se desarrollar los distintos diagramas de caso de uso expandido

para el modulo de la aplicacin mvil para la gestin 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
Tabla 28: Descripcin de caso de uso expandido Registrar pedido
Casos de uso: Registrar pedido

Actores: Chef
Tipo: Segundo
Descripcin: El Chef debe realizar los pedidos que requiere para
la empresa tomando en cuenta los diferentes
productos que ofrece el servicio catering
VALENCIA.
Tabla 29: Descripcin de accin de actores Registrar pedido

1.- El Chef deber ingresar a
Registrar pedido para poder
116 - 162
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 botn pedir
4.- El sistema mostrar la opcin
enviar
5.-El Chef deber presionar el
botn enviar para poder
confirmar el pedido.
6.- El sistema mostrar un mensaje
Su pedido ha sido enviado
correctamente
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
Tabla 30: Descripcin de caso de uso expandido de Visualiza pedido y registra

compra
Casos de uso: Registrar pedido

Actores: Encargado de compras
Tipo: Tercero
Descripcin: El encargado de compras tendr que ver los
pedidos para realizar las compras de los
ingredientes solicitados.
Tabla 31: Descripcin de accin de actores de Visualiza pedido y registra compra

1.- El Encargado de compras
despus de ingresar al sistema
tendr dos opciones ver pedido y
compras realizadas deber
presionar primeramente ver
118 - 162
pedido para poder ver la solicitud
de ingredientes que debe comprar.
2.-El sistema mostrar la lista de
ingredientes que debe comprar
con la opcin de tickear las
compras que ya realiz.
3.- El encargado de compras
deber presionar el botn
compras realizadas para poder
visualizar las compras ya hechas.
4.- El sistema mostrar una lista de
los ingredientes que fueron
registrados como comprados.
3.6.4. Diagramas de robustez
decir, comprobar si el texto caso de uso es correcto. ste es un diagrama que no
tiene que mantenerse al da ya que se utiliza slo para la transicin.
f) Registrar pedido.
A continuacin se describe grficamente el proceso para registrar pedido
119 - 162
Figura 48: Diagrama de robustez de registrar pedido
3:Enva datos
2:Seleccina
tipo de Gestor producto Producto
1:Ingresar a producto
tipo de
producto
4:Registra datos
IU:Tipos de productos de pedido
IU:Men de chef
5:Enviar datos
6:Lista de
pedidos
registrados Gestor pedido Pedido
IU:Pedidos
g) Visualiza pedido y registra compras.
A continuacin se describe grficamente el proceso de Visualiza pedido y registra

compras
120 - 162
Figura 49: Diagrama de robustez de Visualiza pedido y registra compras
4:Envia datos de cantidad
Gestor stock Stock
3:Enva datos
5:Enva
1:Selecciona ingredientes 6:Enva datos
2:Envia datos
fecha del producto del producto
IU:Men encargado de
IU:Pedidos Gestor compras Gestor producto Producto
compras
7:Registra compras
IU:Compras realizadas

A continuacin se describe grficamente el diagrama del modelado del dominio de la

aplicacin mvil Android de gestin de abastecimiento de productos.
121 - 162
abastecimiento de productos
1 1
Usuario
Chef
-Nombre 1
-Apellido1 1 -id_usuario
-CI -pedido
-Celular -empresa
-Contrasea
-Tipo_de_usuario
1 n
+Eliminar()
1 +Editar() +modificar()
tipo_usuario tipo_producto 1
-t_usuario -tipo_producto
+Editar () n Producto
1
+eliminar() n -nombre_producto
-ingredientes
1 -precio
Pedido
-tipo
-tipo_producto 1 +Eliminar()
-producto +Editar()
-cantidad +Agregar()
-fecha
+editar()
3.6.6. Implementar el mdulo para la gestin de abastecimiento de productos.
A continuacin se mostrarn las interfaces requeridas para el mdulo de gestin de

abastecimiento de productos para el servicio de catering.
122 - 162
Figura 51: Interfaces para el registro de pedidos
Figura 52: Interfaces para enviar pedido
123 - 162
Figura 53: Interfaces para el encargado de compras
3.6.7. Realizar pruebas de funcionamiento.
A continuacin se presenta las pruebas funcionales del mdulo de la aplicacin mvil

Android para la gestin de abastecimiento de productos.
124 - 162
Figura 54: Prueba funcional del caso de uso registro de datos.

Registra pedido y cantidad Ingresar cantidad
Exitoso
Aplicacin de personas de pedido
mvil Android El sistema realiza Ingresa cantidad
para la gestin operaciones de los de pedido y
Exitoso
de ingredientes con la cantidad visualiza los
abastecimiento de pedido ingredientes
de productos El encargado visualiza
Registra compras Exitoso
pedido del chef
3.7. SINCRONIZACIN DE LA APLICACIN CLIENTE CON LA

APLICACIN SERVIDOR HACIENDO USO DE DATA STORAGE
EN LA NUBE.
3.7.1. Diagrama del proceso de sincronizacin.
Figura 55: Proceso de sincronizacin
Sincronizacin
BD
API REST
Servidor
web
125 - 162
3.7.2. Realizar las pruebas de funcionalidad.
A continuacin se muestran las capturas de pantalla del sistema en ejecucin.
Figura 56: Sistema en ejecucin
Figura 57: Conexin activa
3.8. REALIZAR PRUEBAS DEL SISTEMA TERMINADO.
A continuacin se detalla el tipo de prueba adecuado para el sistema.
3.8.1. Identificar los tipos de pruebas adecuados.
Existen varios mtodos para evaluar el funcionamiento de un sistema. Para cumplir

con la validacin y verificacin del sistema, se eligieron las pruebas de caja negra
126 - 162
debido a que se basan en la evaluacin 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 mdulos.
A continuacin 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

autenticacin de usuario del sistema.
Tabla 32: Autentificacin de usuario de usuario
Caso de prueba # 1 Autenticacin de usuario
Propsito Autenticarse en el sistema ingresando los datos de

usuario que son el usuario y la contrasea.
Pre-requisitos Ninguno
Datos de entrada central Entrada Salida
Usuario: Giovana Usuario correcto:
Contrasea: Giovana Mostrar la pantalla para el

administrador.
Usuario: Giovan Usuario incorrecto:
Contrasea: Giovana Mostrar mensaje de error

Sus datos son
incorrectos
Pasos 1. Ingresar datos de usuario: usuario y contrasea
2. Presionar el botn de ingresar
Resultados esperados - Los datos son ingresados
127 - 162
- Ingresar a la pantalla principal
- Devolver valor de error Sus datos son incorrectos
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
Propsito Registrar un producto con todos los datos que se

requiere para tener una informacin clara y efectiva.
Pre-requisitos Recetas definidas

Nombre del producto: Datos correctos:
Precio del producto: Mostrar pantalla con nuevo
Seleccin 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
Seleccin de tipo de estar llenados
producto: XXXX
Agregar ingredientes:
XXXX
Pasos 1. Ingresar datos del producto
2. Presionar el botn de Guardar producto
128 - 162
- Ingresar a la pantalla de nuevo producto
- Devolver valor de error Todos los campos deben estar
llenados
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
Propsito Registrar un pedido de acuerdo a la solicitud de la

empresa
Pre-requisitos Ninguno

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 botn de Enviar
- Ingresar a la pantalla principal de pedido
- Devolver valor de error Debe llenar todos los campos
129 - 162
3.8.3. Documentar las pruebas.
A continuacin se muestran las capturas de las pruebas descritas anteriormente.
Figura 58: Autentificacin de usuarios
Figura 59: Registrar un producto
130 - 162
Figura 60: Registrar un pedido
3.9. DEMOSTRACIN DE LA HIPOTESIS.
El sistema de gestin de abastecimiento de productos y servicios de catering integrado

con una aplicacin mvil Android permitir reducir el nmero de errores en la
elaboracin de la lista de productos que se deben comprar, as mismo reducir el tiempo
en la organizacin del Servicio de Catering para las empresas.
Para demostrar la hiptesis es necesario analizar las variables dependientes de la

hiptesis
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.
131 - 162
Los procedimientos que se llevan a cabo de registros generan una demora al momento
de la organizacin fundamentalmente para la entrega de productos a cada chef
encargado del Servicio de Catering de la empresa.
3.9.1. Demostracin de la primera variable dependiente.
A continuacin 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 transcripcin de pedidos de

ingredientes y solamente sern registrados en el sistema el cual har un clculo
automtico de la cantidad que se requiere, en este caso se supone que se considera
un mnimo 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 mnimo de 5 errores
por ao.
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 conclusin obtenemos un 95.83% de reduccin de errores utilizando el sistema

propuesto.
3.9.2. Demostracin de la segunda variable.
Para la demostracin de la segunda variable dependiente donde el tiempo invertido en

el proceso se realiza una comparacin con el sistema actual y con el sistema propuesto
que se describe en la siguiente tabla:
Tabla 35: Demostracin de la segunda variable dependiente
Pasos sin Tiempo sin Pasos con Tiempo con

Actividad
sistema sistema. sistema sistema.
El chef realiza
Registro de
la lista de El chef ingresa
ingredientes
ingredientes al sistema y
que se
que se registra
solicita para
requieren para 50 min cantidad de 20 min.
la
la preparacin pedidos
preparacin
de productos
de los
que fueron
productos
solicitados
Se realiza la El encargado
Proceso de revisin de ingresa al
verificacin pedidos de sistema y
de pedidos ingredientes 30min visualiza los 5 min.
solicitados por el pedidos de
por el chef encargado de ingredientes
compras
133 - 162
Pasos sin Tiempo sin Pasos con Tiempo con
Actividad
sistema sistema. sistema sistema.
Proceso de El chef enva
entrega de Se realiza una pedido por
pedidos al comunicacin medio de la
chef para va llamadas o aplicacin sin
que se mensajes para 180 min tener un 5 min
realice las la entrega de contacto
compras de listas de personal con
los pedidos el encargado
ingredientes de compras
Total tiempo
260 min Total tiempo 30 min
Despus de haber analizado el tiempo en la realizacin 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. Demostracin de la variable independiente.
En la demostracin de la variable independiente, se realiza el anlisis a travs 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: Demostracin 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
el personal.
3 Permite registrar producto con sus SI SI
respectivos ingredientes.
4 Permite la registrar los ingredientes que se NO SI
almacenan en la bodega
5 Permite visualizar el stock de productos NO SI
almacenado en la bodega
6 Permite verificar las compras realizadas de NO SI
los ingredientes
7 Permite registrar pedidos desde una NO SI
aplicacin mvil
8 Permite obtener los registros del control del NO SI
personal del dispositivo biomtrico.
9 Permite registrar men de la semana SI SI
TOTAL 3 (SI) 9 (SI)
Teniendo como resultado del anlisis 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 tomarn en cuenta en el clculo de estadstico T student
para realizar la aceptacin o rechazo de la hiptesis.
135 - 162
Para la definir la hiptesis se considera el anlisis de aceptacin y rechazo de la
misma, haciendo referencia a un que representa una probabilidad, en nuestro caso
tenemos que:
1 = Nmero de errores cometidos en la elaboracin de pedidos.

2 = El tiempo en la verificacin de ingredientes comprados.
Y para los factores que influyen en la Operativizacin son:
Hiptesis nula: Los factores de xito de antes son iguales a los factores de xito
posteriores:
0 : 1 = 2
Hiptesis 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 gestin 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 gestin 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 gestin 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 gestin de abastecimiento y servicio de catering).
136 - 162
Clculo del estadstico T.
Este clculo permite conocer la aceptacin de la hiptesis, teniendo en cuenta que

existe un rango de aceptacin. Luego con el dato encontrado con las probabilidades
se ubica si est dentro del rango de aceptacin o rechazo. Para ello se realiza los
clculos con las siguientes frmulas:
( ) + ( )
=
+

=

+
Dnde:
= Probabilidad de ocurrencia de uno de los casos
= Nmero de aciertos en la muestra de la probabilidad
= Nmero de muestras (beneficios analizados)
= Valor estadstico para la aceptacin o rechazo de la hiptesis
= Probabilidad de concurrencia de uno de los casos
= nivel de significancia
= Grado de libertad
137 - 162
=
3
1 = 9 = 0,33331 Alcanz un 33% de los beneficios de la muestra.
9
2 = 9 = 12 Alcanz un 100% de los beneficios de la muestra.
1 < 2 Por lo tanto 2 es mejor que 1 .
Segn el clculo t-student se considera el valor de de acuerdo con el nmero de

muestras que se tiene. En este caso, considerndose de una muestra menor a 100, el
valor es de 0.05 para hacer el clculo del grado de error.
0,05
= = 0,025
2
= 8
De acuerdo al clculo de 1 y 2 se acepta la hiptesis 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 hiptesis 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 hiptesis es nula (0 ) y la aceptacin (hiptesis alternativa 1 ) de la hiptesis
se encuentra fuera de estos rangos
3
1 = 9 = 0,3333 Entonces 1 = 1 0,3333 = 0,6667
9
2 = 9 = 1 Entonces 2 = 1 1 = 0
0,3333 1
= = 4,2429
0,3333 0,6667 + 1 0
9 9
Campana de Gauss para la aceptacin de la hiptesis
138 - 162
Figura 61: Campana de gauss
1 1
1 : 1 < 2 1 : 1 > 2
4,2429 2,3060 2,3060
Despus de realizar el anlisis del clculo de T-Student se puede indicar que se

rechaza la hiptesis 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 estadstico 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 ms
beneficios que el sistema actualmente existente permitiendo un proceso ptimo del
servicio de catering.
139 - 162
BOLIVIA
CAPTULO 4
ANLISIS DE
VIABILIDAD.
4. ANLISIS DE VIABILIDAD
A continuacin se realizar un anlisis en tres aspectos que son viabilidad tcnica,

econmica y operativa.
4.1. VIABILIDAD TCNICA.
Para el desarrollo del presente proyecto y funcionamiento de la aplicacin mvil se

debe cumplir con los siguientes requerimientos en cuanto Software y Hardware, en la
tabla que se muestra a continuacin se muestra a detalle los requerimientos de
Hardware para el servidor web y el mvil.
Tabla 37: Requerimientos de hardware
HARDWARE REQUERIMIENTO MNIMO REQUERIMIENTO IDEAL
- Procesador Pentium IV - Procesador CORE i7

1.2Ghz. 3.7Ghz.
- Memoria RAM 1GB. - Memoria RAM 4GB.
SERVIDOR WEB - Disco duro 100GB. - Disco duro 180GB
- Monitor resolucin - Monitor resolucin
1024x768. 1024x768.
- Teclado y mouse - Teclado y mouse.
- Procesador Broadcom - Procesador 1.9Ghz. (Quad-
BCM21654G/ARM Cortex- Core).
A5. - RAM 2GB.
- RAM 768MB - Memoria interna 16GB
CLIENTE MVIL
- Memoria interna 4GB - Pantalla 136.6x69.8x7.9
(2GB accesible al mm.
usuario).
- Pantalla 58.6x109.4 mm.
141 - 162
A continuacin se muestra una tabla a detalle los requerimientos mnimos e ideales
para el servidor web y cliente en cuanto a software para el correcto funcionamiento de
la aplicacin mvil.
Tabla 38: Requerimientos de Software
HARDWARE REQUERIMIENTO MNIMO REQUERIMIENTO IDEAL
- Sistema operativo XP. - Sistema operativo

- Navegador Explorer. Windows7.
- Cuenta de Gmail. - Navegador Google Chrome.
- Gestor de base de datos - Cuenta de Gmail.
SERVIDOR WEB
MySQL almacenados en - Gestor de base de datos
Google cloud Platform. MySQL almacenados en
- Banda ancha 128kbps. Google cloud Platform.
- Banda ancha 1Mbps.
- Sistema operativo Android - Sistema operativo Android
CLIENTE MVIL 4.0. 5.0.
- Plan de datos 3G. - Plan de datos 4G.
Despus del anlisis 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 adquisicin 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 fsico simplemente una cuenta de Gmail
para asociarla con un servicio de Google cloud Platform, en cuanto al cliente mvil la
mayora 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, adems que estos se encuentran disponibles en el mercado,
concluyendo as que el proyecto es tcnicamente viable.
142 - 162
4.2. VIABILIDAD ECONMICA.
El presente proyecto se realiz con la utilizacin de diferentes herramientas
programacin 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 implementacin del proyecto.
A continuacin se describe los precios de los requerimientos mnimos y requerimientos

ideales tanto en hardware como en software para el servidor.
Tabla 39: Costos de Hardware y Software del servidor
HERRAMIENTA COSTO MNIMO Bs. COSTO IDEAL
Pc incluyendo Procesador
Memoria
Disco duro 2150 4020
Monitor
Teclado y mouse
Sistema operativo XP.
Navegador Explorer.
Cuenta de Gmail.
Gestor de base de datos 0 0
MySQL almacenados en
Google cloud Platform.
Banda ancha 128kbps.
TOTAL Bs 2150.- Bs 4020.-
143 - 162
En la siguiente tabla se muestra el anlisis de costos del hardware y software del para
el cliente mvil.
Tabla 40: Costos de Hardware y Software del cliente
HERRAMIENTA COSTO MNIMO Bs. COSTO IDEAL
Requerimiento
Tcnico (Mvil de
300 1750
reserva en la
empresa)
Sistema
operativo Android
4.0. 0 0
Plan de datos
3G.
TOTAL Bs 300.- Bs 1750.-
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, exponindolo
detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981).
COCOMO es una jerarqua de modelos de estimacin de costos que hace referencia
al modo de desarrollo del proyecto, que influye directamente en el costo y duracin del
mismo, y que puede ser:
A. Modelo orgnico: cuando el proyecto es desarrollado en un ambiente familiar

y estable, en el que el producto es similar a otros desarrollados previamente.
Son adems productos pequeos y poco novedosos, con unos requerimientos
definidos y poco rgidos.
144 - 162
B. Modelo semiacoplado: es un modelo para proyectos que presentan
caractersticas intermedias entre el orgnico y el empotrado, con un equipo
formado por miembros de distintos niveles de experiencia, que trabajan sobre
un conjunto de requisitos ms o menos flexibles.
C. Modelo Empotrado: para proyectos caracterizados por unos requerimientos y
restricciones poco flexibles, que requieren un gran esfuerzo de innovacin.
Tambin poseen un elevado nivel de complejidad en hardware.
Tabla 41: Valores COCOMO
Modo ai bi ai bi
Orgnico
3.20 1.05 2.50 0.38
Semiacoplado
3.00 1.12 2.50 0.35
Empotrado
2.80 1.20 2.50 0.32
Fuente: (Boehm, 1981)
Para el siguiente proyecto se utilizar el modo orgnico, porque se tienen los

requerimientos bien definidos.
COCOMO est definido en trminos de tres modelos diferentes: modelo bsico,

modelo intermedio y modelo detallado, que reflejan el nivel de detalle considerado a
la hora de realizar la estimacin del coste. Segn la teora, el modelo intermedio y el
detallado, usan un Factor de ajuste del esfuerzo (EAF), cuyos valores se pueden
obtener en base a la ecuacin determinada para cada tipo de modelo como se puede
apreciar continuacin en la siguiente tabla:
145 - 162
Tabla 42: Ecuacin bsica del esfuerzo en COCOMO (Modelo intermedio y
Detallado).
MODO DE DESARROLLO ECUACIN BSICA
ORGNICO = 3,2 1,05
SEMIACOPLADO = 3.0 1,12
EMPOTRADO = 3.8 1.2
Para determinar el tiempo de desarrollo se tiene:
Tabla 43: Ecuacin bsica del tiempo en COCOMO (Modelo intermedio).
MODO DE DESARROLLO ECUACIN BSICA
ORGNICO = 2,5 0,38
SEMIACOPLADO = 2,5 0,32
EMPOTRADO = 2,5 0,35
La ecuacin del esfuerzo y del tiempo de Desarrollo que se utilizarn ser para el
Modelo de desarrollo Orgnico, a continuacin 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 duracin y el coste del proyecto, a continuacin
se pueden apreciar los valores seleccionados para cada factor:
Tabla 44: Factores de Costo en COCOMO
Conductores del Grados

coste Muy Bajo Medio Alto Muy Extra
bajo alto altor
CUALIDADES DE
PRODUCTO
Fiabilidad requerida 0.75 0.88 1.00 1.15 1.40 -
del software
Tamao de la base - 0.94 1.00 1.08 1.16 -
de datos del uso
Complejidad del 0.70 0.85 1.00 1.15 1.30 1.65
producto
CUALIDADES DEL
HARDWARE
Restricciones del - - 1.00 1.11 1.30 1.66
tiempo de ejecucin
Restricciones del - - 1.00 1.06 1.21 1.56
almacenamiento
principal
Volatilidad del - 0.87 1.00 1.15 1.30 -
ambiente virtual de
la mquina
Tiempo de - 0.87 1.00 1.07 1.15 -
respuesta de
ordenador
147 - 162
Conductores del Grados
coste Muy Bajo Medio Alto Muy Extra
bajo alto altor
CUALIDADES DEL
PERSONAL
Capacidad del 1.46 1.19 1.00 0.86 0.71 -
analista
Experiencia de los 1.29 1.13 1.00 0.91 0.82 -
usos
Capacidad de los 1.42 1.17 1.00 0.86 0.70 -
programadores
Experiencia en 1.21 1.10 1.00 0.90 - -
sistema operativo
utilizado
Experiencia del 1.14 1.07 1.00 0.95 - -
lenguaje de
programacin
CUALIDADES DEL
PROYECTO
Uso de las 1.24 1.10 1.00 0.91 0.82 -
herramientas del
software
Uso de los mtodos 1.24 1.10 1.00 0.91 0.83 -
de la tecnologa de
dotacin lgica
Horario requerido 1.23 1.08 1.00 1.04 1.10 -
del desarrollo
La justificacin de la seleccin 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
multiplicarn y se obtendrn 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 lneas de cdigo fuente se ha contado las lneas
de cada clase de la arquitectura MVC, para lo cual se utiliza la herramienta Code Line
Counter Pro Versin 6.5.
Archivo SLOC
MODELO (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 (lneas
de cdigo fuente), con las siguientes restricciones. Sumar las lneas de cdigo creadas
por el personal del proyecto. Se considera que una instruccin es una lnea de cdigo.
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 lneas de cdigo, 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 situacin en ste caso, el proyecto ha sido desarrollado por
una sola persona. Se ha considerado el trabajo en das laborales de lunes a sbado,
2 horas al da, lo que supone unas 40 horas al mes. Y segn 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 aproximacin del costo de desarrollo del proyecto se ha

averiguado que el sueldo para el rea de programacin en Bolivia oscila entre los
valores de Bs. 30 a Bs. 40 por lo tanto se toma en cuenta el costo mnimo Bs. 30 por
hora promedio.
Por tanto ajustando el horario de trabajo del autor del proyecto (2 horas al da), 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 segn el horario:

289,532[] 35 [ ] = 10.133,62[. ]

Obteniendo el resultado de la ecuacin 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 mnimos e ideales son:
Tabla 45: Costos totales mnimos e ideales
COSTO MNIMO Bs. COSTO IDEAL
Costo de hardware y
2150 4020
software del servidor
Costo de hardware y
300 1750
software del cliente mvil
Costo desarrollo del
10.133,62 10.133,62
proyecto
TOTAL Bs 12.583,62.- Bs 15903.62.-
De esta manera, se ha empleado el mtodo de estimacin de costos COCOMO,

calculando los valores para medir el esfuerzo (E), cantidad de lneas de cdigo
(KSLOC), el ajuste de los factores de esfuerzo (EAF) y el tiempo para el desarrollo del
proyecto, determinando as que el costo mnimo 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. Anlisis de beneficio costo
A continuacin de determina el anlisis Beneficio/costo detalladamente, para

desarrollar el anlisis 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
DESCRIPCIN MONTO SIN SISTEMA MONTO CON SISTEMA
Costo en material de
372 Bs.- 0,00 Bs.-
escritorio.
152 - 162
DESCRIPCIN MONTO SIN SISTEMA MONTO CON SISTEMA
Costo de llamadas para la

comunicacin entre 1440 Bs.- 0,00 Bs.-
usuarios
Costo del tiempo invertido

el proceso de elaboracin 7200 Bs.- 2400 bs.-
de reportes
TOTAL Bs.-12312 Bs.-3550
Para el clculo de la estimacin Beneficio/Costo se tiene:
Si B/C > 1 el proyecto es viable econmicamente ya que los beneficios superan a

los costos.
Si B/C < 1 el proyecto no es viable econmicamente ya que los beneficios son

superados
Para el clculo de la estimacin Beneficio/Costo se tiene:

=1
(1 + )
/ =

0 + =1
(1 + )
= 2.31% Basado en el Banco Nacional de Bolivia (BNB)
Alcance temporal = 5 aos
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 implantacin del proyecto son justificables respecto al costo invertido para su
desarrollo del sistema. Por lo tanto el proyecto es econmicamente viable.
4.3. VIABILIDAD OPERATIVA.
El proceso actual de administracin 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
informacin de manera oportuna.
Una vez implementado la aplicacin mvil Android ser capaz de obtener informacin
de datos actuales sobre los productos necesarios para el abastecimiento de la
empresa por medio de un servidor que permitir al dueo llevar un registro controlado
mediante un diseo 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 segn funciones de cargo
CARGO NIVEL DE COMPLEJIDAD
Administrador Alto
Chef Medio
Encargado de compras Bajo
154 - 162
Para el uso de la aplicacin mvil se tienen los siguientes roles: Administrador,

vendedor por mayor.
Administrador:
El administrador es el dueo de la empresa, el tiene la ponderacin de realizar todas

las tareas en cuanto al control de stock, gestin de usuarios, registrar productos, tiene
que estar al tanto de toda la informacin 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 tambin podr registrar las
compras realizadas.
155 - 162
BOLIVIA
CAPTULO 5
CONCLUSIONES Y
RECOMENDACIONES.
5. CONCLUSIONES Y RECOMENDACIONES.
A continuacin se describen conclusiones y recomendaciones acerca del sistema de

gestin de abastecimiento y servicio de catering integrado con una aplicacin mvil
Android.
5.1. CONCLUSIONES
A continuacin se detallarn 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 travs 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 gestin de abastecimiento, pedido y compras de productos para el
servicio de catering lo cual llevo a la comprensin de la lgica de negocio y la
identificacin de los aspectos que pueden mejorar el uso de la tecnologa y
respectivo desarrollo del sistema.
Con el diseo del modelado de negocio alternativo se logro elaborar la propuesta
de una nueva lgica de negocio en la cual los procedimientos estn basados en la
utilizacin de la aplicacin mvil, 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 mdulo de gestin de usuarios para el personal de la empresa
permite la introduccin y almacenamiento de informacin bsica requerida de cada
involucrado en el proceso de trabajo que realiza la empresa as mismo asigna a
cada participante la labor que debe desempear dentro la empresa servicios de
catering VALENCIA.
Se desarroll un mdulo de control de stock para el usuario el cual permite de
manera fcil 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 implementacin del mdulo 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 mvil de los empleados
de la empresa.
Se desarroll un mdulo de gestin 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 elaboracin 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 aplicacin mvil se decidi
utilizar los servicios REST API e intercambio de datos aplicando JSON que
reducen el tiempo de intercambio de datos y sincronizacin entre ambos.
Finalmente se han realizado pruebas con usuarios finales verificando que el
sistema concluye con los requisitos solicitados por el administrador y dueo de la
empresa
Con la hiptesis planteada en el proyecto se ha demostrado que los beneficios

principales del sistema desarrollado estn relacionados con las disminucin de tiempo
invertido en el proceso de organizacin del servicio de catering para las empresas
disminuyendo la probabilidad del riesgo de errores en la informacin al registrar la lista
de ingredientes que se deben comprar, por lo cual se concluye que la aplicacin 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 gestin de abastecimiento de productos y servicios de catering
integrado con una aplicacin mvil Android, logrando obtener informacin confiable y
rpida, reduciendo el tiempo invertido en el proceso de elaboracin de pedidos y
157 - 162
compra de ingredientes y disminuyendo los errores en la elaboracin de listas de
productos y gastos econmicos por este motivo.
5.2. RECOMENDACIONES
Las recomendaciones de funcionamiento son:
Para un buen funcionamiento del sistema se recomienda cumplir con los

requerimientos mnimos de hardware establecidos en la viabilidad tcnica.
Se recomienda la capacitacin previa a la implantacin 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 pgina web para los clientes, donde se pueda
promocionar productos, compartir los servicios que brinda la empresa y todas las
caractersticas 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
BIBLIOGRAFA
Alonso, G. (2004). Web Services Concepts, Architectures and Applications.

Springer.
AndroidGuys. (2009). Appcelerator, un nuevo concepto iSuriv's Weblog Dame

Tonos - Telefona Mvil en su ms 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-for-
android.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
Girons, J. T. (2013). El gran libro de Android. marcombo, S.A.
Gutierrez, D. (2011). Mtodos de desarrollo de software. Venezuela: Universidad

de los Andes.
Gutirrez, 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 Villafaa, H. (2009). Ingeniera en sistemas

computacionales. Instituto Tecnolgico de Toluca.
Marin, d. l. (2014). Phonegap y Titanium Appcelerator. Retrieved from

http://www.marindelafuente.com.ar/phonegap-y-titanium-appcelerator/
Martnez, H. L., Ceceas, T. P., & Leyva, A. M. (2015). Lo que se de

computacin. Mxico : Universidad Jurez del Estado de Durango.
MINGUET, M. J. (2008). nformtica Fundamental. Ramn 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.
Nez Mori, J. G. (2010). Usabilidad en metodologas agiles. Espaa:

Universidad Politcnica de Madrid.
Pez, N. (2014). Construccin de software: una mirada gil. Retrieved from

http://dominointernet.com/el-manifiesto-agile/
Perdita Stevens, R. P. (2002). Utilizacin de UML en Ingeniera del Software con

Objetos y Componentes.
Petkovic, D. (2008). MICROSOFT SQL SERVER. Germany: Mcgraw-hill.
Pressman, R. (2005). Ingeniera de Software: Un Enfoque Prctico (Sexta ed.).

McGraw-Hill.
160 - 162
Pressman, R. (2010). Ingeniera de Software: Un Enfoque Prctico (Sptima ed.).
McGraw-Hill.
Pressman, R. (2010). Ingeniera de Software: Un Enfoque Prctico (Sptima 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-php-
mysql-json/
Ribas, L. J. (2011). Desarrollo de aplicaciones para Android. En J. R. Lequerica.
Rodrguez, A. (2009). ENTORNO DE DESARROLLO (IDE) JAVA. Retrieved from

http://www.aprenderaprogramar.com/index.php?option=com_attachments&task=
download&id=345
Rmmel, F. (2007). Base de Datos SQLite. Retrieved from

http://sg.com.mx/revista/17/sqlite-la-base-datos-embebida#.VD27zfmG8T8
Sacristn, C. R., & Fernndez, D. R. (2012). Programacin en Android. Espaa:

Mentor.
Scientia, e. T. (2007). Universidad Tecnolgica de Pereira. ISSN 0122-1701.
Scott, K., & Rosenberg, D. (2001). ICONIX Software Engineering.
Shafer, D. (2003). Revolucin : Software a la velocidad del pensamiento. Tiempo

de ejecucin revolucin Ltd, Volumen 1.
Shane Conder, L. D. (2012). Android Wireless Application Development.

Retrieved from http://www.4rsoluciones.com/que-es-un-kit-de-desarrollo-de-
software-sdk/
161 - 162
Sommerville, I. (2005). Ingeniera de Software. Madrid, Espaa: Pearson
Educacin S.A.
Sommerville, I. (2011). Ingeniera de Software. (novena edicin). Mxico:

Pearson Educacin S.A.
Sosinformatico. (2012). Desarrollo y Programacin. 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-para-
desarrolladores-android.html
162 - 162
ANEXOS
ANEXO A: Servicio de Catering
ANEXO B: Licitacin del Servicio de Catering
ANEXO C: Entrevista al gerente de la empresa
ANEXO D: Diagrama Ishikawa.
Proceso manual de Registro manual de

registro de productos. empresas que solicitan
Servicio de Catering.
Ilegibilidad. Ilegibilidad.
Tareas repetitivas de confeccin
Proceso moroso en la Demora en la toma
de listas diarias de productos
toma de datos. de datos.
faltantes, prdida de tiempo en la
revisin de los pedidos realizados
por las empresas para determinar
los productos que deben
abastecerse y gastos innecesarios
Revisin de productos
en la adquisicin de productos
Revisin de compras faltantes.
que se tienen disponibles.
realizadas. Registro de cantidad de
productos incorrecto. Elaboracin de una sola
lista comn.
La verificacin de Lista de productos puede

productos es moroso. contener errores.
ANEXO E: Conformidad y aceptacin de interfaces
Anexo F: Tabla de justificaciones
Valor
Factores de costo Justificacion
escogido
Fiabilidad requerida del El software maneja varios datos los cuales deben ser fiables y
alto
software disponibles para su correcto funcionamiento.
Tamao de la base de datos Es medio porque la empresa an no cuenta con una gran
medio
del uso cantidad de datos ya que trabaja con pocas empresas.
Es bajo dado que el proyecto no demanda procesos

Complejidad del producto bajo
complejos o de seguridad de datos.
Restricciones del tiempo de
bajo No se tiene tiempo de restriccin de tiempo de ejecucin.
ejecucin
Restricciones del Se toma bajo dado que no se tiene restricciones de
bajo
almacenamiento principal almacenamiento.
Volatilidad del ambiente Esta caracterstica no se aplica al proyecto pero como es
bajo
virtual de la mquina requerida para los clculos se toma bajo.
Tiempo de respuesta de No se tiene una exigencia de tiempo de respuesta rpida, sin

medio
ordenador embargo eso no quiere decir que no importe.
La capacidad del analista es medio dado que no tiene mucha

Capacidad del analista medio
experiencia en trabajos similares.
La experiencia en aplicaciones es media dado que el

Experiencia de los usos medio
desarrollador tiene conocimientos medios sobre aplicaciones.
Capacidad de los Es bajo dado que es la primera vez que el desarrollador

medio
programadores realiza un proyecto con aplicacin mvil y de esa magnitud.
Experiencia en sistema
medio Es alto dado que el sistema opertico se usa a diario.
operativo utilizado
Experiencia del lenguaje de Es medio ya que el desarrollador tiene conocimientos bsicos

bajo
programacin acerca de los lenguajes de programacin.
Uso de las herramientas del Es baja dado que se utiliza herramientas de programacin
bajo
software modernas de los cuales no se tena experiencia.
Uso de los mtodos de la Se tenia base acerca de la utilizacin de herramientas de

alto
tecnologa de dotacin lgica software por lo tanto es alto.
Es medio dado que si fuera bajo, se cumplira con la
Horario requerido del
medio planificacin de desarrollo para el proyecto sin exigencia del
desarrollo
cliente, por otro si el cliente exigiera su propia planificacin.

Borrador Final Después de La Defensa

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Borrador Final Después de La Defensa

Hochgeladen von

Copyright:

Verfügbare Formate

ESCUELA MILITAR DE INGENIERA

MCAL. ANTONIO JOS DE SUCRE

SISTEMA DE GESTIN DE ABASTECIMIENTO DE PRODUCTOS Y

CASO DE ESTUDIO: SERVICIOS DE CATERING VALENCIA

GIOVANA EDITH YUJRA NINA

SISTEMA DE GESTIN DE ABASTECIMIENTO DE PRODUCTOS Y

CASO DE ESTUDIO: SERVICIOS DE CATERING VALENCIA

GIOVANA EDITH YUJRA NINA

Modalidad: Proyecto de Grado,

TUTOR: ING. JHOMIL ZAMBRANA BURGOS

1.1. INTRODUCCIN. ......................................................................................... 1

1.3.1. Identificacin del problema. .......................................................................... 4

1.3.1.1. Identificacin de la situacin problemtica. .................................................. 4

1.3.1.2. Identificacin de las causas. ......................................................................... 5

1.3.2. Formulacin del problema. ........................................................................... 5

1.3.3. Anlisis causa efecto. ................................................................................... 5

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

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

1.4.2. Objetivo especficos y Acciones. .................................................................. 6

1.5. JUSTIFICACIN. ......................................................................................... 8

1.5.1. Justificacin tcnica. ..................................................................................... 9

1.5.2. Justificacin econmica. ............................................................................... 9

1.5.3. Justificacin operativa. ................................................................................. 9

1.6.1. Alcance Temtico. ........................................................................................ 9

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

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

1.7. HIPTESIS. ............................................................................................... 10

1.7.2. Definicin conceptual. ................................................................................ 10

1.7.3. Operativizacin de variables....................................................................... 11

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

2. MARCO TERICO. .................................................................................... 13

2.1. TCNICAS DE RECOPILACIN DE DATOS ............................................ 13

2.1.1. Entrevistas. ................................................................................................. 13

2.1.2. Observacin. .............................................................................................. 14

2.1.3. Cuestionario. .............................................................................................. 14

2.2. INGENIERA DE SOFTWARE.................................................................... 15

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

2.2.2. Patrn de Arquitectura de Modelo Vista Controlador. ................................ 16

2.2.3. Metodologa de desarrollo de software. ...................................................... 18

2.2.3.1. Programacin 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 metodologas .................................. 26

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

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

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

2.2.6.3. Prueba de Usabilidad. ................................................................................ 34

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

2.3.1. Cliente Servidor Mvil. ................................................................................ 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. TECNOLOGAS DE DESARROLLO DE APLICACIONES MVILES ........ 45

2.5.1. APLICACIN MVIL .................................................................................. 45

2.5.1.1. Aplicaciones mviles nativas ...................................................................... 46

2.5.1.2. Aplicaciones mviles web ........................................................................... 48

2.5.1.3. Aplicaciones mviles hibridas ..................................................................... 49

2.5.2.1. jQuery Mobile. ............................................................................................ 51