Seminario de Tesis

UNIVERSIDAD NACIONAL TECNOLÓGICA DE LIMA SUR
FACULTAD DE INGENIERÍA Y GESTIÓN
CARRERA PROFESIONAL DE INGENIERÍA DE SISTEMAS
IMPLEMENTACIÓN DE UN APLICATIVO MÓVIL PARA AUTOMATIZAR LA

ELABORACIÓN DE EVIDENCIAS DE LOS SERVICIOS PRESTADOS POR EL
ÁREA DE TELECOMUNICACIONES EN LA EMPRESA DELTA ELECTRONICS
PRESENTADO POR EL BACHILLER:
AYMA FLORES JHENSSON FRANK
PARA OPTAR EL TÍTULO DE INGENIERO DE SISTEMAS
Villa El Salvador
-2018-
DEDICATORIA
A mis padres, Walter y Beatriz, por su apoyo

incondicional e instruirme que siempre debo
perseguir mis sueños; cualquiera de mis logros es
gracias a ellos.
A mi hermano Walter por siempre apoyarme

moral y económicamente, impulsándome a seguir
creciendo como persona y profesional.
AGRADECIMIENTOS
- A mi hermano Walter por la ayuda económica e impulsarme a seguir creciendo

cada día como persona y como profesional.
- A mis padres por su apoyo incondicional e instruirme que siempre debo perseguir
mis sueños.
- A mis tíos Walter y Ricardo que fueron fundamentales en mis estudios primarios.
- A mi tío Willy que ha sido una pieza fundamental en mis estudios secundarios.
- Agradezco a los docentes Zapillado Huanco Oscar Adrian, Frank Edmundo

Escobedo Bailón, Diaz Leyva Teodoro Neri, Rubén Tacza Valverde y Arqque
Pantigozo Antonio que además de ser excelentes profesores, también han sido
aquellas personas fundamentales que me han inspirado y transmitido un gran
aprecio a mi carrera universitaria.
ÍNDICE
INTRODUCCIÓN ........................................................................................... 7
1. CAPÍTULO I PLANTEAMIENTO DEL PROBLEMA ............................ 9
1.1 Descripción de la Realidad Problemática. .......................................... 9

1.2 Justificación de la Investigación........................................................ 10
1.3 Delimitación de la Investigación........................................................ 11
1.3.1 Espacial..................................................................................... 11
1.3.2 Temporal ................................................................................... 11
1.3.3 Conceptual................................................................................ 12
1.4 Formulación del Problema ................................................................ 12
1.4.1 Problema General .................................................................... 12
1.4.2 Problemas Específicos. ........................................................... 12
1.5 Objetivos ........................................................................................... 13
1.5.1 Objetivo General ...................................................................... 13
1.5.2 Objetivos Específicos .............................................................. 13
1.6 Hipótesis ........................................................................................... 14
1.6.1 Hipótesis General ..................................................................... 14
1.6.2 Hipótesis Específicas .............................................................. 14
2. CAPÍTULO II MARCO TEÓRICO ....................................................... 15
2.1 Antecedentes .................................................................................... 15

2.2 Aplicación móvil ................................................................................ 25
2.2.1 Origen de las aplicaciones móviles ........................................ 25
2.2.2 Clasificación de las aplicaciones ........................................... 26
2.2.3 Distribución .............................................................................. 28
2.3 Automatización ................................................................................. 31
2.3.1 Tipos de automatización ......................................................... 31
2.3.2 Objetivos de la automatización ............................................... 33
2.3.3 Justificación de la automatización ......................................... 33
2.3.4 Obsolescencia .......................................................................... 34
2.4 Marco Conceptual............................................................................. 35
v
3. CAPÍTULO III DESARROLLO DE LA METODOLOGÍA ..................... 40
3.1 Sprint 1 ............................................................................................. 41

3.1.1 Fase de inicio ........................................................................... 41
I) Creando la visión del proyecto ...................................................... 41
3.1.2 Fase de planificación ............................................................... 50
3.1.3 Fase de implementación.......................................................... 62
3.1.4 Fase de revisión y retrospectiva ............................................. 69
3.2 Sprint 2 ............................................................................................. 76
3.2.1 Fase de inicio ........................................................................... 76
I) Creando la visión del proyecto ...................................................... 76
3.2.2 Fase de planificación ............................................................... 85
3.2.3 Fase de implementación.......................................................... 96
3.2.4 Fase de revisión y retrospectiva ........................................... 107
vi
INTRODUCCIÓN
En la actualidad las grandes empresas están obligadas a automatizar sus

procesos haciendo uso de la tecnología debido a muchas razones, entre ellas
ahorrar costos, reducir tiempos y mejorar la calidad del producto o servicio.
No solo las grandes empresas están obligadas a automatizar sus procesos,

si no que la gran mayoría de empresas pequeñas y medianas también deben
hacerlo si quieren tener alguna oportunidad de competir en el mercado. Esto
debido a que el mundo actual es mucho más exigente que el de antes en precios,
tiempo y calidad.
Siendo conscientes de esta gran necesidad mi equipo y yo nos hemos

propuesto a implementar un sistema capaz de automatizar los procesos de
elaboración de evidencias de los servicios prestados por el área de
telecomunicaciones en la empresa Delta Electronics
La empresa mencionada se encarga de brindar suministros, servicios de

instalación y supervisión a las principales empresas del rubro de
Telecomunicaciones, pero tiene problemas de tiempo al momento de evidenciar
sus servicios prestados debido a que estos procesos lo realizan de forma
manual, invirtiendo mucho tiempo al usar solo la herramienta Excel para la
creación de sus reportes, generando numerosos retrasos al momento de la
entrega de estos.
Es por ello que la presente tesis busca implementar un aplicativo móvil para
automatizar la elaboración de evidencias de los servicios prestados por el área
de telecomunicaciones en la empresa Delta Electronics
La estructura del trabajo está compuesta por 2 capítulos principales. El

primer capítulo se destaca por el planteamiento del problema que se vive en la
empresa Delta Electronics por no tener automatizado el proceso de elaboración
de evidencias de los servicios prestados por el área de telecomunicaciones; en
7
el segundo, se establecerá las bases teóricas sobre la automatización y el
aplicativo móvil.
La conclusión del proyecto dará muestra de resultados a los que se llegó

posterior a la implementación, ya en las recomendaciones tendremos consejos
que serán de utilidad para futuros proyectos en relación a la investigación y
buenas prácticas.
8
1. CAPÍTULO I
PLANTEAMIENTO DEL PROBLEMA
1.1 Descripción de la Realidad Problemática.
En el mundo moderno automatizar los procesos se ha vuelto una

herramienta indispensable para ser competentes como empresa. Hoy en
día el mercado es muy competitivo, son cada vez muchas más
organizaciones las que optan por automatizar procesos, con el fin de ser
mucho más rentables y eficaces.
La empresa Delta Electronics es una empresa ubicada en la Calle

Hipólito Unanue 460 - Distrito Comas, en el departamento de Lima, Perú y
se encarga de brindar suministros, servicios de instalación y supervisión a
las principales empresas del rubro de Telecomunicaciones.
Para el desarrollo de sus servicios es necesario realizar el proceso de

la elaboración de evidencias como prueba de que el trabajo se realizó
correctamente, pero últimamente ha tenido problemas de tiempo al
momento de evidenciar sus servicios prestados debido a que estos
procesos realizados de forma manual, invierten mucho tiempo al usar
solamente la herramienta Excel para la elaboración de sus reportes,
generando gran cantidad retrasos al momento de la entrega de estos.
Es por ello que la presente tesis busca implementar un aplicativo móvil

para automatizar la elaboración de evidencias de los servicios prestados
por el área de telecomunicaciones en la empresa Delta Electronics
9
1.2 Justificación de la Investigación
Delta Electronics es una empresa que brinda suministros, servicios de

instalación y supervisión a las principales empresas del rubro de
Telecomunicaciones.
La empresa siempre ha llevado sus servicios a diferentes partes del

país, siendo contratada por empresas más grandes y al finalizar sus
servicios deben generar un reporte o evidencias de su trabajo terminado.
La empresa distribuye las labores de la siguiente manera: instalador,

supervisor de campo, revisor y coordinador.
El flujo de trabajo para que un reporte se diga “finalizado” empieza

cuando el coordinador asigna al instalador la labor de realizar una
instalación en alguna parte del país. El coordinador le brinda la información
necesaria para que el instalador pueda realizar su trabajo. El instalador
utiliza la herramienta Excel para poder colocar la información correspondida
de su trabajo y como evidencia toma fotos con el celular que la empresa
ofrece a cada uno de los trabajadores. En este reporte se especifica puntos
claves como la ubicación en la que se encuentra laborando el instalador, el
nombre del proyecto, la fecha en la que se tomó la foto y una descripción
de la foto; toda esta información debe estar escrita en letras pequeñas en
la parte inferior derecha de las fotos, provocando que los instaladores
tomen más tiempo en editar la foto, y aparte de ello deben colocar cada foto
en una posición especificada en el formato establecido por la empresa.
Cuando el instalador haya terminado su reporte, éste será enviado al

revisor, quién es el encargado de verificar si el instalador realizó
correctamente su reporte; en caso de que el instalador no haya cometido
errores, el reporte se dará por finalizado, pero en caso de que el instalador
haya cometido algún error ya sea por no haber tomado una foto
fundamental para el reporte o por temas de imágenes borrosas, éste será
enviado al supervisor de campo quién es el encargado de mejorar el reporte
hasta todos los requisitos necesarios establecidos por la empresa.
10
Cuando el supervisor de campo haya terminado con la mejoría del
reporte, éste será enviado al coordinador que al igual que el revisor puede
finalizar un reporte.
Se debe tomar en cuenta que la mayor parte de la realización del

reporte queda en manos del instalador, el cual invierte demasiado tiempo
en una tarea que en la actualidad puede ser realizado por un software
automatizado.
Por lo tanto, para que la empresa Delta Electronics siga mejorando,

se requiere automatizar la elaboración de esas evidencias haciendo uso de
un aplicativo móvil.
1.3 Delimitación de la Investigación
1.3.1 Espacial
Se realizará en la empresa Delta Electronics ubicada en la Av.

Brasil 2011, distrito de Jesús María, departamento de Lima - Perú.
1.3.2 Temporal
Inicio: Agosto de 2018.
Fin: Diciembre de 2018.
11
1.3.3 Conceptual
Aplicación móvil. Es una aplicación de software que se instala

en teléfonos móviles o tablets para favorecer al usuario en una
actividad concreta, ya sea de carácter profesional, de ocio o de
entretenimiento, a diferencia de una aplicación web, el aplicativo móvil
no es instalable. El objetivo de un aplicativo móvil es facilitarnos la
consecución de una tarea determinada o ayudarnos en operaciones
y gestiones del día a día. (Qode, 2012)
Automatización. La palabra automatización engloba un

amplio abanico de sistemas y procesos en los cuales se requiere la
mínima intervención del ser humano, además debe de ser un
sistema “flexible” el cual se debe ajustar de distintas maneras a los
posibles cambios en momentos puntuales. (Martínez, 2017).
1.4 Formulación del Problema
1.4.1 Problema General
¿De qué manera la implementación de un aplicativo móvil

permite automatizar la elaboración de evidencias de los
servicios prestados por el área de telecomunicaciones en la
empresa Delta Electronics?
1.4.2 Problemas Específicos.
- ¿De qué manera la implementación de un aplicativo móvil

permite reducir el tiempo en el proceso de elaboración de
evidencias de los servicios prestados por el área de
telecomunicaciones en la empresa Delta Electronics?
12
permite ahorrar costos en el proceso de elaboración
evidencias de los servicios prestados por el área de
telecomunicaciones en la empresa Delta Electronics?

permite mejorar el nivel de calidad en las evidencias de los
empresa Delta Electronics?
1.5 Objetivos
1.5.1 Objetivo General
Implementar un aplicativo móvil para automatizar la

elaboración de evidencias de los servicios prestados por el
área de telecomunicaciones en la empresa Delta Electronics
1.5.2 Objetivos Específicos
- Implementar un aplicativo móvil para reducir el tiempo en el

