Trabajo Final Sol

UNIVERSIDAD MEXIQUENSE DEL BICENTENARIO
UNIDAD DE ESTUDIOS SUPERIORES

TEMOAYA
DESARROLLO DE UNA APLICACIÓN MÓVIL iOS Y

ANDROID PARA LA ADMINISTRACIÓN DE
PROYECTOS UTILIZANDO WCF
MEMORIA DE RESIDENCIA
QUE PARA OBTENER EL TÍTULO PROFESIONAL DE:

LICENCIADA EN INFORMÁTICA
PRESENTA:
MARISOL CIRILO MEJIA
ASESOR:
M.C.E. JOSÉ DAVID LÓPEZ RODRÍGUEZ
23 Noviembre de 2017.
UNIVERSIDAD MEXIQUENSE DEL BICENTENARIO
UNIDAD DE ESTUDIOS SUPERIORES
TEMOAYA
DESARROLLO DE UNA APLICACIÓN MÓVIL iOS Y

ANDROID PARA LA ADMINISTRACIÓN DE
PROYECTOS UTILIZANDO WCF
MEMORIA DE RESIDENCIA
QUE PARA OBTENER EL TÍTULO PROFESIONAL DE:

LICENCIADA EN INFORMÁTICA
PRESENTA:
MARISOL CIRILO MEJIA
ASESOR:
M.C.E. JOSÉ DAVID LÓPEZ RODRÍGUEZ
23 Noviembre de 2017.
I
DEDICATORIAS
A Dios por haberme permitido lograr este proyecto en mi vida, al mismo tiempo fortalecer mi
espíritu para ser cada día más fuerte y aferrarme.
A mi papá Fidel Cirilo Anastacio por estar a mi lado incondicionalmente siempre con algún consejo
en tiempos difíciles, también por brindarme todo lo que estuvo en sus manos y siempre recordarme
ser mejor persona cada día.
A mi mamá W. Antonia Mejia Becerril por enseñarme que en la vida hay que ser perseverantes para
obtener lo que se quiere, le agradezco la compañía aquellas noches cuando tenía que terminar alguna
tarea desde el preescolar hasta ahora.
A mis hermanos Ruben Cirilo Mejia, David Cirilo Mejia por compartirme experiencias de vida y
provocarme aquellas risas incontrolables que me hacían olvidar el estrés y la preocupación.
A mi hermana Alejandra Anastacio Gabina por demostrarme su amistad, me siento afortunada de

saber que somos hermanas.
A mis profesores por motivarme cada día y compartirme su valioso conocimiento para formarme
como una profesional en el área de Informática.
VI
ÍNDICE GENERAL
RESUMEN ................................................................................................................................ XIV

INTRODUCCIÓN ........................................................................................................................ 15
JUSTIFICACIÓN ......................................................................................................................... 16
OBJETIVO GENERAL ................................................................................................................ 17
Objetivos específicos ................................................................................................................ 17
MARCO CONTEXTUAL ............................................................................................................ 18
PLANTEAMIENTO DEL PROBLEMA ..................................................................................... 19
ALCANCES ................................................................................................................................. 20
LIMITACIONES .......................................................................................................................... 20
CAPÍTULO I. MARCO TEÓRICO ............................................................................................. 21
1.1. Aplicación móvil ............................................................................................................... 22
1.1.1. Definición de una aplicación móvil .............................................................................. 22
1.1.2. Tipos de aplicaciones móviles ...................................................................................... 22
1.1.2.1. Según el entorno en el que se ejecutan ................................................................. 22
1.1.2.2. Con base a su funcionalidad ................................................................................. 23
1.1.2.3. Según su desarrollo ............................................................................................... 24
1.2. Software para desarrollo de aplicaciones móviles ............................................................ 25
1.3. Xamarin y Visual Studio ................................................................................................... 26
1.3.1. Desarrollo de aplicaciones móviles en Xamarin y Visual Studio ................................. 27
1.3.1.1. Android ................................................................................................................. 27
1.3.1.2. iOS ........................................................................................................................ 28
1.3.1.3. Cross-platform ...................................................................................................... 28
1.3.2. Estructura de una aplicación Black Xaml App (Xamarin.Forms Portable) en Visual
Studio.. ...................................................................................................................................... 29
1.4. Emuladores ....................................................................................................................... 30
1.4.1. Concepto ....................................................................................................................... 30
1.4.2. Emulador de Visual Studio para Android ..................................................................... 30
1.4.3. ¿Cómo ejecutar el emulador?........................................................................................ 30
1.4.4. Función de los botones del emulador............................................................................ 32
1.5. Bases de datos ................................................................................................................... 35
1.5.1. ¿Qué es una base de datos? ........................................................................................... 35
1.5.2. Diccionario de datos ..................................................................................................... 36
VII
1.5.3. Procedimientos almacenados ........................................................................................ 36

1.5.4. Sistema de Gestión de Bases de Datos ......................................................................... 37
1.6. ADO.NET Entity Framework ............................................................................................ 38
1.6.1. Componentes fundamentales de Entity Framework ..................................................... 38
1.6.2. Ventajas de Entity Framework...................................................................................... 38
1.6.3. Entity Data Model ......................................................................................................... 39
1.7. Servicio Web ..................................................................................................................... 39
1.7.1. SOAP ............................................................................................................................. 39
1.7.2. REST ............................................................................................................................. 40
1.7.3. SOA ............................................................................................................................... 40
1.8. WCF (Windows Communication Foundation).................................................................. 40
1.8.1. Servicio Web WCF ........................................................................................................ 41
1.8.2. Ventajas de WCF .......................................................................................................... 42
1.8.3. Consumir un Servicio Web ........................................................................................... 43
1.9. Impacto de las aplicaciones móviles en las empresas ....................................................... 44
1.10. Metodología para el desarrollo de aplicaciones móviles Mobile-D.................................. 45
1.10.1. Fase de exploración....................................................................................................... 46
1.10.2. Fase de inicialización .................................................................................................... 47
1.10.3. Fase de producto ........................................................................................................... 48
1.10.4. Fase de estabilización ................................................................................................... 50
1.10.5. Fase de pruebas y corrección ........................................................................................ 51
CAPíTULO II. DISEÑO Y DESARROLLO DE LA APLICACIÓN MÓVIL ........................... 53
2.1. Exploración ....................................................................................................................... 54
2.1.1. Alcance del sistema....................................................................................................... 54
2.1.2. Descripción general ...................................................................................................... 54
2.1.2.1. Perspectiva ............................................................................................................ 54
2.1.2.2. Funciones .............................................................................................................. 55
2.1.2.3. Restricciones ......................................................................................................... 55
2.1.2.4. Suposiciones y dependencias ................................................................................ 56
2.1.3. Requerimientos ............................................................................................................. 56
2.1.3.1. Requerimientos de interfaces externas .................................................................. 56
2.1.3.2. Requerimientos de interfaces internas .................................................................. 56
VIII
2.1.4. Requerimientos de datos ............................................................................................... 57

2.2. Inicialización ..................................................................................................................... 59
2.2.1. Software de desarrollo................................................................................................... 59
2.2.2. Recursos físicos y técnicos ........................................................................................... 60
2.2.3. Arquitectura .................................................................................................................. 61
2.2.4. Diagrama de actividad .................................................................................................. 62
2.2.5. Diagrama de casos de uso general ................................................................................ 64
2.2.6. Descripción de los casos de uso .................................................................................... 64
2.2.6.1. Caso de uso iniciar sesión ..................................................................................... 65
2.2.6.2. Caso de uso registrar proyecto .............................................................................. 66
2.2.6.3. Caso de uso editar proyecto .................................................................................. 67
2.2.6.4. Caso de uso eliminar proyecto .............................................................................. 68
2.2.6.5. Caso de uso registrar actividad ............................................................................. 69
2.2.6.6. Caso de uso editar actividad ................................................................................. 70
2.2.6.7. Caso de uso eliminar actividad ............................................................................. 71
2.3. Producción ........................................................................................................................ 71
2.3.1. Diccionario de datos ..................................................................................................... 71
2.3.2. Bases de datos ............................................................................................................... 77
2.3.3. Diagrama de clases ....................................................................................................... 77
2.3.4. Diagrama de Entidad-Relación ..................................................................................... 77
2.3.5. Diseño de la aplicación móvil ....................................................................................... 80
2.3.5.1. Interfaz de iniciar sesión ....................................................................................... 80
2.3.5.2. Interfaz de menú ................................................................................................... 80
2.3.5.3. Interfaz de proyecto .............................................................................................. 82
2.3.5.4. Interfaz de editar proyecto .................................................................................... 83
2.3.5.5. Interfaz de actividad .............................................................................................. 85
2.3.5.6. Interfaz editar actividad ........................................................................................ 86
2.3.6. Creación del Web Service WCF (Windows Comunication Fundation) ........................ 88
2.3.6.1. Procedimientos creados en el Web Service WCF ................................................. 93
2.3.6.2. Diagramas de flujo ................................................................................................ 93
2.3. Estabilización .................................................................................................................. 107
2.4. Pruebas y corrección ....................................................................................................... 109
2.4.6. Casos de prueba .......................................................................................................... 111
2.4.6.1. Prueba: registrar proyecto ..................................................................................... 111
2.4.6.2. Prueba: actualizar proyecto ................................................................................. 113
2.4.6.3. Prueba: baja de un proyecto ................................................................................ 115
IX
2.4.6.4. Prueba: registrar actividad .................................................................................. 117

2.4.6.5. Prueba: actualizar actividad ................................................................................ 119
2.4.6.6. Prueba: cancelar operación ................................................................................. 122
2.4.7. Escenarios de pruebas ................................................................................................. 122
2.4.8. Matriz de pruebas de ejecución de la aplicación ........................................................ 123
2.4.9. Velocidad de ejecución de la aplicación ..................................................................... 124
RESULTADOS........................................................................................................................... 125
CONCLUSIONES ...................................................................................................................... 128
RECOMENDACIONES ............................................................................................................. 129
GLOSARIO ................................................................................................................................ 131
REFERENCIAS .......................................................................................................................... 133
X
ÍNDICE DE TABLAS
Tabla 1. Descripción de los elementos de la aplicación Blank Xaml App .................................... 30

Tabla 2. Elementos nombrados del emulador para aplicaciones móviles .................................... 32
Tabla 3. Módulos .......................................................................................................................... 55
Tabla 4. Descripción de las actividades de los usuarios ............................................................... 55
Tabla 5. Reglas de relación de datos ............................................................................................. 57
Tabla 6. Cronograma de actividades ............................................................................................. 58
Tabla 7. Recursos físicos y técnicos para el desarrollo de la aplicación ...................................... 60
Tabla 8. Recursos físicos y técnicos para el servidor SQL Server ................................................ 61
Tabla 9. Caso de uso iniciar sesión ............................................................................................... 65
Tabla 10. Comportamiento de usuario-aplicación en iniciar sesión ............................................. 65
Tabla 11. Caso de uso registrar proyecto ...................................................................................... 66
Tabla 12. Comportamiento usuario-aplicación en registrar proyecto ........................................... 66
Tabla 13. Caso de uso editar proyecto .......................................................................................... 67
Tabla 14. Comportamiento usuario-aplicación en editar proyecto ............................................... 67
Tabla 15. Caso de uso eliminar proyecto ...................................................................................... 68
Tabla 16. Comportamiento usuario-aplicación en eliminar proyecto ........................................... 68
Tabla 17. Caso de uso registrar actividad ..................................................................................... 69
Tabla 18. Comportamiento usuario-aplicación en registrar actividad .......................................... 69
Tabla 19. Caso de uso editar actividad ......................................................................................... 70
Tabla 20. Comportamiento usuario-aplicación en editar actividad .............................................. 70
Tabla 21. Caso de uso eliminar actividad ..................................................................................... 71
Tabla 22. Comportamiento usuario-aplicación en eliminar actividad .......................................... 71
Tabla 23. Diccionario de datos de la entidad TipoActor .............................................................. 72
Tabla 24. Diccionario de datos de la entidad Actor ...................................................................... 72
Tabla 25. Diccionario de datos de la entidad ProyectoAtor ......................................................... 73
Tabla 26. Diccionario de datos de la entidad TipoPrincipal ......................................................... 73
Tabla 27. Diccionario de datos de la entidad Principal ................................................................ 73
Tabla 28. Diccionario de datos de la entidad ProyectoEmpresa ................................................... 74
Tabla 29. Diccionario de datos de la entidad Roles ...................................................................... 74
Tabla 30. Diccionario de datos de la entidad UsuarioRoles ......................................................... 74
Tabla 31. Diccionario de datos de la entidad UsuarioProyecto .................................................... 75
Tabla 32. Diccionario de datos de la entidad Usuario .................................................................. 75
Tabla 33. Diccionario de datos de la entidad Proyectos ............................................................... 76
Tabla 34. Diccionario de datos de la entidad Actividades ............................................................ 76
Tabla 35. Descripción de la interfaz iniciar sesión ....................................................................... 80
Tabla 36. Descripción de la interfaz menú ................................................................................... 82
Tabla 37. Descripción de interfaz editar proyecto ........................................................................ 83
Tabla 38. Descripción de la interfaz editar proyecto .................................................................... 85
Tabla 39. Descripción de la interfaz actividad.............................................................................. 86
Tabla 40. Descripción de interfaz editar actividad ....................................................................... 88
Tabla 41. Descripción de los elementos de la aplicación Web Service WCF ............................... 88
XI
Tabla 42. Descripción de diagramas de flujo................................................................................ 96

Tabla 43. Comportamiento al registrar un proyecto ................................................................... 112
Tabla 44. Comportamiento al actualizar un proyecto ................................................................. 114
Tabla 45. Comportamiento para dar de baja un proyecto ........................................................... 117
Tabla 46. Comportamiento al registrar una actividad a un proyecto .......................................... 118
Tabla 47. Comportamiento al actualizar una actividad de un proyecto ...................................... 121
Tabla 48. Comportamiento al cancelar una operación................................................................ 122
Tabla 49. Tabla de dispositivos donde se ejecutó la aplicación móvil ....................................... 123
Tabla 50. Matriz de pruebas de ejecución .................................................................................. 123
Tabla 51. Tiempo de ejecución de la aplicación por Mbps......................................................... 124
Tabla 52. Resumen de procesos automatizados .......................................................................... 126
Tabla 53. Tabla de recomendaciones .......................................................................................... 129
XII
ÍNDICE DE FIGURAS
Figura 1. Organigrama de la empresa ........................................................................................... 18

Figura 2. Arquitectura de aplicación cross-platform .................................................................... 26
Figura 3. Captura de pantalla de la vista de desarrollo de una aplicación Android ...................... 27
Figura 4. Captura de pantalla de la vista de componentes de una aplicación Android ................. 27
Figura 5. Captura de pantalla de la vista de desarrollo de aplicación iOS.................................... 28
Figura 6. Captura de pantalla de la vista de componentes de una aplicación iOS ........................ 28
Figura 7. Captura de pantalla de la vista de desarrollo de aplicación cross-platform .................. 29
Figura 8. Captura de pantalla de los componentes de aplicación Blank Xaml App ...................... 29
Figura 9. Captura de pantallas de los elementos de la aplicación Blank Xaml App
(Xamarin.Forms Portable) ........................................................................................................... 29
Figura 10. Menú de dispositivos disponibles................................................................................ 30
Figura 11. Mensaje de inicio de depuración ................................................................................. 31
Figura 12. Inicio de depuración de la aplicación móvil ................................................................ 31
Figura 13. Menú del emulador ...................................................................................................... 32
Figura 14. Herramientas adicionales del SV Emulador ................................................................ 34
Figura 15. Esquema del Web Service WCF .................................................................................. 42
Figura 16. Vista agregar referencia de servicio en un proyecto ................................................... 43
Figura 17. Agregar URL del Servicio Web ................................................................................... 44
Figura 18. Ciclo de vida Mobile-D ............................................................................................... 45
Figura 19. Captura de pantalla de la vista de la creación de aplicación ....................................... 59
Figura 20. Captura de pantalla de la vista de la creación del Web Service WCF ......................... 60
Figura 21. Arquitectura de desarrollo de la aplicación ................................................................. 61
Figura 22. Diagrama de actividad de la aplicación ....................................................................... 63
Figura 23. Caso de uso general ..................................................................................................... 64
Figura 24. Diagrama de clase........................................................................................................ 78
Figura 25. Diagrama Entidad-Relación ........................................................................................ 79
Figura 26. Interfaz iniciar sesión .................................................................................................. 80
Figura 27. Interfaz menú ............................................................................................................... 81
Figura 28. Interfaz de proyecto ..................................................................................................... 82
Figura 29. Interfaz editar proyecto................................................................................................ 84
Figura 30. Interfaz de actividad .................................................................................................... 85
Figura 31. Interfaz editar actividad ............................................................................................... 87
Figura 32. Composición de la aplicación del Web Service WCF ................................................. 88
Figura 33. Elementos de la librería del Web Service WCF ........................................................... 89
Figura 34. Captura de pantalla de la vista agregar ADO.NET Entity Data Model ....................... 90
Figura 35. Captura de pantalla de vista agregar módelo (Code First from database) .................. 90
Figura 36. Captura de pantalla de la vista de mapeado de la base de datos a la solución ............ 90
Figura 37. Captura de pantalla de la vista de entidades y procedimientos almacenados .............. 91
Figura 38. Captura de pantalla de la vista de los procedimientos almacenados ........................... 92
Figura 39. Diagrama de flujo de iniciar sesión ............................................................................. 97
Figura 40. Diagrama de flujo de servicio obtener proyectos ........................................................ 98
XIII
Figura 41. Diagramas de flujo de servicio obtener actores ........................................................... 99

