UNIVERSIDAD SALESIANA DE BOLIVIA

CARRERA DE INGENIERÍA DE SISTEMAS

TESIS DE GRADO

Para obtener el Grado Académico de

Licenciatura en Ingeniería de Sistemas

“APLICACIÓN MÓVIL COMO HERRAMIENTA DIDÁCTICA DE

APRENDIZAJE PARA LA ENSEÑANZA DE MULTIPLICACIÓN DE 1
A 3 DÍGITOS PARA LOS NIÑOS DE TERCERO DE PRIMARIA”

Postulante: Rudy diego Dara Gonzales

Docente guía: Ing. Denise Cleofe Aguilar Aliaga

LA PAZ-BOLIVIA
2022
 INDICE ESPECÍFICO

CAPÍTULO I GENERALIDADES.............................................................................6
1.1 Introducción..................................................................................................6

1.2. Antecedentes.................................................................................................7

1.2.1. Antecedentes internacionales.....................................................................7

1.2.2. Antecedentes nacionales........................................................................7

1.3. Justificación....................................................................................................8

1.3.1. Justificación técnica.................................................................................8

1.3.2. Justificación económica...........................................................................8

1.3.3. Justificación social...................................................................................8

1.4. Planteamiento del problema..........................................................................8

1.4.1. Descripción del problema........................................................................9

1.4.2. Problema principal...................................................................................9

1.4.3. Problemas secundarios...........................................................................9

1.5. Objetivos......................................................................................................10

1.5.1. Objetivo principal...................................................................................10

1.5.2. Objetivos específicos.............................................................................10

1.6. Hipótesis...................................................................................................10

1.6.1. Definición y operacionalización de variables........................................11

CAPÍTULO II MARCO TEÓRICO..........................................................................13

2.1. Proceso de enseñanza y aprendizaje..........................................................13

2.2. Educación regular en Bolivia.......................................................................13

2.2.1. Programa de educación regular primaria referente a las matemáticas 13

2
 1.1.1 Cognoscitivas......................................................................................13

1.2 Constructivista............................................................................................14

2.3. Tecnologías de la información y comunicación como herramienta didáctica

de enseñanza..........................................................................................................15

2.3.1. Multimedia...........................................................................................15

2.4. Ingeniería de aplicaciones móviles..............................................................15

2.4.1. Aplicación móvil....................................................................................16

2.4.2. Modelo de proceso de software............................................................16

2.4.3. Desarrollo ágil........................................................................................18

2.4.4. Metodología para el Desarrollo de Aplicaciones Móviles.....................19

2.5. Método de estimación de costos Cocomo II................................................21

2.5.1. Estimación de esfuerzo.........................................................................22

2.5.1. Estimación del cronograma.............................................................24

2.5.4. Métricas del software.............................................................................24

1.2.1 Puntos objeto......................................................................................25

2.6. Pruebas técnicas de software......................................................................25

2.6.2. Prueba de caja blanca.....................................................................25

1.2.2 Prueba de caja negra..........................................................................26

2.7. Modelo de calidad de software ISO/IEC 25000...........................................27

2.8. Lenguade de Modelado Unificado...............................................................27

2.8.1. Historia de UML...............................................................................27

2.8.2. Diagramas UML....................................................................................29

2.8. Herramientas para desarrollo de aplicaciones móviles...............................31

2.8.1. Lenguaje de programación Java..............................................................31

3
 2.8.2. Android Studio..........................................................................................31

2.8.3. Unity..........................................................................................................32

2.8.4. Lenguaje de programación C Sharp.........................................................33

2.8.5. Visual Studio Code................................................................................34

CAPITULO III DISEÑO METODOLOGICO...........................................................35

3.1. Diseño metodológico..............................................................................35

3.1.1. Delimitación temporal y espacial.....................................................35

3.1.2. Materiales.........................................................................................35

3.2. Metodología de la investigación.............................................................35

3.2.1. Metodología.....................................................................................35

3.2.2. Criterios de inclusión Criterios de exclusión....................................36

3.3. Técnicas de recolección de datos..........................................................36

3.4. Técnicas..................................................................................................36

3.4.1. Técnicas de adquisición de información..........................................36

3.4.2. Lectura del material bibliográfico.....................................................36

3.4.3. La documentación............................................................................36

3.4.4. Cuestionario.....................................................................................36

3.4.5. Encuestas........................................................................................37

3.4.6. Observación.....................................................................................37

3.5. Parámetros de evaluación......................................................................37

3.5.1. * Procesamiento y análisis de datos................................................37

3.5.2. * Análisis estadístico (Diseño experimental)...................................37

CAPITULO IV INGENIERÍA DE LA APLICACIÓN MOVIL....................................38

4.1. Análisis de requerimientos...........................................................................38

4
 4.1.1. Requerimientos funcionales..................................................................38

4.1.2. Requerimientos no funcionales.............................................................38

4.2. Diseño..........................................................................................................39

4.2.1. Modelo de uso.......................................................................................40

4.2.2. Modelo estructural.................................................................................42

4.2.3. Modelo de interacción...........................................................................43

4.2.4. Modelo de comportamiento...................................................................43

4.2.5. Modelo de implementación....................................................................43

4.2.6. Maquetación de interfaces gráficas.......................................................43

4.3. Desarrollo.....................................................................................................46

CAPITULO V RESULTADOS Y DISCUSIONES...................................................49

5.1. RESULTADOS.............................................................................................49

5.2. DISCUSIONES............................................................................................49

CAPITULO VI CONCLUSIONES Y RECOMENDACIONES.................................50

6.1. Conclusiones...................................................................................................50
6.2. Recomendaciones...........................................................................................50
REFERENCIAS BIBLIOGRÁFICAS.......................................................................51
ANEXOS.................................................................................................................53

5
CAPÍTULO I GENERALIDADES
1.1 Introducción
La educación en Bolivia ha ido evolucionando al pasar el tiempo, iniciándose
en el ministerio de planeamiento y coordinación siendo ellos los que crearon el
equipo técnico de apoyo a la reforma educativa.
El sistema educativo a lo largo de su historia ha ido evolucionando haciendo
cambios significativos para la misma, muestra clara de lo dicho es el cambio
que se dio del sistema educativo conductista al sistema educativo
constructivista.
Anteriormente se trabajaba con el enfoque conductista el cual se
concentraba en la conducta real, basando sus conclusiones en la observación
de las manifestaciones del estudiante. A diferencia del constructivismo que
orienta al estudiante a ser responsable de su propio aprendizaje, sin depender
necesaria o exclusivamente de la intervención del profesor, el auto control del
aprendizaje es una condición necesaria para la motivación a indagar nuevos
conocimientos.
Uno de los problemas que se presenta con mayor frecuencia en la
educación, sobre todo en el nivel primario es la existencia de un elevado
número de estudiantes que fracasan en el área de matemáticas, por las
dificultades en el manejo y resolución de las operaciones básicas de la
aritmética. Se afirma que las enseñanzas de las matemáticas se considera
importante porque desarrolla el pensar cuantitativo, mejora la inteligencia, el
juicio espontáneo el razonamiento lógico, sin embargo en los últimos años se
ve que la enseñanza de las matemáticas no es adecuada puesto que sigue
siendo un aprendizaje mecánico y repetitivo, memorístico por ello hay que crear
nuevas formas de aprendizaje que genere en los estudiantes mayor capacidad
de análisis y razonamiento. Sin embargo para dicho aprendizaje es necesario
previa organización de los pensamientos además de desarrollarse dentro del
contexto de los niños impartiéndose de forma grupal para que los estudiantes
logren compartir sus conocimientos.

6
 En el campo de la docencia, las transformaciones tecnológicas podrían
llegar a la necesidad y sobre todo; la posibilidad de renovar las técnicas de
enseñanza y aprendizaje el tipo de material del profesor a usar en las clases.
Las condiciones actuales proporcionan contar con herramientas de apoyo al
proceso educativo para que exista una enseñanza más dinámica, llena de
estímulos para los estudiantes, convirtiéndose el computador de esta manera
en una herramienta de apoyo al desarrollo de enseñanza-aprendizaje de los
niños.
Se desarrolla el presente proyecto tomando en cuenta lo anterior mente
mencionado y tomando en cuenta la importancia de la multiplicación se
desarrollará una aplicación móvil para alcanzar nuevas inquietudes en las
sociedades y es así como se desarrolla el presente proyecto