proceso de elaboración de evidencias de los servicios
prestados por el área de telecomunicaciones en la empresa
Delta Electronics
- Implementar un aplicativo móvil para ahorrar costos en el

proceso de elaboración de evidencias de los servicios
Delta Electronics
- Implementar un aplicativo móvil para mejorar el nivel de

calidad de las evidencias de los servicios prestados por el
área de telecomunicaciones en la empresa Delta
Electronics
13
1.6 Hipótesis
1.6.1 Hipótesis General
Si se Implementa un aplicativo móvil se podrá

automatizar la elaboración de evidencias de los servicios
Delta Electronics
1.6.2 Hipótesis Específicas
- Si se implementa un aplicativo móvil se podrá reducir el

tiempo en el proceso de elaboración de evidencias de los
empresa Delta Electronics
- Si se implementa un aplicativo móvil se podrá ahorrar

costos en el proceso de elaboración de evidencias de los
empresa Delta Electronics
- Si se implementa un aplicativo móvil se podrá mejorar el

nivel de calidad de las evidencias de los servicios prestados
por el área de telecomunicaciones en la empresa Delta
Electronics
14
2. CAPÍTULO II
MARCO TEÓRICO
2.1 Antecedentes
A nivel nacional e internacional se han realizado diferentes trabajos

de investigación que de alguna manera se relacionan con los temas
abordados en la presente tesis.
“SISTEMA AUTOMATIZADO PARA LA GESTIÓN DEL PROGRAMA

DE CONTROL SANITARIO INTERNACIONAL DE CUBA”, presentado por
el Ing. Miguel Ángel Fernández Marín, la Ing. Débora González Tolmo y la
Ing. Annia Valdés Díaz; en el cual se propone desarrollar el sistema
informático de Control Sanitario Internacional(CSI) para informatizar los
procesos relacionados con la salud ambiental, control de vectores y
vigilancias epidemiológicas llevadas a cabo por los especialistas del
MINSAP, lo cual permite gestionar los procesos que ellos desarrollan de
forma automática.
En resumen, realizaron que el programa de Control Sanitario

Internacional propuesto en Cuba permita el control y seguimiento de la
importación de productos, enfermedades endémicas de otros países y las
transmisibles por vectores. Todo esto es realizado en formato duro, de
forma manual, por teléfono, correo y Excel. Existen algunos sistemas
desarrollados que no presentan todas las funcionalidades necesarias para
el manejo de la información requerida. En la Universidad de las Ciencias
Informáticas (UCI), se desarrolló el sistema “Control Sanitario Internacional”
(CSI) y su objetivo fundamental es automatizar todos los procesos
relacionados a la vigilancia, seguimiento de la higiene de los productos,
control de foco y la detección de enfermedades. Para la implementación
usaron Apache, base de datos MySQL 5, PHP 5 y el framework CodeIgniter
15
v1.6. Con la implantación del sistema se espera centralizar la gestión de la
información, otorgando rapidez, calidad y seguridad en la información.
Finalmente concluyeron que una visión panorámica del Sistema

Informático Control Sanitario Internacional, evidenciando el impacto de la
solución propuesta desde el punto de vista social y económico. Se obtuvo
como resultado los subsistemas Vigilancia Epidemiológica, Salud
Ambiental y Control de Vectores para una versión 1.0, cumpliendo con el
objetivo de automatizar los procesos de vigilancia a viajeros para el control
de enfermedades transmisibles, la campaña anti vectorial en Cuba y las
acciones referentes al control de la calidad y seguridad biológica de la
importación y distribución de productos en el país. Para su desarrollo se
utilizó la metodología RUP, como Servidor Web Apache, sistema gestor de
base de datos MySQL, lenguaje de programación PHP 5, framework
CodeIgniter v1.6, metodología RUP y como Lenguaje de Modelado (UML
2.0). El sistema permite obtener y analizar los reportes estadísticos, se
podrá llevar a cabo un conjunto de acciones encaminadas a mejorar la
calidad de vida de la población desde el punto de vista de su higiene y
sanidad. (Fernández et al., 2012)
Esto será útil para la presente tesis debido a que se automatizará un

proceso con el fin de mejorar el punto económico de la empresa.
“DISEÑO E IMPLEMENTACIÓN DE UNA APLICACIÓN MÓVIL PARA

LA PRESENTACIÓN DE ESTADÍSTICAS DEL MÓDULO DE
INCIDENCIAS DE UN SISTEMA DE GESTIÓN DE SERVICIOS”,
presentado por Luis Carlos Gamarra Muro; en el cual se propone diseñar e
implementar un aplicativo móvil que se encargue de presentar las
estadísticas del módulo de incidencias de un sistema de gestión de
servicios. La aplicación tendrá por nombre Incident Dashboard Mobile y
consistirá de 3 interfaces que guiarán al usuario de forma directa a las
presentaciones comenzando por la interfaz de inicio de sesión, pasando
16
por la interfaz de elección de cuadro de resumen, y finalmente la aplicación
mostrará el cuadro seleccionado por el usuario.
En resumen, el crecimiento y desarrollo de las tecnologías de la

información han influenciado en gran manera el mercado durante los
últimos 15 años. Con la aparición de hardware más poderoso, software más
versátil y redes de alta velocidad, hemos pasado de la Era Industrial a la
Era de la Información. El cambio acelerado del mercado de tecnología e
información ha generado un nuevo enfoque horizontal de procesos de
negocio en las empresas de TI (Tecnología de Información). Justamente,
en el contexto anterior se da lugar a la Gestión de Servicios de Información
(GSI), que se encarga de velar por la correcta operación de todos los
procesos involucrados en la gestión de la información de la empresa como,
por ejemplo, el proceso de gestión de incidencias, gestión de cambios,
gestión de requerimientos, entre otros. De esta manera se asegura que la
información sensible e importante para el negocio este siempre disponible,
protegida y respaldada.
Finalmente se llegó a la conclusión que la aplicación ha logrado

automatizar el proceso de generación de cuadros de resumen, ya que los
datos del proceso de Gestión de Incidencias solamente son manipulados
por la aplicación durante todo el proceso. El usuario sólo visualiza el
resultado final a través de gráficos estadísticos.
“ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UN BANCO

ESTANDARIZADO DE HISTORIAS CLÍNICAS Y APLICACIÓN MÓVIL
PARA LAS CLÍNICAS ODONTOLÓGICAS”, presentado por Luis Martín
Allende Flores; en el cual se propone desarrollar un proyecto cuya principal
finalidad y objetivo es la resolución de un problema latente en el actual
sistema de manejo de historias clínicas odontológicas en los
establecimientos de salud públicos.
17
En resumen, el presente proyecto tiene como uno de sus productos
finales un banco estandarizado de historias clínicas odontológicas, el cual
intentará resolver los problemas descritos anteriormente. Actualmente, el
Ministerio de Salud no dictamina un método estándar para la manipulación
automatizada de historias clínicas, es por ello que los establecimientos de
salud públicos recurren a la utilización de los procesos manuales para el
manejo de las mismas sin sopesar que, en su mayoría, infringen las normas
[NTHC]. A pesar de esto, los establecimientos de salud públicos tienen una
gran cantidad de fondos disponibles no utilizados [ENSF], los cuales nos
servirían para el financiamiento del proyecto y adquisición de hardware
necesario. En dicho contexto, la implementación de un banco
estandarizado de historias clínicas permitiría monopolizar la información
relacionada y cumplir con los estándares dictaminados [NTHC]. Asimismo,
es necesario implementar una aplicación móvil que aproveche dichas
ventajas y que, mediante sus funcionalidades, permita al profesional de
salud manipular dicha información.
Finalmente se llegó a las siguientes conclusiones:
- El tiempo real de desarrollo del proyecto excedió ligeramente el

propuesto, y esto se debe a una falla en el cálculo de la curva de
aprendizaje y las labores extra curriculares realizadas por mí,
considerando ser el único recurso del proyecto.
- La metodología SCRUM utilizada para el manejo del proyecto resulto
positiva de sobremanera, ya que permitió una mejor adaptación a los
constantes cambios que se presentaban durante todo el tiempo de vida
del mismo.
- Las decisiones de plataformas tecnológicas tomadas para este proyecto
fueron acertadas, tanto en el manejo de servicios como en la aplicación
móvil.
- La aplicación móvil desarrollada representa la información básica a ser
utilizada por un odontólogo en su labor diaria, pero esta labor no debe
ser limitada por la información dispuesta.
18
- La calidad de información que se pretende representar con la Base de
Datos utilizada fue obtenida tras encuestas e investigación en múltiples
centros de salud, clínicas y hospitales de la ciudad de Lima, con el fin
de poder hacer que esta represente la realidad. Sin embargo, se
considera que una mayor cantidad de información puede ser
representada en ella, con la ayuda de un correcto manejo y
estandarización de datos.
“DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE

AUTOMATIZACIÓN PARA MEJORAR LA PRODUCCIÓN DE CARRETOS
EN LA EMPRESA LA CASA DE TORNILLO SRL”, presentado por Joselito
Sánchez Pérez; en el cual se propone diseñar e implementar un sistema
de automatización para la empresa La Casa del Tornillo, en el proceso de
ensamble de carretos representa una oportunidad de aumentar la
productividad aumentando la eficiencia del proceso productivo en esta
área, contribuyendo de esta manera al crecimiento y desarrollo de dicha
empresa. Para ello se diseñará e implantará un sistema de automatización
de ensamble para realizar los 3 procesos (apuntalado, resoldado y
rectificado) en un solo proceso, mejorando la producción, aumentando la
flexibilidad en la fabricación de los productos, permitiendo adecuarse a la
demanda del mercado, integrando nuevas tecnologías de producción,
desarrollando nuevos productos y así aumentando la calidad.
Contribuyendo a un mejor desempeño de la maquinaria y del proceso.
En resumen se tuvo como objetivo diseñar e implementar un sistema