Figura 42. Diagramas de flujo de servicio obtener empresas ..................................................... 100
Figura 43. Diagrama de flujo de servicio obtener principales .................................................... 101
Figura 44. Diagrama de flujo de servicio guardar proyecto ....................................................... 102
Figura 45. Diagrama de flujo de servicio actualizar proyecto .................................................... 103
Figura 46. Diagrama de flujo de servicio baja de proyecto ........................................................ 104
Figura 47. Diagrama de flujo de servicio guardar actividad ....................................................... 105
Figura 48. Diagrama de flujo de servicio actualizar actividad ................................................... 106
Figura 49. Diagrama de flujo de servicio eliminar actividad...................................................... 107
Figura 50. Captura de pantalla para agregar referencia de servicio ............................................ 108
Figura 51. Captura de pantalla de la vista enlace al servicio publicado ..................................... 108
Figura 52. Captura de pantalla de la vista referencia de servicio agregada al proyecto ............. 109
Figura 53. Captura de pantalla del WCF Test Client .................................................................. 109
Figura 54. Captura de pantalla de la vista del WCF Test Client obteniendo los métodos .......... 110
Figura 55. Captura de pantalla del cliente de prueba WCF para registrar un proyecto .............. 111
Figura 56. Captura de pantalla de respuesta a la solicitud del cliente registrar proyecto ........... 111
Figura 57. Prueba registrar proyecto ........................................................................................... 112
Figura 58. Captura de pantalla de los parámetros que solicita el Servicio Web WCF para
actualizar proyecto ...................................................................................................................... 113
Figura 59. Captura de pantalla de respuesta a la solicitud actualizar proyecto ......................... 113
Figura 60. Prueba actualizar proyecto ........................................................................................ 114
Figura 61. Captura de pantalla del cliente de prueba WCF para dar de baja un proyecto .......... 115
Figura 62. Captura de pantalla para invocar método y confirmar baja de proyecto ................... 115
Figura 63. Captura de pantalla de la respuesta al cliente de prueba WCF a la solicitud a baja de
proyecto....................................................................................................................................... 116
Figura 64. Captura de pantalla de los parámetros agregados para registrar actividad a un proyecto
..................................................................................................................................................... 117
Figura 65. Captura de pantalla de respuesta del Servicio Web WCF para registrar actividad .... 118
Figura 66. Prueba registrar actividad .......................................................................................... 119
Figura 67. Captura de pantalla de la consulta de un proyecto por el cliente de prueba WCF .... 119
Figura 68. Captura de pantalla para confirmar llamada de método actualizar actividad ............ 120
Figura 69. Captura de pantalla de la respuesta mostrada en la interfaz de cliente de prueba WCF
..................................................................................................................................................... 120
Figura 70. Prueba actualizar actividad ........................................................................................ 121
Figura 71. Prueba cancelar operación ......................................................................................... 122
Figura 72. Prueba de velocidad de internet ................................................................................. 124
Figura 73. Navegación final de la aplicación.............................................................................. 127
XIV
RESUMEN
En este documento se da a conocer el desarrollo de una aplicación móvil para la administración de

proyectos en el departamento de sistemas dentro de la agencia CPM Medios.
Inicia con la elección del Hardware y Software que se utilizó para el desarrollo de la misma, que
es Visual Studio 2015 con Xamarin para habilitar el desarrollo en dispositivos móviles. Además,
se utilizó una metodología de desarrollo de aplicaciones móviles que recibe el nombre de Mobile-
D que comprende 5 fases; exploración, inicialización, producción, estabilización y (pruebas y
corrección) para su cumplimiento. Así como el tipo de Web Service WCF para alojar los
procedimientos, que funcionará como intermediario entre la base de datos y la aplicación móvil
para cumplir sus funciones.
En la fase de exploración se escriben los alcances de la aplicación, una descripción general, así
como los requerimientos.
Después sigue la fase de inicialización se fundamenta en Software para desarrollo, recursos físicos
y técnicos, la arquitectura, así como todo el comportamiento que tendrá la aplicación móvil.
En la fase de producción se llevó a cabo la actualización de la base de datos, crear un Servicio Web
WCF para desarrollar la aplicación móvil con los requerimientos del cliente que se establecieron
en la fase de exploración.
Posteriormente en la fase de estabilización es donde se vincula la aplicación con el Servicio Web
WCF.
En la fase pruebas y corrección se muestran todos los escenarios de peticiones del cliente
(aplicación móvil) con la respuesta del servidor (Servicio Web WCF).
15
INTRODUCCIÓN
CPM Medios es una agencia de publicidad que cuenta con 5 áreas, en la que se trabajo fue en el
área de sistemas, quien se encarga de llevar el control de proyectos, así como las actividades que
cada uno de ellos ejecutan.
El presente trabajo muestra dos capítulos dentro de los cuales se encuentra la información acerca
del análisis y desarrollo de la aplicación móvil.
En el primer capítulo se realiza el análisis de terminologías importantes como lo son aplicaciones
móviles, Servicio Web anudado a lo anterior se describe la metodología que se implementó.
En este orden, en el segundo capítulo se fundamenta la descripción detallada de las actividades en
las fases exploración, inicialización, producción, estabilización y pruebas y/o corrección;
realizados con base a la metodología llamada Mobile-D.
Finalmente se presentan conclusiones y recomendaciones para mejorar el diseño de presentación

de la información extensa en la aplicación.
16
JUSTIFICACIÓN
Actualmente la agencia CPM Medios cuenta con un control de proyectos a través de un aplicación
Web que no incluye el módulo de actividades, en consecuencia, se genera un reporte impreso de
dicho proyecto y ahí mismo se escriben las actividades a realizar, sin embargo, no es un control
formal de las actividades de los proyectos; por lo anterior, se genera gasto de hojas incluso falta
de espacio para actualizaciones que se le agregan a un proyecto por lo tanto, se tiene la necesidad
de implementar una aplicación móvil para agilizar esta administración.
El desarrollo de la aplicación móvil permitirá el uso responsivo en un dispositivo móvil mejorando

así la experiencia de usuario de quien lleva la administración. Contendrá los procesos CRUD
(Create, Read, Update y Delete) en español crear, leer, actualizar y eliminar de los módulos
proyecto y actividades, además del manejo de catálogos de responsables, partners, empresas y
principales.
Permitirá al usuario (asistente) poder asistir a la reunión con su dispositivo móvil (tableta o
celular), sin necesidad de hojas extras y/o posponer reuniones, en la reunión puede consultar y
actualizar información de un proyecto en tiempo real, es decir, sin necesidad de agendar otra
reunión.
Los usuarios se beneficiarán porque la aplicación móvil permitirá su uso desde cualquier lugar
siempre y cuando el dispositivo cuente con conexión a internet sin proxy; también un ahorro en
tiempo y gasto en hojas.
la integración de Xamarin en el IDE de Visual Studio 2015 resulta una nueva tecnología
innovadora para el desarrollo de aplicaciones móviles, que permitirá la automatización de las
actividades de una empresa, utilizando un solo código para sistema operativo móvil iOS y Android.
También con la utilización de WCF permitirá separar la lógica de la aplicación de la interfaz de
usuario, reduciendo la carga de código de la misma. Además de la integración de la metodología
Mobile-D que permitirá ejecutar un adecuado plan de desarrollo.
17
OBJETIVO GENERAL
Desarrollar una aplicación móvil iOS y Android mediante la implementación de una serie de
actividades con base en la metodología Mobile-D para administrar proyectos por la dirección de
proyectos de la agencia de publicidad CPM Medios.
Objetivos específicos
 Analizar los procesos que se llevan a cabo en administración de proyectos.

 Agregar entidades necesarias a la base de datos.
 Crear los procedimientos almacenado necesarios para la base de datos.
 Diseñar la interfaz y navegación de usuario Xamarin.
 Desarrollar los métodos que permitirán cumplir las solicitudes de la aplicación móvil.
 Desarrollar un Web Service WCF para incluir métodos.
 Conectar Web Service WCF con la aplicación móvil para consultar catálogos.
 Identificar escenarios de prueba para la aplicación móvil.
18
MARCO CONTEXTUAL
 DATOS DE LA EMPRESA
Nombre: CPM Medios S.A. de C.V.

Dirección: Guillermo González Camarena No. 1000 2do piso, #201, Col. Centro Ciudad
Santa Fe CP.01210 México DF.
Tel. (55)2591-0256, www.cpmmedios.com

Giro de la empresa: Publicidad, contratación de medios publicitarios
Objetivo: Somos una agencia de publicidad, con experiencia en utilizar una metodología probada
en el ámbito de campañas a nivel municipal, estatal y nacional. Nuestra prioridad es diseñar e
implementar soluciones certeras y creativas, enfocadas en implementar la competitividad y
posicionamiento.
Estructura Organizacional:
Figura 1. Organigrama de la empresa

Fuente: (López Rodríguez, 2016)
Departamento: Área de sistemas

Principales actividades:
 Administración y diseño de base de datos
 Análisis y diseño de Software
 Generación de estadísticos de las campañas
 Análisis y diseños de los procesos de la agencia
 Asistencia técnica a las diferentes áreas de la empresa
Asesor Externo: Jefe del área de sistemas

19
PLANTEAMIENTO DEL PROBLEMA
Los usuarios de la aplicación Web actualmente utilizan sus navegadores que tienen disponibles en
sus laptops y hojas extras para hacer anotaciones de actividades por proyecto, cuando desean hacer
uso de la aplicación Web en lugares como el automóvil, es complicado, porque se tiene que sujetar
y/o apoyar la laptop para utilizarla cuando el automóvil está en movimiento o en una reunión
corporativa no se puede actualizar al momento, debido a que al ingreso de las mismas son con
dispositivos móviles (tabletas o celulares) por falta de espacio.
Previo a una reunión el usuario (asistente) imprime un reporte de forma física de los proyectos, si
en la reunión se necesita información específica de algún proyecto misma que no está contenida
en reporte, la reunión fracasa y el asistente tiene que agendar otra reunión para dar continuidad a
la previa, lo que genera pérdida de tiempo.
En una reunión de trabajo las actualizaciones de un proyecto y sus actividades se escriben en hojas,
lo que genera doble trabajo porque el módulo actividades no está automatizado en la aplicación
Web, además el usuario tiene que rescatar en el menor tiempo posible las actualizaciones y/o
anotaciones de un proyecto, esto puede provocar confusión en la información registrada.
Si los usuarios lo desean utilizar desde sus dispositivos móviles la aplicación no es adaptativo,
todo esto provoca una mala experiencia de usuario.
Por lo anterior expuesto, surge la siguiente pregunta:

Al desarrollar una aplicación móvil iOS y Android en el IDE de desarrollo de Visual Studio 2015
permitirá la administración de proyectos de una forma remota aplicando la metodología Mobile-
D, así como la utilización de Windows Comunication Fundation, ¿y por lo tanto minimizar la
utilización de recursos humanos y materiales?
20
ALCANCES
 Desarrollar las operaciones CRUD (Create, Read, Update, Delete) en los módulos
proyectos y actividades.
 Desarrollar los métodos para las operaciones que se llevaran a cabo en el servicio WCF.
 Se tendrá acceso a la base de datos para agregar y modificar la estructura de la misma.
 El desarrollo de esta aplicación móvil permitirá el acceso a usuarios con dispositivos de
sistema Android y iOS.
LIMITACIONES
 Si no es usuario asignado no podrá utilizar la aplicación.

 No se tendrá acceso al servidor de la empresa para la publicación de “Web Service WCF”.
 No se podrá hacer una prueba en un dispositivo móvil iOS porque no se cuenta con el
equipo.
 Si el internet proviene de una red con proxy la aplicación no podrá funcionar
correctamente.
21
CAPÍTULO I. MARCO TEÓRICO

22
1.1. Aplicación móvil
En la actualidad las personas están más familiarizadas con las aplicaciones móviles debido al
desarrollo de las tecnologías.
1.1.1. Definición de una aplicación móvil
“Una aplicación móvil consiste en un Software que funciona en un dispositivo móvil (teléfonos y
tabletas) y ejecuta ciertas tareas para el usuario” (Mobile Marketing Association, 2011).
1.1.2. Tipos de aplicaciones móviles
Existen aplicaciones móviles de diversos tipos que se caracterizan por sus usos y por sus
funcionalidades. A continuación se describe la clasificación según el entorno donde se ejecutan y
con base a su funcionalidad por (Mobile Marketing Association), al último por su desarrollo según
(Cuello & Vittone)
1.1.2.1. Según el entorno en el que se ejecutan
Según (Mobile Marketing Association) por su entorno en el que se ejecutan menciona lo siguiente:
 Funcionamiento de la app en sistemas operativos móviles nativos como Apple™ iOS, Google
Android, Windows Mobile®, Blackberry OS™, Samsung Bada o Symbian, entre otros. Estos
entornos llegan habitualmente preinstalados en los terminales.
 Funcionamiento de la aplicación en “Web” móvil, también conocidas como: aplicaciones

Web ejecutadas desde el navegador del dispositivo.
Ventajas:
 Pueden ser instaladas en distintos sistemas operativos
Desventajas:
 Menor rendimiento y menor aprovechamiento de las capacidades técnicas en
determinadas situaciones.
 Otras plataformas como Java/J2ME, BREW, Flash Lite o Silverlight (menos utilizadas en la
actualidad).
23
1.1.2.2. Con base a su funcionalidad
También (Mobile Marketing Association, 2011) menciona que también se clasifican con base a su
funcionalidad y se describe a continuación:
 Comunicaciones: Clientes de redes sociales (ejemplo: Facebook, Twitter), mensajería

instantánea (ejemplo: WhatsApp), clientes de email, navegadores Web, servicios de noticias y
voz IP.
 Juegos: Cartas o de casino (ejemplo: solitario, blackjack, ruleta, póker), puzle o estrategia
(ejemplo Tetris, Sudoku, Ajedrez, Juegos de Mesa), acción o aventura (ejemplo: Doom,
piratas del caribe, juegos de rol), deportes (ejemplo: futbol, tenis, baloncesto, carreras, boxeo,
aky) y deportes de ocio.
 Multimedia: visores de gráficos de imágenes, visores de presentaciones, reproductores de

video (ejemplo: youtube), reproductores de audio y reproductores de streaming
(Audio/Video).
 Productividad: calendarios, calculadoras, diarios, notas, hojas de cálculo, servicios de

directorio (ejemplo: páginas amarillas) y bancos o finanzas.
 Viajes: Guías de ciudadanos (ejemplo: Lonely planet), convertidores de moneda, traductores,

mapas/GPS, itinerarios programados y previsión meteorológica.
 Utilidades: Gestores de perfiles de usuario, libretas de direcciones, gestor de procesos,

llamadas y ficheros
 Compras: Lectores de código de barras y bases de datos de productos, clientes de tiendas

Web, subastas, cupones de descuento, lista de la compra.
 Entretenimiento: Lectores de libros, horóscopos, guías de programación de televisión,

recetas, cómics.
24
 Bienestar: Seguimiento de dietas, primeros auxilios, consejos y entretenimiento personal.
1.1.2.3. Según su desarrollo
Según (Cuello & Vittone) consideran que la clasificación de las aplicaciones de acuerdo con su
desarrollo es:
 Aplicaciones nativas
Son aquellas que han sido desarrolladas con el Software que ofrece cada sistema operativo a
los programadores, llamando genéricamente Software Development Kit o SDK. Así, Android,
iOS y Windows® Phone.
Características:
 Se diseñan y programan específicamente para cada plataforma en el lenguaje utilizado
por el SDK.
 Se actualizan frecuentemente (el usuario debe volver a descargarlas) para obtener la

última versión, que a veces corrige errores o añade mejoras.
 A nivel de diseño, esta clase de aplicaciones tiene una interfaz basada en las guías de
cada sistema operativo.
 Aplicaciones Web
También llamadas Webapps en este caso no se emplea un SDK, lo cual permite programar de
forma independiente al sistema operativo al que cual se usará la aplicación.
Características:
 Pueden ser fácilmente utilizadas en diferentes plataformas sin mayores inconvenientes
y sin necesidad de desarrollar un código diferente para cada caso particular.
 Estas no necesitan instalarse, porque se visualizan usando un navegador del teléfono
como un sitio normal. Por esta misma razón, no se distribuyen en una tienda de
aplicaciones, sino que se comercializan y promocionan de forma independiente.
25
 Su interfaz es más genérica e independiente de la apariencia del sistema operativo, la

experiencia e identificación del usuario con los elementos de navegación e interacción,
suele ser menor que en el caso de las nativas.
 Aplicaciones hibridas
Es una combinación de las dos anteriores.
Características:
 Su desarrollo se parece a la de una aplicación Web usando HTML, CSS y JavaScript.
Cuando la app está terminada, se compila o empaqueta de forma que el resultado final
es como si se tratara de una aplicación nativa.
 Permite que con un mismo código obtener diferentes aplicaciones, por ejemplo, para
Android y iOS, y distribuirlas en cada una de sus tiendas.
 A diferencia de las aplicaciones Web, estas permiten acceder, usando librerías, a las
capacidades del teléfono, tal como haría una app nativa.
 Su diseño visual no se identifica en gran medida con el del sistema operativo. Sin embargo,
hay formas de usar controles y botones nativos de cada plataforma para apegarse más a la
estética propia del sistema
1.2. Software para desarrollo de aplicaciones móviles
Existen distintos Softwares para desarrollo de aplicaciones, dado que el uso de dispositivos
móviles ha incrementado al igual que el uso del internet hay disponibles desde Software que
funciona solo como plantilla para diseño de una app hasta los disponibles para aquellos que se
dedican al desarrollo desde código. En la que se mencionan 5 tipos de Software para análisis y el
que se utilizará para el desarrollo de la aplicación.
26
1.3. Xamarin y Visual Studio
¿Qué es Xamarin? Es una plataforma de desarrollo que permite codificar, entre plataformas iOS,
Android y Windows® Phone aplicaciones móviles en C# (Hermes, 2015).
¿Qué es Visual Studio? Es un conjunto completo de herramientas de desarrollo para la generación

de aplicaciones Web ASP.NET, servicios Web XML, aplicaciones de escritorio y aplicaciones
móviles.
Características de Xamarin según Hermes (2015) son:
 Puede compartir la mayor parte del código entre los proyectos de plataforma (Windows®, iOS
y Android).
 Incluye cualquier lógica de negocios, la integración en la nube, el acceso a bases de datos o
cualquier otro código que tenga como destino .NET Framework.
 El código se puede compartir mediante un proyecto compartido que se genera en Visual
Studio.
 El único código que no se puede compartir es el código que tiene como destino una plataforma
específica.
A continuación, en la Figura 2 se muestra la arquitectura de la aplicación cross-platform con

la descripción anterior:
Figura 2. Arquitectura de aplicación cross-platform

Fuente: “Compartir código entre aplicaciones de Android, iOS”, recuperado en
https://msdn.microsoft.com/es-MX/library/dn771552.aspx, 25/marzo/2017
27
Al crear el proyecto en el Software carga la interfaz del usuario en este caso es (Windows®,
iOS y Android) por lo que no se necesita cargar código en cada uno de ellos toda vez que se
trata de un código compartido para las tres plataformas.
1.3.1. Desarrollo de aplicaciones móviles en Xamarin y Visual Studio
En la vista de desarrollo en Visual Studio se encuentra Android, iOS y cross-platform.
1.3.1.1. Android
En este caso se utilizan los componentes específicos para la plataforma Android. Librerías de clase
y aplicaciones Android con elementos exclusivos para plataforma Android como se ve en la Figura
4 a partir de la creación como se muestra vista en la Figura 3.
Figura 3. Captura de pantalla de la vista de desarrollo de una aplicación Android

Fuente: Elaboración propia, con base en el IDE de Visual Studio 2015
Figura 4. Captura de pantalla de la vista de componentes de una aplicación Android