1.2. Antecedentes
1.2.1. Antecedentes internacionales
En trabajo de grado titulado “software educativo aprende con Erika, en los
procesos de aprendizaje de las cuatro operaciones basicas del area de
matemáticas, en los estudiantes del grado tercero de la institución educativa
agropecuaria Rio Sanquianga del Municipio de Oyala Herrera” presentada en la
Universidad Santo Tomás, Bogotá, se analiza cómo el software educativo
Aprende con Erika aporta a los niños de grado tercero en el proceso de
aprendizaje de las cuatro operaciones básicas del área de matemáticas
(Anchico, 2018). La inclusión de las TIC al proceso educativo permite
transformar de manera positiva la práctica docente.
En el proyecto titulado “Desarrollo de un recurso digital que facilite la
enseñanza de las tablas de multiplicar en el grado tercero de la I.E. Pio XII,
corregimiento de Florencia, Samaná, Caldas” presentado en la Universidad de
Cartagena, Colombia, se busca que las prácticas educativas de dicha área del
conocimiento tenga un cambio innovador y significativo otorgando bases
sólidas con operaciones básicas de suma y multiplicación (Botero, Negrete &
Tabares, 2021).
1.2.2. Antecedentes nacionales
En la tesis titulada “Aplicación móvil para promover la educación en seguridad
vial en etapa escolar desarrollado en Android” presentada en la Universidad

7
Mayor de San Andrés, se construye una aplicación tipo juego desarrollado para
el desarrollo cognitivo en niños de edad escolar (). En esta tesis se utiliza el
framework CORONA SDK que permite programar juegos en Android de una
manera rápida y sencilla.
En la tesis titulada “Desarrollo de una aplicación móvil multiplataforma
utilizando un Sphero para la enseñanza de programación en niños” presentada
en la Universidad Mayor de San Andrés, se plantea implementar una aplicación
móvil que tiene como características un pseudo lenguaje de programación
capaz de manipular un Sphero para la enseñanza de programación (Rojas,
2015). En este trabajo se emplea la metodología Mobile - D para la ingeniería
de la aplicación móvil.
1.3. Justificación
1.3.1. Justificación técnica
El avance de la tecnología tanto en hardware y software, da a nuestra sociedad
más opciones de ponernos al día en cuanto a nuevas tecnologías, las
aplicaciones para internet diseñadas para ser más amigables a los usuarios
esto permitirá que los usuarios puedan interactuar desde un teléfono móvil
hasta una computadora.

1.3.2. Justificación económica

Puesto que el software educativo es de uso libre en su mayoría el desarrollo de
los programas educativos no tendrán coste elevado ya que no se hace pago de
licencias, ni tampoco se hará uso de máquinas de última tecnología, por lo que
esto ayudará a los padres de familia a ahorrar el costo de un libro, solo existirá
coste de producción de la aplicación móvil.

1.3.3. Justificación social

El proyecto tendrá un gran impacto social ya que ayudara a que los niños de
tercero de primaria puedan desarrollar sus capacidades con mayor facilidad,
esto ayudara a que el docente de la materia de matemática tenga una
herramienta de apoyo que le permita tener una mejor proyección para poder
ayudar a entender de una buena manera lo que es la multiplicación de varios
dígitos, además de lograr mayor efectividad en el proceso de enseñanza y

8
aprendizaje de la multiplicación haciendo que se desenvuelvan de manera
natural
1.4. Planteamiento del problema
1.4.1. Descripción del problema
Una vez realizado el análisis de la situación actual, se pudo evidenciar un
conjunto de problemas relacionados al proceso de enseñanza y aprendizaje de
la multiplicación en niños de tercero de primaria.
Dado que los estudiantes están acostumbrados a aprender la multiplicación
inicialmente con un método memorístico y repetitivo, es decir, repitiendo las
tablas de multiplicación de una cifra, luego tienen dificultades de resolver
problemas más complejos cuando se presentan ejercicios con más de una
cifra, generando frustración en ellos.
Por otra parte, existen limitaciones en el empleo de material didáctico en
clases, ya sea porque los docentes lo desconocen o bien el material escolar
según la malla curricular presenta solo métodos tradicionales, razón por la cual
estudiantes desconocen otros conceptos para aprender a multiplicar o pierden
el interés de aprender nuevos métodos, lo cual genera un bajo rendimiento en
la asignatura de matemáticas y ocasiona efectos negativos a largo plazo.
1.4.2. Problema principal
Luego de identificar algunas necesidades relacionadas al proceso de
enseñanza y aprendizaje de la multiplicación en niños de tercero de primaria y
haber efectuado el análisis de problemas para la presente tesis de grado
(Anexo A), se formula el problema principal de investigación de la siguiente
forma:

¿Cómo mejorar la eficiencia en el proceso enseñanza y aprendizaje de la

multiplicación de uno a tres dígitos en niños de tercero de primaria?

1.4.3. Problemas secundarios

● Uso de un método memorístico para aprender a multiplicar impide
desarrollar el razonamiento matemático.
● Utilización frecuente de métodos repetitivos para aprender a multiplicar
origina dificultades al resolver multiplicaciones de dos o más cifras.

9
 ● Las limitaciones en el empleo de material didáctico durante la
enseñanza de la multiplicación ocasionan perdida de interés.
● El desconocimiento de métodos alternativos de aprendizaje de la
multiplicación genera bajo rendimiento y desconocimiento de otros
conceptos matemáticos.
1.5. Objetivos
1.5.1. Objetivo principal
Desarrollar una aplicación móvil como herramienta didáctica para mejorar la
eficiencia en el proceso de enseñanza y aprendizaje de la multiplicación de uno
a tres dígitos en niños de tercero de primaria.

1.5.2. Objetivos específicos

● Describir el fundamento teórico, procedimientos, métodos y técnicas
relacionadas a la enseñanza de la multiplicación de uno a tres dígitos, y las
metodologías o herramientas que permitan plantear una solución adecuada.
● Diseñar la aplicación móvil con base a la metodología XP y el lenguaje
modelado UML que permit-a plasmar métodos didácticos de enseñanza de
la multiplicación de uno a tres dígitos.
● Desarrollar la aplicación móvil con base a métodos y herramientas de
ingeniería de software para facilitar el proceso de enseñanza y aprendizaje
identificado.
● Evaluar la aplicación móvil con estudiantes de tercero de primaria de una
unidad educativa, y a su vez aplicar las pruebas técnicas necesarias al
software para asegurar su calidad.
1.6. Hipótesis
La hipótesis de la presente investigación se plantea de la siguiente forma:
 La aplicación móvil como herramienta didáctica permite mejorar la eficiencia
en el proceso de enseñanza y aprendizaje de la multiplicación de uno a tres
dígitos en niños de tercero de primaria.
La demostración de la hipótesis se efectuará con base en la medición de los
indicadores identificados en cada variable de la hipótesis, lo que implica
estimar el resultado de la presente propuesta en los correspondientes ámbitos
involucrados en el proceso de enseñanza y aprendizaje de la multiplicación de
uno a tres dígitos.
10
1.6.1. Definición y operacionalización de variables
En la Tabla 1, se presenta la operacionalización de variables de hipótesis de la
presente investigación.
Tabla 1. Operacionalización de variables de hipótesis

Variable Definición Dimensión Indicadores Instrumento

conceptual

Proceso enseñ Proceso Métodos y Número de Cuestionarios

anza y mediante el técnicas de métodos de
aprendizaje de cual se enseñanza enseñanza de
la transmiten para transmitir la
multiplicación conocimientos conocimientos multiplicación
de uno a tres especiales o alternativos
dígitos en generales aplicados.
niños de sobre una
tercero de materia. Número de
primaria. recursos
didácticos
utilizados para
la enseñanza
de
multiplicación.

Grado de
aprendizaje
adquirido

Aplicación Herramienta Conjunto de Usabilidad del Pruebas

móvil como software cuyo algoritmos y software técnicas de
herramienta uso en elementos software
didáctica dispositivos visuales Accesibilidad
móviles disponibles en del software Cuestionarios
permite la un dispositivo de evaluación
interacción de móvil. Número de de calidad.
un estudiante métodos y
con el recursos
contenido de didácticos

11
 una materia utilizados

Fuente: Elaborado con base a (Gutiérrez, s.f.)

Variable dependiente
 Proceso enseñanza y aprendizaje de la multiplicación de uno a tres dígitos
en niños de tercero de primaria.
Variable independiente
 Aplicación móvil como herramienta didáctica.

12
CAPÍTULO II MARCO TEÓRICO
2.1. Proceso de enseñanza y aprendizaje
2.1.1. Enseñanza y aprendizaje de las matemáticas

2.2. Educación regular en Bolivia