de automatización para mejorar la producción de los carretos, esto se
realizó mediante un autómata programable industrial (API) o Programable
Logic Controller (PLC), que es un equipo electrónico programable en
lenguaje no informático, diseñado para controlar en tiempo real y en el
ambiente de tipo industrial los procesos secuenciales. También mediante
los dispositivos de control de automatización (sensores inductivos,
19
contactores, motores, estos recepcionan o emiten una señal la cual será
procesada dando como resultados soluciones de acuerdo al tipo de
necesidad del sistema que es el soldado automático. Mediante este sistema
permite al hombre intervenir un 20% y a los sistemas de automatización un
80% del proceso, haciéndolo más eficiente, ya que se logró reducir 150
horas de trabajo de 225 horas, la producción aumento en un 33%.
Finalmente se llegó a las conclusiones:
- Al implementar el sistema de automatización se logró reducir 150 horas

de trabajo de 225 horas, es decir que anteriormente en 225 horas se
obtenía una producción de ensamble de 1500 carretos y ahora, en 75
horas se ensambla los1500 reduciendo 150 horas equivalente a 18.5
días y de esta manera se ha aumentado la productividad de 0.94 a 3.72.
- La producción aumento en un 33.3% equivalente a 500 carretos que
dejan un margen de utilidad de s/ 6977 mensuales.
- En cuanto a los gastos y costos de fabricación por cada 1500 carretos
ensamblados la empresa se ahorra S/1237.5 mensual.
- Asimismo, por cada lote de 100 carretos que se fabricaban, 5 salían
defectuosos, ahora, con el nuevo sistema no existen piezas
defectuosas. Ahorrando S/107.4 mensual.
“ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UN BANCO

ESTANDARIZADO DE HISTORIAS CLÍNICAS Y APLICACIÓN MÓVIL
PARA LAS CLÍNICAS ODONTOLÓGICAS”, presentado por Luis Martín
Allende Flores; el cual consiste en el desarrollo de un proyecto cuya
principal finalidad y objetivo es la resolución de un problema latente en el
actual sistema de manejo de historias clínicas odontológicas en los
establecimientos de salud públicos.
20
En resumen, se ha podido determinar que, en los establecimientos de
salud públicos, sobre todo en los que brindan servicios de atención
odontológica, se presentan múltiples inconvenientes que repercuten
directamente en la imposibilidad del cumplimiento de la “Norma Técnica de
Salud para la Gestión de la Historia Clínica”, con especial énfasis en lo
relacionado a:
- Custodia: No existe seguridad adecuada durante el almacenamiento

de la Historia Clínica.
- Conservación: Existen problemas con humedad y moho.
- Confidencialidad: Falta de definición de políticas de confidencialidad.
- Acceso: Permisos no definidos para la recolección de la Historia
Clínica.
El presente proyecto de fin de carrera tiene como uno de sus

productos finales un banco estandarizado de historias clínicas
odontológicas, el cual intentará resolver los problemas descritos
anteriormente. Actualmente, el Ministerio de Salud no dictamina un método
estándar para la manipulación automatizada de historias clínicas, es por
ello que los establecimientos de salud públicos recurren a la utilización de
los procesos manuales para el manejo de las mismas sin sopesar que, en
su mayoría, infringen las normas. A pesar de esto, los establecimientos de
salud públicos tienen una gran cantidad de fondos disponibles no utilizados,
los cuales nos servirían para el financiamiento del proyecto y adquisición
de hardware necesario. En dicho contexto, la implementación de un banco
estandarizado de historias clínicas permitiría monopolizar la información
relacionada y cumplir con los estándares dictaminados. Asimismo, es
necesario implementar una aplicación móvil que aproveche dichas ventajas
y que, mediante sus funcionalidades, permita al profesional de salud
manipular dicha información. En base a estos argumentos, se considera
que el desarrollo del presente proyecto adquiere importancia y es altamente
viable dentro del escenario planteado. Dejando, además, una ventana
abierta a posibles ampliaciones y mejoras en el futuro.
21
Finalmente se llegó a las conclusiones:
- El tiempo real de desarrollo del proyecto excedió ligeramente el

propuesto, y esto se debe a una falla en el cálculo de la curva de
aprendizaje y las labores extra curriculares realizadas por mí,
considerando ser el único recurso del proyecto.
- La metodología SCRUM utilizada para el manejo del proyecto resulto
positiva de sobremanera, ya que permitió una mejor adaptación a los
constantes cambios que se presentaban durante todo el tiempo de vida
del mismo.
- Las decisiones de plataformas tecnológicas tomadas para este proyecto
fueron acertadas, tanto en el manejo de servicios como en la aplicación
móvil.
- La API desarrollada para ser manejada por el Ministerio de Salud
(MINSA) requerirá una mejor administración de los recursos
informáticos que tienen a su disposición, ya que se esperaría un
crecimiento exponencial de la utilización de la misma una vez se adapte
a la utilización general. 68
- La aplicación móvil desarrollada representa la información básica a ser
utilizada por un odontólogo en su labor diaria, pero esta labor no debe
ser limitada por la información dispuesta.
- La calidad de información que se pretende representar con la Base de
Datos utilizada fue obtenida tras encuestas e investigación en múltiples
centros de salud, clínicas y hospitales de la ciudad de Lima, con el fin
de poder hacer que esta represente la realidad. Sin embargo, se
considera que una mayor cantidad de información puede ser
representada en ella, con la ayuda de un correcto manejo y
estandarización de datos.
- El mayor problema que puede enfrentar la aplicación del proyecto, es
por temas burocráticos en el Ministerio de Salud (MINSA), es por ello
que se tuvo una charla previa a la finalización del proyecto con los
dirigentes del Colegio Odontológico de Lima, los cuales apoyaron la
idea y propusieron una implementación controlada.
22
“ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UNA APLICACIÓN
PARA ADMINISTRAR Y CONSULTAR AVISOS CLASIFICADOS PARA
TABLETAS ANDROID”, presentado por Jorge Fabrisio Cornejo Aramayo;
el cual se propone el desarrollo de una aplicación llamada i-Avisos, que dé
respuesta a necesidades enfocadas al tema de servicios (avisos
clasificados).
En resumen, el presente proyecto consiste en el análisis, diseño e

implementación de una aplicación para administrar la publicación y las
consultas de avisos clasificados estructurados para tabletas con sistema
operativo Android, orientado a cualquier tipo de usuario que desee
interactuar con un aplicativo de fácil uso, con interfaces amigables e
intuitivas y que además integre las más usadas funcionalidades de las
herramientas (sitios web, aplicativos, periódicos, etc.) avocadas al rubro de
los avisos clasificados.
Finalmente se llegó a la conclusión que proyecto actual representa

una gran ayuda a diferentes tipos de usuario que desean publicar y/o
encontrar un producto y/o servicio, debido a que i-Avisos integra las más
importantes funcionalidades encontradas en diferentes aplicativos y medios
no digitales, brindando flexibilidad en el manejo y distribución de la
información a cualquiera que interactúe con él.
“DISEÑO E IMPLEMENTACIÓN DE UNA APLICACIÓN MÓVIL

BASADA EN LA TECNOLOGÍA NFC PARA ACCESO A INFORMACIÓN
DE LAS PIEZAS DE ARTE DE UN MUSEO”, presentado por Jesús Jorge
Herrera Mires; el cual consiste en diseñar e implementar un aplicativo móvil
de uso sencillo e intuitivo basado en la tecnología NFC para el acceso a
información e imágenes de piezas y obras de arte de un museo, con la
finalidad de mejorar la interacción de los visitantes con las piezas durante
su recorrido y promover el desarrollo cultural del país impulsando una
mayor asistencia a los museos.
23
En resumen, la presente tesis desarrolla el diseño e implementación
de una aplicación móvil enfocado en el sistema operativo Android para
agilizar y dinamizar el acceso a información de las piezas de arte de un
museo. Para este propósito, se adaptará la base de datos del museo
arqueológico Josefina Ramos de Cox. Además, se implementará una
aplicación web en el framework Web2py para la gestión de contenidos que
serán mostrados en la aplicación móvil. La aplicación móvil estará basada
en la tecnología Near Field Communication para obtener el identificador de
la pieza de arte de un tag NFC. Adicionalmente, se desarrolla un servicio
web en Web2py para consultar a la base de datos y retornar la información
en formato JSON a la aplicación móvil. En el capítulo 1 se desarrolla el
análisis de entornos y situación actual respecto a la visita a un museo, se
identifica la problemática, se plantea los objetivos de la presente Tesis y se
justifica su desarrollo. En el capítulo 2 se revisan las tecnologías necesarias
para la implementación de la aplicación móvil y la aplicación web, entre
ellas la tecnología NFC, los sistemas operativos móviles con mayor
cobertura de mercado, PhoneGap y Web2py. En el capítulo 3 definimos el
diseño de nuestras aplicaciones en base a la justificación del uso de NFC
sobre otras tecnologías. Asimismo, se definen los diagramas de casos de
uso, mockups de las aplicaciones y sus especificaciones. Por último, en el
capítulo 4 se indica el proceso de construcción de la aplicación móvil y la
aplicación web de administración. Se explica la escritura de un tag NFC a
través de la aplicación TagWriter, se muestra las aplicaciones finales con
sus funcionalidades definidas y se exponen los resultados.
Finalmente se obtienen las siguientes conclusiones a partir de los

resultados obtenidos tras el diseño y la implementación de la aplicación
web y móvil:
- Los museos necesitan de la integración de nuevas tecnologías en sus

ambientes para lograr la interacción con los visitantes. Los nuevos
contenidos atraerán mayor cantidad de visitas y modernizarán la forma
en la que las personas acceden a la información en los ambientes del
museo
24
- PythonAnywhere es la forma más rápida y simple de desplegar
aplicaciones Web2py. No necesitamos contar con un servidor físico, el
cual también involucra un costo, para desplegar nuestra aplicación
web; basta con subirlo a la “nube” de forma gratuita para tener acceso
a través de un navegador web. Cabe resaltar que también es posible
realizar la implementación en un servidor propio.
- La aplicación móvil implementada permite acceder a la información de
las piezas de arte en un museo. Su uso es sencillo e intuitivo, en base
a que el 75% de las personas que probaron la aplicación tuvieron éxito
al utilizarla y lograron tener la información de la pieza de arte en un
corto tiempo. El 25% ha tenido poca experiencia anterior con
smartphones, por lo que se entiende que las personas que han
utilizado anteriormente unos móviles inteligentes podrán utilizar la
aplicación.
- Se logró implementar una aplicación web sencilla para administrar el
contenido de la base de datos. No obstante, se considera que aún se
puede diseñar la aplicación web de una manera más amigable e
interactiva. Esto se afirma en base a que el 85% de personas que la
utilizaron pudieron de forma intuitiva crear y editar una pieza de arte
del museo, el otro 15% no lo logró.
2.2 Aplicación móvil
2.2.1 Origen de las aplicaciones móviles
Investigando sobre sus orígenes, no existe un criterio único

aceptado por la comunidad tecnológica sobre el origen de las
aplicaciones como tal. Sin embargo, se pueden situar en las
primeras aplicaciones de videojuegos, de tonos de llamada,
calendario y agenda implementados en los teléfonos celulares o
móviles de segunda generación de los años 90. Eran los
denominados teléfonos básicos de pantallas reducidas, la mayoría
de ellas no táctiles.
25
El popular Tetris fue el primer juego instalado en el año 1994
en un teléfono móvil de manufactura danesa, el Hagenuk mt-2000.
Tres años más tarde, Nokia lanzó el juego de mayor aceptación
hasta el momento el Snake cuyo desarrollo se basa en Arcade
Blockade. Este juego y sus variantes fue preinstalado en más de 350
millones de dispositivos móviles de la marca finlandesa. El modelo
6110 fue el primer videojuego que permitía el uso compartido de dos
jugadores utilizando el puerto infrarrojo. A día de hoy (2017) aún
perdura una variante del mismo, Arrow, desarrollado por la empresa
francesa Ketchapp.
Hacía el año 2000, la irrupción tecnológica del WAP (protocolo

de aplicaciones inalámbricas) permitió una mayor capacidad para la
descarga de juegos distribuidos por los operadores de telefonía con
un volumen de negocio era marginal comparado con las
videoconsolas de quinta y sexta generación coetáneas. Pero el
verdadero auge de las aplicaciones se produjo a partir del año 2008
con el lanzamiento del App Store de Apple, la publicación del primer
SDK para Android y la posterior pero casi inmediata inauguración del
Android Market, renombrado en marzo de 2012 como Google Play,
tras su fusión con Google Music, en un nuevo planteamiento
estratégico en la distribución digital de Google.
2.2.2 Clasificación de las aplicaciones
Las aplicaciones se pueden clasificar atendiendo a diversos

criterios, entre ellos:
2.2.2.1 Clasificación de las aplicaciones
- Aplicaciones capacitadoras: aquellas que permiten o

incitan a buscar posibilidades nuevas o fomentar la
creatividad.
26
- Aplicaciones de dependencia: aquellas que impiden,
limiten o determinen nuestros actos, capacidad de
elección, creatividad, etc.
2.2.2.2 Por el tipo de contenido que ofrecen al usuario
- De entretenimiento: donde se encuadran

mayoritariamente las apps de juegos.
- De relación social: dirigidas a la comunicación
interpersonal
- De producción o utilitarias: proporcionan instrumentos
para la resolución de tareas específicas que requieren
inmediatez y rapidez para solucionar problemas, en
especial en el sector empresarial y comercial.
- Educativas o informativas: diseñadas y desarrolladas
como transmisoras de la información y el conocimiento
donde se prioriza el acceso a los contenidos y a las
herramientas de búsqueda mediante una interfaz de
navegación lo más sencillo y fácil posible.
- Creativas: ofrecen herramientas que potencien la
creatividad literaria, musical (y sonora), fotográfica o
video-gráfica.
- Publicitarias: con fines comerciales la gran mayoría son
de distribución gratuita.
2.2.2.3 Por las condiciones de distribución
Pueden clasificarse como gratuitas, de pago y

freemium, las cuales permiten su descarga inicial gratuita
para un uso limitado y básico, posibilitando posteriormente
el acceso a funcionalidades más avanzadas previo pago.
27
2.2.2.4 Por la edad de destino de los usuarios del contenido
El App Store establece una clasificación del contenido

por tramos de edades de “4+, 9+, 12+ y 17+”, que limita el
acceso a la descarga de dicha aplicación.
2.2.2.5 Por el tipo de diseño y desarrollo:
Como ya se ha especificado en apartados anteriores

su diseño y desarrollo permite diferenciar entre aplicaciones.
- Genéricas: prácticamente todo el diseño y programación

de lenguaje es compatible con la mayoría de los
dispositivos.
- Híbridas: determinados componentes de la
programación son comunes para todos los smartphones
y otro porcentaje es específico, dependiendo del sistema
operativo.
- Nativas: su programación en su totalidad es específica
para cada Market de distribución.
2.2.3 Distribución
Existen diferentes tipos de tiendas para descargar

aplicaciones, estas pueden ser creadas por el mismo sistema
operativo o por independientes. Las tiendas organizan las
aplicaciones y cada una tiene normas diferentes de retribución y
publicación. Para la distribución de aplicaciones móviles existen
diferentes plataformas distribuidoras:
28
2.2.3.1 Google Play
Google Play (anteriormente Android Market) es una

plataforma de distribución de software en línea desarrollado
por Google Inc. para dispositivos con sistema operativo
Android. Fue lanzado en octubre de 2008. Hasta octubre de
2012, Google Play contaba con más de 700 000
aplicaciones. En la plataforma se encuentran disponibles
tanto aplicaciones gratuitas como de pago.
2.2.3.2 App Store
La App Store fue el primer servicio de distribución de

aplicaciones, siendo lanzada el 10 de julio de 2008. En 2016,
el CEO de Apple, Tim Cook, anunció que existen 2.000.000
aplicaciones disponibles para dispositivos con iOS. Desde
su creación en 2008, más de un millón de aplicaciones
estuvieron disponibles en el App Store. Numerosas
empresas utilizan este canal para distribuir las aplicaciones
colaborativas, de gestión y de productividad a los usuarios
externos e internos.
Apple transformó el mercado de las aplicaciones para

dispositivos móviles, estrenándose con un pequeño
catálogo de solamente 500 aplicaciones y logrando en
cuatro días 10 millones de aplicaciones descargadas.
En julio de 2012, Apple creó App Store Volume

purchasing for business. Disponible únicamente en EE. UU.,
este programa permite a las empresas comprar aplicaciones
en grandes cantidades con el fin de distribuirlas a sus
colaboradores a través de códigos promocionales. Es
posible también integrar en esta tienda "business to
business", aplicaciones desarrolladas por terceros y que no
son publicadas en el App Store clásico.
29
2.2.3.3 Windows Store
La Windows Store es la plataforma de distribución de

Microsoft para los dispositivos que cuentan con el sistema
operativo móvil Windows Phone. Fue lanzado en octubre de
2010. Para octubre de 2012, contaba con 120 000
aplicaciones disponibles. En mayo de 2013 Microsoft
anunció que ya contaba con 145 000 aplicaciones en
Windows Phone Store.
2.2.3.4 BlackBerry World
Las aplicaciones para los dispositivos BlackBerry se

encuentran disponibles mediante descarga a través del
servicio BlackBerry World (antes BlackBerry App World).
Fue lanzada el 1 de abril de 2009. En julio de 2011 se
reportaron tres millones de descargas al día.
2.2.3.5 Amazon Appstore
La Amazon Appstore es una aplicación móvil de

distribución de software disponible para los dispositivos con
sistema operativo Android. Fue lanzada en marzo de 2011,
contando con 3 800 aplicaciones.
2.2.3.6 F-Droid
F-Droid es un repositorio de aplicaciones para Android

que incluye únicamente software libre y de código abierto.
Fue fundado en 2010 por Ciaran Gultnieks.
30
2.3 Automatización
La palabra automatización engloba un amplio abanico de sistemas y

procesos en los cuales se requiere la mínima intervención del ser humano,
además debe de ser un sistema “flexible” el cual se debe ajustar de distintas
maneras a los posibles cambios en momentos puntuales.
2.3.1 Tipos de automatización
Existen diferentes tipos de tiendas para descargar

aplicaciones, estas pueden ser creadas por el mismo sistema
operativo o por independientes. Las tiendas organizan las
aplicaciones y cada una tiene normas diferentes de retribución y
publicación. Para la distribución de aplicaciones móviles existen
diferentes plataformas distribuidoras:
2.3.1.1 Control discreto (On/Off)
Uno de los más simples tipos de control es el control

On/Off. Un ejemplo de esto son los termostatos que se
utilizan en las viviendas, que sólo tienen un botón de
prendido y apagado para controlar el calor. Sistemas un
poco más complejos poseen también un controlador con
varios niveles de calor y múltiples velocidades para el
ventilador.
2.3.1.2 Control continuo
El tipo de control que ha revolucionado la manufactura,

la ciencia aeroespacial, las comunicaciones y otras
industrias, es el control de retroalimentación, el cual es
usualmente continuo. Este consiste en la toma de medidas
usando un sensor y haciendo ajustes en los cálculos para
poder tomar medidas variables y así el sistema siga
31
rabajando sin la necesidad de que intervenga el operador
humano.
2.3.1.3 Control Secuencial
El control secuencial no es más que una secuencia de

algoritmos (instrucciones) que se van ejecutando uno tras
de otro. El primero que se haya escrito es el primero que se
ejecuta y la salida de una orden es el comienzo de la
siguiente. Esto sigue así hasta el final del proceso. Este tipo
de estructuras se basan en las 5 etapas que deben seguir
todos los algoritmos o programas: definición de variables,
inicialización de variables, lectura de datos, cálculo y salida
2.3.1.4 Control computacional
Los computadores pueden realizar ambos, controles

secuenciales y de retroalimentación. Típicamente un único
computador hace ambos procesos en una aplicación
industrial. El control computacional ha ido reemplazando
con el tiempo los controles que se dedican a un solo
proceso, ya que estos se pueden encargar de operar cientos
de procesos al mismo tiempo. Esto lo realiza por medio de
procesamientos de información provenientes de todos los
controles programables que opera y así controla todas las
múltiples variables que inciden en el proceso de
automatización. Además, mientras operan todo el sistema,
también pueden analizar toda la información del proceso,
para así crear gráficos en tiempo real para que los
operadores humanos tengan noción de cómo se está
realizando el proceso de automatización, lo que les permite
tomar decisiones más informadas y reparar errores
de programación más eficientemente.
32
2.3.2 Objetivos de la automatización
- Mejorar la productividad de la empresa, reduciendo los costes

de la producción y mejorando la calidad y uniformidad de la
misma, mediante un mejor control de la producción y procesos
repetitivos.
- Mejorar las condiciones de trabajo del personal, suprimiendo los
trabajos penosos e incrementando la seguridad personal.
- Minimizar el esfuerzo humano y tiempo de producción por
procesos.
- Realizar las operaciones imposibles de controlar intelectual o
manualmente por humanos.
- Reducir la intervención humana, el aburrimiento y posibilidad de
error humano (daño en piezas, etc).
- Mejorar la disponibilidad de los productos, pudiendo proveer las
cantidades necesarias en el momento preciso.
- Simplificar el mantenimiento de forma que el operario no
requiera grandes conocimientos para la manipulación del
proceso productivo.
- Integrar la gestión y producción a la empresa.
2.3.3 Justificación de la automatización
Realizar un proceso de automatización no siempre justifica la

implementación de sistemas de automatización, pero existen ciertos
criterios y señales indicadoras que justifican y hacen necesario la
implementación de estos sistemas, algunos son:
- Requerimientos de un aumento en la producción

- Requerimientos de una mejora en la calidad de los productos
- Necesidad de bajar los costos de producción
- Escasez de energía
- Encarecimiento de la materia prima
- Necesidad de protección ambiental
33
- Necesidad de brindar seguridad al personal
- Desarrollo de nuevas tecnologías
La automatización solo es viable si al evaluar los beneficios

económicos y sociales de las mejoras que se podrían obtener al
automatizar, estas son mayores a los costos de operación y
mantenimiento del sistema.
2.3.4 Obsolescencia
La automatización del trabajo demuestra la obsoleta de los

artefactos y del trabajo humano esto a través de:
- Percibidas: este se refiere a lo que las normas generan. Un

ejemplo de esto es al cambiar los zapatos sin que esto sea
necesario, eso se da ya que el producto está fuera de moda.
- Programada: Se da por el constante cambio tecnológico que

afrontan los artefactos, al dejar de funcionar o no cumplir con lo
necesario actualmente. Este utiliza recursos del consumo para el
re-cambiar del producto una y otra vez.
- Laboral: también conocida como el desempleo tecnológico, esta

se refiere a los empleados que no pueden adaptarse a los
cambios tecnológicos y son desplazados por nuevos
profesionales o robot.
34
2.4 Marco Conceptual
- Android. Es un sistema operativo inicialmente pensado para teléfonos

móviles, al igual que iOS, Symbian y Blackberry OS. Lo que lo hace
diferente es que está basado en Linux, un núcleo de sistema operativo
libre, gratuito y multiplataforma. El sistema operativo proporciona todas
las interfaces necesarias para desarrollar aplicaciones que accedan a las
funciones del teléfono (como el GPS, las llamadas, la agenda, etc.) de
una forma muy sencilla en un lenguaje de programación muy conocido
como es Java. (Nieto, 2011).
- Aplicación móvil. Es una aplicación de software que se instala en

teléfonos móviles o tablets para favorecer al usuario en una actividad
concreta, ya sea de carácter profesional, de ocio o de entretenimiento, a
diferencia de una aplicación web, el aplicativo móvil no es instalable. El
objetivo de un aplicativo móvil es facilitarnos la consecución de una tarea
determinada o ayudarnos en operaciones y gestiones del día a día. (Qode,
2012).
- Automatización. La palabra automatización engloba un amplio abanico

de sistemas y procesos en los cuales se requiere la mínima intervención
del ser humano, además debe de ser un sistema “flexible” el cual se debe
ajustar de distintas maneras a los posibles cambios en momentos
puntuales. (Martínez, 2017).
- Backlog Priorizado del Producto. Es un solo documento de requisitos

que define el alcance del proyecto, proporcionando una lista de
prioridades de las características del producto o servicio a ser entregado
por el proyecto. (SCRUMstudy, 2017).
35
- Composer. Es un gestor de dependencias en proyectos, para
programación en PHP. Eso quiere decir que nos permite gestionar
(declarar, descargar y mantener actualizados) los paquetes de software
en los que se basa nuestro proyecto PHP. Se ha convertido en una
herramienta de cabecera para cualquier desarrollador en este lenguaje
que aprecie su tiempo y el desarrollo ágil. (Alvarez, Composer gestor de
dependencias para PHP, 2014).
- Daily Standup. Es una breve reunión diaria con un bloque de tiempo de

15 minutos. Los miembros del equipo se reúnen para dar un reporte sobre
su progreso en el sprint y planificar las actividades del día. La duración de
la reunión es muy corta y se busca que todos los integrantes del equipo
Scrum estén presentes. Sin embargo, la reunión no se cancela o se
retrasa si uno o más miembros no pueden asistir. (SCRUMstudy, 2017).
- Equipo Scrum. Es uno de los roles del equipo principal de Scrum. El

equipo Scrum trabaja en la creación de entregables del proyecto y
contribuye a la realización del valor del negocio para todos los socios y
del proyecto. (SCRUMstudy, 2017).
- Historias de usuario. Las historias de usuario se adhieren a una

estructura específica y predefinida y son una manera simplista de
documentar los requisitos y la funcionalidad deseada del usuario final. Los
requerimientos expresados en las historias de usuario son afirmaciones
breves, simples y fáciles de entender, lo cual resulta en una mejor
comunicación entre socios y mejores estimaciones por parte del equipo.
(SCRUMstudy, 2017).
- Java. Es un lenguaje de programación orientado a objetos creado en 1991

y publicado en 1995 por Sun Microsystem (adquirida por Oracle en 2010),
con la intención de que los programadores escribieran el código solo una
vez y lo ejecutarán en cualquier dispositivo. (Guevara, 2016).
36
- Librería Volley. Es una librería desarrollada por Google para optimizar el
envío de peticiones HTTP desde las aplicaciones Android hacia
servidores externos. Este componente actúa como una interfaz de alto
nivel, liberando al programador de la administración de hilos y procesos
tediosos de parsing, para permitir publicar fácilmente resultados en el hilo
principal. (Revelo, 2015).
- MySQL. Es un sistema de gestión de base de datos relacional (RDBMS)

de código abierto, basado en lenguaje de consulta estructurado (SQL).
MySQL se ejecuta en prácticamente todas las plataformas, incluyendo
Linux, UNIX y Windows. (Rouse, 2015).
- PHP. Es el acrónimo de Hipertext Preprocesor. Es un lenguaje de

programación del lado del servidor gratuito e independiente de plataforma,
rápido, con una gran librería de funciones y mucha documentación.
(Alvarez, Qué es PHP, 2001).
- PhpMyAdmin. Es una herramienta gratuita, que permite de una manera

muy completa acceder a todas las funciones de la base de datos MySQL,
mediante una interfaz web muy intuitiva. (Vergara, 2016).
- Planning Poker. Es una técnica de estimacin implementa el consenso

para estimar los tamaños relativos de las historias de usuario o el trabajo
necesario para desarrollarlos. (SCRUMstudy, 2017).
- Product Owner. Es la persona responsable de maximizar el valor del

negocio en el proyecto. Es la persona responsable de articular los
requerimientos del cliente y mantener la justificación del negocio del
proyecto. (SCRUMstudy, 2017).
37
- Scrumboard. Es una herramienta utilizada por el equipo Scrum para
planificar y dar seguimiento al proceso durante cada sprint. El tablero de
Scrum contiene cuatro columnas para indicar el progreso de las tareas
estimadas para el sprint: una columna “por hacer” (To Do) para las tareas
que aún no inician; una columna “en progreso” (In Progress) para las
tareas iniciadas, pero que no se han terminado; una columna de “prueba”
(Testing) para tareas terminadas pero que están en proceso de prueba; y
la columna de “terminado” (Done) para las tareas que se han terminado y
examinado satisfactoriamente. (SCRUMstudy, 2017).
- Scrum Master. Es uno de los roles en el equipo principal de Scrum. Él o

ella facilitan la creación de entregables del proyecto, gestiona riesgos,
cambios e impedimentos durante el proceso de llevar a cabo la reunión
diaria de pie, retrospectiva del sprint y demás procesos de Scrum.
(SCRUMstudy, 2017).
- Sprint. Es una iteración con un bloque de tiempo asignado de una a seis

semanas de duración durante el cual el equipo Scrum crea y trabaja en
los entregables del sprint. (SCRUMstudy, 2017).
- Sprint Backlog. Es una lista de tareas a ser ejecutadas por el Equipo

Scrum en el próximo sprint. (SCRUMstudy, 2017).
- Sprint Burndown Chart. Es una gráfica que muestra la cantidad de

trabajo pendiente en el actual sprint. (SCRUMstudy, 2017).
- Stakeholder. Es un término colectivo que incluye a clientes, usuarios y

patrocinadores que interactúan frecuentemente con el Product Owner,
con el Scrum Master y con el Equipo Scrum para brindar opiniones y
facilitar la creación del producto del proyecto, servicio u otros resultados.
(SCRUMstudy, 2017).
38
- Time-boxing. La asignación de bloque de tiempo es la fijación de breves
periodos para realizar el trabajo. Si el trabajo asumido permanece
incompleto al final del bloque de tiempo, se traslada al subsecuente
bloque. Los bloques de tiempo proporcionan la estructura necesaria para
los proyectos Scrum, los cuales tienen un elemento de incertidumbre, son
de naturaleza dinámica y son propensos a cambios frecuentes.
(SCRUMstudy, 2017).
- Web Service. Es una colección de protocolos abiertos y estándares

usados para intercambiar datos entre aplicaciones o sistemas que están
conectados a una misma red. Las aplicaciones escritas en varios
lenguajes de programación que funcionan en plataformas diferentes
pueden utilizar web services para intercambiar información a través de
una red. (Lázaro, 2018).
39
3. CAPÍTULO III
DESARROLLO DE LA METODOLOGÍA
En la implementación de un aplicativo móvil para automatizar la elaboración

de evidencias se utiliza una metodología ágil, descartando el uso de una
metodología clásica, debido a que se deben cumplir los estándares de tiempo
brindados por la empresa Delta Electronics y es de suma importancia entregar
valor lo antes posible.
Dentro de las metodologías ágiles se elige el marco de trabajo Scrum ya

que muy aparte de brindar valor pronto a través de la priorización también
asegurará la calidad y futuro escalamiento del sistema.
A continuación, se muestra el desarrollo de la solución mencionada

haciendo uso del marco de trabajo Scrum, para ello se considera 3 sprints que a
su vez se desglosan en fases como:
- Fase de Inicio
- Fase de Planificación
- Fase de Implementación
- Fase de Revisión y Retrospectiva
- Entregables
A partir de las fases mencionadas se desprenden actividades que son

consideradas por la guía de Scrum como procesos los cuales contarán con
entradas, procesos y salidas.
Los procesos dentro de los sprint son considerados repetitivos a excepción

del proceso de retrospectiva del proyecto que solo es considerado al final del
mismo.
40
3.1 Sprint 1
3.1.1 Fase de inicio
I) Creando la visión del proyecto
ENTRADAS:
DESCRIPCIÓN DE LA EMPRESA
Delta Electronics es una empresa con 30 años de