28
1.3.1.2. iOS
En este caso se crean los componentes específicos para la plataforma iOS como se ve en la Figura
6 y el inicio de la creación de la aplicación se observa en la Figura 5.
Figura 5. Captura de pantalla de la vista de desarrollo de aplicación iOS

Figura 6. Captura de pantalla de la vista de componentes de una aplicación iOS

1.3.1.3. Cross-platform
Permite crear interfaces de usuario para diferentes plataformas como pueden ser Android, iOS y
Windows Phone, con la capacidad de compartir código, sin embargo, existe la posibilidad de
personalizar en cada plataforma. El inicio de creación de la aplicación en Visual Studio se ve como
en la Figura 7.
Xamarin.Forms que integra Visual Studio permite la instalación de la aplicación en un móvil o
emularla con sus propiedades según el tipo de plataforma. Native Portable (que es código se hará
por cada plataforma) o Blank Xaml App Portable (Se controla el comportamiento desde un solo
código) como se observa en la Figura 8.
29
Figura 7. Captura de pantalla de la vista de desarrollo de aplicación cross-platform

1.3.2. Estructura de una aplicación Black Xaml App (Xamarin.Forms Portable) en

Visual Studio
Figura 8. Captura de pantalla de los componentes de aplicación Blank Xaml App

En la Figura 9 se ven los 4 elementos de la aplicación que se describen en la Tabla 1.
Figura 9. Captura de pantallas de los elementos de la aplicación Blank Xaml

App (Xamarin.Forms Portable)
30
Numeración Nombre Descripción

1 Clase compartida para todas las Es el cuerpo de la aplicación, donde se encuentra la
plataformas referencia de servicio, vistas de interfaz y código que
compartirán las plataformas.
2 Plataforma Android Esta contiene una referencia que se vincula a la carpeta
3 Plataforma iOS compartida, para después ejecutarla
4 Plataforma Windows® Phone
Tabla 1. Descripción de los elementos de la aplicación Blank Xaml App
Fuente: Elaboración propia
1.4. Emuladores
1.4.1. Concepto
Es aquel que imita un dispositivo real y lo hace virtual.
1.4.2. Emulador de Visual Studio para Android
Este emulador utiliza las capacidades de Hyper-V del equipo de desarrollo, su objetivo es para
depuración de una aplicación Android.
1.4.3. ¿Cómo ejecutar el emulador?
Visual Studio crea varios perfiles preconfigurados con objeto de mostrar en un menú desplegable
los dispositivos disponibles para la depuración de la aplicación como se ve en la Figura 10.
Figura 10. Menú de dispositivos disponibles

Fuente: “Ejecutar el emulador”, recuperado en https://developer.xamarin.com/es-
es/guides/android/deployment,_testing,_and_metrics/debug-on-emulator/visual-studio-android-
emulator/, 12/enero/2017
31
Para aviso de que se está depurando la aplicación, se muestra un mensaje en la parte inferior
izquierda como se ve en la Figura 11.
Figura 11. Mensaje de inicio de depuración

es/guides/android/deployment,_testing,_and_metrics/debug-on-emulator/visual-studio-android-emulator/, 12/enero/2017
En el emulador se inicia la interfaz virtual del dispositivo con las funciones normales, así mismo
se monta la aplicación desarrollada como se muestra en la Figura 12.
Figura 12. Inicio de depuración de la aplicación móvil

es/guides/android/deployment,_testing,_and_metrics/debug-on-emulator/visual-studio-android-emulator/,
12/enero/2017
32
La aplicación desarrollada en Visual Studio se depura en el emulador Android para ver las
funcionalidades de esta, en este caso solo fue un botón con título “Hello world, Click Me”.
1.4.4. Función de los botones del emulador
Figura 13. Menú del emulador

Fuente: “Ejecutar el emulador”, readaptado de https://developer.xamarin.com/es-
es/guides/android/deployment,_testing,_and_metrics/debug-on-emulator/visual-
studio-android-emulator/, 12/enero/2017
Numeración Nombre
1 Cerrar emulador
2 Minimizar emulador
3 Apagar
4 Un solo punto de entrada
5 Multi-touch
6 Girar a la izquierda
7 Girar a la derecha
8 Ajustar a la pantalla
9 Zoom
10 Herramientas adicionales
Tabla 2. Elementos nombrados del emulador para aplicaciones
móviles
La Tabla 2 describe los elementos del menú de la Figura 13, en la siguiente lista resume la función
de cada botón en la barra de herramientas vertical del emulador:
 Cerrar: Cierra la aplicación del emulador. Este botón no se utiliza a menudo en
funcionamiento normalmente, el emulador se deja después de la primera puesta en marcha
(para evitar el retardo de arranque emulador) y se cierra sólo cuando ya no es necesaria.
33
 Minimizar: Deja el emulador en funcionamiento, pero minimiza a la barra de tareas.
 Apagar: Imita el dispositivo de encendido y apagado. (El emulador permanece en

funcionamiento.)
 Multi-touch: Varios puntos sobreimpresiones en la pantalla del dispositivo que actúan

como puntos de contacto para tocar pantalla y agregar zoom. Arrastrando un punto hace
que el otro punto se mueva en la dirección opuesta, la simulación de movimiento con dos
dedos.
 Un solo punto de entrada del ratón: Devuelve el dispositivo a la entrada de un solo punto.
 Girar a la izquierda / Girar a la derecha: Ayuda a probar cómo la aplicación responde

a los cambios de orientación. Por ejemplo, para rotar a la izquierda se hace clic en el botón
el emulador se cambiará al modo horizontal. Para rotar a la derecha se pulsa el botón

.
 Ajustar a la pantalla: Amplía el tamaño de la pantalla del emulador para que quepa en la
pantalla del escritorio.
 Zoom: Ver la pantalla del emulador en un 33%, 50%, 66%, 100%, o por algún porcentaje
personalizado.
 Herramientas adicionales: Aparecerá un cuadro que muestra las características

adicionales del emulador cómo: Acelerómetro, Ubicación, Batería, Captura de pantalla,
Cámara, SD Card, Red. Como se ve en la Figura 14.
34
Figura 14. Herramientas adicionales del SV Emulador

Fuente: “Herramientas adicionales”, recuperado en
https://developer.xamarin.com/eses/guides/android/deployment,_testing,_and_metrics/debug-on-emulator/visual-
studio-android-emulator/, 12/enero/2017
Las herramientas adicionales de la Figura 14 se describen a continuación:
 Acelerómetro (Acelerometer): Simula el movimiento del dispositivo en un espacio 3D.
 Ubicación (Location): Presenta un mapa que se puede utilizar para seleccionar y simular
una ubicación GPS. En este mapa, los puntos del mapa se pueden crear para simular el
movimiento entre las localidades.
 Batería (Battery): Proporciona un control deslizante para simular la cantidad de carga

restante en la batería.
35
 Captura de pantalla (Screenshot): En esta fich<a, lleva a una captura de pantalla y

muestra una vista previa instantánea y se selecciona guardar la captura.
 Cámara (Camera): Imita tomar una foto a través de una imagen animada fija, una imagen
desde un archivo o desde una cámara Web conectada en el ordenador anfitrión. Es posible
seleccionar entre las cámaras delanteras o traseras.
 Tarjeta SD (Card SD): El emulador puede hacer una carpeta en el ordenador anfitrión
disponible para el dispositivo como una tarjeta SD. Cuando la aplicación lee y escribe
archivos en la tarjeta SD simulada, se puede acceder directamente desde el escritorio sin
necesidad de utilizar el comando.
 Red (Network): Muestra un resumen de la configuración de red del emulador (emulador

vuelve a utilizar la conexión de red del equipo) (Xamarin, 2017).
1.5. Bases de datos

1.5.1. ¿Qué es una base de datos?
Una base de datos es un conjunto de tablas llamadas entidades que almacenan datos con menor
redundancia posible.
Una base de datos es un conjunto de datos almacenados sin redundancias innecesarias en

un soporte informático y accesible simultáneamente por distintos usuarios y aplicaciones.
Los datos deben de estar estructurados y almacenados de forma totalmente independiente
de las aplicaciones que la utilizan (Cobo Yera, 2007).
 Datos:
Conjunto de información que pueden ser registrados de algún modo, y que cuentan con un
significado implícito.
Reflejan situaciones del mundo real y cambios en esas situaciones.
36
 Relacionados:
Debe existir homogeneidad en la colección de datos que conforma una Base de datos (BD).
Los datos se recopilan y registran con una finalidad.
Los datos deben ser relevantes con respecto a esa finalidad.
1.5.2. Diccionario de datos
Un diccionario de datos es una obra de consulta con información acerca de los datos (es decir,
metadatos), compilada por los analistas de sistemas para guiarse en el análisis y diseño. Como un
documento, el diccionario de datos recopila y coordina términos de datos específicos, y confirma
lo que cada término significa para las diferentes personas en la organización (E. Kendall & E.
Kendall, 2005).
1.5.3. Procedimientos almacenados
Un procedimiento almacenado de SQL Server es un grupo de una o varias instrucciones Transact-

SQL o una referencia a un método de Common Runtime Language (CLR) de Microsoft® .NET
Framework. Los procedimientos se asemejan a las construcciones de otros lenguajes de
programación, porque pueden:
 Aceptar parámetros de entrada y devolver varios valores en forma de parámetros de salida
al programa que realiza la llamada.
 Contener instrucciones de programación que realicen operaciones en la base de datos. Entre

otras, pueden contener llamadas a otros procedimientos.
 Devolver un valor de estado a un programa que realiza una llamada para indicar si la
operación se ha realizado correctamente o se han producido errores, y el motivo de estos
(Microsoft®, 2017).
37
 Ejemplo de procedimiento almacenado para agregar un registro:
CREATE PROCEDURE [Nombre_del_procedimiento]

@Parametro_1 tipodedato longitud,
.
.
.
@Parametro_n tipodedato longitud
AS
INSERT INTO dbo.[Nombre_de_la_entidad](Valor_1, ..., Valor_n)
VALUES (@Parametro_1, ..., Parametron_n);
SELECT @ID_Parametro_PK=SCOPE_IDENTITY();
RETURN
GO
 Ejemplo de procedimiento almacenado para actualizar un registro:

.
.
.
AS
UPDATE SET (Valor_1, ... ,Valor_n)
FROM dbo.[Nombre_de_la_entidad]
WHERE(Valor_1=@Parametro_1) and ... and (Valor_n=@Parametro_n);
GO
 Ejemplo de procedimiento almacenado para eliminar un registro:

.
.
.
AS
DELETE FROM dbo.[Nombre_de_la_entidad]
WHERE(ID_Valor_PK=@ID_Parametro_PK);
GO
1.5.4. Sistema de Gestión de Bases de Datos
Conjunto de programas de propósito general, que proporcionan funcionalidades horizontales para

facilitar la gestión de la información contenida en una base de datos.
38
Durante el desarrollo de la aplicación se utiliza el sistema de manejo de bases de datos del modelo
relacional (Microsoft® SQL Server).
1.6. ADO.NET Entity Framework
“ADO.NET Entity Framework es un marco de trabajo para la plataforma .NET que permite
superponer varias capas de abstracción sobre un almacén relacional con el fin de hacer posible una
programación más conceptual” (Zorrilla Castro, de la Torre Llorente, Hernandez Saa, & Peláez
Aller, 2011).
1.6.1. Componentes fundamentales de Entity Framework
También los autores (Zorrilla Castro, de la Torre Llorente, Hernandez Saa, & Peláez Aller)
fundamentan que los componentes son dos que se describen a continuación:
1) Recursos para el entorno de desarrollo y en particular un asistente para el diseño visual

de modelos de entidades dentro de Visual Studio así como la generación de código a partir
de los mismos.
2) Biblioteca. Los tipos que componen ADO.NET Entity Framework se implementan
físicamente en el ensamblado System.Data.Entity.
1.6.2. Ventajas de Entity Framework
Según Microsoft® (2017) las aplicaciones de Entity Framework ofrecen las siguientes ventajas:
 Las aplicaciones pueden funcionar en términos de un modelo conceptual más centrado

en la aplicación, que incluye tipos con herencia, miembros complejos y relaciones.
 Las aplicaciones están libres de dependencias de codificación rígida de un motor de

datos o de un esquema de almacenamiento.
 Las asignaciones entre el modelo conceptual y el esquema específico de

almacenamiento pueden cambiar sin tener que cambiar el código de la aplicación.
39
 Los desarrolladores pueden trabajar con un modelo de objeto de aplicación coherente

que se puede asignar a diversos esquemas de almacenamiento, posiblemente
implementados en sistemas de administración de base de datos diferentes.
 Se pueden asignar varios modelos conceptuales a un único esquema de

almacenamiento.
 La compatibilidad con Language Integrated Query (LINQ) proporciona validación de

la sintaxis en el momento de la compilación para consultas en un modelo conceptual.
1.6.3. Entity Data Model
Zorrilla Castro, de la Torre Llorente, Hernandez Saa, & Peláez Aller (2011), mencionan que el
Modelo de Entidades, normalmente conocido como EDM (Entity Data Model). Este diseñador
permite definir los conjuntos de entidades y relaciones entre las mismas de los modelos
conceptuales, así como especificar de qué manera estos tipos se mapearán a la estructura de la
fuente de almacenamiento relacional subyacente.
1.7. Servicio Web
El propósito de los servicios Web es permitir la comunicación independiente de lenguaje de

programación y plataforma.
1.7.1. SOAP
Simple Object Access Protocol (SOAP), creado en 1998, se sirve de mensajes XML para el
intercambio de mensajes. Puede operar sobre cualquier protocolo de transporte, aunque lo más
común es que lo haga sobre HTTP o HTTPS. Es el protocolo más común en servicios Web de
carácter privado una característica es que puede ser transmitido a través de HTTP, TCP/IP, SMTP
o cualquier otro.
40
Los servicios Web (SOAP) utilizan un protocolo Internet para asegurar la comunicación con sus
aplicaciones cliente. A menudo, se trata del protocolo HTTP, de ahí la denominación servicios
Web (Guérin, 2013).
1.7.2. REST
Representational State Transfer (REST). Concepto surgido en el año 2000, hace uso del protocolo
HTTP para el envío de mensajes, incluso puede utilizar lenguajes como XML o JSON.
Se característica porque pueden utilizarse en el protocolo HTTP y las cuatro operaciones CRUD
Create, Read, Update y Delete (CRUD) en español crear, leer, actualizar y eliminar que pueden
realizarse sobre una fuente de datos.
GET ↔ SELECT (Obtener)
POST ↔ INSERT (Crear)
PUT ↔ UPDATE (Actualizar)
DELETE ↔ DELETE (Borrar)
1.7.3. SOA
Simple Object Access (SOA), se basa en organizar una aplicación en unidades funcionales que
pueden ser gestionadas por distintos proveedores e incluso compañías de modo que puedan ser
accedidas de un modo homogéneo (Guérin, 2013).
1.8. WCF (Windows Communication Foundation)
WCF es un motor de ejecución al mismo tiempo un conjunto de APIs para la creación de sistemas
que envíen mensajes entre servicios y clientes. Se utilizan la misma infraestructura y API tanto
para crear aplicaciones que se comuniquen entre sí en el mismo sistema, como para aplicaciones
en equipos separados en distintas compañías que se comuniquen a través de Internet (Microsoft®,
2016).
41
1.8.1. Servicio Web WCF
WCF separa operaciones y datos, es decir un Servicio Web WCF establece un contrato a través de
una interfaz que una clase implementará. Los elementos de un Servicio Web WCF según Ceballos
Villach, Gañán Jiménez, Conesa Caralt y Rius Gavidia (2010) son:
Contratos
Los contratos se utilizan para definir los diferentes elementos que forman parte de un servicio:
 Contrato de servicio - ServiceContract: Se utiliza para definir las distintas operaciones que
proporciona un servicio, así como otros detalles del servicio, es decir, que expone una
operación que el Servicio Web es capaz de ejecutar que es una interfaz.
 Contratos de operación - OperationContract: Se definen las funcionalidades que este

ofrece utilizando definiciones de métodos con el atributo. Los métodos pueden tener o no
tipos de retorno, así como parámetros. Dado que el contrato de servicio es una interfaz,
solamente se incluye la cabecera del método, no su implementación.
 Contrato de datos - DataContract: Los tipos de parámetros de una operación de servicio,

así como su tipo de retorno, deben ser tipos serializables. WCF utiliza un serializador
específico que serializa tipos de datos que estén definidos mediante un contrato de datos.
El atributo DataContract puede aplicarse a clases o estructuras. Por otro lado, DataMember
se puede aplicar a métodos, campos y eventos no estáticos. En otras palabras, se
implementan los datos que el Servicio Web va a manejar así mismo el dato que manejará
el contrato de servicio.
Finalmente la implementación del servicio: Aquí se implementa la interfaz correspondiente al

contrato de servicio, haciendo uso del contrato de datos para intercambiar la información (Guérin,
2013).
El Service implementa IService y obliga a declarar los métodos que aparecen en la interface como
se ve en la Figura 15.
42
Figura 15. Esquema del Web Service WCF

Fuente: Elaboración propia, con base en Visio UML 2013
1.8.2. Ventajas de WCF
Patel (2017) considera lo siguiente como ventajas de usar WCF:
 Interoperabilidad: WCF es interoperable con otros servicios y lenguajes.
 Seguridad y confiabilidad: WCF proporciona más seguridad en comparación con los

servicios Web .NET (.ASMX). Para aplicar la seguridad en WCF no se requiere una
codificación extensa. Un programador necesita configurar los atributos de la seguridad y
la seguridad adecuada. Se aplica en función de los atributos establecidos por el
programador. Los mensajes pueden registrarse y se rastrea utilizando la herramienta
Service Trace Viewer en español visor de rastreo de servicio, que es una ventaja principal
de WCF como registro puede ser útil para investigar problemas de seguridad.
Además, se puede garantizar la entrega del mensaje utilizando MSMQ con el programa
WCF. Un programador también puede crear sesiones confiables mediante el protocolo
message confiable y las sesiones son creadas automáticamente por WCF, necesita
43
simplemente cambiar la configuración del Servicio Web WCF, tener una sesión confiable
en él. Esto hace que WCF sea realmente robusto y potente (Patel, 2017).
 Comunicación dúplex: Es una comunicación de dos direcciones en la cual, un servicio

WCF puede consumir la funcionalidad del cliente llamándolo. Esta característica no está
disponible en el servicio Web tradicional. En la comunicación dúplex, tanto el cliente como
el servicio pueden iniciar la comunicación al mismo tiempo. esto proporciona flexibilidad
al desarrollador para diseñar una comunicación de dos vías (Patel, 2017).
1.8.3. Consumir un Servicio Web
Todo tipo de Software (incluido Java, PHP, C++…) es capaz de consumir un Servicio Web SOAP
(Guérin, 2013). A continuación, se muestra como generar y consumir un Servicio Web:
a) Al proyecto se agrega una referencia de tipo servicio haciendo lo que se ve en la Figura 16.
Figura 16. Vista agregar referencia de servicio en un proyecto