Ley N° 070. Ley de la Educación “Avelino Siñani - Elizardo Pérez” Establece
que toda persona tiene derecho a recibir educación en todos los niveles de
manera universal, productiva, gratuita, integral e intercultural, sin
discriminación; que la educación constituye una función suprema y primera
responsabilidad financiera del Estado; y garantiza la participación social y
comunitaria de madres y padres de familia en el sistema educativo, por lo tanto
aprender comprende la adquisición y modificación de conocimientos, creencias,
conductas, habilidades, estrategias y actitudes. Exige capacidades lingüísticas,
cognoscitivas, motoras y sociales, y adopta muchas formas. En un nivel simple,
el niño aprende a sumar dos más dos, a reconocer imágenes u otros. En otra
situación más compleja, los estudiantes aprenden a solucionar extensos
problemas de divisiones, multiplicaciones, redactar trabajos de fin de curso,
montar en bicicleta y cooperar con los proyectos colectivos. Ninguna definición
de aprendizaje es aceptada por todos los teóricos, investigadores y
profesionales de la educación; y las que hay son numerosas y variadas, pues
existen desacuerdos acerca de la naturaleza precisa del aprendizaje. Estas
diferencias resultan latentes aún entre las mismas corrientes de aprendizaje.
2.2.1. Programa de educación regular primaria referente a las matemáticas
En general de todos los grados que se aprende multiplicación y luego en el
are
1.1.1 Cognoscitivas
En psicología y pedagogía se emplea este término en referencia a la
capacidad humana para aprender y asimilar conocimientos,  por su parte, se
enfoca en los procedimientos intelectuales y en las conductas que emanan de
estos procesos, Las capacidades cognitivas  se refieren a lo relacionado con el
procesamiento de la información, esto es la atención, percepción, memoria,
resolución de problemas, comprensión, establecimientos de analogías entre
otras, como Procedimiento lingüístico mediante el cual se crean palabras o

13
expresiones nuevas, o se transforman otras que ya existen, con el fin de
acomodarlas a un determinado modelo.
Fuente: la enseñanza de las matemáticas y las ntic. una estrategia de
formación permanente. Mariela sarmiento santana isbn: 978-84-690-8294-2 /
d.l: t.1625-2007.

1.2 Constructivista
El constructivismo educativo propone un paradigma en donde el proceso de
enseñanza se percibe y se lleva a cabo como un proceso dinámico,
participativo e interactivo del sujeto, de modo que el conocimiento sea una
auténtica construcción operada por la persona que aprende.
Es por ello que se debe aplicar nuevas situaciones de aprendizaje, contando
con sus experiencias previas se aplicará una nueva herramienta de
aprendizaje en el área de matemáticas (multiplicación de 1 a 3
dígitos),utilizando la multiplicación en diagonal En cada una de las sumas
por diagonales, si la cifra obtenida tiene dos dígitos, nos «llevaremos»
(«acarrearemos») las decenas a la siguiente diagonal (como hacemos en
la multiplicación o en la suma habitual), indicando únicamente las unidades.
Dibujando tablas según la cantidad que se va a multiplicar por ejemplo se
observa en la Tabla 2 la multiplicación de 234x322, y utilizando las diagonales
para sumarlas y así obtener el resultado igual a 75348.

14
Tabla 2. Multiplicación de dos números de tres cifras.

2.3. Tecnologías de la información y comunicación como herramienta

didáctica de enseñanza
2.3.1. Multimedia
Se utilizará los materiales didácticos multimedia que orientan y regulan el
proceso de enseñanza-aprendizaje de los estudiantes, mediante la
combinación de texto, color, gráficas, animaciones, video, sonido, en un mismo
entorno.

En el presente capítulo se detallan los fundamentos teóricos para el

desarrollo de la tesis de Grado, se considera que la parte teórica es pieza
fundamental para la obtención de un documento.
Es por esta razón que en el presente capitulo se abordará conceptos
vinculados con el desarrollo del proyecto, por ejemplo se mencionaran
conceptos de relacionados con el diseño de software. Las herramientas
utilizadas en el proyecto, se tiene al lenguaje de modelado unificado (UML)
utilizado para el modelado del proyecto, también el uso de la metodología XP
para el desarrollo del ciclo de desarrollo del proyecto también contemplara
aspectos principales de la programación java y entre otros.
2.4. Ingeniería de aplicaciones móviles

15
2.4.1. Aplicación móvil
Las aplicaciones móviles son herramientas de software escritas en distintos
lenguajes de programación destinados a ejecutarse en teléfono inteligentes, y
se caracterizan por ser útiles, fáciles de instalar y manejar (Calvo 2022). Por lo
general las aplicaciones requieren una conexión a Internet aunque no es
prescindible. Normalmente las aplicaciones se suelen descargar de grandes
tiendas virtuales como Appstore de Apple y PlayStore de Google.
Según Calvo (2022), las aplicaciones móviles se pueden clasificar según
diversos criterios, por ejemplo:
 Por los efectos psicológicos que pueden producir podemos distinguir entre
aplicaciones capacitadoras (aquellas que buscan fomentar la creatividad) y
las que generan dependencia (que limitan la capacidad de elección del
usuario)
 En función del contenido que ofrecen al usuario encontramos apps de
entretenimiento (juegos), de relación social (redes sociales como TikTok,
mensajería), de producción (aquellas usadas para resolver problemas de
manera inmediata), educativas o informativas (para transmitir información y
facilitar el conocimiento de los usuarios) y publicitarias (con fines
comerciales).
 Por cómo se pueden adquirir se dividen entre aplicaciones gratuitas, de
pago y freemium. Estas últimas actúan como híbrido entre las dos
anteriores, permitiendo al inicio su descarga gratuita pero si se requieren
funciones más avanzadas es obligatorio abonar una tarifa, ya sea puntual o
mediante suscripción.
 Por la edad mínima recomendada de uso, un criterio que marcan tanto
Google como Apple para diferenciar aquellas apps aptas para todos los
públicos o aquellas que tienen contenido no recomendado para menores de
edad.

2.4.2. Modelo de proceso de software

Un proceso de software es un conjunto de actividades, acciones, tareas y
resultados asociados que producen un producto software, cuya estructura
establece el fundamento para el proceso completo de la ingeniería de software
(Presman, 2010; Sommerville, 2005). Las actividades estructurales se dividen

16
en: comunicación planeación, modelado, construcción y despliegue, las cuales
también se conocen como ciclo de vida del software, y también están definidas
por un flujo de proceso, como ser: lineal, iterativo, evolutivo y en paralelo, cada
uno de acuerdo a un modelo de proceso.
Los modelos de proceso tienen la finalidad de poner orden en el caos del
desarrollo del software y se basan en algún enfoque o paradigma, como ser:
enfoque en cascada, desarrollo iterativo, y enfoque basado en componentes
(Pressman, 2010; Sommerville, 2005). Todos los modelos de proceso del
software pueden incluir las actividades estructurales, éstos se dividen en:
modelo de proceso en cascada, modelos de proceso incremental, modelos de
proceso evolutivo, modelos concurrentes, entre otros.
a) Modelo de la cascada, se aplica por lo general cuando los requerimientos se
comprenden bien desde la comunicación hasta el despliegue; y siguiere un
enfoque sistemático y secuencial para el desarrollo del software (Pressman,
2010). Una ilustración del modelo se presenta en la Figura 4.

b) Modelo de proceso incremental, se aplica por lo general cuando los

requerimientos iniciales del software están razonablemente bien definidos, pero
el alcance general del esfuerzo de desarrollo imposibilita un proceso lineal,
donde se dé la necesidad imperiosa de dar rápidamente cierta funcionalidad
limitada de software a los usuarios y aumentarla en entregas posteriores
(Pressman, 2010). Este modelo combina el flujo de proceso lineal para cada
incremento, y el flujo paralelo entre cada incremento de ser necesario.
c) Modelos de proceso evolutivo, se aplican por lo general cuando los
requerimientos del negocio y del producto cambian conforme avanza el
desarrollo, por tanto, se requieren iteraciones que permitan desarrollar
versiones cada vez más complejas del software (Pressman, 2010). Entre los
modelos que siguen un proceso evolutivo se puede mencionar al modelo del
prototipado y el modelo en espiral.