experiencia, que diseña y fabrica equipos de vanguardia para
el segmento terrestre, y brinda soluciones integrales y
servicios de extremo a extremo, impulsados por su tecnología
innovadora con sede en la Av. Brasil 2011, distrito de Jesús
María, departamento de Lima - Perú.
Figura 1: Logotipo de la empresa Delta Electronics
Fuente: Delta Electronics
41
MISIÓN DE LA EMPRESA
Proporcionar soluciones innovadoras, limpias y

eficientes desde el punto de vista energético para un futuro
mejor.
VISIÓN DE LA EMPRESA
Ser la empresa número uno en proporcionar soluciones

del punto de vista energético a nivel internacional.
CULTURA DE LA EMPRESA
- Innovación: Crear nuevas ideas y llevarlas al éxito con

eficacia.
- Calidad: Ofrecer constantemente un rendimiento
superior y perseguir la mejora todo el tiempo
- Agilidad: Identificar las tendencias emergentes y
actuar rápidamente para capturar nuevas
oportunidades.
- Trabajo en equipo: Aprovechar al máximo las redes de
valor global y colaborar para lograr objetivos comunes.
- La satisfacción del cliente: Anticipar las necesidades del
cliente y superar las expectativas.
HERRAMIENTAS:
REUNIÓN DE LA VISIÓN DEL PROYECTO
En esta reunión con el Stakeholder(s), el Product Owner,