b) Introducir la URL del servicio y clic en aceptar para que este sea agregado, nombrar el
servicio como se observa en la Figura 17.
44
Figura 17. Agregar URL del Servicio Web

1.9. Impacto de las aplicaciones móviles en las empresas
Según un estudio realizado por el Consejo Nacional de Ciencia y Tecnología (CONACYT); la

adopción de tecnologías y aplicaciones móviles (apps) es la gran oportunidad que tienen las
pequeñas y medianas empresas (PyMES) en México para detonar su crecimiento a corto plazo, dio
como resultado que en México el 95.4% de las unidades económicas son PyMES.
El 43 por ciento de las pymes menciona que el uso de las apps incrementa su número de clientes,
31 por ciento considera que con ello aumentaría sus ventas y 23 por ciento asevera que estas
herramientas mejoran la productividad de la empresa (CONACYT, 2015).
45
1.10. Metodología para el desarrollo de aplicaciones móviles Mobile-D
Es la metodología de Valtion Teknillinen Tutkimuskeskus (VTT) para el desarrollo ágil de Software.

Además del desarrollo de Software para móviles, es conveniente para los varios contextos, por
ejemplo, la seguridad, financieros, logística y aplicaciones de simulación de productos (Valtion
Teknillinen Tutkimuskeskus, 2006).
El objetivo principal de este método es conseguir ciclos de desarrollo rápidos en equipos pequeños
de trabajo. Fue creado en un proyecto finlandés en 2005, pero sigue estando vigente. Basado en
metodologías conocidas pero aplicadas de forma estricta como: extreme programming, Crystal
Methodologies y Rational Unified Process.
Se encuentra integrada por 5 fases: exploración, inicialización, fase de producto, fase de
estabilización y la fase de pruebas. Cada una tiene un día de planificación y otro de entrega. Como
es muestra en la Figura 18.
FASES
EXPLORACIÓN INICIALIZACIÓN PRODUCTO ESTABILIZACIÓN FASE DE PRUEBAS
ESTABLECIMIENTO PREPARAR EL DÍA DE DÍA DE PRUEBA DEL

DE INTERESADOS PROYECTO PLANIFICACIÓN PLANIFICACIÓN SISTEMA
DEFINICIÓN DEL PLANIFICACIÓN DÍA DE

DÍA DE TRABAJO DÍA DE TRABAJO
ALCANCE INICIAL PLANIFICACIÓN
ETAPAS
ESTABLECIMIENTO DÍA DE
DÍA DE PRUEBA DOCUMENTACIÓN DÍA DE TRABAJO
DE PROYECTOS LANZAMIENTO
DÍA DE DÍA DE
LANZAMIENTO LANZAMIENTO
Figura 18. Ciclo de vida Mobile-D

Fuente: Readaptado de (Valtion Teknillinen Tutkimuskeskus, 2006)
46
1.10.1. Fase de exploración
Se centra en la planificación y a los conceptos básicos del proyecto. Se realizan los alcances de
proyecto con su establecimiento con las funcionalidades donde se va a llegar.
a) Propósito:
Establecer las bases para una implementación bien controlada de Software, la arquitectura del
producto, el proceso de desarrollo finalmente la selección del medio ambiente.
Se necesitan diferentes grupos y puntos de vista de las partes interesadas en el producto para
ofrecer una mejor experiencia.
b) Objetivos:
 Establecer los grupos de actores necesarios en la planificación y el seguimiento del
proyecto.
 Definir los alcances y limitaciones del proyecto
 Planificar el proyecto respecto al entorno, el personal y los problemas del proceso
c) Entradas de la fase de exploración:

 Propuesta del producto
 Biblioteca de procesos de Mobile-D
 Contrato
 Documento de requisitos iniciales
 Normas y restricciones en caso de que existan
d) Salidas de esta fase:

 Documento de requerimientos iniciales donde se definen los requerimientos iniciales del
desarrollo.
 Plan del proyecto incluyendo línea del tiempo, el ritmo, las terminaciones, los recursos
del proyecto, los actores y sus responsabilidades.
47
 Descripción de la base del proceso que incluye la línea de base, las actividades de
seguimiento de calidad, documentación, puntos de integración del Hardware.
 Plan de medición y plan de formación.
e) Funciones del proyecto

 Equipo del proyecto
 Grupo de apoyo
 Grupo del cliente y el cliente
 Grupo directivo
 Grupo de exploración
1.10.2. Fase de inicialización
También llamada fase de iniciación donde se configura el proyecto y se preparan todos los recursos
necesarios, en ella se le dedica un día de planificación y el resto al trabajo con su publicación.
a) Propósito:
Se realiza la preparación y verificación de todas las cuestiones fundamentales del desarrollo a fin
de que los integrantes tengan conocimiento de los requisitos que seleccione el cliente.
b) Objetivos:
 Obtener la comprensión global del producto para el equipo de desarrollo del proyecto,
sobre los requisitos iniciales y la línea de la arquitectura.
 Preparar los requisitos físicos, técnicos y humanos, así como la comunicación con el
cliente, los planes del proyecto y todas las cuestiones fundamentales de desarrollo a fin de
que todo esté en plena disposición para la implementación.
c) Entradas de esta fase:

 Plan de proyecto y descripción del proceso base
48
 Plan de medición y plan de formación

 Descripción de la línea de arquitectura
d) Salidas de esta fase:

 Plan del proyecto actualizado
 La primera versión del diseño del Software
 Documento con descripción del diseño
 Funcionalidad implementada
 Documento y requisitos iniciales actualizados
 Desarrollo de notas y la interfaz de usuario
 Ilustración de cada requisito
 Pruebas aceptadas de cada requisito
e) Roles de esta etapa:

 Grupo del proyecto
 Jefe del proyecto
 Arquitectos del proyecto
 Grupo de apoyo
 Grupo del cliente
1.10.3. Fase de producto
En esta fase se lleva a cabo toda la implementación de los módulos.
a) Propósito:
Es la de implementar la funcionalidad requerida en el producto mediante la aplicación del ciclo de
desarrollo iterativo e incremental.
b) Objetivos:
 Implementar la funcionalidad del producto priorizando los requerimientos del cliente.
 Centrarse en la funcionalidad básica fundamental para permitir múltiples ciclos de mejora.
49
c) Entradas de esta fase:

 Actualizar el plan del proyecto y plan de línea de arquitectura
 La primera versión de la arquitectura de Software y descripción del diseño
 Planes para la comprobación de los elementos críticos del desarrollo
 Métrica de datos
 Experiencia del equipo de proyecto
 Historia y tarjetas de tareas
 Datos sobre los recursos gastados
 Manuales, especificaciones API y material de apoyo
 Pruebas unitarias
d) Después de cada iteración la entrada de la siguiente es:

 Los resultados de la iteración anterior
e) Salidas de esta fase:

 Documento de aceptación de pruebas
 Notas de desarrollo
 Ilustraciones de Interfaz de usuario
 Lista de puntos de acción
 Plan de proyecto actualizado
 Conocimiento de los requisitos del sistema y pruebas de aceptación
 Lista de defectos
 Informe del estado diario
Esta fase utiliza los mismos roles que las anteriores y la comunicación con el cliente se debe
enfatizar con retroalimentación rápida durante la ejecución de la misma.
50
f) Roles de esta etapa:

 Equipo del proyecto
 Grupo de apoyo
 Grupo directivo
1.10.4. Fase de estabilización
En esta fase se vinculan los módulos separados en una única aplicación.
a) Propósito:
Asegurar la calidad de la implementación del proyecto.
b) Objetivos:
 Finalizar la implementación del producto
 Mejorar y garantizar la calidad del producto
 Finalizar la documentación del proyecto
c) Entradas de la fase:
 Funcionalidad implementada del producto
 Los artefactos de desarrollo relacionado
d) Salidas de la fase:
 Funcionalidad implementada de todo el proyecto de todo el Software
 La documentación del producto finalizado
e) Funciones o roles:
 Equipo de proyecto
 Jefe del proyecto
 Arquitectos del proyecto
 Grupo de apoyo
51
 Grupo directivo
1.10.5. Fase de pruebas y corrección
Se continua con el testeo hasta tener una versión estable del producto según lo establecido por el
cliente, en caso de ser necesario se reparan errores. Una vez culminadas todas las fases es necesario
contar con una aplicación publicable o entregable al cliente.
a) Propósito:
Verificar que el sistema implementa la funcionalidad definida del cliente, proporcionar
retroalimentación al equipo de desarrollo de los defectos y errores encontrados en el Software.
b) Objetivos:
 Probar el sistema basado en la documentación producida en el proyecto.
 Proporcionar información de defectos encontrados
 Planificar la solución a los defectos encontrados
 Fijar los errores hallados
 Producir un sistema libre de errores como sea posible
c) Entradas a la fase:
 Documentación de aceptación de pruebas
 Funcionalidad del usuario definida completamente
 Descripción de la interfaz de usuario que se utilizar para crear casos de pruebas
d) Salidas de la fase:
 Un sistema testeado y corregido (versión final)
 Documentación de errores encontrados
 Informe de pruebas del sistema descripción del proceso de pruebas, también los errores y
defectos encontrados en el Software.
52
 Registro de pruebas realizados en el sistema y los resultados obtenidos al momento de

ejecutar el testeo.
e) Roles:
 Equipo de proyecto
 Grupo de soporte
 Cliente
 Grupo directivo
 Grupo de pruebas de sistemas (Valtion Teknillinen Tutkimuskeskus, 2006)
53
CAPÍTULO II. DISEÑO Y DESARROLLO DE LA APLICACIÓN MÓVIL

54
Para el cumplimiento del proyecto se siguieron los procedimientos recomendados por la

metodología Mobile-D.
2. A
2.1. Exploración
El objetivo de esta fase es la de identificar todos los requisitos de la aplicación, así mismo la
selección del Software para el desarrollo.
Cliente: CPM Medios.
Grupo de trabajo:
Residente
Asesor externo
Asesor interno
2.1.1. Alcance del sistema
El Departamento de Sistemas de acuerdo con sus procedimientos ha considerado el desarrollo de

una solución tecnológica, que consiste en la implementación de una aplicación móvil la cual
agilizará la administración de proyectos.
La aplicación automatizará los siguientes procesos:

a) Manejo de catálogos referente a actores, empresas y partners.
b) Registro, actualización y baja de proyectos.
c) Registro, actualización y eliminación de actividades de un proyecto.
d) Consultas a todo lo ya declarado.
2.1.2. Descripción general

2.1.2.1. Perspectiva
Con la finalidad de apoyar al Departamento de Sistemas, la aplicación móvil se compone de los

siguientes módulos:
1) Iniciar sesión
2) Manejo de catálogos por consulta
a) Actores
55
b) Empresas
c) Principales
3) Proyectos
4) Actividades
2.1.2.2. Funciones
En la Tabla 3 se visualiza cada una de las actividades que pueden realizar los usuarios en los
módulos de la aplicación.
Módulo Funciones
Catálogos Se podrá consultar a actores, empresas y principales
Proyecto El usuario podrá registrar, actualizar, eliminar y consultar
Actividades El usuario podrá registrar, actualizar, eliminar y consultar actividades

de un proyecto
Tabla 3. Módulos
Fuente: Elaboración propia.
Características de los usuarios

La Tabla 4 presenta los usuarios SuperAdministrador y Administrador quienes tendrán el control
absoluto de la aplicación.
Usuario Características
Manejo de catálogos
SuperAdministrador Registro de proyectos y actividades
Presentación
Monitorear
Base de datos
Manejo de catálogos
Administrador Registro de proyectos y actividades
Presentación
Monitorear
Tabla 4. Descripción de las actividades de los usuarios
Fuente: Elaboración propia.
2.1.2.3. Restricciones
Las restricciones o limitaciones que se pueden presentar en el desarrollo de la aplicación se

presentan en el servidor que provee a la aplicación de servicios Web.
56
2.1.2.4. Suposiciones y dependencias
SD-1: Principal: Catálogo proporcionado por el departamento de sistemas.

SD-2: Perfiles: SuperAdministrador y Administrador para esta versión.
SD-3: Un Actor puede ser representante y partner a la vez.
SD-4: Un puede estar asociado como máximo a 5 partners.
SD-5: Un proyecto puede no tener ningún partner asociado.
2.1.3. Requerimientos
2.1.3.1. Requerimientos de interfaces externas
 Interfaces de usuario
IU-1: La aplicación debe contener estilos en los botones, texto, entre otros elementos como
opciones de menú.
IU-2: Las interfaces serán sencillas con operaciones que permitan almacenar, modificar, consultar
y eliminar.
 Interfaces de Hardware
IH-1: Los usuarios requerirán equipo, como: un dispositivo móvil con sistema operativo Android
o iOS.
IH-2: La aplicación debe interactuar a través de las interfaces adecuadas con la base de datos.
 Interfaces de Software
IS-1: Implementar la aplicación móvil a un dispositivo.

 Interfaces de comunicación
IC-1: Para el uso de la aplicación móvil se debe contar con internet como medio de comunicación
entre la aplicación móvil y el Servicio Web (WCF).
IC-2: La relación con un gestor de base de datos.
2.1.3.2. Requerimientos de interfaces internas
RII-1: Toda la información relacionada con actor, empresa y principal solo será de consulta
57
RII-2: Todos los eventos en la aplicación deben mostrarse.
2.1.4. Requerimientos de datos
Se requiere una base de datos para almacenar las siguientes entidades:

a. Actor
b. Proyecto
c. Empresa
d. Principal
e. TipoPrincipal
f. ProyectoActor
g. ProyectoEmpresa
h. Actividades
Se definieron las reglas de relación como se muestra en la Tabla 5, también se generó un

cronograma de actividades como se muestra en la Tabla 6.
Relación Regla
Un actor Deberá tener asociado un tipo de actor.
Deberá tener asociado un usuario.
Un proyecto Deberá tener asociado una empresa.
Deberá tener asociado un principal.
Deberá tener asociado un usuario.
Un proyecto actor Deberá tener asociado un proyecto.
Deberá tener asociado un actor.
Deberá tener asociado un tipo de actor.
Un usuario Deberá tener asociado un usuario rol.
Deberá tener asociado un usuario proyecto.
Deberá tener asociado un usuario contacto.
Una actividad Deberá tener asociado proyecto.
Un proyecto empresa Deberá tener asociado un proyecto.
Deberá tener asociada a una empresa.
Un principal Deberá tener asociado a un tipo principal.
Deberá tener asociado una dependencia.
Un usuario roles Deberá tener asociado a un rol.
Deberá tener asociado a un usuario.
Un usuario proyecto Deberá tener asociado un usuario.
Deberá tener asociado un proyecto.
Tabla 5. Reglas de relación de datos
58
Septiembre Octubre Noviembre Diciembre Enero

Actividad//Mes 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Formulación y aprobación
anteproyecto
Documento
Análisis de documentación
Lectura de documentos
Entrevistas
Diseño y codificación
Exploración
Elección de herramientas de
desarrollo
Planeación de tareas
Inicialización
Configuración de proyecto
Análisis inicial de
requerimientos
Planeación de la arquitectura
de línea (Diagramas, casos de
uso, clases, actividades y
relacional)
Test de aceptación
Producción
Día de planeación
Día de trabajo
Día de liberación
Estabilización
Día de planeación
Día de trabajo
Recapitulación de
documentación
Día de liberación
Prueba y corrección del
sistema
Prueba con los test
Tabla 6. Cronograma de actividades
59
2.2. Inicialización
Para cumplir con esta fase se hizo la elección del Software de desarrollo, asi como los recursos
físicos, técnicos y las herramientas para realizar las pruebas (dipositivo móvil: tablet lenovo,
smartphone samsung y htc); también se realizarón diseños de interfaces de la aplicación, para así
pasar a la realización de diagramas, casos de uso de la lógica de comportamiento de la aplicación
móvil.
2.2.1. Software de desarrollo
Para el funcionamiento de la aplicación, está consumirá un Servicio Web WCF, por lo que es
necesario que la aplicación utilice internet Wi-fi o de datos móviles.
 Software: Se considera Visual Studio 2015, con la integración de Xamarin 4 que habilita la
sección de desarrollo cross-platform.
En la Figura 19 se observan las aplicaciones disponibles que pueden utilizarse para desarrollar
aplicaciones móviles.
Figura 19. Captura de pantalla de la vista de la creación de aplicación

Fuente: Elaboración propia, en base en el IDE de Visual Studio 2015
 Servicio Web: Tanto para la aplicación como el servicio se desarrollarán en Visual Studio.
En la Figura 20 se observa la opción para crear la aplicación de tipo servicio WCF.

60
Figura 20. Captura de pantalla de la vista de la creación del Web Service WCF
2.2.2. Recursos físicos y técnicos
La Tabla 7 especifica los recursos físicos y técnicos necesarios para el desarrollo de la aplicación
móvil.
RECURSOS PARA LLEVAR A CABO DESARROLLO DE LA APLICACIÓN
RECURSOS FÍSICOS RECURSOS TÉCNICOS
 Procesador de 1,6 GHz o superior  WCF (Windows Comunication

Fundation)
 1 GB de RAM (1,5 GB si se ejecuta
en una máquina virtual)
 SQL Server 2012
 10 GB de espacio disponible en el
disco duro  Visual Studio 2015 Update 3
 Unidad de disco duro de 5400 rpm  Xamarin 4 para Visual Studio 2015
(revolución por minuto)
 Tarjeta de vídeo compatible con

DirectX 9 con una resolución de pantalla
de 1024 x 768 o superior
Tabla 7. Recursos físicos y técnicos para el desarrollo de la aplicación

La Tabla 8 explica los recursos físicos y técnicos necesarios para alojar un servidor de base de
datos.
61
RECURSOS PARA EL SERVIDOR DE BASES DE DATOS
RECURSOS FÍSICOS RECURSOS TÉCNICOS
 Memoria 1GB  .NET Framework 3.5 en adelante.

 1 GB de RAM (1,5 GB si se ejecuta en
una máquina virtual)
 6 GB de espacio disponible en el disco

duro en adelante en caso de que la base vaya
creciendo.
Tabla 8. Recursos físicos y técnicos para el servidor SQL Server

2.2.3. Arquitectura
Figura 21. Arquitectura de desarrollo de la aplicación