17
d) Modelos concurrentes, también llamada ingeniería concurrente, permite que
un equipo de software represente elementos iterativos y concurrentes de
cualquiera de los modelos de proceso anteriormente descritos (Pressman,
2010).
2.4.3. Desarrollo ágil
Según Pressman (2010), cualquier proceso del software se considera ágil si
aborda ciertas suposiciones clave acerca de la mayoría del software, como ser:
a) Es difícil determinar los requerimientos que persistirán y cuales cambiarán.
b) Para muchos tipos de software, el diseño y la construcción deben ejecutarse
de manera paralela, de modo que los modelos de diseño se prueban a medida
que se crean.
c) El análisis, el diseño, la construcción y las pruebas no son tan predecibles
como nos gustaría.
Dado que se presentan escenarios impredecibles, la adaptabilidad es una
característica clave para que un proceso de considere ágil. Según Pressman
(2010), se deben considerar doce principios propuestos por la Alianza Ágil para
alcanzar la agilidad en un proceso, estos son:
1. La prioridad más alta es satisfacer al cliente a través de la entrega pronta y
continua de software valioso.
2. Son bienvenidos los requerimientos cambiantes, aún en una etapa avanzada
del desarrollo.
3. Entregar con frecuencia software que funcione, de dos semanas a un par de
meses.
4. Las personas de negocios y los desarrolladores deben trabajar juntos, a
diario y durante todo el proyecto.
5. Hay que desarrollar los proyectos con individuos motivados.
6. El método más eficiente y eficaz para transmitir información a los integrantes
de un equipo de desarrollo es la conversación cara a cara.
7. La medida principal de avance es el software que funciona.
8. Los procesos ágiles promueven el desarrollo sostenible.
9. La atención continua a la excelencia técnica y el buen diseño mejora la
agilidad.
10. Es esencial la simplicidad.

18
11. Las mejores arquitecturas, requerimientos y diseños surgen de los equipos
con organización propia.
12. El equipo reflexiona a intervalos regulares sobre cómo ser eficaz para
después afinar y ajustar su comportamiento.
Asimismo, este autor afirma que no todo método de desarrollo ágil aplica estos
12 principios con igual intensidad.
Entre los métodos de desarrollo ágil que aplican los principios descritos
anteriormente, se tienen, por ejemplo: la programación extrema (XP), SCRUM,
el desarrollo adaptativo de software (DAS), KANBAN, método de desarrollo de
sistemas dinámicos (MDSD), Cristal, desarrollo impulsado por las
características
(DIC), desarrollo esbelto de software (DES), proceso unificado ágil (AUP), entre
otros (Pressman, 2010).
2.4.4. Metodología para el Desarrollo de Aplicaciones Móviles
El desarrollo de aplicaciones para proveer servicios móviles, difiere del
desarrollo de software tradicional en muchos aspectos, lo que provoca que las
metodologías usadas para estos entornos móviles, también difieran de las del
software clásico (Rahimian y Ramsin, 2008). Las características especiales de
los entornos móviles como la capacidad de los terminales, la portabilidad, la
movilidad del usuario, entre otros, exige nuevas tendencias para desarrollar
software móvil.
La Metodología para el Desarrollo de Aplicaciones Móviles (MDAM) se
fundamenta en la experiencia de investigaciones previas en aplicaciones
móviles, la evaluación del potencial de éxito para servicios de tercera
generación denominada 6M1, la ingeniería de software educativo con modelado
orientado a objetos, y principalmente en los valores de las metodologías ágiles
(Gasca, Camargo y Medina, 2013). Según este autor, de las metodologías
ágiles se heredan los conceptos inmersos en cuatro postulados del manifiesto
ágil, como ser:
 Desarrollar software que funciona más que conseguir buena
documentación.

1
La 6 M’s debe su nombre a los seis atributos que se miden para evaluar el éxito del
servicio propuesto: Movement (Movimiento), Moment (Momento), Me (Yo), Multi-user
(Multiusuario), Money (Dinero) y Machines (Máquinas) (Ahonen, Barret y Golding, 2002).

19
 La respuesta ante el cambio es más importante que el seguimiento de un
plan.
 Colaboración con el cliente sobre negociación contractual.
 Individuos e interacciones sobre procesos y herramientas.
La metodología MDAM se encuentra enmarcada en un proceso iterativo
incremental de cinco fases (Gasca, Camargo y Medina, 2013), como se
muestra en la Figura (3), las cuales se describen a continuación:
Figura 3 Fases de la metodología MDAM

Fuente: (Gasca, Camargo y Medina, 2013)

a) Análisis
Etapa donde se analizan las peticiones o requerimientos de las personas
o la entidad para la cual se desarrolla la aplicación móvil (Gasca, Camargo y
Medina, 2013). El propósito es definir las características del mundo o entorno
de la aplicación. En esta etapa se realizan al menos dos tareas que son: la
obtención de los requerimientos y la clasificación de requerimientos.
b) Diseño
El objetivo de esta etapa es plasmar el pensamiento de la solución
mediante diagramas o esquemas, considerando la mejor alternativa al integrar
los aspectos técnicos, funcionales, sociales y económicos (Gasca, Camargo y
Medina). A esta etapa se retorna si no se obtiene lo deseado en la etapa de
pruebas. Las actividades principales de esta etapa es la de definir escenarios,
estructurar el software, definir tiempos y asignar recursos. Además, se deben

20
utilizar algunos diagramas del Lenguaje de Modelado Unificado (UML). Para
esto, Gasca, Camargo y Medina (2013) proponen una equivalencia de posibles
diagramas para el desarrollo, como se muestra en la Figura 4.
Figura 4. Posibles diagramas para el desarrollo de aplicaciones móviles

Fuente: (Gasca, Camargo y Medina, 2013)

c) Desarrollo
En esta etapa se debe plasmar el diseño en un producto software, donde se
realizan actividades, como ser: codificar la aplicación móvil, documentar el
código, y codificar las ayudas (Gasca, Camargo y Medina, 2013).
d) Pruebas
Gasca, Camargo y Medina (2013), indican que el objetivo de esta etapa
es la verificación del funcionamiento de la aplicación en diferentes escenarios y
condiciones, para lo cual se realizan las siguientes tareas: i) emulación de
dispositivos móviles y simulación escenarios para medir la funcionalidad del
software, ii) prueba en dispositivos reales o pruebas de campo para medir el
desempeño, rendimiento y encontrar fallas en tiempo de ejecución si el
software no cumple con ciertos requerimientos.
e) Entrega
Terminada la depuración de la aplicación y atendidos todos los
requerimientos se da por finalizado el desarrollo de la aplicación y se procede
con la entrega del ejecutable y la documentación, y si el caso amerita también
se adjunta el código fuente (Gasca, Camargo y Medina, 2013).
2.5. Método de estimación de costos Cocomo II

21
 COCOMO II (Constructive Cost Model) es un modelo paramétrico que
establece ecuaciones matemáticas para describir las relaciones entre el
tamaño del software y factor primario de costo usualmente representado en
términos de puntos de función y otros factores secundarios que buscan
capturar particularidades de producto, proceso, personas y plataforma. Esos
factores son denominados Cost Drivers, siendo algunos de efecto proporcional
y otros de efecto exponencial. Surge como una alternativa para incluir
componentes de incerteza en las estimaciones conforme al nivel de
información disponible
Para este punto se describirá lo esencial:

2.5.1. Estimación de esfuerzo

El esfuerzo necesario para concretar un proyecto de desarrollo de software,
cualquiera sea el modelo empleado, se calcula en meses/persona (PM) y
representa los meses de trabajo de una persona, requeridos para desarrollar el
proyecto.
⮚ Modelo Composición de Aplicación
La fórmula propuesta en este modelo es la siguiente:
PM = NOP / PROD
Dónde:
⮚ NOP (Nuevos Puntos Objeto): Tamaño del nuevo software a desarrollar
expresado en Puntos Objeto y se calcula de la siguiente manera:
⮚ NOP = OP x (100 - %reuso)/100
OP (Puntos Objeto): Tamaño del software a desarrollar expresado en
Puntos Objeto.
%reuso: Porcentaje de reuso que se espera lograr en el proyecto.
PROD: Es la productividad promedio determinada a partir del análisis de
datos de proyectos.
Para el modelo Composición de Aplicación
⮚ Modelo Diseño Temprano
Este modelo se usa en las etapas tempranas de un proyecto de software,
cuando se conoce muy poco del tamaño del producto a ser desarrollado, de la
naturaleza de la plataforma, del personal a ser incorporado al proyecto o
detalles específicos del proceso a utilizar. Este modelo podría emplearse tanto

22
en productos desarrollados en sectores de Generadores de Aplicación,
Sistemas Integrados o Infraestructura.
El modelo de Diseño Temprano ajusta el esfuerzo nominal usando siete
factores de costo. La fórmula para el cálculo del esfuerzo es la siguiente:

Dónde:
PM estimado es el esfuerzo Nominal ajustado por 7 factores, que reflejan
otros aspectos propios del proyecto que afectan al esfuerzo necesario para la
ejecución del mismo.
KSLOC es el tamaño del software a desarrollar expresado en miles de líneas
de código fuente.
A es una constante que captura los efectos lineales sobre el esfuerzo de
acuerdo a la variación del tamaño, (A=2.94).
B es el factor exponencial de escala, toma en cuenta las características
relacionadas con las economías y des economías de escala producidas cuando
un proyecto de software incrementa su tamaño.
EMi corresponde a los factores de costo que tienen un efecto multiplicativo
sobre el esfuerzo, llamados Multiplicadores de Esfuerzo (Effort Multipliers).
Cada factor se puede clasificar en seis niveles diferentes que expresan el
impacto del multiplicador sobre el esfuerzo de desarrollo. Esta escala varía
desde un nivel Extra Bajo hasta un nivel Extra Alto. Cada nivel tiene un peso
asociado. El peso promedio o nominal es 1.0. Si el factor provoca un efecto
nocivo en el esfuerzo de un proyecto, el valor del multiplicador correspondiente
será mayor que 1.0, caso contrario el multiplicador será inferior a 1.0.
Modelo Post - Arquitectura

23
 Es el modelo de estimación más detallado y se aplica cuando la arquitectura
del proyecto está completamente definida. Este modelo se aplica durante el
desarrollo y mantenimiento de productos de software incluidos en las áreas de
Sistemas Integrados, Infraestructura y Generadores de Aplicaciones.
El esfuerzo nominal se ajusta usando 17 factores multiplicadores de
esfuerzo. El mayor número de multiplicadores permite analizar con más
exactitud el conocimiento disponible en las últimas etapas de desarrollo,
ajustando el modelo de tal forma que refleje fielmente el producto de software
bajo desarrollo. La fórmula para el cálculo del esfuerzo es la siguiente:

2.5.1. Estimación del cronograma

COCOMO II ofrece una estimación de costos tanto como en COCOMO 81 y
ADA COCOMO, ésta estimación se centra en esta ecuación:

Dónde:
TDEV es el tiempo calendario en meses que transcurre desde la
determinación de los requerimientos a la culminación de una actividad que
certifique que el producto cumple con las especificaciones.
PM* es el esfuerzo expresado en meses personas, calculado sin tener en
cuenta el multiplicador de esfuerzo SCED.

Compresión/expansión del cronograma.

2.5.4. Métricas del software
Para la estimación del tamaño de software COCOMO II utiliza tres técnicas:
Puntos Objeto, Puntos Función No Ajustados y Líneas de Código Fuente.
Además se emplean otros parámetros relativos al tamaño que contemplan
aspectos tales como: reusó, reingeniería, conversión, y mantenimiento.

24
 Es necesario unificar criterios de medición de tamaño, tanto para poder
planificar y controlar proyectos, como para realizar estudios y análisis entre
proyectos en pro de la mejora de procesos. (Park, 1992)
1.2.1 Puntos objeto
Es un enfoque de medición de estimación de software que apareció
recientemente, ideal para su uso en el modelo de estimación por Composición
de aplicaciones de COCOMO II.
Los puntos objeto son el recuento de pantallas, informes, módulos de
lenguajes de 3ra generación desarrollados en la aplicación, cada uno
ponderado mediante un factor de complejidad en tres niveles (simple, medio y
complejo)
A continuación se describen los pasos para la estimación por Puntos Objeto:
Primero: Determinar Cantidad de Objetos: Estimar la cantidad de pantallas,
reportes, componentes de 3GL5 que contendrá la aplicación.
Segundo: Clasificar cada instancia de un objeto según sus niveles de
complejidad (simple, media o difícil)
Tercero: Dar el peso a cada objeto según el nivel de complejidad. Los pesos
reflejan el esfuerzo relativo requerido para implementar una instancia de ese
nivel de complejidad.
Cuarto: Determinar la cantidad de Puntos Objeto, sumando todos los pesos
de las instancias de los tipos de objetos especificados.
2.6. Pruebas técnicas de software
2.6.2. Prueba de caja blanca
La prueba de caja blanca se basa en el diseño de casos de prueba que usa
la estructura de control del diseño procedimental para derivarlos. Mediante la
prueba de la caja blanca el ingeniero del software puede obtener casos de
prueba que:
Garanticen que se ejerciten por lo menos una vez todos los caminos
independientes de cada módulo, programa o método.
Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
Ejecuten todos los bucles en sus límites operacionales.
Ejerciten las estructuras internas de datos para asegurar su validez.
Es por ello que se considera a la prueba de Caja Blanca como uno de los
tipos de pruebas más importantes que se le aplican a los software, logrando

25
como resultado que disminuya en un gran porciento el número de errores
existentes en los sistemas y por ende una mayor calidad y confiabilidad.
Camino básico. Esta prueba permite obtener una medida de la complejidad
del diseño para así luego obtener una guía para la definición de un conjunto
básico. Su técnica es:
A partir del diseño o del código fuente, se dibuja el grafo de flujo asociado.
Se calcula la complejidad ciclomática del grafo.
Se determina un conjunto básico de caminos independientes.
Se preparan los casos de prueba que obliguen a la ejecución de cada
camino del conjunto básico.
Notación de grafo de flujo. A partir de un flujo de control se representa por
un grafo de flujo Cada nodo del grafo corresponde a una o más sentencias de
código fuente, segmento de código de cualquier programa.
Complejidad ciclomática. La complejidad ciclomática es una métrica de
software extremadamente útil que proporciona una medición cuantitativa de la
complejidad lógica de un programa.
El valor calculado como complejidad ciclomática define el número de
caminos independientes del conjunto básico de un programa y nos da un límite
superior para el número de pruebas que se deben realizar para asegurar que
se ejecute cada sentencia al menos una vez.
Derivación de casos de prueba. Luego de tener elaborados los Grafos de
Flujos y los caminos a recorrer, se preparan los casos de prueba que forzarán
la ejecución de cada uno de esos caminos. Se escogen los datos de forma que
las condiciones de los nodos predicados estén adecuadamente establecidas,
con el fin de comprobar cada camino.
Luego de confeccionar los casos de prueba se ejecutan cada uno de estos y
se comparan los resultados con los esperados. Una vez terminados todos los
casos de prueba, se estará seguro de que todas las sentencias del programa
se han ejecutado por lo menos una vez.
1.2.2 Prueba de caja negra
La prueba de Caja Negra no es una alternativa a las técnicas de prueba de
la Caja Blanca, sino un enfoque complementario que intenta descubrir
diferentes tipos de errores a los encontrados en los métodos de la Caja Blanca.
Muchos autores consideran que estas pruebas permiten encontrar:

26
 Funciones incorrectas o ausentes.
Errores de interfaz.
Errores en estructuras de datos o en accesos a las Bases de Datos
externas.
Errores de rendimiento.
Errores de inicialización y terminación.
Para desarrollar la prueba de caja negra existen varias técnicas, entre ellas
están:
Técnica de la Partición de Equivalencia: esta técnica divide el campo de
entrada en clases de datos que tienden a ejercitar determinadas funciones del
software.
Técnica del Análisis de Valores Límites: esta Técnica prueba la habilidad del
programa para manejar datos que se encuentran en los límites aceptables.
Técnica de Grafos de Causa-Efecto: es una técnica que permite al
encargado de la prueba validar complejos conjuntos de acciones y condiciones.
Dentro del método de Caja Negra la técnica de la Partición de Equivalencia
es una de las más efectivas pues permite examinar los valores válidos e
inválidos de las entradas existentes en el software, descubre de forma
inmediata una clase de errores que, de otro modo, requerirían la ejecución de
muchos casos antes de detectar el error genérico. La partición equivalente se
dirige a la definición de casos de pruebas que descubran clases de errores,
reduciendo así en número de clases de prueba que hay que desarrollar.
Fuente: Macario Polo Usaola, Departamento de Tecnologías y Sistemas de
Información - Universidad de Castilla-La Mancha
8 Fuente:

 B. W. Boehm "Software Engineering Economics" (Prentice-Hall, 1981)

 http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm

2.7. Modelo de calidad de software ISO/IEC 25000

2.8. Lenguade de Modelado Unificado

2.8.1. Historia de UML
El lenguaje UML comenzó a gestarse en octubre de 1994, cuando
Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados

27
investigadores en el área de metodología del software). El objetivo de ambos
era unificar dos métodos que habían desarrollado: el método Booch y el OMT
(Object Modell ing Tool). El primer borrador apareció en octubre de 1995. En
esa misma época otro reputado investigador, Jacobson, se unió a Rationaly se
incluyeron ideas suyas. Estas tres personas son conocidas como los “tres
amigos”. Además, este lenguaje se abrió a la colaboración de otras empresas
para que aportaran sus ideas.
Todas estas colaboraciones derivaron en la definición de la primera versión
de UML. Esta primera versión se ofreció a un grupo de trabajo para convertirlo
en 1997 en un estándar del OMG (Object Management Group).
Este grupo, que gestiona estándares relacionados con la tecnología
orientada a objetos (metodologías, bases de datos objetuales, CORBA, etc.),
propuso una serie de modificaciones y una nueva versión de UML, que fue
adoptada por el OMG como estándar en noviembre de 1997. Desde aquella
versión ha habido varias revisiones que gestiona la OMG Revision Task Force.
La última versión aprobada es la 1.4.
Fuente: Enrique Hernández Orallo ([email protected])-El Lenguaje
Unificado de Modelado
UML es ante todo un lenguaje que proporciona un vocabulario y una regla
para permitir una comunicación. En este caso, este lenguaje se centra en la
representación gráfica de un sistema.
Este lenguaje nos indica cómo crear y leer los modelos, pero no dice cómo
crearlos. Esto último es el objetivo de las metodologías de desarrollo.
Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones:
• Visualizar: UML permite expresar de una forma gráfica un sistema de forma
que otro lo puede entender.
• Especificar: UML permite especificar cuáles son las características de un
sistema antes de su construcción.
• Construir: A partir de los modelos especificados se pueden construir los
sistemas diseñados.
• Documentar: Los propios elementos gráficos sirven como documentación
del sistema desarrollado que pueden servir para su futura revisión.

28
 Aunque UML está pensado para modelar sistemas complejos con gran
cantidad de software, el lenguaje es lo suficientemente expresivo como para
modelar
Sistemas que no son informáticos, como flujos de trabajo (workflow) en una
empresa, diseño de la estructura de una organización y por supuesto, en el
diseño de hardware.
Un modelo UML está compuesto por tres clases de bloques de construcción:
• Elementos: Los elementos son abstracciones de cosas reales o ficticias
(objetos, acciones, etc.)
• Relaciones: relacionan los elementos entre sí.
• Diagramas: Son colecciones de elementos con sus relaciones.
2.8.2. Diagramas UML
Un diagrama es la representación gráfica de un conjunto de elementos con
sus relaciones. En concreto, un diagrama ofrece una vista del sistema a
modelar. Para poder representar correctamente un sistema, UML ofrece una
amplia variedad de diagramas para visualizar el sistema desde varias
perspectivas. UML incluye los siguientes diagramas:
• Diagrama de casos de uso.
• Diagrama de clases.
• Diagrama de objetos.
• Diagrama de secuencia.
• Diagrama de estados.
• Diagrama de actividades.
El diagrama de casos de usos representa gráficamente los casos de uso que
tiene un sistema (Figura 3). Se define un caso de uso como cada interacción
supuesta con el sistema a desarrollar, donde se representan los requisitos
funcionales. Es decir, se está diciendo lo que tiene que hacer un sistema se
puede observar un ejemplo de casos de uso y las operaciones que realiza.
El diagrama de clases muestra un conjunto de clases, interfaces y sus
relaciones (Figura 4). Éste es el diagrama más común a la hora de describir el
diseño de los sistemas orientados a objetos. Se muestran las clases globales,
sus atributos y las relaciones.
En el diagrama de secuencia se muestra la interacción de los objetos que
componen un sistema de forma temporal.

29
 El resto de diagramas muestran distintos aspectos del sistema a modelar.
Para modelar el comportamiento dinámico del sistema están los de interacción,
colaboración, estados y actividades. Los diagramas de componentes y
despliegue están enfocados a la implementación del sistema.
Figura 3. Ejemplo de un diagrama de Casos de Uso

Fuente: Adaptado de “Introduction to the Diagrams of UML 2.X”, Scott, A,

(2014).
Figura 4. Ejemplo de un diagrama de Clases

Fuente: Adaptado de “Introduction to the Diagrams of UML 2.X”, Scott, A,

(2014).

Figura 5. Ejemplo de Diagrama de Secuencia

30
2.8. Herramientas para desarrollo de aplicaciones móviles
2.8.1. Lenguaje de programación Java
El lenguaje Java es un lenguaje de programación orientada a objetos de
propósito general creado por James Gosling y Bill Joy en Sun Microsystems,
conocido inicialmente como un lenguaje de Applets que se ejecutaban en un
navegador Web (Fernandez, 2005). Su sintaxis es muy parecida a la del
lenguaje C y C++, realiza la comprobación estricta de tipos de datos durante la
compilación a bytecode que es independiente de la plataforma, el cual es
interpretado por una máquina virtual que si es dependiente de la plataforma
donde se ejecuta el código.
Las herramientas de desarrollo de Java se conocen como Java Development
Kit (JDK), que cuenta entre otros con: un compilador de línea de comandos
denominado javac, la máquina virtual de Java necesaria para ejecutar
aplicaciones Java, una herramienta de documentación de código javac, y un
empaquetador de proyectos jar (Fernandez, 2005).
2.8.2. Android Studio
Android Studio (Figura X) es un entorno de desarrollo integrado (IDE) oficial
para el desarrollo de aplicaciones móviles Android, basado en el software

31
IntellJ IDEA y publicado de forma gratuita a través de la licencia Apache 2.0
(Google, 2022). Este entorno de desarrollo admite Kotlin como lenguaje
principal, aunque también soporta lenguajes como Java y C++.
Figura X. Interfaz gráfica principal de Android Studio

Fuente: (Google, 2022)

Entre las herramientas que tiene Android Studio, Google (2022) indica que
actualmente tiene disponible: soporte para construcción basada en Gradle,
plantillas para crear diseños comunes y otros componentes, soporte integrado
para Google Cloud Plattform que permite la integración con Firebase Cloud
Messaging y Google App Engine. Android Studio puede ser instalado en
sistemas Windows, MacOS y Linux, con un minimo de 4GB de RAM, y un
entorno Java JDK 8.
Asensio, I. (2021). ¿Qué es Unity y para qué sirve? Recuperado de:
https://www.masterd.es/blog/que-es-unity-3d-tutorial
Google (2022). Introducción a Android Studio. Recuperado de:
https://developer.android.com/studio/intro?hl=es-419
2.8.3. Unity
Unity es un entorno de creación de juegos más usados en la actualidad, de
desarrollo flexible y poderoso para crear experiencias interactivas 2D y 3D
multiplataforma (Asensio, 2021). Unity viene empaquetado como una
herramienta para crear juegos, aplicaciones interactivas, visualizaciones y

32
animaciones en 3D y tiempo real, con las siguientes características: motor
gráfico para renderizar gráficos 2D y 3D, motor físico que simule las leyes de la
física, animaciones, sonidos, inteligencia artificial, programación o scripting,
entre otros (Unity, 2022).
Figura X. Interfaz gráfica de usuario principal de Unity

Fuente: (Unity, 2022)

Desde Unity se puede publicar contenido para múltiples plataformas como
Windows, Mac, Nintendo, Wii, Android y iPhone, además permite publicar
juegos basados en web usando el plugin Unity web player. (Asensio, 2021).
2.8.4. Lenguaje de programación C Sharp
CSharp es un lenguaje de propósito general que Microsoft desarrolló tomando
lo mejor de los lenguajes C y C++, añadiendo la orientación a objetos para su
plataforma .Net y así crear aplicaciones de forma sencilla (). Entre las
características que destacan a CSharp se tiene: la sencillez, modernidad,
seguridad, sistema de tipos unificados, extensibilidad, versionabilidad,
compatibilidad y eficiencia.
Para trabajar con CSharp es recomendable utilizar Microsoft Visual Studio,
aunque también es compatible usarlo junto a Visual Studio Code. Unity también
permite crear programas con el lenguaje CSharp, siendo éste el lenguaje
predeterminado para crear scripts.

33
2.8.5. Visual Studio Code

Visual Studio Code es un editor de código fuente desarrollado por Microsoft

(Figura X), de código libre y multiplataforma, disponible para Windows,
GNU/Linux y MacOS, además tiene incorporada la integración con Git, soporte
de depuración de código y dispone de una gran variedad de extensiones que
básicamente posibilitan escribir y ejecutar código en cualquier lenguaje de
programación (Flores, 2022). Entre las características destacables de este
editor, es que: es multiplataforma, posee autocompletado de código, permite
depuración de código, y permite una fácil integración con herramientas de
versionamiento de código.
Figura X. Interfaz gráfica de usuario de Visual Studio Code