y el Scrum Master. Esta ayuda a identificar el contexto
empresarial, los requerimientos de negocio y las expectativas
de los stakeholders a fin de desarrollar una declaración de la
visión del proyecto eficaz (SCRUMstudy, 2017).
42
En la implementación de un aplicativo móvil para
automatizar la elaboración de evidencias para la presente
tesis la reunión se da con la máxima autoridad de una
Asociación, la Asamblea General de Asociados de Delta
(SCRUMstudy, 2017).
Esta reunión se da de manera informal con los miembros

el viernes 10 de agosto de 2018 (SCRUMstudy, 2017).
SALIDAS:
PRODUCT OWNER IDENTIFICADO
El Product Owner es la persona responsable de lograr el

máximo valor empresarial para el proyecto. También está a cargo
de la articulación de requerimientos por parte de los clientes y de
mantener la justificación del negocio para el proyecto. El Product
Owner representa la voz del cliente.
En este caso el rol de Product Owner cae sobre el Sr. Rodrigo

Vidal Paucarima Navarro, esta decisión fue tomada ya que este
señor posee habilidades de comunicación y de negociació.
Además, tiene una gran variedad de contactos los cuales pueden
ser de gran ayuda conforme avance el proyecto.
DECLARACIÓN DE LA VISION DEL PROYECTO
Aquí se llegan de manera informal a los siguientes puntos:
- Generar un Software funcional para la empresa Delta

Electronics.
- Satisfacer todas las necesidades requeridas por los
Stakeholder.
43
- El aplicativo móvil debe ser amigable y manejable para los
usuarios de campo, los cuales se encargarán de tomar fotos
en provincia para generar las evidencias
- Tener un compromiso sólido para el desarrollo del aplicativo
móvil.
II) Identificando al Scrum Master y Stakeholder
ENTRADAS:
Product Owner y la reunión del proyecto.
HERRAMIENTAS:
CRITERIOS DE SELECCIÓN DE SCRUM MASTER
- Habilidades para resolver problemas: Es uno de los principales

criterios a considerar al seleccionar al Scrum Master. El Scrum
Master debe tener las habilidades y la experiencia necesaria
para ayudar a eliminar cualquier impedimento que enfrente el
Equipo Scrum (SCRUMstudy, 2017).
- Disponibilidad: El Scrum Master debe estar disponible para
programar, supervisar y organizar varias reuniones, incluyendo
la reunión de planificación de del lanzamiento, el Daily Standup
y otras reuniones relacionadas al sprint (SCRUMstudy, 2017).
- Compromiso: El Scrum Master debe estar muy comprometido a
fin de asegurar que el Equipo Scrum cuente con un ambiente
laboral conductivo para garantizar la entrega exitosa de
proyectos Scrum (SCRUMstudy, 2017).
- Estilo de liderazgo servicial (SCRUMstudy, 2017).
44
SELECCIÓN DE STAKEHOLDERS
En la identificación del stakeholder es importante recordar

que estos incluyen a todos los clientes, usuarios y patrocinadores,
quienes a menudo interactúan con el Product Owner, Scrum Master
y Equipo Scrum para proveer entradas y facilitar la creación de los
productos del proyecto. Los stakeholders influyen en el proyecto a
lo largo de su ciclo de vida.
SALIDAS:
SCRUM MASTER IDENTIFICADO
Para la presente tesis el cargo de Scrum Master será

asignado al Ing. Daniel Cóndor García que cumple exactamente
con las habilidades mencionadas en la herramienta de Criterios de
Selección de Scrum Master.
STAKEHOLDER IDENTIFICADO
Para la presente el stakeholder identificado será el Sr.

Oscar Ybargüen Ignacio que cumple exactamente con las
habilidades mencionadas en la herramienta de Selección de
Stakeholders.
45
III) Formar equipos Scrum
ENTRADAS:
Product Owner, Scrum Master y la reunión de la visión de

proyecto.
HERRAMIENTAS:
SELECCIÓN DEL EQUIPO SCRUM
El Equipo Scrum es la base para un proyecto de Scrum y

el miembro o los miembros son responsables del éxito en el
cumplimiento de los entregables. Él o los miembros del Equipo
Scrum son generalistas y especialistas, porque están provistos con
conocimiento en diversos campos y son expertos en mínimamente
uno. Las habilidades interpersonales son vitales en equipos auto –
organizados, estas deben estar a nivel personal. Los miembros
ideales del Equipo Scrum tienen ideales independientes, se
motivan a si mismo, gran enfoque en el cliente y poseen un alto
sentido de responsabilidad y colaboración. El equipo fomenta un
ambiente de reflexión independiente y toma decisiones para
aportar mayor valor al producto. (SCRUMstudy, 2017).
SALIDAS:
EQUIPO SCRUM IDENTIFICADO
En la presente tesis el Equipo Scrum está conformado por

mi persona Sr.Jhensson Frank Ayma Flores y el Sr. Ricardo Levi
Guevara Alvarado los cuales nos encargaremos del desarrollo e
implementación del aplicativo móvil para automatizar la elaboración
de evidencias de los servicios prestados por el área de
telecomunicaciones en la empresa Delta Electronics.
46
IV) Crear el backlog priorizado del producto
ENTRADAS:
El equipo Scrum principal, las historias de usuario y los

prototipos.
HERRAMIENTAS:
MÉTODOS DE PRIORIZACIÓN SIMPLE DE HISTORIAS DE