Fuente: 1.- “Servidor”, recuperado en https://pixabay.com/es/equipo-base-de-datos-red-servidor-156948/, 24/junio/2017.
2.- “Nube”, recuperado en https://www.technodyan.com/la-ofimatica-en-la-nube/, 24/junio/2017. 3.- “Servidor IIS”,
recuperado en http://www.iconarchive.com/show/vista-hardware-devices-icons-by-icons-land/Home-Server-icon.html,
24/junio/2017. 4.- “Dispositivo móvil”, recuperado en http://nanobul.com/tablet-hannspree-sn1at74b-
10418?tag=B&sort=p.sort_order&order=ASC&page=44, 24/junio/2017.
62
En la Figura 21 se muestra que la aplicación está instalada en el dispositivo móvil o cliente, el cual
consumirá el Web Service WCF que contiene la lógica de las operaciones Create, Read, Update y
Delete (CRUD) que significa crear, leer, actualizar y eliminar de los módulos proyectos y
actividad.
El Web Service WCF funciona como intermediario entre la aplicación y la base de datos lo que
permitirá una mayor seguridad de información, en atención a que la conexión a la base de datos se
realiza por autenticación de usuario.
El comportamiento inicia de la siguiente forma: cliente envía una petición y es respondida por
parte del servicio como se ve en la Figura 21.
2.2.4. Diagrama de actividad
En él se especifican las opciones a las que tiene acceso el usuario y la secuencia según sus
elecciones como se ve en la Figura 22 el menú comprende el módulo proyecto y módulo actividad
con las operaciones registrar, eliminar, actualizar y consultar. Según Rumbaugh y Jacobson (2000)
un diagrama de actividad es aquel que contiene bifurcaciones, así como divisiones de control. Los
hilos concurrentes representan actividades que se pueden realizar por los diversos objetos o
personas en una organización; los estados de actividad se representan con los extremos
redondeados que contienen una descripción de actividad y sus transiciones con flechas.
63
Figura 22. Diagrama de actividad de la aplicación

64
2.2.5. Diagrama de casos de uso general
Son una unidad coherente de funcionalidad, expresada como transacción entre los actores y el
sistema como menciona Rumbaugh y Jacobson (2000), es decir, muestran la funcionalidad del
sistema de acuerdo a los permisos que perciben los usuarios llamados actores, en la Figura 23 se
observa que los dos usuarios tienen permiso para agregar, modificar el eliminar proyectos o
actividades.
Figura 23. Caso de uso general

2.2.6. Descripción de los casos de uso
Los casos de uso se describen a partir del comportamiento de un actor, así como el del sistema
como se muestra en las siguientes descripciones paso a paso, también las precondiciones,
poscondiciones, los cursos alternos y requerimientos especiales.
65
2.2.6.1. Caso de uso iniciar sesión
La Tabla 9 muestra la descripción de los actores, propósito, resumen, tipo precondiciones así como
las poscondiciones, una vez que se explican estas a continuación en la Tabla 10 se visualiza el
comportamiento del usuario y la aplicación para poder iniciar sesión.
Caso de uso: Iniciar sesión

Actores: SuperAdministrador y Administrador.
Propósito: Ingresar a la aplicación.
Resumen: El usuario ingresa su clave de usuario y contraseña, si los datos son válidos, la
aplicación muestra las opciones a las que tiene acceso el perfil de usuario.
Tipo: Primario y esencial.
Precondiciones: El dispositivo cuente con internet e inicien la aplicación.
Poscondiciones: Una vez que se ha iniciado sesión el usuario podrá hacer uso de las opciones
a las que tiene acceso.
Tabla 9. Caso de uso iniciar sesión
Acción de los actores Respuesta de la aplicación
1.- Este caso de uso solicita abrir la aplicación. 2.- Revisa que el dispositivo móvil tenga conexión
a internet si la respuesta es sí continua al paso 3, si
la respuesta es no se cierra la aplicación para
activar Wi-fi o datos móviles.
3.- El usuario solicita ingresar a la aplicación 4.-La aplicación muestra una interfaz donde solicita
ingresar: usuario y contraseña.
5.-El usuario ingresa su usuario y contraseña 6.-La aplicación envía la solicitud al Web Service
WCF llevando consigo los datos de usuario y la
contraseña.
7.-El servicio realiza su validación con los datos
recibidos, si los datos son correctos responde la
solicitud con un “true”.
8.- La aplicación habilita las opciones a las que
tiene acceso el usuario (Menú).
Cursos Alternos:
Inciso 4: Si la aplicación no puede comunicarse con el servicio la aplicación no funcionará.
Inciso 5: Si los datos son incorrectos el servicio mandará un mensaje de alerta y la aplicación solicitará
ingresar los datos de nuevo para iniciar sesión.
Requerimientos especiales
El dispositivo debe de contar con acceso a internet
Tabla 10. Comportamiento de usuario-aplicación en iniciar sesión
66
2.2.6.2. Caso de uso registrar proyecto
La Tabla 11 muestra la descripción de los actores, el propósito, resumen, tipo, precondiciones y

poscondiciones este caso para registrar un proyecto desde la aplicación. Después en la Tabla 12 se
muestra el comportamiento entre actor y aplicación móvil.
Caso de uso: Registrar proyecto

Propósito: Registrar un nuevo proyecto.
Resumen: El usuario selecciona: prioridad, categoría, responsable, partner, empresa,
periodo, avance, principal y fecha. También agrega el nombre del proyecto, la
rentabilidad y las observaciones, y la aplicación los envía al Web Service, si
los datos son correctos se agrega el proyecto.
Precondiciones: Entrar a la interfaz de menú.
Poscondiciones: Si los datos son correctos, el proyecto se agregará a la base de datos.
Tabla 11. Caso de uso registrar proyecto
1.- Este caso de uso comienza cuando el 2.-La aplicación muestra una interfaz donde solicita
usuario solicita registrar un nuevo proyecto ingresar: nombre del proyecto, la rentabilidad y las
observaciones así como seleccionar prioridad,
categoría, responsable, partner, empresa, periodo,
avance, principal y fecha.
3.-El usuario ingresa y selecciona los datos 4.-La aplicación envía la solicitud de registrar nuevo
solicitados proyecto al Web Service WCF llevando consigo todos
los datos.
5.-El servicio realiza su validación con los datos
recibidos, si los datos son correctos responde a la
aplicación la solicitud con un “true” y devolviendo la
clave del proyecto agregado.
6.- La aplicación muestra un mensaje de “Proyecto
guardado”.
7.-El usuario selecciona “OK” 8.-La aplicación se devuelve al menú de la aplicación
con el proyecto seleccionado.
Cursos Alternos:
Inciso 4: Si la aplicación no puede comunicarse con el servicio la aplicación no funcionará
Inciso 5: Si los datos son incorrectos el servicio mandará un mensaje de alerta y en la interfaz un mensaje
“Proyecto no guardado”.
El dispositivo debe de contar con acceso a internet
Tabla 12. Comportamiento usuario-aplicación en registrar proyecto
67
2.2.6.3. Caso de uso editar proyecto
En la Tabla 13 se muestra la descripción de los elementos del caso de uso para editar proyecto, así
como la descripción del comportamiento entre actor y aplicación móvil en la Tabla 14.
Caso de uso: Editar proyecto

Propósito: Editar un proyecto.
Resumen: El usuario selecciona un proyecto que desee editar, la aplicación envía la
solicitud al Web Service WCF quien devuelve la información del proyecto
como: la prioridad, categoría, responsable, partner, empresa, periodo, avance,
principal y fecha, también el nombre del proyecto, la rentabilidad y las
observaciones, a la interfaz editar proyecto.
Precondiciones: Seleccionar un proyecto.
Poscondiciones: Si los datos son correctos, el proyecto actualizará el registro.
Tabla 13. Caso de uso editar proyecto
1.- Este caso de uso comienza cuando el usuario 2.-La aplicación envía la solicitud al Web Service
solicita editar un proyecto, seleccionando el WCF llevando también id del proyecto.
proyecto
3.-El usuario ingresa y selecciona los datos 4.-El Web Service WCF recibe la petición la ejecuta
solicitados y la devuelve a la aplicación enviando toda la
información del proyecto.
5.-La aplicación muestra la información del
proyecto en la interfaz editar proyecto.
6.- El usuario edita la información y selecciona 7.- La aplicación recupera los datos del proyecto y
guardar los envía al Web Service para actualizar.
8.-El Web Service WCF recibe la petición y lo
ejecuta, si los datos son correctos devuelve un
mensaje igual a verdadero que quiere decir
proyecto actualizado.
9.-La aplicación recibe el resultado y envía un
mensaje a la interfaz de “Proyecto actualizado”.
10.-El usuario selecciona “OK” 11.-Muestra la interfaz de menú.
Cursos Alternos:
Inciso 2: Si la aplicación no puede comunicarse con el servicio la aplicación no funcionará.
Inciso 8: Si los datos son incorrectos el servicio mandará un mensaje de alerta y en la interfaz el mensaje de
“Proyecto no actualizado”.
El dispositivo debe de contar con acceso a internet.
Tabla 14. Comportamiento usuario-aplicación en editar proyecto
68
2.2.6.4. Caso de uso eliminar proyecto
La Tabla 15 muestra la descripción funcional para una eliminación de un proyecto existente; por
otro lado se presenta el comportamiento funcional tanto de los actores como de la aplicación móvil
en la Tabla 16.
Caso de uso: Eliminar proyecto

Actores: SuperAdministrador y Administrador
Propósito: Eliminar un proyecto.
Resumen: El usuario selecciona un proyecto para eliminar o dar de baja un proyecto y
las relaciones ProyectoActor, ProyectoEmpresa, ProyectoActividad se
eliminarán o permanecerán en caso de seleccionar baja de proyecto y se
agregará el motivo.
Poscondiciones: Si se confirma la eliminación, el proyecto será eliminado.
Tabla 15. Caso de uso eliminar proyecto

1.- Este caso de uso comienza cuando el 2.-La aplicación muestra una lista de opciones en la
usuario selecciona un proyecto para borrar que aparece como primera opción baja de un proyecto
y la segunda eliminar proyecto.
3.- El usuario selecciona la opción un proyecto 4.-La aplicación recupera el proceso del proyecto.
para borrar
5. La aplicación solicita confirmar opción.
6.- El usuario confirma la opción un proyecto 7.-La aplicación envía la clave del proyecto la solicitud
para borrar del proceso al Web Service WCF quien recibe la
solicitud, si la opción es baja del proyecto solicitara el
motivo de la baja.
8.- El usuario ingresa el motivo de la baja. 9.-La aplicación rescata la información ingresada y la
envía al Web Service WCF quien recibe la información
y el proyecto se actualizara a modo no activo
10.-La aplicación recibe el resultado, envía un mensaje
en la interfaz de proyecto que dice “El proyecto ahora
es no activo, ya no aparecerá en lista”.
11.-El usuario selecciona “OK” 12.- La aplicación se devuelve al menú de la
aplicación.
Cursos Alternos:
Inciso 2: Si la aplicación no puede comunicarse con el servicio, la aplicación no funcionará.
Inciso 4: Si los datos son incorrectos, el servicio mandará una alerta y en la interfaz un mensaje con la
descripción del error.
Inciso 8: Si la operación se cancela, la operación se detendrá y no habrá pérdida de datos.
Tabla 16. Comportamiento usuario-aplicación en eliminar proyecto
69
2.2.6.5. Caso de uso registrar actividad
En la Tabla 17 se visualiza la descripción de los elementos de caso de uso para registrar un

proyecto, también en la Tabla 18 se muestra la secuencia de acciones entre los actores y la
aplicación móvil.
Caso de uso: Registrar actividad

Actores: SuperAdministrador y Administrador
Propósito: Registrar una actividad a un proyecto.
Resumen: El usuario agrega el nombre de la actividad, fecha de inicio, fecha de término,
comentario y seleccionar estado.
Poscondiciones: Si los datos son correctos, se agrega la actividad al proyecto.
Tabla 17. Caso de uso registrar actividad
1.- Este caso de uso comienza cuando el 2.-La aplicación solicita seleccionar proyecto.
usuario solicita registrar una actividad.
3.-El usuario selecciona proyecto. 4.-La aplicación recupera el identificador del
proyecto y solicita nombre de la actividad, fecha de
inicio, fecha de término, comentario y seleccionar
estado: Pendiente o Terminado.
5.-El usuario agrega nombre de la actividad, 6.-La aplicación envía la solicitud registrar
fecha de inicio, fecha de término, comentario y actividad al Web Service WCF con los datos
seleccionar estado: Pendiente o Terminado. recibidos del usuario, si los datos son correctos
responde a la aplicación la solicitud con un “true”.
7.- La aplicación muestra un mensaje de “Actividad
guardada”.
8.-El usuario selecciona “OK” 9.-La aplicación se devuelve al menú de la
aplicación.
Cursos Alternos:
Inciso 5: Si los datos son incorrectos, el servicio mandará una alerta y en la interfaz un mensaje con la
Tabla 18. Comportamiento usuario-aplicación en registrar actividad
70
2.2.6.6. Caso de uso editar actividad
El propósito de este caso implica editar una actividad por lo que se muestran más detalles de los
elementos en la Tabla 19 y en la Tabla 20 se visualiza qué acciones realizan los actores y qué
acciones realiza la aplicación móvil.
Caso de uso: Editar actividad

Propósito: Editar una actividad de un proyecto.
Resumen: El usuario selecciona el proyecto para cargar sus actividades, selecciona la
actividad, edita la información necesaria y actualiza actividad.
Poscondiciones: Si los datos son correctos, se actualiza la actividad del proyecto.
Tabla 19. Caso de uso editar actividad
1.- Este caso de uso comienza cuando el 2.-La aplicación solicita seleccionar proyecto.
usuario solicita editar una actividad
3.-El usuario selecciona proyecto 4.-La aplicación recupera el id del proyecto y
solicita sus actividades al Web Service WCF.
5.-El Web Service WCF ejecuta la petición y
devuelve la consulta de las actividades y responde
a la aplicación la solicitud con un “true”.
6.- La aplicación recibe la información y la carga
en la interfaz.
7.-El usuario selecciona la actividad 8.- La aplicación recupera la información que le
envié el Web Service WCF. La aplicación envía a la
interfaz editar actividad con la información de la
actividad.
9.-El usuario edita la información necesaria y 10.- La aplicación envía la información al Web
guarda Service WCF y devuelve el resultado.
11.- La aplicación envía un mensaje de “Actividad
actualizada”.
12.-El usuario selecciona “OK” 13.-La aplicación se devuelve al menú.
Cursos Alternos:
Inciso 5: Si los datos son incorrectos, el servicio mandará una alerta y en la interfaz mensaje con la
Tabla 20. Comportamiento usuario-aplicación en editar actividad
71
2.2.6.7. Caso de uso eliminar actividad
El propósito de este caso consiste en eliminar una actividad como se observa en la Tabla 21 donde
se especifican las precondiciones y poscondiciones. La Tabla 22 representa el comportamiento
paso a paso de los actores y la aplicación móvil para realizar la eliminación de una actividad.
Caso de uso: Eliminar actividad

Propósito: Eliminar una actividad.
Resumen: El usuario selecciona una actividad para eliminar.
Precondiciones: Seleccionar un proyecto para cargar las actividades.
Poscondiciones: Si se confirma la eliminación, la actividad será eliminada.
Tabla 21. Caso de uso eliminar actividad
1.- Este caso de uso comienza cuando el 2.-La aplicación recupera el id de la actividad y
usuario selecciona una actividad para eliminar. envía la solicitud al Web Service WCF en eliminar
actividad.
4.-El Web Service WCF recibe la solicitud y
devuelve el resultado si es “true”, se hizo la
eliminación.
5.-La aplicación recibe el resultado, envía un
mensaje en la interfaz con un mensaje “Actividad
eliminada”.
6.-El usuario selecciona “OK”. 7.- La aplicación se devuelve al menú.
Cursos Alternos:
Inciso 4: Si los datos son incorrectos, el servicio mandará una alerta y en la interfaz un mensaje con las
Tabla 22. Comportamiento usuario-aplicación en eliminar actividad
2.3. Producción
2.3.1. Diccionario de datos
Un diccionario de datos mantiene la información sobre las entidades utilizadas en el diseño de la

base de datos. La Tabla 23 muestra la descripción de atributos de la entidad Tipo de actor.
72
1. Entidad: Son las tablas que contiene la base de datos.
2. Atributo: Son los campos de las entidades.
3. [*]: Llave primaria.
4. [**]: Llave foránea.
5. Tipo de dato: Se ocupa para almacenar y agregar longitud si es el caso.
6. Null [NN]: Atributos que no pueden quedar vacíos.
7. Null [--]: Atributos que pueden quedar vacíos.
8. Descripción: Resumen de los datos.
9. Dominio: Caracteres que acepta el atributo de la entidad.
Entidad Atributos Llaves Tipo de Null Descripción Dominio

Datos
TipoActor Identificador * bigint NN Número asignado a {0-9}
TipoActor al momento de
ser registrado.
Descripcion nvarchar(50) NN Tipo de Actor que puede {A-Z|a-z|}
ser responsable o partner.
Tabla 23. Diccionario de datos de la entidad TipoActor
En la
Datos
Actor Identificador * bigint NN Número asignado al Actor {0-9}
al momento de ser
registrado
Nombre nvarchar(70) -- Nombre del Actor. {A-Z|a-z|.}
Iniciales nvarchar(10) -- Iniciales del Actor. {A-Z|a-z|}
Prioridad int NN Número de partner que es {1-5}
asignada en relación a un
proyecto.
IdTipoActor ** bigint NN Tipo de Actor que puede {0-9}
Origen nvarchar(50) -- El origen de un actor {A-Z|a-z|}
puede ser interno, externo,
externo2 y externo3.
IdUsuario ** bigint -- Clave asignado a un {0-9}
Usuario en relación a un
Actor
Tabla 24 se muestra la descripción detallada de los atributos de la entidad Actor, esta tiene una
relación con la entidad TipoActor.

Datos
73
Actor Identificador * bigint NN Número asignado al Actor {0-9}
al momento de ser
registrado
Nombre nvarchar(70) -- Nombre del Actor. {A-Z|a-z|.}
Iniciales nvarchar(10) -- Iniciales del Actor. {A-Z|a-z|}
Prioridad int NN Número de partner que es {1-5}
asignada en relación a un
proyecto.
IdTipoActor ** bigint NN Tipo de Actor que puede {0-9}
Origen nvarchar(50) -- El origen de un actor {A-Z|a-z|}
puede ser interno, externo,
externo2 y externo3.
IdUsuario ** bigint -- Clave asignado a un {0-9}
Usuario en relación a un
Actor
Tabla 24. Diccionario de datos de la entidad Actor
La Tabla 25 muestra el diccionario de datos con los atributos de la entidad ProyectoActor:

Datos
Proyecto Identificador * bigint NN Número asignado a {0-9}
Actor ProyectoActor al momento de
ser registrado
IdProyecto ** bigint NN Clave de proyecto que es {0-9}
asignado al momento de hacer
un registro.
IdActor ** bigint NN Clave del actor que es {0-9}
asignada en relación al tipo de
proyecto.
Prioridad int -- Número de prioridad que es {1-5}
asignado en relación a un
proyecto.
IdTipoActor ** bigint -- Número asignado en relación {0-9}
al TipoActor.
Tabla 25. Diccionario de datos de la entidad ProyectoAtor
En la Tabla 26 se visualizan los atributos de la entidad TipoPrincipal que es su clave y nombre.