¿?
Fuente: (Flores, 2022)

34
CAPITULO III DISEÑO METODOLOGICO
3.1. Diseño metodológico
3.1.1. Delimitación temporal y espacial
El trabajo de investigación se realizará en un curso de tercero de primaria
con niños de 8 a 10 años en la ciudad de La Paz-Bolivia. Asimismo, el trabajo
tendrá una duración de cinco meses.
3.1.2. Materiales
La aplicación móvil será una nueva herramienta que contribuye
específicamente al área de matemática. El sistema que se desarrollará utilizara
las herramientas para el diseño de dicho sistema será una computadora con
las siguientes características en marcado en la siguiente tabla también se
utilizara herramientas de programación Android studio y java también contará
con un criterio investigativo y metodológico, haciendo uso de la metodología
Programación Extrema (XP), lo cual permite definir la arquitectura del sistema a
corto plazo. Para el desarrollo del proyecto se requiere el siguiente Hardware y
Software.
Tabla 3. de requerimientos mínimo de hardware
detalle Descripción (min)

Marca HP

Capacidad de la memoria RAM 6GB

Tipo de memoria del ordenador DDR3 SDRAM

Velocidad del procesador 2400 MHz

Número de procesadores 1

Disco Duro 500 GB

3.2. Metodología de la investigación

3.2.1. Metodología
La metodología de investigación utilizada en el presente trabajo será
descriptiva, dado que ante un fenómeno y elementos medibles se puede aplicar
métodos estadísticos para la comprobación de la hipótesis.

35
3.2.2. Criterios de inclusión Criterios de exclusión
Criterios de inclusión: se considerará a todos los estudiantes de tercero de
primaria en las escuelas fiscales de la ciudad de La Paz, en el periodo de
septiembre de 2020
Criterios de exclusión: la aplicación no realizara restas matemáticas
Criterios de exclusión: se considerara a todos los estudiantes que no sea
del curso de tercero de primaria, se excluirá a los cursos de primero de
primaria segundo de primaria

* Población y muestra:
Población: se realizara con los estudiantes de tercero de primaria de una
escuela fiscal
Muestra: 20 estudiantes de tercero de primaria de la escuela fiscal de la
ciudad de La Paz Bolivia que estén cursando en los años 2022

3.3. Técnicas de recolección de datos

3.4. Técnicas
3.4.1. Técnicas de adquisición de información
3.4.2. Lectura del material bibliográfico
Una ficha bibliográfica, es un elemento que contiene información relativa a
un texto, video, otro elemento de consulta
Se utilizará esta técnica para recopilación de la información requerida
durante el proceso de elaboración del marco teórico y en la investigación del
tema durante el perfil
3.4.3. La documentación
Consiste en la recolección de trabajos de investigación, documentos,
bibliografía, apuntes, referentes al tema y la revisión de la misma
Se emplea esta técnica para la obtención de información, que ayudara a
llevar a cabo la investigación.
3.4.4. Cuestionario
El cuestionario consiste en la formulación de una serie de preguntas las
cuales nos permite medir una o más variables.

36
 Como se sabe, se necesitan respuestas que nos lleven la determinación y
análisis de los factores que causa que el aprendizaje no sea eficiente en el
área de matemáticas de tercero de primaria.
3.4.5. Encuestas
Es una técnica en la cual se requiere información a partir de preguntas, sus
respuestas permiten estudiar determinados hechos a través de lo expresado,
es una técnica que no permite conocer las diversas opiniones.
En la investigación se necesita tener datos estadísticos que muestren
cuantos niños comprenden en su totalidad las matemáticas antes de ser
empleados la aplicación y cuantos después de ser utilizado el mismo.
3.4.6. Observación
Como se sabe la observación también es una forma de adquirir información
interactuando directamente con el ambiente a estudiar.
Es por esta razón que esta técnica al igual que las anteriores juega un papel
importante en la investigación, ya que nos permite ver de cerca como es el
desarrollo en clases de los actores y que influencia existe en su aprendizaje.
3.5. Parámetros de evaluación
Se evaluara Proceso Enseñanza-Aprendizaje expresado en cantidad niños
de 8 a 9 años que cursan tercero de primaria, área de matemáticas 
3.5.1. * Procesamiento y análisis de datos
Información obtenida mediante pruebas como resultado se demostrará el
Proceso Aprendizaje en niños de tercero de primaria
3.5.2. * Análisis estadístico (Diseño experimental)
Se realizarán las pruebas de la aplicación mediante teléfono móvil a dicha
cantidad de estudiantes de tercero de primaria teniendo datos estadísticos de
las pruebas realizadas con el sistema.

37
CAPITULO IV INGENIERÍA DE LA APLICACIÓN MOVIL
4.1. Análisis de requerimientos
4.1.1. Requerimientos funcionales
Realizadas las reuniones y entrevistas con personal docente del área de
matemáticas de la Unidad Educativa “Bicentenario La Paz”, se procedió con la
identificación de los requerimientos necesarios para el diseño y desarrollo de la
aplicación móvil.
Cabe recalcar, que los requerimientos funcionales corresponden a la dimensión
de calidad Adecuación funcional del modelo de calidad de producto software
ISO/IEC 25010.
La aplicación móvil debe cubrir los siguientes requerimientos funcionales:
1) Permitir la administración de datos de jugadores, incluyendo
principalmente el registro del nombre del jugador para identificarlo
posteriormente.
2) Permitir la autenticación del jugador, consultando el nombre con el cual el
usuario va a ingresar al juego.
3) Mostrar un menú de usuario, que incluya opciones como ser:
presentación de niveles de juego, instrucciones de juego, opciones de
configuración y visualización de recompensas actualizado.
4) Facilitar la realización de una prueba diagnóstico inicial, a fin de
determinar el grado de aprendizaje del estudiante, e incluir al finalizar el
resultado obtenido en la prueba.
5) Permitir la resolución al menos 5 ejercicios por nivel. Al obtener un
mínimo del 51% de recompensas por nivel, deber permitir el avance al
siguiente nivel. La acumulación de recompensas debe ser automática.
Cada interfaz de resolución de ejercicios debe permitir el abandono del
ejercicio.

4.1.2. Requerimientos no funcionales

Los requerimientos no funcionales corresponden a las siguientes áreas del
modelo de calidad de producto software ISO/IEC 25010, como ser: eficiencia
del desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad

38
y portabilidad. La aplicación móvil también debe cubrir ciertos requerimientos
no funcionales, los cuales se presentan a continuación.
Eficiencia del desempeño
 El tiempo de respuesta de cada GUI no debe exceder los 2 segundos.
 Los recursos de la aplicación (imágenes, videos, entre otros), deben estar
comprimidos para minimizar el tiempo de respuesta y procesamiento.
Compatibilidad
 La aplicación no debe exceder el uso de 200MB de memoria RAM durante
su ejecución, esto para no entorpecer el funcionamiento del dispositivo
móvil.
Usabilidad
 Las tipografías y colores utilizadas en el diseño de la aplicación deben
hacer legible la interpretación de las GUI.
 La terminología empleada en las interfaces gráficas debe estar acorde al
vocabulario usado para la enseñanza de la multiplicación y adecuada a la
edad de los jugadores.
 El esquema de navegación debe ser simple de comprender para el jugador.

Fiabilidad
 El guardado del avance y recompensas del jugador debe ser automática, a
fin de no perder datos en caso de una salida repentina de la aplicación.
Seguridad
 Como método de autenticación, se debe permitir la identificación del usuario
por nombre. En caso de encontrar duplicado, avisarle el usuario para
continuar o crear nuevo usuario.
Mantenibilidad
 Documentar el diseño y código del programa fuente para futuras
modificaciones.
Portabilidad
 La aplicación debe permitir la instalación en una versión mínima de Android
8 Oreo.

39
 La aplicación debe estar disponible en formato APK para su fácil instalación
en dispositivos Android.
4.2. Diseño
4.2.1. Modelo de uso
4.2.1.1. Identificación de actores
Se ha identificado solamente un (1) actor que debe interactuar con el
software, es decir, el Estudiante, el cual tiene acceso a todas las
funcionalidades de la aplicación móvil. En una jerarquía de actores de un
sistema en UML, el actor Estudiante se representa como único elemento hijo,
tal como muestra en la Figura 1.

Figura 1. Actores que interactúan con la aplicación móvil