USUARIO
Para la priorización se utilizó el método de los 100 puntos

que consiste en dar 100 puntos a los stakeholder para que sean
repartidos entre las historias de usuario (SCRUMstudy, 2017).
Tabla 1: Priorización de las Historias de Usuario
ID HISTORIA DE USUARIO PUNTAJE
1 Autenticación del usuario. 15
El sistema debe mostrar los nodos

2 correspondientes según el usuario 20
ingresado.
El sistema debe mostrar los indicadores

3 30
correspondientes según el nodo elegido.
El sistema debe convertir las fotos y los

4 datos brindados en un PDF con 5 40
diferentes estructuras.
Elaboración: Propia
47
SALIDAS:
BACKLOG PRIORIZADO DEL PRODUCTO
Es un solo documento de requisitos que define el alcance

del proyecto, proporcionando una lista de prioridades de las
características del producto o servicio a ser entregado por el
Figura 2: Backlog Priorizado del Producto
Fuente: Elaboración Propia
IV) Realizar la planificación del lanzamiento
ENTRADAS:
El equipo Scrum principal, stakeholder y la declaración de la

visión del proyecto.
48
HERRAMIENTAS:
SESIONES DE PLANIFICACION DE LANZAMIENTO
Se llegó a un acuerdo con el stakeholder sobre los tiempos

aproximados del proyecto el cual debería acabar en el plazo de 4
meses y se determinó que serán 2 sprints los cuáles durarán 2
meses cada uno.
SALIDAS:
CRONOGRAMA DE PLANIFICACIÓN DE LANZAMIENTO SPRINT 1
Tabla 2: Cronograma de planificación de lanzamiento del Sprint 1
Semana Semana 2, 3, Semana Semana

1 4, 5 Y 6 7 8
Difundir la historias de usuario actualizadas x
Estimación de las historias de usuario x
Comprometer las historias de usuario x
Estimar las tareas x
Crear el Sprint Backlog x
Avances y culminación del entregable x
Daily Standup x
Refinación de Backlog priorizado x
Demostración y validación de Sprint x
Retrospectiva del sprint 1 x
Envío del entregable x
La duración del Sprint es de 2 meses
El trabajo diario será de 8 horas diarias de lunes a sábado

que hacen un total de 48 horas semanales u 192 horas
mensuales.
49
Si se observa el cronograma veremos que hasta la
creación del Sprint Backlog se usarán 48 horas laborales o 1
semana.
En las semanas 2, 3, 4, 5 y 6 se utilizarán 240 horas para

los avances y culminación del entregable, en este lapso de tiempo
se realizará el Daily Standup todos los días por 15 minutos.
En la semana 7 se realizará la refinación del Backlog

priorizado, la demostración y la validación del sprint.
Finalmente, en la semana 8 se realizará la retrospectiva del

sprint 1 y el envío del entregable.
3.1.2 Fase de planificación
I) Crear historias de usuario
ENTRADAS:
Equipo Scrum, Backlog Priorizado del Producto, criterios de

terminado y prototipos descritos anteriormente.
HERRAMIENTAS:
EXPERIENCIA EN REDACCIÓN DE HISTORIAS DE USUARIO
La experiencia que demuestro es por haber concluido con

éxito la asignatura de Ingeniería de Software en la UNTELS
además de haber logrado conseguir certificación en la metodología
a través de la página Scrum Study.
50
Figura 3: Certificado de Scrum Study
Fuente: Scrum Study
SALIDAS:
HISTORIAS DE USUARIO + CRITERIOS DE ACEPTACIÓN
Las historias de usuario pueden entenderse como los requerimientos de

la solución de negocios, mientras que los criterios de aceptación son
requerimientos de más bajo nivel los cuales sirven para la aprobación o
desaprobación futura de las historias de usuario (SCRUMstudy, 2017).
51
Tabla 3: Historias de Usuario con criterios de aceptación del Sprint
ID HISTORIA DE USUARIO CRITERIOS DE ACEPTACIÓN

Como mínimo la contraseña
debe poseer una letra
mayúscula y un número.
1 Autenticación del usuario. Deben existir 2 roles distintos
de usuario:
- Instalador
- Coordinador
Los nodos deben tener los
siguientes estados:
El sistema debe mostrar los - En curso
2 nodos correspondientes según - En revisión
el usuario ingresado. - Deshabilitado
- Finalizado
Los indicadores pueden tener

los siguientes estados:
El sistema debe mostrar los
- A: Aceptado
3 indicadores correspondientes
- N: No aceptado
según el nodo elegido.
- OBS: Observado
- N/A: No aplicable
Para tomar cualquier foto es
obligatorio tener activado el
El sistema debe convertir las
GPS.
fotografías tomadas y los datos
4
brindados en un PDF con 5 Las fotografías tomadas deben
diferentes estructuras. tener el rotulado: Nombre de
proyecto, GPS y Fecha.
II) Estimar historias de usuario
ENTRADAS:
Equipo Principal Scrum y las historias de usuario.
52
HERRAMIENTAS:
REUNIONES DE PLANIFICACIÓN DE SPRINT
La estimación la realizamos tomando en cuenta el esfuerzo

que demanda el cumplimiento de la historia de usuario.
MÉTODOS DE ESTIMACIÓN
El método de estimación usado es el planning póker

tomando en cuenta el nivel de esfuerzo.
SALIDAS:
HISTORIAS DE USUARIO ESTIMADAS
Tabla 4: Historias de usuario estimadas del Sprint 1
ID HISTORIA DE USUARIO PLANNING POKER

El sistema debe mostrar
los nodos
2 5
correspondientes según el
usuario ingresado.
los indicadores
3 8
nodo elegido.
El sistema debe convertir

las fotos y los datos
4 13
brindados en un PDF con 5
diferentes estructuras.
53
III) Comprometer historias de usuario
ENTRADAS:
Equipo Principal Scrum, las historias de usuario estimadas y

la duración del sprint.
HERRAMIENTAS:
REUNIONES DE PLANIFICACIÓN DE TAREAS
En la reunión de planificación de tareas, el Equipo Scrum se

reunió con los stakeholder para planificar el trabajo a realizarse en
el sprint, la reunión concluyó con el compromiso del equipo Scrum,
para entregar un subconjunto de historias de usuario del Backlog
Priorizado del Producto en el sprint, se acordó que las historias de
usuario serian desarrollados en orden de priorización.
SALIDAS:
HISTORIAS DE USUARIO COMPROMETIDAS
Para el primer sprint nos comprometeremos a realizar las

siguientes historias de usuario, esto debido a que la historia de
usuario más valorizada depende de todas estas para su
realización.
Tabla 5: Historias de usuario comprometidas del Sprint 1

los nodos
2 5
usuario ingresado.
los indicadores
3 8
nodo elegido.
54
IV) Identificar tareas
ENTRADAS:
Equipo Principal Scrum y las historias de usuario

comprometidas.
HERRAMIENTAS:
REUNIONES DE PLANIFICACIÓN DEL SPRINT
Esto dio cabida a reflexionar sobre las tareas a realizar para

el cumplir de los criterios de aceptación de cada historia de usuario
comprometida.
DESCOMPOSICIÓN
Esta técnica consiste en la segmentación de las historias de

usuario con el fin de crear tareas de corte más específico para un
mejor desarrollo de la solución.
SALIDAS:
LISTA DE TAREAS
Es un conjunto de actividades por cada historia de usuario

que se va a realizar el Sprint 1.
55
Figura 4: Lista de tareas (I parte) Sprint 1
56
Figura 5: Lista de tareas (II parte) Sprint 1
57
V) Estimar tareas
ENTRADAS:
Equipo Principal Scrum y la lista de tareas y los criterios de

aceptación.
HERRAMIENTAS:
CRITERIOS DE ESTIMACIÓN
El criterio de estimación que utilizaremos será, el tiempo que

demora en concluir la tarea.
DESCOMPOSICIÓN
El Equipo Scrum escoge el método de Puño de Cinco, por

ser un mecanismo sencillo y rápido para este método cada
miembro del Equipo Scrum vota en una escala del 1 al 5 utilizando
los dedos de las manos. Así tomaremos cada dedo como una hora
de trabajo.
SALIDAS:
EFFORT ESTIMATED TASK LIST

58
Figura 6: Effort Estimated Task List (I parte) Sprint 1
59
Figura 7: Effort Estimated Task List (II parte) Sprint 1
60
VI) Crear el Sprint Backlog
ENTRADAS:
Equipo Principal Scrum, Effort Estimated Task List y la

duración del Sprint.
HERRAMIENTAS:
REUNIÓN DE PLANIFICACIÓN DEL SPRINT
El Equipo Scrum elabora también el Sprint Backlog y el

Sprint Burndown Chart utilizando las historias de usuario y la lista
de tareas antes mencionada durante las reuniones de planificación
del Sprint.
SALIDAS:
SPRINT BACKLOG
Figura 8: Sprint Backlog de Sprint 1
61
3.1.3 Fase de implementación
I) Crear entregables
ENTRADAS:
Equipo Scrum, Sprint Backlog y Scrumboard.
HERRAMIENTAS:
EXPERIENCIA DEL EQUIPO
Fuente: Scrum Study
SALIDAS:
ENTREGABLES DEL SPRINT
62
Figura 10: Base de datos realizada en MYSQL
63
Figura 11: Tabla usuario en la BBDD
64
Figura 12: Tabla nodo en la BBDD
65
Figura 13: Tabla indicador en la BBDD
Figura 14: Interfaz Login
66
Figura 15: Interfaz para visualizar los nodos
67
Figura 16: Interfaz para visualizar los indicadores
68
SCRUMBOARD ACTUALIZADO
Figura 17: Scrumboard actualizado en Trello del Sprint 1
3.1.4 Fase de revisión y retrospectiva
I) Demostrar y validar el sprint
ENTRADAS:
Equipo Principal Scrum, entregable del sprint, sprint backlog,

criterios de terminado y los criterios de aceptación de las historias
de usuario.
69
HERRAMIENTAS:
REUNIONES DE REVISIÓN DE SPRINT
Posterior al culminado del entregable, este fue autoevaluado

con los criterios de aceptación de las historias de usuario
pertinentes, determinando así si es adecuado para ser entregado
al stakeholder.
Figura 18: Criterios de aceptación de la HU Autenticación del usuario
El criterio de tener como mínimo una letra mayúscula y un número se

respetaron en la interface del Login.
Y el criterio el cual indica que deben existir 2 roles se solucionó

creando una tabla llamada Rol en la base de datos.
70
71
Figura 20: Tabla Rol en la base de datos
Figura 21: Criterios de aceptación de la HU El Sistema debe mostrar los

nodos correspondientes según el usuario ingresado
El criterio de que los nodos deben tener los estados: En curso, en

revisión, deshabilitado y finalizado se plasmó en la interfaz para visualizar
los nodos.
72
73
Figura 23: Criterios de aceptación de la HU El Sistema debe mostrar los
indicadores según el nodo elegido
El criterio de que los indicadores deban tener los siguientes estados:

Aceptado(A), no aceptado(N), observado (OBS) y no aplicable (NA) se
plasmó en la interfaz para visualizar los indicadores.
74
SALIDAS:
ENTREGABLES ACEPTADOS
El entregable presentado fue aceptado por el stakeholder y

el Product Owner.
II) Retrospectiva del Sprint
ENTRADAS:
Scrum Master, equipo Scrum, entregable aceptado.
HERRAMIENTAS:
REUNIÓN DE RETROSPECTIVA DEL SPRINT
Lo que se debe mantener en el proyecto es la actitud positiva

y gusto por el tema, el uso del trello y el constante aprendizaje.
Lo que se debe mejorar es el cumplimiento estándar de las

horas para evitar el sobrecargo en los últimos días del sprint.
Un impedimento para cumplir los objetivos del proyecto es el

tiempo que invierte el programador en otras actividades.
SALIDAS:
AGREED ACTIONABLE IMPROVEMENTS
Tabla 6: Agreed Actionable Improvements
MEJORES PRÁCTICAS
ID
ACEPTABLES
Uso de Trello para la
1
transparencia.
2 Actitud Positiva.
3 Constante aprendizaje.
75
3.2 Sprint 2
3.2.1 Fase de inicio
I) Creando la visión del proyecto
ENTRADAS:
DESCRIPCIÓN DE LA EMPRESA
Delta Electronics es una empresa con 30 años de