Datos
TipoPrincip Identificador * bigint NN Número asignado a {0-9}
al TipoPrincipal al momento
de ser registrado.
Nombre nvarchar(50) NN Tipo de Principal que {A-Z|a-z|}
puede ser entidad,
municipio, dependencia,
ámbito, sector, categoría y
otro.
Tabla 26. Diccionario de datos de la entidad TipoPrincipal
74
Los atributos de la entidad Principal son la clave de principal, descripción, clave del tipo de
principal y la clave de dependencia como se ve en la Tabla 27.
Datos
Principal Identificador * Bigint NN Número asignado a {0-9}
Principal al momento de
ser registrado.
Descripción varchar(100) NN Nombre de Principal. {A-Z|a-z|}
IdTipoPrincipal ** Bigint NN Clave de Tipoprincipal que {0-9}
es asignada en relación al
tipo de principal.
IdDependencia ** Bigint -- Número asignado del {0-9}
catálogo Tipo de Principal
referente a Dependencia.
Tabla 27. Diccionario de datos de la entidad Principal
El diccionario de datos de la entidad o tabla ProyectoEmpresa tiene 4 atributos que se describen

en la Tabla 28.
Datos
Proyecto Identificador * bigint NN Número asignado a {0-9}
Empresa ProyectoEmpresa al momento de
ser registrado
IdProyecto ** bigint -- Clave del proyecto que es asignada {0-9}
en relación al Proyecto.
IdEmpresa ** bigint -- Clave de la empresa que es {0-9}
asignada en relación a la Empresa.
Prioridad int NN Número asignado en relación a la {1-5}
prioridad de un proyecto.
Tabla 28. Diccionario de datos de la entidad ProyectoEmpresa
La Tabla 29 muestra los atributos de la entidad o tabla roles, estos roles se asignan a los usuarios.

Datos
Roles Identificador * bigint NN Número asignado a Roles al {0-9}
momento de ser registrado.
Nombre nvarchar(50) NN Nombre del rol que puede tener {A-Z|a-
un usuario que puede ser z|}
SuperAdministrador,
Administrador, Consultor,
Consultor2 y Consultor3.
Tabla 29. Diccionario de datos de la entidad Roles
75
El diccionario de datos de la entidad o tabla UsuarioRoles contiene 4 atributos como se muestra
en la Tabla 30.

Datos
Usuario Identificador * bigint NN Número asignado a UsuarioRoles {0-9}
Roles al momento de ser registrado.
UsuarioId ** bigint NN Clave de Usuario que es asignada {0-9}
en relación a UsuarioRoles.
RolesId ** bigint NN Clave de Roles que es asignada en {0-9}
relación a UsuarioRoles.
FechaRegistro datetime Se muestra la fecha en la que un DD/MM/
usuario ingresa al sistema AAAA
Tabla 30. Diccionario de datos de la entidad UsuarioRoles
El diccionario de datos de la entidad UsuarioProyecto se muestra en la Tabla 31.

Datos
UsuarioPro Identificador * bigint NN Número asignado a {0-9}
yecto UsuarioProyecto al momento de
ser registrado.
IdUsuario ** bigint -- Clave de Usuario que es asignada {0-9}
en relación a UsuarioProyecto.
IdProyecto ** bigint -- Clave de Proyecto que es {0-9}
asignada en relación a
UsuarioProyecto.
Tabla 31. Diccionario de datos de la entidad UsuarioProyecto
La tabla Usuario tiene contiene atributos que son la clave de usuario, nombre, contraseña y correo
como se ve en la Tabla 32.

Datos
Usuario Identificador * bigint NN Número asignado a Usuario {0-9}
al momento de ser
registrado.
UserName nvarchar(50) -- Nombre del usuario. {A-Z|a-z|}
Contrasenia nvarchar(50) -- Contraseña del usuario. {A-Z|a-z|}
Email nvarchar(50) -- Email del usuario. {A-Z|a-z|}
Tabla 32. Diccionario de datos de la entidad Usuario
76
El diccionario de datos de la entidad o tabla proyecto contiene 15 atributos que se visualizan en la
Tabla 33.
Entidad Atributos Llaves Tipo de Datos Null Descripción Dominio
Proyectos IdProyecto * bigint NN Número asignado a {0-9}
Proyectos al momento de ser
registrado.
Categoria int -- Categoría a la que pertenece {1-5}
el proyecto.
Prioridad smallint -- Número asignado en {1-5}
relación a la prioridad de un
proyecto.
Avances nvarchar(50) NN Número asignado de {A-Z|a-z|}
acuerdo al avance del
proyecto.
FechaCompr datetime NN Fecha en la que se tiene que DD/MM/
omiso hacer la entrega de un AAAA
proyecto.
Nombre nvarchar(250) -- Nombre del proyecto. {A-Z|a-z|}
IdPrincipal ** bigint NN Clave de Principal que es {0-9}
Proyectos.
Observacione nvarchar(250) -- Elementos adicionales que {A-Z|a-z|}
s describen algunas
observaciones con respecto
al proyecto registrado.
EsActivo bit -- Verificar si un proyecto esta {0-1}
activo o inactivo.
IdEmpresa ** bigint -- Clave de Empresa que es {0-9}
Proyectos.
Rentabilidad int -- Valor asignado a un {0-9}
proyecto de acuerdo a su
rentabilidad.
UserName nvarchar(50) -- Nombre del usuario, el cual, {A-Z|a-z|}
hace el registro del proyecto.
Hora_Operac datetime -- Hora específica en la que el DD/MM/
ion usuario hace el registro de AAAA
un proyecto.
Origen nvarchar(50) -- Se define el origen del {A-Z|a-z|}
proyecto, que puede ser
interno, externo, externo2 y
externo3.
Periodo nvarchar(50) -- Se describe el periodo del {A-Z|a-z|}
proyecto.
Tabla 33. Diccionario de datos de la entidad Proyectos
La Tabla 34 muestra el diccionario de datos de la entidad Actividades, donde se describen cada

uno de los atributos.
77
Datos
Actividades Identificador * bigint NN Número asignado al {0-9}
Comentario al momento de ser
registrado.
Nombre nvarchar(20 -- Nombre que proporciona un {A-Z|a-
0) usuario de acuerdo a la z|}{0-9}
actividad
FechaIni datetime -- Fecha de inicio de actividad DD/MM/
AAAA
FechaFin datetime -- Fecha final de la actividad a DD/MM/
realizar AAAA
Cometario varchar -- Descripción de la actividad a {A-Z|a-
realizar z|}{0-9}
Estado varchar(50) -- Estado de la actividad a partir {“PENDI-
de que se crea ENTE”}
{“TERMI
-NADO”}
IdProyecto ** bigint NN Clave del proyecto a quien {0-9}
pertenece la actividad
Tabla 34. Diccionario de datos de la entidad Actividades
2.3.2. Bases de datos
 Tablas:
a) Actividades
b) Proyectos
 Procedimientos almacenados
a) Insertar proyecto g) Eliminar proyecto
b) Insertar proyectoactor h) Baja de un proyecto
c) Insertar proyectoempresa i) Insertar actividad
d) Actualizar proyecto j) Actualizar actividad
e) Actualizar proyectoactor k) Eliminar actividad
f) Actualizar proyectoempresa
2.3.3. Diagrama de clases
Un diagrama de clases describe los tipos de objetos que hay en el sistema y las diversas clases de
relaciones estáticas que existen entre ellos según Fowler & Scott (1999).
78
En la Figura 24 se aprecia el modelo de clases que se rescata de la base de datos en SQL Server,
se muestra en Visual Studio y para actualizar solo basta con seleccionar la opción update
(actualizar) en el modelo.
2.3.4. Diagrama de Entidad-Relación
Un diagrama de Entidad-Relacion, también llamado diagrama E-R se utiliza para representar las
entidades que contiene una base de datos.
“Los diagramas de entidad-relación ayudan al analista de sistemas a comprender las
entidades y relaciones que conforman el sistema organizacional. Los diagrmas E-R pueden
describir relaciones uno a uno, uno a muchos, muchos a uno y muchos a muchos” (E.
Kendall & E. Kendall, 2005).
En la Figura 25 muestra que el diagrama se compone de 12 Entidades que son TipoPrincipal,

Principal, Proyecto, Actividades, Empresa, ProyectoEmpresa, TipoActor, Actor, ProyectoActor,
Roles, UsuarioRol,Usuario y UsuarioProyecto. Quienes integran sus propios atributos.
79
Figura 24. Diagrama de clase

80
Figura 25. Diagrama Entidad-Relación

81
2.3.5. Diseño de la aplicación móvil
2.3.5.1. Interfaz de iniciar sesión
La Figura 26 muestra el diseño de interfaz para iniciar sesión de la aplicación lo cual se describe
en la Tabla 35.
Figura 26. Interfaz iniciar sesión

Fuente: Elaboración propia, con base en https://solcmraeey.proto.io/, 02/septiembre/2017
Numeración Nombre Descripción Ejemplo

1 Encabezado Texto Título: Iniciar sesión
2 Usuario Caja de texto Administrador
3 Contraseña Caja de texto Admin
4 Ingresar Botón Presionar el botón “Ingresar” para ingresar a las
opciones
Tabla 35. Descripción de la interfaz iniciar sesión
2.3.5.2. Interfaz de menú
La Figura 27 muestra el diseño de la interfaz de menú de la aplicación, así como sus componentes
que la integran mismos que se describen en la Tabla 36.
82
Figura 27. Interfaz menú


1 Encabezado Texto Título: Menú
2 Registrar nuevo usuario Botón Presionar el botón para abrir interfaz que solicita
información para registrar un proyecto
3 Lista de proyectos ListView Lista de todos los proyectos registrados
4 Eliminar Botón Presionar el botón para dar de baja el proyecto
seleccionado
5 Editar Botón Presionar el botón para abrir interfaz que carga
información y poder editar el proyecto seleccionado
en la lista
6 Agregar actividad Botón Presionar el botón para abrir interfaz que solicita
información para agregar actividad al proyecto
seleccionado en la lista
7 Actividades del ListView Lista de todas las actividades que le pertenecen a un
proyecto proyecto seleccionado
83
8 Eliminar Botón Presionar el botón para eliminar la actividad que le
pertenece al proyecto seleccionado
9 Editar Botón Presionar el botón para abrir interfaz que carga
información para editar la actividad
10 Detalle Texto Información resumen del proyecto seleccionado
Tabla 36. Descripción de la interfaz menú
2.3.5.3. Interfaz de proyecto
La Figura 28 presenta el diseño de la interfaz de proyecto donde se puede guardar un proyecto, en

la Tabla 37 se describen los elementos del diseño.
Figura 28. Interfaz de proyecto

84
1 Encabezado Texto Título: Proyecto
2 Seleccionar prioridad Lista de [1-5] 1
3 Seleccionar categoría Lista de [★-★★★★★] [★★]
4 Seleccionar responsable Lista Administrador
5 Seleccionar partner Lista Todos los actores de tipo partner
6 Partners Lista de los partners MCM, JDLR
seleccionados
7 Nombre del proyecto Caja de texto “APP CONTROL DE GASTOS”
8 Seleccionar empresa Lista Todas las empresas
9 Empresas Lista de las empresas ACER®
seleccionadas
10 Rentabilidad Texto 20
11 Seleccionar avance Lista de % 5%
12 Observaciones Texto “PRESENTAR PROPUESTA”
13 Seleccionar principal Lista
14 Fecha Fecha 30/06/2017 12:00:00 a.m.
15 Cancelar Botón Presionar el botón para regresar al menú de
la aplicación
16 Guardar Botón Presionar el botón para guardar el proyecto
Tabla 37. Descripción de interfaz editar proyecto
2.3.5.4. Interfaz de editar proyecto
En la Figura 29 se aprecian cada uno de los elementos que serán necesarios para realizar una
modificación a un proyecto, la descripción se aprecia en la Tabla 38.
85
Figura 29. Interfaz editar proyecto

Fuente: Elaboración propia, con base en https://solcmraeey.proto.io/,
02/septiembre/2017
Numeración Nombre Descripción Ejemplo (es opcional la modificación)

1 Encabezado Texto Título: Editar Proyecto
2 Seleccionar prioridad Lista de [1-5] 1
3 Seleccionar categoría Lista de [★-★★★★★] [★★]
4 Seleccionar responsable Lista
5 Seleccionar partner Lista Todos los actores de tipo partner
6 Parners Lista de los partners
seleccionados
7 Nombre del proyecto Caja de texto “APP CONTROL DE GASTOS”
8 Seleccionar empresa Lista Todas las empresas
9 Empresas Lista de las empresas
seleccionadas
86
10 Rentabilidad Texto 20
11 Seleccionar avance Lista de % 5%
12 Observaciones Texto “PRESENTAR PROPUESTA”
13 Seleccionar principal Lista () “”
14 Fecha Fecha 30/06/2017 12:00:00 a.m.
la aplicación
16 Guardar Botón Presionar el botón para guardar el proyecto
Tabla 38. Descripción de la interfaz editar proyecto
2.3.5.5. Interfaz de actividad
La Figura 31 muestra los elementos necesarios para guardar una actividad que le pertenece a un
proyecto, una descripción de ello se ve en la Tabla 39.
Figura 30. Interfaz de actividad

87

2 Proyecto Texto resumen del Nombre del proyecto: Aplicación nueva
proyecto Resumen X
3 Actividad Encabezado Título: Actividad
4 Nombre de la actividad Caja de texto “CITA URGENTE DE LIBERACIÓN”
5 Fecha de inicio Fecha y hora 13/02/2017 06:58:00 a.m.
6 Fecha de termino Fecha y hora 12/02/2017 06:58:00 a.m.
7 Comentario Caja de texto “LISTAR LOS DOCUMENTOS
IMPORTANTES”
8 Seleccionar estado Lista con dos opciones “PENDIENTE”
[“PENDIENTE” o
“TERMINADO”]
la aplicación
10 Guardar Botón Presionar el botón para guardar la actividad
del proyecto
Tabla 39. Descripción de la interfaz actividad
2.3.5.6. Interfaz editar actividad
En la Figura 31 se aprecian los elementos que pueden ser editados para actualizar una actividad de
un proyecto, estos se describen en la Tabla 40.
88
Figura 31. Interfaz editar actividad

02/septiembre/2017
Numeración Nombre Descripción Ejemplo (es opcional la modificación)

2 Proyecto Texto resumen del Nombre del proyecto: Aplicación nueva
proyecto Resumen X
3 Actividad Encabezado Título: Actividad
4 Nombre de la actividad Caja de texto “CITA URGENTE DE LIBERACIÓN”
5 Fecha de inicio Fecha y hora 13/02/2017 06:58:00 a.m.
6 Fecha de termino Fecha y hora 12/02/2017 06:58:00 a.m.
7 Comentario Caja de texto “LISTAR LOS DOCUMENTOS
IMPORTANTES”
8 Seleccionar estado Lista con dos opciones “PENDIENTE”
[“PENDIENTE” o
“TERMINADO”]
89
la aplicación
10 Guardar Botón Presionar el botón para guardar la actividad
del proyecto
Tabla 40. Descripción de interfaz editar actividad
2.3.6. Creación del Web Service WCF (Windows Comunication Fundation)
Una vez creada la aplicación de tipo WCF Service Aplication o en español aplicación de servicio
WCF la estructura de la aplicación en Visual Studio ver Figura 32.
Figura 32. Composición de la aplicación del Web Service WCF

Numeración Nombre
1 Nombre del proyecto
2 La clase del modelos de datos
3 Administrador de la aplicación
Web
4 Clase que funciona como cliente
(opcional)
5 Librerías del servicio WCF
Tabla 41. Descripción de los elementos de la aplicación

Web Service WCF
90
En la Tabla 41 se aprecia que la aplicación se compone de 4 elementos para su funcionamiento
mismos que se describen a continuación:
1. Modelo de datos: Según (Piñeiro Gómez) es un conjunto de símbolos, conceptos y reglas que
permiten representar los datos que se van a almacenar en la base de datos.
2. Aplicación Web: Es aquella que es subida a la nube mediante un servidor IIS para que el
usuario final pueda hacer peticiones conforme a las funcionalidades que se le brinden en la
aplicación móvil.
3. Aplicación de cliente: Aquí se crea un cliente para comprobar que el Servicio Web esté
funcionando correctamente.
4. Servicio Web WCF: Está compuesto por el Service1.cs y el IService1.cs
a) Service1.cs: Aquí se alojan loa métodos declarados en la interface.
b) IService.cs: Aquí se define un grupo de funciones relacionadas que una
clase puede implementar.
Figura 33. Elementos de la librería del Web Service WCF

En la Figura 33 se observa que el IService.cs contiene el nombre de los métodos, el Service1.cs

contiene el comportamiento de los métodos.
91
A continuación, en la Tabla 35 se muestra como agregar el modelo de datos desde Visual Studio
en el proyecto, para el mapeo de objetos contenidos en la base de datos incluyendo procedimientos
almacenados y estructura de relación de objetos.
En la Figura 34 se observa el uso de ADO.NET Entity Data Model para uso de contexto datos que
contiene la base de datos en SQL Server.
Figura 34. Captura de pantalla de la vista agregar ADO.NET Entity Data Model
En la Figura 35 se observa que Code Fist from Database es la herramienta que permite obtener
el modelo desde la base de datos existente, crear la conexión y que se incluyan todos los objetos
Figura 35. Captura de pantalla de vista agregar módelo (Code First from database)
En la Figura 36 se observan, las entidades, así como las vistas y los procedimientos almacenados
mismos que van a ser utilizados; todo ello contenido en un archivo con extensión .edmx
Figura 36. Captura de pantalla de la vista de mapeado de la base de datos a la

solución
92
La Figura 37 muestra todas las entidades contenidas en la base de datos y que se traen como clases
al proyecto.
Figura 37. Captura de pantalla de la vista de entidades y procedimientos almacenados

93
La Figura 38 muestra los procedimientos almacenados obtenidos desde la base de datos que
obtiene el archivo .edmx
Figura 38. Captura de pantalla de la vista de los procedimientos almacenados

94
2.3.6.1. Procedimientos creados en el Web Service WCF
a) Agregar proyecto h) Obtener actores
b) Actualizar proyecto i) Obtener empresas
c) Eliminar ProyectoEmpresa j) Agregar actividad
d) Eliminar Proyectoactor k) Actualizar actividad
e) Baja de un proyecto l) Eliminar actividad
f) Obtener proyectos m) Consultar actividad
g) Obtener actividades
2.3.6.2. Diagramas de flujo
El desarrollo de un diagrama de flujo de datos lógicos para el servicio Web ofrece un