Fuente: Elaboración propia

4.2.1.2. Casos de uso
Una vez identificados los actores de la aplicación, se procede a la identificación
de los escenarios mediante casos de uso, mismos que se representan en el
diagrama general de casos de uso en la Figura 2, y se describen a
continuación.
Figura 2. Diagrama general de casos de uso de la aplicación móvil.

40
Fuente: Elaboración propia
 Administrar jugadores, consiste en la administración de los datos de los
jugadores en una tabla de base de datos.
 Registrar jugadores, comprende el registro de nombre de jugadores en la
base de datos.
 Realizar prueba diagnóstico, abarca un conjunto de preguntas de control
para determinar el grado de aprendizaje del jugador.
 Mostrar resultado diagnóstico, consiste en la presentación del resultado de
la prueba diagnóstico.
 Mostrar menú de usuario, consta de una interfaz que muestra las diversas
opciones que el jugador dispone en la aplicación móvil.
 Mostrar niveles, comprende la presentación de una interfaz que muestra los
niveles de juego de la aplicación móvil.
 Mostrar instrucciones, consta de la presentación de las instrucciones para el
uso de la aplicación a modo de tutorial.

41
 Mostrar opciones de configuración, comprende la muestra de las opciones
que tiene el jugador para ajustar características como: volumen del audio,
grado de dificultad, entre otros.
 Mostrar recompensas, consiste en la presentación de las recompensas
ganadas por el estudiante durante su avance en la aplicación.
 Autenticar jugador, consta de un pequeño formulario para identificar al
jugador mediante su nombre.
 Resolver ejercicio de nivel, abarca la resolución de un ejercicio de
multiplicación mediante una interfaz gráfica que facilite dicha operación.
 Acumular recompensas, comprende las rutinas y eventos que permiten
acumular puntaje al jugador de manera automática de acuerdo a la
resolución de los problemas.
 Salir de ejercicio, consta del evento u opción que permite al jugador salir de
un escenario de resolución de ejercicios.
4.2.2. Modelo estructural
Luego de definir los escenarios mediante la identificación de casos de uso, se
procede con el modelado de la estructura de la aplicación móvil mediante un
diagrama de objetos, como se muestra en la Figura X.
Figura X. Modelo estructural de la aplicación móvil

Fuente: Elaboración propia

42
4.2.3. Modelo de interacción
El modelo de interacción permite determinar la secuencia en la cual se
conectan los distintos elementos de la aplicación móvil y define la navegación a
través de un diagrama de colaboración UML, como se muestra en la Figura X.

Figura X. Modelo de interacción de la aplicación móvil

Fuente: Elaboración propia

4.2.4. Modelo de comportamiento
El modelo de comportamiento permite describir el procedimiento mediante el
cual interactúan los distintos elementos y actores que intervienen o hacen uso
de la aplicación móvil. Esto se define a través de un diagrama de actividades
UML, como se muestra en la Figura X.
4.2.5. Modelo de implementación
El modelo de implementación permite describir las relaciones entre
componentes que forman parte de la aplicación móvil, y se define mediante de
un diagrama de implementación UML, como se muestra en la Figura X.
4.2.6. Maquetación de interfaces gráficas
La maquetación de las interfaces gráficas permite definir los elementos gráficos
que formaran parte de la vista que será presentada al usuario final. Esta

43
maquetación es realizada principalmente con base al modelo de interacción,
que brinda información relacionada a la navegación de los usuarios del
software.
Figura X. Modelo de comportamiento de la aplicación móvil

44
Fuente: Elaboración propia
Figura X. Modelo de implementación

Fuente: Elaboración propia

Figura X. Maquetación de interfaces gráficas de usuario

Fuente: Elaboración propia

45
4.3. Desarrollo
Durante el desarrollo del software se programaron las interfaces graficas de

usuario de la aplicación móvil en el software Unity de acuerdo a las

características definidas en la maquetación de interfaces graficas de usuario de

la sección anterior.

46
47
48
CAPITULO V RESULTADOS Y DISCUSIONES
5.1. RESULTADOS

5.2. DISCUSIONES

49
CAPITULO VI CONCLUSIONES Y RECOMENDACIONES
6.1. Conclusiones
6.2. Recomendaciones

50
REFERENCIAS BIBLIOGRÁFICAS
Anchico, G. (2018). software educativo aprende con Erika, en los procesos de
aprendizaje de las cuatro operaciones básicas del área de matemáticas, en los
estudiantes del grado tercero de la institución educativa agropecuaria Rio
Sanquianga del Municipio de Oyala Herrera [Tesis de pregrado, Universidad
Santo Tomás de Bogotá]. Repositorio institucional - Universidad Santo Tomás.

Botero, A., Negrete, J. & Tabares, N. (2021).  Desarrollo de un recurso digital

que facilite la enseñanza de las tablas de multiplicar en el grado tercero de la
I.E. Pio XII, corregimiento de Florencia, Samaná, Caldas [Proyecto de grado,
Universidad de Cartagena]. Repositorio institucional - Universidad de
Cartagena. 

Calvo, L. (2022). ¿Qué es una app, para que se utiliza y que tipos existen?.
Recuperado de: https://es.godaddy.com/blog/que-es-una-app-y-para-que-se-
utiliza/

Fernandez, O. (2005). Introducción al lenguaje de programación Java: Una

guía básica. Revista de investigación Academia.
Flores, F. (2022). ¿Qué es Visual Studio Code y qué ventajas ofrece?.
Recuperado de: https://openwebinars.net/blog/que-es-visual-studio-code-y-que-
ventajas-ofrece/
Gasca, M., Camargo, L. y Medina, B. (2013). Metodología para el desarrollo de
aplicaciones móviles. Revista Tecnura 18(40). Bogotá, Colombia.

Huancario, L. (2013).  Aplicación movil para promover la educación en

seguridad vial en etapa escolar desarrollado en Android [Tesis de grado,
Universidad Mayor de San Andrés]. Repositorio institucional - Universidad
Mayor de San Andrés.

Pressman, R. (2010). Ingeniería de software: Un enfoque práctico. Editorial

McGraw Hill.

Rahimian, V. & Ramsin, R. (2008, 6 de junio). Designing and agile methodology

for mobile software development: a hybrid ethod engineering approach. Second
International Conference on Research Challenges in Information Science.
Recuperado de http://ieeexplore.ieee.org/xpl/articleDetails.jsp?
arnumber=4632123&punumber%3D4620134%26sortType
%3Dasc_p_Sequence%26filter%3DAND%28p_IS_Number
%3A4632084%29%26pageNumber%3D2.

Rojas, A. (2015).  Desarrollo de un aplicación móvil multiplataforma utilizando

un sphero para la enseñanza de programación en niños [Tesis de grado,
Universidad Mayor de San Andrés]. Repositorio institucional - Universidad
Mayor de San Andrés.

Sommervile, I. (2005). Ingenieria del software. Editorial Pearson Education.

---****** 

51
[RumJaBo 2000], Rumbaugh, Jacobson, El Proceso Unificado de Desarrollo de
Software – manual de referencia, rational Software.
 [Pavon, Jacobo 2007], Navegar en Internet. Creación de un portal con
VISUAL STUDIO 2012 y SQL-Tercera Edición.
 [James Senn], Sistema de Información Administración, Ed. McGraw –
Hill/Mexico.
 [Julio Cesar Rueda Chacon], Aplicación de la Metodología RUP para el
desarrollo rápido de aplicaciones basado en el estándar JEE, Universidad de
San Carlos de Guatemala – Guatemala.
 [Pressman, R 2002], Ingeniería de Software, España, edición MacGraw.
 [Somerville 2002], Ingeniera de Software: un Enfoque Práctico, Quinta
edición - editorial McGraw – Hill.
 [Roberto Hernadez Sampieri, Dr. Carlos Fernández Callado, Dra. Pilar
Baptista Lucio 1991], Metodologías de la investigación, editorial McGraw – Hill.
 [Gomez Ceja, Guillermo 2002], Sistemas Administrativos Análisis y
Diseño, MacGraw – Hill.
 Scott, A. (2014). Introduction to the Diagrams of UML 2.X. Recuperado
febrero de 2017, de http://agilemodeling.com/essays/umlDiagrams.htm.
 Teruel, A. (2001, 27 de febrero). COCOMO II: “Una Familia de Modelos de
Estimación”. Recuperado el 15 de marzo de 2017, de
https://ldc.usb.ve/~teruel/ci4713/clases2001/cocomo2.html

52
ANEXOS

53
ANEXO 1 ARBOL DE PROBLEMAS

54
55