experiencia, que diseña y fabrica equipos de vanguardia para
el segmento terrestre, y brinda soluciones integrales y
servicios de extremo a extremo, impulsados por su tecnología
innovadora con sede en la Av. Brasil 2011, distrito de Jesús
María, departamento de Lima - Perú.
Figura 25: Logotipo de la empresa Delta Electronics
Fuente: Delta Electronics
MISIÓN DE LA EMPRESA
Proporcionar soluciones innovadoras, limpias y

eficientes desde el punto de vista energético para un futuro
mejor.
76
VISIÓN DE LA EMPRESA
Ser la empresa número uno en proporcionar soluciones

del punto de vista energético a nivel internacional.
CULTURA DE LA EMPRESA
- Innovación: Crear nuevas ideas y llevarlas al éxito con

eficacia.
- Calidad: Ofrecer constantemente un rendimiento
superior y perseguir la mejora todo el tiempo
- Agilidad: Identificar las tendencias emergentes y
actuar rápidamente para capturar nuevas
oportunidades.
- Trabajo en equipo: Aprovechar al máximo las redes de
valor global y colaborar para lograr objetivos comunes.
- La satisfacción del cliente: Anticipar las necesidades del
cliente y superar las expectativas.
HERRAMIENTAS:
REUNIÓN DE LA VISIÓN DEL PROYECTO
En esta reunión con el Stakeholder(s), el Product Owner,

y el Scrum Master. Esta ayuda a identificar el contexto
empresarial, los requerimientos de negocio y las expectativas
de los stakeholders a fin de desarrollar una declaración de la
visión del proyecto eficaz (SCRUMstudy, 2017).
En la implementación de un aplicativo móvil para

automatizar la elaboración de evidencias para la presente
tesis la reunión se da con la máxima autoridad de una
Asociación, la Asamblea General de Asociados de Delta
(SCRUMstudy, 2017).
77
Esta reunión se da de manera informal con los miembros
el viernes 10 de agosto de 2018 (SCRUMstudy, 2017).
SALIDAS:
PRODUCT OWNER IDENTIFICADO
El Product Owner es la persona responsable de lograr el

máximo valor empresarial para el proyecto. También está a cargo
de la articulación de requerimientos por parte de los clientes y de
mantener la justificación del negocio para el proyecto. El Product
Owner representa la voz del cliente.
En este caso el rol de Product Owner cae sobre el Sr. Rodrigo

Vidal Paucarima Navarro, esta decisión fue tomada ya que este
señor posee habilidades de comunicación y de negociació.
Además, tiene una gran variedad de contactos los cuales pueden
ser de gran ayuda conforme avance el proyecto.
DECLARACIÓN DE LA VISION DEL PROYECTO
Aquí se llegan de manera informal a los siguientes puntos:
- Generar un Software funcional para la empresa Delta

Electronics.
- Satisfacer todas las necesidades requeridas por los
Stakeholder.
- El aplicativo móvil debe ser amigable y manejable para los
usuarios de campo, los cuales se encargarán de tomar fotos
en provincia para generar las evidencias
- Tener un compromiso sólido para el desarrollo del aplicativo
móvil.
II) Identificando al Scrum Master y Stakeholder
ENTRADAS:
78
Product Owner y la reunión del proyecto.
HERRAMIENTAS:
CRITERIOS DE SELECCIÓN DE SCRUM MASTER
- Habilidades para resolver problemas: Es uno de los principales

criterios a considerar al seleccionar al Scrum Master. El Scrum
Master debe tener las habilidades y la experiencia necesaria
para ayudar a eliminar cualquier impedimento que enfrente el
Equipo Scrum (SCRUMstudy, 2017).
- Disponibilidad: El Scrum Master debe estar disponible para
programar, supervisar y organizar varias reuniones, incluyendo
la reunión de planificación de del lanzamiento, el Daily Standup
y otras reuniones relacionadas al sprint (SCRUMstudy, 2017).
- Compromiso: El Scrum Master debe estar muy comprometido a
fin de asegurar que el Equipo Scrum cuente con un ambiente
laboral conductivo para garantizar la entrega exitosa de
proyectos Scrum (SCRUMstudy, 2017).
- Estilo de liderazgo servicial (SCRUMstudy, 2017).
SELECCIÓN DE STAKEHOLDERS
En la identificación del stakeholder es importante recordar

que estos incluyen a todos los clientes, usuarios y patrocinadores,
quienes a menudo interactúan con el Product Owner, Scrum Master
y Equipo Scrum para proveer entradas y facilitar la creación de los
79
productos del proyecto. Los stakeholders influyen en el proyecto a
lo largo de su ciclo de vida.
SALIDAS:
SCRUM MASTER IDENTIFICADO
Para la presente tesis el cargo de Scrum Master será

asignado al Ing. Daniel Cóndor García que cumple exactamente
con las habilidades mencionadas en la herramienta de Criterios de
Selección de Scrum Master.
STAKEHOLDER IDENTIFICADO
Para la presente el stakeholder identificado será el Sr.

Oscar Ybargüen Ignacio que cumple exactamente con las
habilidades mencionadas en la herramienta de Selección de
Stakeholders.
III) Formar equipos Scrum
ENTRADAS:
Product Owner, Scrum Master y la reunión de la visión de

proyecto.
80
HERRAMIENTAS:
SELECCIÓN DEL EQUIPO SCRUM
El Equipo Scrum es la base para un proyecto de Scrum y

el miembro o los miembros son responsables del éxito en el
cumplimiento de los entregables. Él o los miembros del Equipo
Scrum son generalistas y especialistas, porque están provistos con
conocimiento en diversos campos y son expertos en mínimamente
uno. Las habilidades interpersonales son vitales en equipos auto –
organizados, estas deben estar a nivel personal. Los miembros
ideales del Equipo Scrum tienen ideales independientes, se
motivan a si mismo, gran enfoque en el cliente y poseen un alto
sentido de responsabilidad y colaboración. El equipo fomenta un
ambiente de reflexión independiente y toma decisiones para
aportar mayor valor al producto. (SCRUMstudy, 2017).
SALIDAS:
EQUIPO SCRUM IDENTIFICADO
En la presente tesis el Equipo Scrum está conformado por

mi persona Sr.Jhensson Frank Ayma Flores y el Sr. Ricardo Levi
Guevara Alvarado los cuales nos encargaremos del desarrollo e
implementación del aplicativo móvil para automatizar la elaboración
de evidencias de los servicios prestados por el área de
telecomunicaciones en la empresa Delta Electronics.
IV) Crear el backlog priorizado del producto
ENTRADAS:
El equipo Scrum principal, las historias de usuario y los

prototipos.
81
HERRAMIENTAS:
MÉTODOS DE PRIORIZACIÓN SIMPLE DE HISTORIAS DE

USUARIO
Para la priorización se utilizó el método de los 100 puntos

que consiste en dar 100 puntos a los stakeholder para que sean
repartidos entre las historias de usuario (SCRUMstudy, 2017).
Tabla 7: Priorización de las Historias de Usuario del Sprint 2
ID HISTORIA DE USUARIO PUNTAJE
1 Mantenimiento de los usuarios 15
2 Mantenimiento de los nodos 20
El sistema debe convertir las

fotos y los datos brindados en
3 30
un PDF con 5 diferentes
estructuras.
Elaboración: Propia
SALIDAS:
BACKLOG PRIORIZADO DEL PRODUCTO
Es un solo documento de requisitos que define el alcance

del proyecto, proporcionando una lista de prioridades de las
características del producto o servicio a ser entregado por el
82
Figura 26: Backlog Priorizado del Producto del Sprint 2
IV) Realizar la planificación del lanzamiento
ENTRADAS:
El equipo Scrum principal, stakeholder y la declaración de la

visión del proyecto.
HERRAMIENTAS:
SESIONES DE PLANIFICACION DE LANZAMIENTO
Se llegó a un acuerdo con el stakeholder sobre los tiempos

aproximados del proyecto el cual debería acabar en el plazo de 4
meses y se determinó que serán 2 sprints los cuáles durarán 2
meses cada uno.
83
SALIDAS:
CRONOGRAMA DE PLANIFICACIÓN DE LANZAMIENTO SPRINT 1
Tabla 8: Cronograma de planificación de lanzamiento del Sprint 1
Semana Semana 2, 3, Semana Semana

1 4, 5 Y 6 7 8
Difundir la historias de usuario actualizadas x
Estimación de las historias de usuario x
Comprometer las historias de usuario x
Estimar las tareas x
Crear el Sprint Backlog x
Avances y culminación del entregable x
Daily Standup x
Refinación de Backlog priorizado x
Demostración y validación de Sprint x
Retrospectiva del sprint 1 x
Envío del entregable x
La duración del Sprint es de 2 meses
El trabajo diario será de 8 horas diarias de lunes a sábado

que hacen un total de 48 horas semanales u 192 horas
mensuales.
Si se observa el cronograma veremos que hasta la

creación del Sprint Backlog se usarán 48 horas laborales o 1
semana.
En las semanas 2, 3, 4, 5 y 6 se utilizarán 240 horas para

los avances y culminación del entregable, en este lapso de tiempo
se realizará el Daily Standup todos los días por 15 minutos.
En la semana 7 se realizará la refinación del Backlog

priorizado, la demostración y la validación del sprint.
84
Finalmente, en la semana 8 se realizará la retrospectiva del
sprint 1 y el envío del entregable.
3.2.2 Fase de planificación
I) Crear historias de usuario
ENTRADAS:
Equipo Scrum, Backlog Priorizado del Producto, criterios de

terminado y prototipos descritos anteriormente.
HERRAMIENTAS:
EXPERIENCIA EN REDACCIÓN DE HISTORIAS DE USUARIO
La experiencia que demuestro es por haber concluido con

éxito la asignatura de Ingeniería de Software en la UNTELS
además de haber logrado conseguir certificación en la metodología
a través de la página Scrum Study.
Figura 27: Certificado de Scrum Study
85
Fuente: Scrum Study
SALIDAS:
HISTORIAS DE USUARIO + CRITERIOS DE ACEPTACIÓN
Las historias de usuario pueden entenderse como los requerimientos de

la solución de negocios, mientras que los criterios de aceptación son
requerimientos de más bajo nivel los cuales sirven para la aprobación o
desaprobación futura de las historias de usuario (SCRUMstudy, 2017).
Tabla 9: Historias de Usuario con criterios de aceptación del Sprint 2
ID HISTORIA DE USUARIO CRITERIOS

El usuario debe registrarse con la
contraseña encriptada - md5.
Mantenimiento de los
1 El usuario "coordinador" debe
usuarios
poseer los privilegios de registrar,
editar y eliminar un usuario.
El usuario "coordinador" debe
poseer los privilegios de registrar,
editar y eliminar un nodo.
Mantenimiento de los Al registrar un nodo es obligatorio

2 rellenar estos campos: Código de
nodos
localidad, clase de nodo, tipo de
nodo, región, provincia, distrito,
localidad, latitud, longitud,
ventilación y cadena de baterías.
El sistema debe Para tomar cualquier foto es

convertir las fotos y los obligatorio tener activado el GPS
3 datos brindados en un
PDF con 5 diferentes Las fotografías tomadas deben
estructuras. tener el rotulado: Nombre de
proyecto, GPS y Fecha.
86
II) Estimar historias de usuario
ENTRADAS:
Equipo Principal Scrum y las historias de usuario.
HERRAMIENTAS:
REUNIONES DE PLANIFICACIÓN DE SPRINT
La estimación la realizamos tomando en cuenta el esfuerzo

que demanda el cumplimiento de la historia de usuario.
MÉTODOS DE ESTIMACIÓN
El método de estimación usado es el planning póker

tomando en cuenta el nivel de esfuerzo.
SALIDAS:
HISTORIAS DE USUARIO ESTIMADAS
Tabla 10: Historias de usuario estimadas del Sprint 2