entendimiento de su funcionamiento.
“Representa la esquematización gráfica de los procesos a seguir para alcanzar la solución

de un problema” (Cairó Battistutti, 2006).
La Tabla 42 muestra una descripción del comportamiento de los métodos que se crearon y
utilizaron en el servicio Web WCF.
Nombre Descripción
1) Diagrama de flujo de iniciar sesión Este proceso del servicio inicia y solicita dos datos que es usuario
y contraseña, una vez que se ingresen, el servicio valida que los
datos sean correctos, si son correctos el servicio responde con un
“true”(verdadera) que se interpreta como correcto y finaliza el
proceso, si son incorrectos responde con un “false” (se interpreta
como error) que se muestra en la Figura 39.
2)Diagrama de flujo obtener En este proceso se declara una variable de tipo lista la cual es la
proyectos responsable de almacenar temporalmente una lista de proyectos
activos, para lograr esto se declara una variable de tipo contexto
para poder realizar el mapeo de objetos de la entidad (Proyecto),
si la entidad no cuenta con objetos entonces se regresa la lista de
proyectos vacía, en caso contrario se valida que los objetos
95
cuenten con el atributo activo, si es así se agregan a la lista de
proyectos, si no regresa a la entidad para verificar si hay otro
objeto activo, este proceso termina cuando no existe ningún otro
objeto para recorrer en la entidad, finalmente se devuelve una
lista de proyectos con que comparten el atributo (Activo); se
observa en la Figura 40.
3)Diagrama de flujo obtener actores En este proceso se declara una variable de tipo lista la cual es la
responsable de almacenar temporalmente una lista de actores,
para lograr esto se declara una variable de tipo contexto para
poder realizar el mapeo de objetos de la entidad (Actores), si la
entidad no cuenta con objetos entonces se regresa la lista de
proyectos vacía, en caso contrario se agregan a la lista de actores,
este proceso termina cuando no existe ningún otro objeto para
recorrer en la entidad, finalmente se devuelve una lista de actores
como se muestra en la Figura 41.
4)Diagrama de flujo obtener empresas En este proceso se declara una variable de tipo lista la cual es la
responsable de almacenar temporalmente una lista de empresas,
poder realizar el mapeo de objetos de la entidad (Empresas), si la
entidad no cuenta con objetos entonces se regresa la lista de
empresas vacía, en caso contrario se agregan a la lista de
empresas, este proceso termina cuando no existe ningún otro
lista de empresas como se ve en la Figura 42.
5) Diagrama de flujo obtener En este proceso se declara una variable de tipo lista la cual es la
principales responsable de almacenar temporalmente una lista de principales,
poder realizar el mapeo de objetos de la entidad (Principales), si
la entidad no cuenta con objetos entonces se regresa la lista de
principales vacía, en caso contrario se agregan a la lista de
principales, este proceso termina cuando no existe ningún otro
96
lista de principales. Este proceso se observa en la Figura 43.
6)Diagrama de flujo guardar proyecto El presente proceso inicia con la declaración de 4 variables de
tipo lista la primera encargada de presentar las lista de
principales con el proceso obtener principales, la segunda
encargada de presentar la lista de actores con el proceso obtener
actores, la tercera encargada de presentar la lista de empresas con
el proceso obtener empresas, una vez así tiene por objeto guardar
un proyecto; solicita los siguientes datos(Categoría, prioridad,
principal, avance, fecha compromiso, nombre del proyecto,
principal, observaciones, rentabilidad, usuario, actores,
empresas), después de haber ingresado los datos antes
mencionados valida los datos, si los datos son incorrectos regresa
a iniciar, si los datos son correctos sigue con la recuperación de
los actores seleccionados de la lista, también las empresas
seleccionadas de la lista finalmente guarda el proyecto y
devuelve un “true”(guardado). Este se visualiza en la Figura 44.
7)Diagrama de flujo actualizar El proceso inicia con la solicitud de la clave del proyecto a
proyecto actualizar, si el proyecto no existe retorna un “false” (error), si
existe obtiene los siguientes datos del proyecto (Categoría,
prioridad, principal, avance, fecha compromiso, nombre del
proyecto, principal, observaciones, rentabilidad, usuario, actores,
empresas), estos con los datos guardados con anterioridad para
ser actualizados, una vez modificando los campos valida los
datos, si los datos son incorrectos regresa un “false” (error), si los
datos son correctos sigue con la recuperación de los actores
seleccionados de la lista, de esta misma forma recupera una lista
de empresas finalmente guarda el proyecto y devuelve un
“true”(actualizado). Dicho proceso se halla en la Figura 45.
8)Diagrama de flujo baja de proyecto Este proceso inicia con la solicitud de la clave del proyecto a dar
de baja, si el proyecto no existe regresa un “false” (error), si el
97
proyecto existe cambia su atributo activo a no activo
posteriormente devuelve un “true” (proyecto dado de baja).Se
puede observar en la Figura 46.
9)Diagrama de flujo guardar actividad El presente proceso inicia con la solicitud los siguientes datos
(clave del proyecto, nombre de la actividad, fecha de inicio, fecha
de término, comentario, estado), después de haber ingresado los
datos antes mencionados valida los datos, si los datos son
incorrectos devuelve un “false” (error) y regresa a iniciar, si los
datos son correctos agrega la actividad al proyecto por ultimo
devuelve un “true” (guardado). Mismo que se visualiza en la
Figura 47.
10)Diagrama de flujo actualizar El proceso inicia con la solicitud de la clave del proyecto, si el
actividad proyecto no existe retorna un “false” (error), si existe muestra la
lista de las actividades que le pertenecen después selecciona la
actividad y obtiene los datos(clave del proyecto, clave de la
actividad, nombre de la actividad, fecha de inicio, fecha de
término, comentario, estado) guardados anteriormente, una vez
modificando los campos valida los datos, si los datos son
incorrectos regresa un “false” (error), si los datos son correctos
finalmente actualiza la actividad del proyecto y devuelve un
“true”(actualizado). Se observa en la Figura 48.
11)Diagrama de flujo eliminar Este proceso inicia solicitando la clave de la actividad, si la

actividad actividad no existe devuelve “false” (error al eliminar), si existe
prosigue a la eliminación de la actividad al finalizar devuelve un
“true” (actividad eliminada).
Mismo que se visualiza en la Figura 49.
Tabla 42. Descripción de diagramas de flujo
98
Figura 39. Diagrama de flujo de iniciar sesión

99
Figura 40. Diagrama de flujo de servicio obtener proyectos

100
Figura 41. Diagramas de flujo de servicio obtener actores

101
Figura 42. Diagramas de flujo de servicio obtener empresas

102
Figura 43. Diagrama de flujo de servicio obtener principales

103
Figura 44. Diagrama de flujo de servicio guardar proyecto

104
Figura 45. Diagrama de flujo de servicio actualizar proyecto

105
Figura 46. Diagrama de flujo de servicio baja de proyecto

106
Figura 47. Diagrama de flujo de servicio guardar actividad

107
Figura 48. Diagrama de flujo de servicio actualizar actividad

108
Figura 49. Diagrama de flujo de servicio eliminar actividad

109
2.3. Estabilización
Consumir el Web Service WCF desde la aplicación en desarrollo, se logró agregando una referencia
de servicio a la aplicación en desarrollo como se muestra en la Figura 50.
En la Figura 51 se visualiza la ventana para agregar URL de la referencia de servicio para después
cargar los elementos que permitirán la conexión al servicio Web como se ve en Figura 52.
Al realizar una modificación en la base de datos, creando procedimientos almacenados, es
necesario actualizar el modelo en el servicio.
Figura 50. Captura de pantalla para agregar referencia de servicio

Figura 51. Captura de pantalla de la vista enlace al servicio publicado

110
Figura 52. Captura de pantalla de la vista referencia de servicio agregada al proyecto

2.4. Pruebas y corrección
Para hacer las pruebas al Web Service WCF se ingresa la URL del servicio en WCF Test Client.
Una vez que se ingresa la URL, el Test Client WCF (Cliente de prueba del Servicio Web WCF)
manda una petición al servidor en el que solicita todos los métodos que contiene como se visualiza
en la Figura 53, después para ver el comportamiento de los métodos agregados al Servicio Web
WCF es necesario seleccionarlo como se observa en la Figura 54.
Figura 53. Captura de pantalla del WCF Test Client

111
Figura 54. Captura de pantalla de la vista del WCF Test Client obteniendo los métodos
112
2.4.6. Casos de prueba
2.4.6.1. Prueba: registrar proyecto
El cliente de prueba WCF recibe en su interfaz todos los parámetros que el Servicio Web WCF
solicita para realizar esta prueba como se observa la Figura 55.
En las tablas (Tabla 43,
Tabla 44,Tabla 45,Tabla 46,Tabla 47,Tabla 48) se visualiza el comportamiento de caso de prueba
según su título.
Figura 55. Captura de pantalla del cliente de prueba WCF para registrar un proyecto
Una vez que se agregan los parámetros se realiza la operación, y el servidor responde con un “true”
cuando la operación se realizó correctamente y “false” cuando no se realiza la operación como se
observa en la Figura 56.
113
Figura 56. Captura de pantalla de respuesta a la solicitud del cliente registrar proyecto
NOMBRE CASO DE PRUEBA: Registrar proyecto

DESCRIPCIÓN: El usuario selecciona: prioridad, categoría, responsable,
partner, empresa, periodo, avance, principal y fecha.
También agrega el nombre del proyecto, la rentabilidad y
las observaciones, y la aplicación los envía al Web
Service, si los datos son correctos se agrega el proyecto.
PRECONDICIONES: Tener internet, ingresar como usuario legitimo al sistema.
DATOS DE ENTRADA: Nombre de la empresa: Nuevas Universidades
Prioridad: 1
Selecciona categoría: *
Responsable: ABELSD
Partner:AC, NP
Empresa: AYASA, KING
Rentabilidad:12
Avance: 100%
Observaciones: Ninguna
Principal: Aguafiel
Fecha:
RESULTADO ESPERADO: Mensaje de confirmación “Proyecto guardado”.
RESULTADO OBTENIDO: Mensaje “Proyecto guardado”.
Tabla 43. Comportamiento al registrar un proyecto
114
Figura 57. Prueba registrar proyecto

02/septiembre/2017
2.4.6.2. Prueba: actualizar proyecto
En la Figura 58 se muestran los datos que solicita el servicio Web para actualizar un proyecto; una
vez que fueron ingresados opcionalmente por el cliente manda un mensaje de respuesta como se
aprecia en la Figura 59.
115
Figura 58. Captura de pantalla de los parámetros que solicita el Servicio Web WCF para actualizar proyecto
Figura 59. Captura de pantalla de respuesta a la solicitud actualizar proyecto

Fuente: Captura de pantalla, con base en el IDE de Visual Studio 2015
NOMBRE CASO DE PRUEBA: Actualizar proyecto

DESCRIPCIÓN: El usuario edita selección: prioridad, categoría, responsable,
partner, empresa, periodo, avance, principal y fecha.
También puede editar el nombre del proyecto, la
rentabilidad y las observaciones, y la aplicación los envía al
Web Service, si los datos son correctos se agrega el
proyecto.
116
PRECONDICIONES: Tener internet, ingresar como usuario legitimo al sistema,
seleccionar un proyecto
DATOS DE CONSULTA Nombre de la empresa: Nuevas universidades
EDITAR: Prioridad: 1
Selecciona categoría: *
Responsable: ABELSD
Partner:AC, NP, RAM.
Empresa: AYASA, KING, MARPEX
Rentabilidad:12
Avance: 100%
Observaciones: NINGUNA
Principal: Aguafiel
Fecha:
RESULTADO ESPERADO: Mensaje de confirmación “Proyecto actualizado”.
RESULTADO OBTENIDO: Mensaje “Proyecto actualizado”.
Tabla 44. Comportamiento al actualizar un proyecto

Figura 60. Prueba actualizar proyecto

02/septiembre/2017
2.4.6.3. Prueba: baja de un proyecto
En la Figura 61 se aprecian los datos que solicita para dar de baja un proyecto en este caso se edita
el atributo “Es activo” de “true” cambia a “false” , después el cliente invoca el método y confirma
la solicitud como se ven la Figura 62.
117
Figura 61. Captura de pantalla del cliente de prueba WCF para dar de baja un proyecto
Figura 62. Captura de pantalla para invocar método y confirmar baja de proyecto
Fuente: Elaboración propia con base en el IDE de Visual Studio 2015
En la Figura 63 se visualiza la respuesta a la solicitud del cliente ante la baja de un proyecto, la

respuesta puede ser “true” o “false” , “true” representa éxito y “false” representa error en la
operación.
118
Figura 63. Captura de pantalla de la respuesta al cliente de prueba WCF a la solicitud a baja de proyecto
NOMBRE CASO DE PRUEBA: Baja proyecto

DESCRIPCIÓN: El usuario selección un proyecto y da clic en borrar.
PRECONDICIONES: Tener internet, ingresar como usuario legitimo al sistema.
DATOS DE ENTRADA: Nombre de la empresa:
Abcd proyecto sol
Seleccionar opción:
119
Baja de proyecto
Si la opción es baja de proyecto ingresar el motivo de la
baja.
RESULTADO ESPERADO: Cambiar el proyecto a modo no activo y mensaje de
confirmación de baja del proyecto.
RESULTADO OBTENIDO: Mensaje “El proyecto ahora es no activo, ya no aparecerá
en lista”.
Tabla 45. Comportamiento para dar de baja un proyecto
2.4.6.4. Prueba: registrar actividad

En la Figura 64 se observa que para registrar una actividad es necesario ingresar los datos que
muestra el servicio Web, cuando estos ya se han agregados se invoca el proceso y al igual que los
demás métodos envía mensaje de respuesta “true”(éxito) y “false” (error) que se puede apreciar
en la Figura 65.
Figura 64. Captura de pantalla de los parámetros agregados para registrar actividad a un proyecto
120
Figura 65. Captura de pantalla de respuesta del Servicio Web WCF para registrar actividad
NOMBRE CASO DE PRUEBA: Registrar actividad

DESCRIPCIÓN: El usuario ingresa: El nombre de la actividad, la fecha
de inicio y la de término un comentario finalmente
selecciona el estado de la actividad que puede ser.
PRECONDICIONES: Tener internet, ingresar como usuario legitimo al
sistema, seleccionar un proyecto.
DATOS DE ENTRADA: Nombre de la actividad: Cita urgente de liberación
Fecha de inicio: 12-02-17
Fecha de término: 13-02-17
Comentario: Listar los documentos importantes
Estado: Pendiente
RESULTADO ESPERADO: Mensaje de confirmación “Actividad guardada”.
RESULTADO OBTENIDO: Mensaje “Actividad guardada”.
Tabla 46. Comportamiento al registrar una actividad a un proyecto
121
Figura 66. Prueba registrar actividad

2.4.6.5. Prueba: actualizar actividad
Para actualizar una actividad primero se obtiene la información de un proyecto para ver las
actividades que le pertenecen como se ve en la Figura 67.
Figura 67. Captura de pantalla de la consulta de un proyecto por el cliente de prueba WCF
122
En la Figura 68 se observa que el cliente confirma la solicitud para actualizar la actividad y
posteriormente el servicio Web envía la respuesta a la petición del cliente como se ve en la Figura
69.
Figura 68. Captura de pantalla para confirmar llamada de método actualizar actividad
Figura 69. Captura de pantalla de la respuesta mostrada en la interfaz de cliente de prueba WCF
123
NOMBRE CASO DE PRUEBA: Actualizar actividad

DESCRIPCIÓN: El usuario puede editar: El nombre de la actividad, la
fecha de inicio y la de término un comentario
finalmente selecciona el estado de la actividad que
puede ser.
sistema, seleccionar una actividad.
DATOS DE CONSULTA Seleccionar actividad de un proyecto: Cita urgente
de liberación.
DATOS DE ENTRADA: Nombre de la actividad: Cita urgente de liberación.

Fecha de inicio: 12-02-17
Fecha de término: 13-02-17
Comentario: Listar los documentos importantes.
Estado: Terminado.
RESULTADO ESPERADO: Mensaje de confirmación de actividad actualizada.

RESULTADO OBTENIDO: Mensaje “Actividad actualizada”.
Tabla 47. Comportamiento al actualizar una actividad de un proyecto

Figura 70. Prueba actualizar actividad

124
2.4.6.6. Prueba: cancelar operación
NOMBRE CASO DE PRUEBA: Cancelar operación

DESCRIPCIÓN: Cancelar una operación sin perder la información que
se esté manejando.
sistema, seleccionar un proyecto.
DATOS DE ENTRADA: Seleccionar botón cancelar.
RESULTADO ESPERADO: Mensaje de operación cancelada.
RESULTADO OBTENIDO: Mensaje de operación cancelada sin perder
información.
Tabla 48. Comportamiento al cancelar una operación
Figura 71. Prueba cancelar operación

2.4.7. Escenarios de pruebas
Escenarios Dispositivos Nombre Descripción Versión de

Android
Físicos HTC Desire RAM: 1GB 5.1
Smartphone 626s Procesador Snapdragon 210
Pantalla 720 x 1280 pixeles
Tablet Lenovo Tab 3 850F 5.1

RAM: 1GB
Pantalla HD de 8 pulgadas
125
Virtuales SA Emulador Emulador Realiza una imitación de un 4.4, 4.5,
dispositivo físico pero en la 5.0 y más
computadora.
Tabla 49. Tabla de dispositivos donde se ejecutó la aplicación móvil
2.4.8. Matriz de pruebas de ejecución de la aplicación
Se refiere a la técnica para recoger información bi-direccional por ejemplo, en las columnas se
representan los casos de pruebas y en las filas los distintos requisitos
ACOTACIÓN
R Requerimiento
T1 Prueba registrar proyecto
T2 Prueba actualizar proyecto
T3 Prueba eliminar proyecto
T4 Prueba registrar actividad
T5 Prueba actualizar actividad
T6 Prueba eliminar actividad
T7 Prueba cancelar operación
La Tabla 50 representa los requerimientos que han sido comprobados cada uno con una prueba o
también llamado “test”.
T1 T2 T3 T4 T5 T6 T7
R-Conexión a internet
R-Iniciar sesión
R-Registrar proyecto
R-Actualizar proyecto
R-Eliminar proyecto
R-Registrar actividad
R-Actualizar actividad
R-Eliminar actividad
Tabla 50. Matriz de pruebas de ejecución
126
2.4.9. Velocidad de ejecución de la aplicación
En función a velocidad del internet la aplicación se ejecutará en mayor tiempo si la velocidad es
menos de 1 Mbps o menor tiempo si rebasa los 5 Mbps como se observa en la Tabla 51.
Velocidad Mbps en Tiempo de ejecución