1 5
usuarios
2 8
nodos
El sistema debe
convertir las fotos y
los datos brindados
3 13
en un PDF con 5
diferentes
estructuras.
87
III) Comprometer historias de usuario
ENTRADAS:
Equipo Principal Scrum, las historias de usuario estimadas y

la duración del sprint.
HERRAMIENTAS:
REUNIONES DE PLANIFICACIÓN DE TAREAS
En la reunión de planificación de tareas, el Equipo Scrum se

reunió con los stakeholder para planificar el trabajo a realizarse en
el sprint, la reunión concluyó con el compromiso del equipo Scrum,
para entregar un subconjunto de historias de usuario del Backlog
Priorizado del Producto en el sprint, se acordó que las historias de
usuario serian desarrollados en orden de priorización.
SALIDAS:
HISTORIAS DE USUARIO COMPROMETIDAS
Para el primer sprint nos comprometeremos a realizar las

siguientes historias de usuario, esto debido a que la historia de
usuario más valorizada depende de todas estas para su
realización.
Tabla 11: Historias de usuario comprometidas del Sprint 1

1 5
usuarios
2 8
nodos
El sistema debe convertir
las fotos y los datos
3 13
brindados en un PDF con
5 diferentes estructuras.
88
IV) Identificar tareas
ENTRADAS:
Equipo Principal Scrum y las historias de usuario

comprometidas.
HERRAMIENTAS:
REUNIONES DE PLANIFICACIÓN DEL SPRINT
Esto dio cabida a reflexionar sobre las tareas a realizar para

el cumplir de los criterios de aceptación de cada historia de usuario
comprometida.
DESCOMPOSICIÓN
Esta técnica consiste en la segmentación de las historias de

usuario con el fin de crear tareas de corte más específico para un
mejor desarrollo de la solución.
SALIDAS:
LISTA DE TAREAS
Es un conjunto de actividades por cada historia de usuario

que se va a realizar el Sprint 1.
89
Figura 28: Lista de tareas (I parte) Sprint 2
90
Figura 29: Lista de tareas (II parte) Sprint 2
91
V) Estimar tareas
ENTRADAS:
Equipo Principal Scrum y la lista de tareas y los criterios de

aceptación.
HERRAMIENTAS:
CRITERIOS DE ESTIMACIÓN

DESCOMPOSICIÓN
El Equipo Scrum escoge el método de Puño de Cinco, por

ser un mecanismo sencillo y rápido para este método cada
miembro del Equipo Scrum vota en una escala del 1 al 5 utilizando
los dedos de las manos. Así tomaremos cada dedo como una hora
de trabajo.
SALIDAS:
EFFORT ESTIMATED TASK LIST

92
Figura 30: Effort Estimated Task List (I parte) Sprint 1
93
Figura 31: Effort Estimated Task List (II parte) Sprint 1
94
VI) Crear el Sprint Backlog
ENTRADAS:
Equipo Principal Scrum, Effort Estimated Task List y la

duración del Sprint.
HERRAMIENTAS:
REUNIÓN DE PLANIFICACIÓN DEL SPRINT
El Equipo Scrum elabora también el Sprint Backlog y el

Sprint Burndown Chart utilizando las historias de usuario y la lista
de tareas antes mencionada durante las reuniones de planificación
del Sprint.
SALIDAS:
SPRINT BACKLOG
95
3.2.3 Fase de implementación
I) Crear entregables
ENTRADAS:
Equipo Scrum, Sprint Backlog y Scrumboard.
HERRAMIENTAS:
EXPERIENCIA DEL EQUIPO
Fuente: Scrum Study
SALIDAS:
ENTREGABLES DEL SPRINT
96
Figura 34: Base de datos realizada en MYSQL
97
Figura 35: Tabla usuario en la BBDD
98
Figura 36: Tabla nodo en la BBDD
99
Figura 37: Tabla indicador en la BBDD
Figura 38: Tabla foto en la BBDD
100
101
102
Figura 41: Interfaz para visualizar los indicadores
103
Figura 42: Interfaz para crear nodos
104
Figura 43: Interfaz para editar y eliminar nodos
Figura 44: Interfaz para crear usuarios
105
Figura 45: Interfaz para editar y eliminar usuarios
SCRUMBOARD ACTUALIZADO
Figura 46: Scrumboard actualizado en Trello del Sprint 1
106
3.2.4 Fase de revisión y retrospectiva
I) Demostrar y validar el sprint
ENTRADAS:
Equipo Principal Scrum, entregable del sprint, sprint backlog,

criterios de terminado y los criterios de aceptación de las historias
de usuario.
HERRAMIENTAS:
REUNIONES DE REVISIÓN DE SPRINT
Posterior al culminado del entregable, este fue autoevaluado

con los criterios de aceptación de las historias de usuario
pertinentes, determinando así si es adecuado para ser entregado
al stakeholder.
Figura 47: Criterios de aceptación de la HU Mantenimiento de los

usuarios
107
El criterio de que el usuario “coordinador” deba poseer los privilegios
registrar, editar y eliminar un usuario se plasmaron en las siguientes
interfaces
Figura 48: Interfaz para crear usuarios
Figura 49: Interfaz para editar y eliminar usuarios
108
Figura 50: Criterios de aceptación de la HU Mantenimiento de los
nodos
El criterio de que el usuario “coordinador” deba poseer los privilegios

registrar, editar y eliminar un nodo se plasmaron en las siguientes interfaces
Figura 51: Interfaz para crear nodos
109
Figura 52: Interfaz para editar y eliminar nodos
ENTREGABLES ACEPTADOS
El entregable presentado fue aceptado por el stakeholder y

el Product Owner.
II) Retrospectiva del Sprint
ENTRADAS:
Scrum Master, equipo Scrum, entregable aceptado.
HERRAMIENTAS:
REUNIÓN DE RETROSPECTIVA DEL SPRINT
Lo que se debe mantener en el proyecto es la actitud positiva

y gusto por el tema, el uso del trello y el constante aprendizaje.
Lo que se debe mejorar es el cumplimiento estándar de las

horas para evitar el sobrecargo en los últimos días del sprint.
110
Un impedimento para cumplir los objetivos del proyecto es el
tiempo que invierte el programador en otras actividades.
SALIDAS:
AGREED ACTIONABLE IMPROVEMENTS
Tabla 6: Agreed Actionable Improvements
MEJORES PRÁCTICAS
ID
ACEPTABLES
Uso de Trello para la
1
transparencia.
2 Actitud Positiva.
3 Constante aprendizaje.
111
REFERENCIAS BIBLIOGRÁFICAS
Alvarez, M. A. (2001). Qué es PHP. Obtenido de Desarrolloweb:

https://www.desarrolloweb.com/articulos/392.php
Alvarez, M. A. (2014). Composer gestor de dependencias para PHP. Obtenido de

Desarrolloweb: https://desarrolloweb.com/articulos/composer-gestor-
dependencias-para-php.html
Guevara, A. (2016). ¿Que és Java y por qué aprenderlo? Obtenido de DevCode:

https://devcode.la/blog/que-es-java/
Lázaro, D. (2018). Introducción a los Web Services. Obtenido de Diego Lázaro:

https://diego.com.es/introduccion-a-los-web-services
Martínez, J. (2017). Qué es la Automatización. Obtenido de Seas:

https://www.seas.es/blog/automatizacion/que-es-la-automatizacion/
Nieto, A. (2011). ¿Qué es Android? Obtenido de Xataka Android:

https://www.xatakandroid.com/sistema-operativo/que-es-android
Qode. (2012). ¿Que es una App? Obtenido de Qode blog: http://qode.pro/blog/que-

es-una-app/
Revelo, J. (2015). Realizar Peticiones Http Con La Librería Volley En Android.

Obtenido de Hermosa Programación:
http://www.hermosaprogramacion.com/2015/02/android-volley-peticiones-
http/
Rouse, M. (2015). MySQL. Obtenido de SearchDataCenter en Español:

https://searchdatacenter.techtarget.com/es/definicion/MySQL
SCRUMstudy. (2017). Una guía para el Cuerpo de Conocimiento de Scrum (Guía

SBOK) - 3ra Edición. Avondale.
Vergara, J. M. (2016). Qué es y qué nos ofrece la herramienta phpMyAdmin.

Obtenido de Coriaweb: https://www.coriaweb.hosting/nos-ofrece-
phpmyadmin/
112

Seminario de Tesis

Cargado por

Información del documento

Título original

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

Seminario de Tesis

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL TECNOLÓGICA DE LIMA SUR

FACULTAD DE INGENIERÍA Y GESTIÓN

CARRERA PROFESIONAL DE INGENIERÍA DE SISTEMAS

IMPLEMENTACIÓN DE UN APLICATIVO MÓVIL PARA AUTOMATIZAR LA

PRESENTADO POR EL BACHILLER:

AYMA FLORES JHENSSON FRANK

PARA OPTAR EL TÍTULO DE INGENIERO DE SISTEMAS

A mis padres, Walter y Beatriz, por su apoyo

A mi hermano Walter por siempre apoyarme

- A mi hermano Walter por la ayuda económica e impulsarme a seguir creciendo

- Agradezco a los docentes Zapillado Huanco Oscar Adrian, Frank Edmundo

1. CAPÍTULO I PLANTEAMIENTO DEL PROBLEMA ............................ 9

1.1 Descripción de la Realidad Problemática. .......................................... 9

2. CAPÍTULO II MARCO TEÓRICO ....................................................... 15

2.1 Antecedentes .................................................................................... 15

3.1 Sprint 1 ............................................................................................. 41

En la actualidad las grandes empresas están obligadas a automatizar sus

No solo las grandes empresas están obligadas a automatizar sus procesos,

Siendo conscientes de esta gran necesidad mi equipo y yo nos hemos

La empresa mencionada se encarga de brindar suministros, servicios de

La estructura del trabajo está compuesta por 2 capítulos principales. El

La conclusión del proyecto dará muestra de resultados a los que se llegó

PLANTEAMIENTO DEL PROBLEMA

1.1 Descripción de la Realidad Problemática.

En el mundo moderno automatizar los procesos se ha vuelto una

La empresa Delta Electronics es una empresa ubicada en la Calle

Para el desarrollo de sus servicios es necesario realizar el proceso de

Es por ello que la presente tesis busca implementar un aplicativo móvil

Delta Electronics es una empresa que brinda suministros, servicios de

La empresa siempre ha llevado sus servicios a diferentes partes del

La empresa distribuye las labores de la siguiente manera: instalador,

El flujo de trabajo para que un reporte se diga “finalizado” empieza

Cuando el instalador haya terminado su reporte, éste será enviado al

Se debe tomar en cuenta que la mayor parte de la realización del

Por lo tanto, para que la empresa Delta Electronics siga mejorando,

1.3 Delimitación de la Investigación

Se realizará en la empresa Delta Electronics ubicada en la Av.

Inicio: Agosto de 2018.

Fin: Diciembre de 2018.

Aplicación móvil. Es una aplicación de software que se instala

Automatización. La palabra automatización engloba un

1.4 Formulación del Problema

1.4.1 Problema General

¿De qué manera la implementación de un aplicativo móvil

1.4.2 Problemas Específicos.

- ¿De qué manera la implementación de un aplicativo móvil

- ¿De qué manera la implementación de un aplicativo móvil

1.5.1 Objetivo General

Implementar un aplicativo móvil para automatizar la

1.5.2 Objetivos Específicos

- Implementar un aplicativo móvil para reducir el tiempo en el

- Implementar un aplicativo móvil para ahorrar costos en el

- Implementar un aplicativo móvil para mejorar el nivel de

1.6.1 Hipótesis General

Si se Implementa un aplicativo móvil se podrá

1.6.2 Hipótesis Específicas

- Si se implementa un aplicativo móvil se podrá reducir el

- Si se implementa un aplicativo móvil se podrá ahorrar

- Si se implementa un aplicativo móvil se podrá mejorar el

A nivel nacional e internacional se han realizado diferentes trabajos

“SISTEMA AUTOMATIZADO PARA LA GESTIÓN DEL PROGRAMA

En resumen, realizaron que el programa de Control Sanitario

Finalmente concluyeron que una visión panorámica del Sistema