Internet Segundos
Menos de 1 5 o más segundos
De 1 a 2 3 segundos
De 3 a 5 2 segundos
De 5 en adelante 1 segundo
Tabla 51. Tiempo de ejecución de la aplicación por Mbps
En la Figura 72 se observa una prueba realizada con “speedtest” en la que se presenta la velocidad
en Mbps (Mega bits por segundo) y la velocidad de carga en Mbps.
Figura 72. Prueba de velocidad de internet

Fuente: Elaboración propia, con base en http://www.speedtest.net/es, 5/octubre/2017
127
RESULTADOS
128
La correcta implementación de procedimientos almacenados y el uso de Entity Framework permite
que el Servicio Web WCF rescate los datos sin tener la necesidad de escribir en código la conexión
a la base de datos cada vez que se requiera hacer una operación, lo que proporciona seguridad.
El Servicio Web WCF utiliza el modelo de la base de datos proporcionado por Entity Framework,
en cada método creado se solicitan los procedimientos almacenados que le corresponden; al
respecto, solicitando solo la información de cada dato, esta confirma que los datos solicitados no
se encuentren vacíos, si es así se envía un mensaje de error a la aplicación y si no la petición de la
aplicación se cumplirá. Para ver el comportamiento del Servicio Web WCF está al alcance el cliente
de prueba WCF, que podrá hacer una conexión al Servicio Web WCF con solo ingresar la URL del
Servicio Web.
Con la automatización de los procesos el usuario puede ingresar a la aplicación móvil de forma
remota aun si el usuario está viajando o en una reunión corporativa, sin tener que utilizar hojas
adicionales, teniendo en cuenta que todo es realizado y guardado gracias a la aplicación móvil
creada.
Los procesos automatizados en la aplicación pueden verse en la Tabla 52 y la secuencia como se
muestra en la Figura 73.
Automatizados
Procesos SI NO
Registrar un proyecto 
Actualizar un proyecto 
Baja de un proyecto 
Registrar actividad a un proyecto 
Actualizar actividad de un proyecto 
Eliminar actividad de un proyecto 
Tabla 52. Resumen de procesos automatizados
129
En la Figura 73 el usuario puede iniciar sesión, así mismo cerrar la aplicación, ingresar al menú de
inicio y manipular los módulos proyecto o actividades que le permiten agregar, actualizar,
consultar o eliminar información.
Figura 73. Navegación final de la aplicación

Fuente: Elaboración propia, con base en https://app.emaze.com/mypresentations#/my, 1/septiembre/2017
Es importante destacar el uso del IDE de Visual Studio 2015 en conjunto con Xamarin permitieron
la correcta automatización de las actividades que se llevan a cabo en la agencia CPM Medios. La
programación de pequeños ciclos de desarrollo rápidos que sugiere la metodología Mobile-D
permitió la validación o corrección por parte del usuario final de la aplicación móvil, además de
generar un mayor número de pruebas, permitiendo así lograr funcionalidad planeada por semanas
y poder avanzar en nuevas implementaciones.
130
CONCLUSIONES
La implementación de la aplicación móvil permitió la automatización de los procesos sobre los

módulos “proyectos y actividades” en el Departamento de Sistemas de CPM Medios, la cual
agilizará el control de actividades para cada proyecto; asimismo, el usuario podrá conectarse desde
cualquier sitio considerando que tenga conexión vía internet, generando ahorro en tiempo y gastos
en papelería.
Las pruebas realizadas en la última fase del desarrollo, permiten el envío de mensajes que dan
como resultado el estado de la operación, que puede ser exitoso o incorrecto.
La implementación del Web Service WCF, reduce la carga de código en la aplicación móvil y
brinda seguridad a la base de datos por autenticación; desde la aplicación, funciona como
intermediario entre la base de datos y la aplicación, es decir, quien se encarga de responder a las
peticiones de la aplicación móvil es el servidor.
Con la adaptación de la metodología Mobile-D se permitió un desarrollo a mayor velocidad y en

menor tiempo, por las entregas que se hacían en semanas y al mismo tiempo pruebas de
funcionalidad y por la orientación a desarrollo de aplicaciones móviles.
No se asegura que el diseño de la aplicación en un dispositivo iOS funcione correctamente debido

a que no se realizaron pruebas en dicho dispositivo por no contar con la licencia de desarrollo para
el despliegue (instalación), se sabe que por la tecnología de Xamarin el despliegue en iOS sería
factible.
Al cumplirse el análisis de los procesos que se llevan a cabo en la administración de proyectos, la

automatización de procedimientos almacenados, la implementación del Servicio Web WCF y el
uso de Xamarin como IDE de desarrollo, se obtiene como resultado una aplicación móvil que
permite agilizar la administración de los proyectos, así como sus actividades en tiempo real y el
ahorro de recurso humano y material.
131
RECOMENDACIONES
Para mejorar la experiencia de usuario es recomendable hacer una consulta mediante filtros por
responsable y partner de un proyecto, lo que reducirá en tiempo la carga de los proyectos activos,
también consumirá menos datos para localizar un proyecto o para hacer la operación requerida por
el usuario ya sea registrar, modificar, eliminar o consultar actividades.
Vista actual Vista de mejora Descripción

Al ingresar el nombre del
usuario, el teclado se
despliega encima del
control de la contraseña
lo provoca que se tenga
Iniciar
que minimizar para poder
sesión ingresar la contraseña.
Filtros de búsqueda: Al hacer la consulta se

obtienen todos los
1) Por Actor proyectos de la base de
Consulta 2) Por Tipo de actor datos, lo que genera más
de 3) Por nombre del consumo de datos.
proyectos proyecto
Para poder visualizar el

No hay proyecto se tiene que
acceder a editar.
Detalle de
proyecto
Tabla 53. Tabla de recomendaciones

132
Si se desea integrar una nueva funcionalidad a la aplicación móvil es necesario recompilar la
aplicación móvil, así como hacer una revisión a la integridad de los datos que se encuentran en la
base de datos y verificar que exista compatibilidad en caso de que se integre una nueva tecnología.
Para la implementación de la aplicación móvil en iOS se deberán configurar las propiedades de
los controles de las interfaces debido a que el diseño de la interfaz en Android es diferente.
133
GLOSARIO
Android: Sistema operativo móvil de código abierto (Niño Camazon, 2011).
ASP.NET: IDE de desarrollo de Microsoft®, modelo de desarrollo Web unificado que incluye
elementos necesarios para crear aplicaciones Web (Ceballos Sierra, 2013).
CSS (Cascading Style Sheet): Hojas de estilo en cascada, su finalidad es definir cómo se han de
mostrar los elementos HTML y con qué estilo se han de presentar (Egea García, 2007).
HTTP: Protocolo de Transferencia de Hipertexto, lenguaje que utilizan los servidores y los clientes
Web para comunicarse entre ellos, soportando la recuperación y presentación de texto, gráficos,
animaciones y la reproducción de sonido (Desongles Corrales Juan, Balongo Montiel , & Ochoa
Guerra (2002).
IDE (Integrated Development Environment): Entorno de desarrollo integrado, conjunto de

herramientas para crear Software, desde la fase de diseño pasando por las fases de diseño de la
interfaz de usuario, codificación, pruebas, depuración, análisis de la calidad y el rendimiento del
código (Microsoft®, 2017).
iOS: Sistema operático móvil creado por Apple para dispositivos móviles (Bellido Quintero,
2013).
.NET Framework: Es un entorno de ejecución runtime que administra aplicaciones cuyo destino
es .NET Framework. Incorpora Common Language Runtime, que proporciona la administración
de la memoria y otros servicios del sistema, y una biblioteca de clases completa, que permite a los
programadores aprovechar el código estable y fiable de todas las áreas principales del desarrollo
de aplicaciones (Microsoft®, 2017).
Partner: En español socio (M. Kaplan, 2014).
SDK: Kid de desarrollo de Software de .NET Framework que cuenta con las herramientas para
escribir, construir, probar e implementar aplicaciones (Ramírez , 2005).
134
Tablet: Es un dispositivo electrónico que tiene un tamaño intermedio entre el ordenador y el móvil;
un ordenador con el que se puede interactuar a través de una pantalla táctil, sin necesidad de usar
un teclado físico y un ratón (Andrés Cabrerizo, 2015).
WCF (Windows Comunication Fundation): es un marco de trabajo para la creación de

aplicaciones orientadas a servicios (Microsoft®, 2016).
Web Service: Son componentes que se ejecutan en el servidor y muestran una interfaz a través de
la cual otras aplicaciones acceden a los servicios ofrecidos (Ceballos Sierra, 2013).
XML( Extensible Markup Languaje): Es un metalenguaje, es decir, un lenguaje para definir

lenguajes de marcado, se usa para representar el significado de los datos (Ramos Salavert &
Lozano Pérez , 2000).
Xaml(eXtensible Application Markup Language): Es un lenguaje de marcado de aplicaciones

extensible, es decir, un lenguaje declarativo; utilizado para definir la estructura jerárquica de la
interfaz de usuario (Ceballos Sierra, 2012).
135
REFERENCIAS
Andrés Cabrerizo, D. M. (2015). Cultura científica. España: Editex.
Bellido Quintero, E. (2013). Instalación y actualización de sistemas operativos. IFCT0309. Málaga: ic

editorial.
Cairó Battistutti, O. (2006). Fundamentos de programación. Piensa en C. México: PEARSON EDUCACIÓN.
Ceballos Sierra, F. J. (2012). Visual Basic™: Interfaces gráficas y aplicaciones para Internet con WPF, WCF
y Silverlight . España: RA-MA.
Ceballos Sierra, F. J. (2013). Enciclopedia de Microsoft® Visual Basic™: Interfaces gráficas y aplicaciones
para Internet con Windows Forms y ASP.NET 3.ª edición. España: RA-MA.
Ceballos Villach, J., Gañán Jiménez, D., Conesa Caralt, J., & Rius Gavidia, À. (2010). Introducción a .NET.
Barcelona: EDITORIAL UOC.
Cobo Yera, A. (2007). Diseño y programación de base de datos. España: Vision Libros.
CONACYT. (26 de Noviembre de 2015). Agencia Informativa del Consejo Nacional de Ciencia y
Tecnología. Obtenido de Agencia Informativa del Consejo Nacional de Ciencia y Tecnología:
http://conacytprensa.mx/index.php/centros-conacyt/3943-uso-de-apps-en-mexico-
oportunidad-para-pymes-estudio-nota
Cuello, J., & Vittone, J. (2013). Diseñando apps para móviles. Argentina: Sin Ed.
Desongles Corrales Juan, Balongo Montiel , M., & Ochoa Guerra, O. (2002). Informática para las
opciones a la comunidad autónoma de las Illes Balears . España: MAD.
E. Kendall, K., & E. Kendall, J. (2005). Análisis y diseño de sistemas. México: PEARSON EDUCACIÓN.
Egea García, C. (2007). Diseño web para todos I accesibilidad al contenido en la web. Barcelona: Icaria.
Fowler, M., & Scott, K. (1999). UML gota a gota. México: Addison Wesley Logman.
Guérin, B. A. (11 de Diciembre de 2013). Diseño y desarrollo de aplicaciones Web. Barcelona: Ediciones
ENI.
Hermes, D. (2015). Xamarin Mobile Application Development Cross-platform C# and Xamarin.Forms

Fundamentals. Sin Cd.: APRESS.
López Rodríguez, J. (16 de Agosto de 2016). Organigrama. (M. Cirilo Mejia, Entrevistador)
M. Kaplan, S. (2014). Essential English/Spanish and Spanish/English legal dictionary. Alphen aan den Rijn:
Wolters Kluwer Law & Business.
Microsoft®. (Mayo de 2016). Developer Network. Obtenido de Developer Network:

https://msdn.microsoft.com/es-MX/library/ms731079(v=vs.110).aspx
136
Microsoft®. (2017). Developer Network. Obtenido de Developer Network:
https://msdn.microsoft.com/es-es/library/ms190782.aspx
Microsoft®. (28 de marzo de 2017). Developer Network. Obtenido de Developer Network:

https://msdn.microsoft.com/es-MX/library/dn771552.aspx
Microsoft®. (1 de Noviembre de 2017). Microsoft Developer Network. Obtenido de Microsoft Developer

Network: https://msdn.microsoft.com/es-MX/library/bb399572(v=vs.100).aspx
Microsoft®. (17 de octubre de 2017). Microsoft®. Obtenido de Microsoft®:

https://docs.microsoft.com/es-mx/dotnet/framework/get-started/
Microsoft®. (23 de agosto de 2017). Microsotf® Developer Network. Obtenido de Microsotf® Developer
Network: https://msdn.microsoft.com/es-mx/library/dn762121.aspx
Mobile Marketing Association. (2011). Libro blanco de apps. España: Sin Ed. Obtenido de
http://www.mmaspain.com/wp-content/uploads/2015/09/Libro-Blanco-Apps.pdf
Niño Camazon, J. (2011). Sistemas operativos monopuestos. España: Editex.
Patel, C. (2017). Developing-Service Applications Using the Windows Comunication Fundation (WCF)
Framework. USA: IGI Global.
Piñeiro Gómez, J. (2013). Bases de datos relacionales y modelos de datos . España: Paraninfo.
Prescott, P. (s.f.). La programación Java Script.
Ramírez , J. F. (2005). Aprenda Practicando Visual Basic 2005 usando Visual Studio 2005. México:
PEARSON EDUCACIÓN.
Ramos Salavert, I., & Lozano Pérez , M. D. (2000). Ingeniería del software y bases de datos, tendencias
actuales. España: Ediciones de la Universidad de Castilla-La Mancha.
Rumbaugh, J., & Jacobson, I. (2000). El lenguaje unificado de modelado. Madrid: PEARSON EDUCACION.
Valtion Teknillinen Tutkimuskeskus. (2006). Agile software technologies research programme. Obtenido
de Agile software technologies research programme: http://agile.vtt.fi/projects.html
Xamarin. (12 de enero de 2017). Xamarin. Obtenido de Xamarin: https://developer.xamarin.com/es-

es/guides/android/deployment,_testing,_and_metrics/debug-on-emulator/visual-studio-
android-emulator/
Zorrilla Castro, U., de la Torre Llorente, C., Hernandez Saa, Y., & Peláez Aller, P. (2011). ADO.NET Entity
Framework 4.1-Aplicaciones y servicios centrados en datos. krasis PRESS.

Trabajo Final Sol

Cargado por

Copyright:

Formatos disponibles

Trabajo Final Sol

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Trabajo Final Sol

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MEXIQUENSE DEL BICENTENARIO

UNIDAD DE ESTUDIOS SUPERIORES

DESARROLLO DE UNA APLICACIÓN MÓVIL iOS Y

QUE PARA OBTENER EL TÍTULO PROFESIONAL DE:

DESARROLLO DE UNA APLICACIÓN MÓVIL iOS Y

QUE PARA OBTENER EL TÍTULO PROFESIONAL DE:

A mi hermana Alejandra Anastacio Gabina por demostrarme su amistad, me siento afortunada de

RESUMEN ................................................................................................................................ XIV

1.5.3. Procedimientos almacenados ........................................................................................ 36

2.1.4. Requerimientos de datos ............................................................................................... 57

2.4.6.4. Prueba: registrar actividad .................................................................................. 117

Tabla 1. Descripción de los elementos de la aplicación Blank Xaml App .................................... 30

Tabla 42. Descripción de diagramas de flujo................................................................................ 96

Figura 1. Organigrama de la empresa ........................................................................................... 18

Figura 41. Diagramas de flujo de servicio obtener actores ........................................................... 99

En este documento se da a conocer el desarrollo de una aplicación móvil para la administración de

Finalmente se presentan conclusiones y recomendaciones para mejorar el diseño de presentación

El desarrollo de la aplicación móvil permitirá el uso responsivo en un dispositivo móvil mejorando

 Analizar los procesos que se llevan a cabo en administración de proyectos.

Nombre: CPM Medios S.A. de C.V.

Tel. (55)2591-0256, www.cpmmedios.com

Figura 1. Organigrama de la empresa

Departamento: Área de sistemas

Asesor Externo: Jefe del área de sistemas

PLANTEAMIENTO DEL PROBLEMA

Por lo anterior expuesto, surge la siguiente pregunta:

 Si no es usuario asignado no podrá utilizar la aplicación.

CAPÍTULO I. MARCO TEÓRICO

1.1. Aplicación móvil

 Funcionamiento de la aplicación en “Web” móvil, también conocidas como: aplicaciones

1.1.2.2. Con base a su funcionalidad

 Comunicaciones: Clientes de redes sociales (ejemplo: Facebook, Twitter), mensajería

 Multimedia: visores de gráficos de imágenes, visores de presentaciones, reproductores de

 Productividad: calendarios, calculadoras, diarios, notas, hojas de cálculo, servicios de

 Viajes: Guías de ciudadanos (ejemplo: Lonely planet), convertidores de moneda, traductores,

 Utilidades: Gestores de perfiles de usuario, libretas de direcciones, gestor de procesos,

 Compras: Lectores de código de barras y bases de datos de productos, clientes de tiendas

 Entretenimiento: Lectores de libros, horóscopos, guías de programación de televisión,

 Bienestar: Seguimiento de dietas, primeros auxilios, consejos y entretenimiento personal.

1.1.2.3. Según su desarrollo

 Se actualizan frecuentemente (el usuario debe volver a descargarlas) para obtener la

 Su interfaz es más genérica e independiente de la apariencia del sistema operativo, la

1.2. Software para desarrollo de aplicaciones móviles

1.3. Xamarin y Visual Studio

¿Qué es Visual Studio? Es un conjunto completo de herramientas de desarrollo para la generación

Características de Xamarin según Hermes (2015) son:

A continuación, en la Figura 2 se muestra la arquitectura de la aplicación cross-platform con

Figura 2. Arquitectura de aplicación cross-platform

1.3.1. Desarrollo de aplicaciones móviles en Xamarin y Visual Studio

En la vista de desarrollo en Visual Studio se encuentra Android, iOS y cross-platform.

Figura 3. Captura de pantalla de la vista de desarrollo de una aplicación Android

Figura 4. Captura de pantalla de la vista de componentes de una aplicación Android

Figura 5. Captura de pantalla de la vista de desarrollo de aplicación iOS

Figura 6. Captura de pantalla de la vista de componentes de una aplicación iOS

Figura 7. Captura de pantalla de la vista de desarrollo de aplicación cross-platform

1.3.2. Estructura de una aplicación Black Xaml App (Xamarin.Forms Portable) en

Figura 8. Captura de pantalla de los componentes de aplicación Blank Xaml App

En la Figura 9 se ven los 4 elementos de la aplicación que se describen en la Tabla 1.

Figura 9. Captura de pantallas de los elementos de la aplicación Blank Xaml

Numeración Nombre Descripción