ESCUELA MILITAR DE INGENIERÍA

Mcal. ANTONIO JOSÉ DE SUCRE

BOLIVIA

TRABAJO DE GRADO

PLATAFORMA DE APRENDIZAJE ONLINE APLICANDO

REDES NEURO-DIFUSAS PARA LA CAPACITACIÓN
MEDIANTE EL ACCESO A MATERIAL DIGITAL EN
PERSONAL DE FUERZA DE VENTAS
CASO DE ESTUDIO: DROGERIA INTI SEDE LA PAZ.
GESTIÓN 2021

EST. DAVID SAMUEL RIOS NUÑEZ

LA PAZ, 2021
ESCUELA MILITAR DE INGENIERÍA
Mcal. ANTONIO JOSE DE SUCRE
BOLIVIA

TRABAJO DE GRADO

PLATAFORMA DE APRENDIZAJE ONLINE APLICANDO

REDES NEURO-DIFUSAS PARA LA CAPACITACIÓN
MEDIANTE EL ACCESO A MATERIAL DIGITAL EN
PERSONAL DE FUERZA DE VENTAS
CASO DE ESTUDIO: DROGERIA INTI SEDE LA PAZ.
GESTIÓN 2021

EST. DAVID SAMUEL RIOS NUÑEZ

Modalidad: Trabajo de Grado

presentado como requisito para
optar al título de Licenciatura en
Ingeniería

TUTOR: ING. OSAMU MANUEL YOKOSAKI PEÑARANDA

LA PAZ, 2021
ÍNDICE
 Índice

1.1. INTRODUCCIÓN .................................................................................................................. 1

1.2. ANTECEDENTES ................................................................................................................. 2

1.3. PLANTEAMIENTO DEL PROBLEMA ................................................................................. 5

1.3.1. IDENTIFICACIÓN DEL PROBLEMA............................................................................... 5

1.3.2. FORMULACIÓN DEL PROBLEMA ................................................................................. 6

1.4. OBJETIVOS.......................................................................................................................... 6

1.4.1. OBJETIVO GENERAL ..................................................................................................... 6

1.4.2. OBJETIVOS ESPECÍFICOS ............................................................................................ 6

1.4.3. ACCIONES DEL PROYECTO ......................................................................................... 7

1.5. JUSTIFICACIÓN................................................................................................................... 8

1.5.1. JUSTIFICACIÓN SOCIAL................................................................................................ 9

1.5.2. JUSTIFICACIÓN ECONOMICA ....................................................................................... 9

1.5.3. JUSTIFICACIÓN TÉCNICA ........................................................................................... 10

1.6. ALCANCE........................................................................................................................... 10

1.6.1. ALCANCE TEMÁTICO .................................................................................................. 10

1.6.1.1. Área y Líneas de Investigación ........................................................................... 10
1.6.1.2. Tema Específico ................................................................................................... 11

1.6.2. ALCANCE GEOGRÁFICO............................................................................................. 11

1.6.3. ALCANCE TEMPORAL ................................................................................................. 11

1.6.4. ALCANCE INSTITUCIONAL ......................................................................................... 11

1.6.5. LIMITACIONES .............................................................................................................. 11

2.1. INTELIGENCIA ARTIFICIAL ............................................................................................. 12

2.1.1. Definición ....................................................................................................................... 12

2.1.2. Categorías de la Inteligencia Artificial ....................................................................... 13

2.2. LÓGICA DIFUSA ................................................................................................................ 14

2.2.1. Definición de Lógica Difusa ........................................................................................ 15

2.2.2. Sistemas Difusos .......................................................................................................... 16

2.3. INGENIERIA DE SOFTWARE ........................................................................................... 17

2.3.1. Definición de Software ................................................................................................. 17

2.3.2. Dominios de Aplicación ............................................................................................... 17

2.3.3. Definición de Ingeniería de software .......................................................................... 18

2.3.4. Lenguaje Unificado de Modelado (UML) .................................................................... 19

2.3.4.1. Diagramas UML .................................................................................................... 20
2.3.5.1. Prueba de Caja Blanca ......................................................................................... 24
2.3.5.2. Prueba de Caja Negra .......................................................................................... 25

2.4. CAPACITACIÓN DE PERSONAL ..................................................................................... 28

2.4.1. Definición de Capacitación .......................................................................................... 28

2.4.2. Características de la Capacitación al Personal ......................................................... 28

2.4.3. Beneficios de la Capacitación al Personal ................................................................ 31

2.4.4. Definición de Capacitación al Personal en la empresa INTI .................................... 32

2.4.5. Métodos de recolección de datos ............................................................................... 33

2.4.5.1. Métodos de recolección de datos primarios ..................................................... 33
2.4.5.2. Métodos y técnicas de recolección de datos secundarias ............................. 37

2.5. METODOLOGÍA TDD ........................................................................................................ 38

2.5.1. TDD ................................................................................................................................. 38

2.5.2. CARACTERÍSTICAS ..................................................................................................... 40

2.5.3. CICLO DE DESARROLLO DEL TDD............................................................................ 41

2.5.4. RESULTADO DE DESARROLLO DEL TDD ................................................................ 44

2.5.4.1. ASPECTOS POSITIVOS ....................................................................................... 44

2.5.5. Metodología SCRUM .................................................................................................... 46

2.5.5.1. Componentes de Scrum ...................................................................................... 48
2.5.5.2. Elementos de Scrum ............................................................................................ 50

1 - 120
2.6. METODOLOGÍA BUCHANAN ........................................................................................... 55

2.6.1. Identificación ................................................................................................................. 55

2.6.2. Conceptualización ........................................................................................................ 55

2.6.3. Formalización ................................................................................................................ 56

2.6.4. Implementación............................................................................................................. 56

2.6.5. Testeo............................................................................................................................. 57

2.6.6. Revisión del Prototipo.................................................................................................. 58

3.1. DISEÑO METODOLÓGICO ............................................................................................... 59

3.1.1. Tipo y Método de Investigación .................................................................................. 62

3.2. INGENIERÍA DEL PROYECTO ......................................................................................... 64

3.2.1. Identificación ................................................................................................................. 64

3.2.1.1. Planteamiento del Problema ....................................................................................... 64

3.2.1.2. Situación Actual ............................................................................................................ 65

3.2.3. Identificación de Flujo de Capacitaciones en INTI ...................................................... 68

3.2.4. Requerimientos del Sistema .......................................................................................... 69

3.2.5. Definición de Procesos ................................................................................................ 71

3.2.6. Establecimiento de la Pila del Producto .................................................................... 72

3.2.7. Construcción de la Red Neuro difusa ........................................................................ 74

3.2.8. Identificación del Caso de Uso de Alto Nivel ............................................................ 78

3.2.9. Planificación del Sprint 1: Autenticación de Usuario (Web).................................... 79

3.2.10. Planificación del Sprint 2: Cargado de Material (Web) ............................................. 84

3.2.11. Planificación del Sprint 3: Gestión de Cursos (Web) ............................................... 89

3.2.12. Planificación del Sprint 4: Gestión de Evaluación (Web) ........................................ 94

3.2.13. Planificación del Sprint 5: Gestión de Calificaciones (Web) ................................... 99

3.2.14. Planificación del Sprint 6: Autenticación de usuario (Móvil) ................................ 103

3.2.15. Planificación del Sprint 7: Visualización de Cursos (Móvil) .................................. 107

2 - 120
 3.2.16. Planificación del Sprint 8: Toma de Evaluación (Móvil) ......................................... 111

3.3. DISEÑO DEL SISTEMA PROPUESTO ........................................................................... 115

3.3.5. Diseño y Arquitectura del Sistema ........................................................................... 116

3.3.6. Diseño de la Base de Datos ....................................................................................... 116

3.4. INTERFAZ GRÁFICA DE LA PLATAFORMA ................................................................ 117

BIBLIOGRAFÍA............................................................................................................................. 121

3 - 120
 CAPÍTULO I.
GENERALIDADES
 CAPITULO 1
GENERALIDADES

1.1. INTRODUCCIÓN

La aparición de las computadoras y el crecimiento explosivo de Internet después, junto

con otras novedades tecnológicas revolucionan la manera de producir, almacenar,
transmitir, compartir, recuperar información, afectando en primer lugar a la
capacitación a distancia y agrietando el inmovilismo de la capacitación presencial
tradicional. Las empresas de principios del siglo XXI tienen ante sí el reto clásico de
los cambios de época: heredan lo complicado del mundo que acaba y lo confuso del
que empieza. Igualmente, comparten la posibilidad de contribuir intelectualmente y en
la práctica a diseñar aquellas concepciones que perdurarán en los próximos decenios.

Las Tecnologías de la Información y la Comunicación cada vez son más utilizadas, es

increíble cómo se puede mejorar en el área de la educación generando un aprendizaje
más productivo y en las capacitaciones organizacionales fácilmente acorta distancias.

El presente trabajo de grado está planteada en Droguería INTI sede La Paz en el cual
se implementara una plataforma digital para la capacitación y evaluación del personal
de fuerzas en el cual se implementara a la plataforma una red neuro-difusa para la
entrega de material según la nota que obtenga cada persona en sus evaluaciones
teniendo material según la necesidad que este tenga, permitiendo la optimización de
tiempos al momento de entregar las calificaciones de las evaluaciones realizadas por
la capacitación dada en la empresa.

1 - 120
La capacitación virtual facilita la enseñanza y los trabajos se vuelven más
automatizados lo que ahorra mucho tiempo, recursos y posee múltiples ventajas que
no se pueden ignorar.

1.2. ANTECEDENTES

• ANTECEDENTES DE LA ENTIDAD

En marzo de 1936 se marca el inicio de la Industria Farmacéutica más importante

de Bolivia, cuando el Empresario Alemán, Don Ernesto W. N. Schilling, funda en
La Paz la “Droguería Hamburgo”, dedicada a la comercialización de Drogas
Medicinales y Medicamentos. Once años después, luego de un proceso de
transformaciones al interior de la firma, se produce el cambio de razón social a
Droguería INTI S.A. Foto Ernesto W. N. Schilling. (Droguería INTI, 2020)

• ANTECEDENTES DEL TEMA

La capacitación es entendida como el esfuerzo generalizado para mejorar los

conocimientos y las destrezas disponibles en la organización. Las acciones de
capacitación deben basarse en un acercamiento entre el área de recursos
humanos y la línea. Debe responder también a la difusión de las prácticas de la
compañía para pertenecer a ella y representarla. El término, se utiliza con
frecuencia de manera casual, para referirse a la generalidad de los esfuerzos
iniciados por una organización, para impulsar el aprendizaje de sus miembros
(Sherman, Bohlander y Snell, 1999).

La capacitación es un proceso, que parte de la comparación entre las

necesidades para cubrir cada puesto y la formación previa que tiene el individuo
que lo ocupa, a partir de ahí, se trabaja para cubrir esa brecha.

2 - 120
Muchos empleados llegan con una importante proporción del conocimiento,
habilidades y capacidades necesarios para comenzar a trabajar. Otros quizá
requieren una capacitación extensa antes de poder contribuir a la organización.
Sin embargo, la mayoría necesita cierto tipo de capacitación continua, a fin de
mantener un desempeño eficaz, o bien para ajustarse a las nuevas maneras de
trabajar (Sherman, Bohlander y Snell, 1999).

En este sentido, la formación es uno de los medios que posee la dirección para
asegurar que el nivel de competencia de las personas y equipos estén a la altura
de las exigencias del medio (Meignant, 1997).

Para una gran parte del personal, el término capacitación se aplica a la acción
de cubrir necesidades específicas de la compañía, según el puesto que ocupen
y es una formación de tipo instrumental. Es un entrenamiento operativo, se
enseña a manejar una herramienta nueva, a llenar un formulario o un
procedimiento interno, una nueva política de vacaciones o un sistema de premios
por asistencia. La capacitación entonces no es conceptual ni filosófica, algunos
autores diferencian entre capacitación y entrenamiento, o entre formación y
perfeccionamiento (Gómez-Mejía, Balkin y Cardy, 1997).

Antecedentes de Trabajos similares:

Moodle

La plataforma Moodle es un sistema de enseñanza diseñado para crear y

gestionar espacios de aprendizaje online adaptados a las necesidades de
profesores, estudiantes y administradores.

En términos más técnicos, es un sistema web dinámico creado para gestionar

entornos de enseñanza virtual, basado en tecnología PHP y bases de datos
MySQL.

3 - 120
La primera versión fue creada en el año 2002 por el pedagogo e informático
australiano Martin Dougiamas, y su nombre original procede del acrónimo
de Module Object-Oriented Dynamic Learning Environment (Entorno Modular de
Aprendizaje Dinámico Orientado a Objetos).

El carácter gratuito y abierto de Moodle lo convierten en una herramienta muy

atractiva, que además cuenta con muchas más ventajas:

Herramienta estable y de confianza, Intuitiva y fácil de usar, Siempre actualizada,

Flexible y personalizable, Escalable a cualquier tamaño, Ubicua y accesible
desde cualquier dispositivo, Robusta, segura y privada, Con funcionalidades
ampliables, Moodle está traducido a más de 120 idiomas. Su capacidad
multilingüe es otra de sus características más apreciadas. (Moodle, 2021)

eFront

eFront es una plataforma de aprendizaje electrónico (también conocida como

Sistema de gestión de cursos (CMS), Sistemas de gestión de aprendizaje (LMS)
o Entorno de aprendizaje virtual (VLE)) . Históricamente, eFront ha venido en
varias ediciones, desde una edición de Código abierto hasta la última edición de
eFrontPro (que es la única disponible en 2018).

eFront está diseñado para ayudar con la creación de comunidades de

aprendizaje en línea al tiempo que ofrece varias oportunidades de colaboración
e interacción a través de una interfaz de usuario basada en iconos. La plataforma
ofrece herramientas para la creación de contenido, construcción de pruebas,
administración de asignaciones, informes, mensajería interna, foro, chat,
encuestas, calendario y otros. Es un sistema certificado SCORM 1.
2 y compatible con SCORM 2004/4ª edición traducido a 40 idiomas.

4 - 120
 eFront se incluye comúnmente en listas de sistemas de aprendizaje de código
abierto bien conocidos o se lo conoce como una alternativa de Moodle. Las
matrices de comparación independientes entre los sistemas de gestión del
aprendizaje a menudo favorecen a eFront, especialmente en las características
de usabilidad. Varios artículos de investigación y portales de tecnología
describen el sistema bajo la perspectiva de funcionalidad, usabilidad y
estándares. (eFront, 2018)

EdModo

Edmodo es una plataforma tecnológica, social, educativa y gratuita que permite

la comunicación entre los alumnos y los profesores en un entorno cerrado y
privado a modo de microblogging, creado para un uso específico en educación
media superior.

Edmodo está apoyado por Index Ventures, Benchmark, Greylock Partners,

Learn Capital, New Enterprise Associates, Union Square Ventures, Glynn Capital
Management, Tenaya Capital, SingTel Innov8 y KDDI.

En marzo del 2018, Noodle nombró a Edmodo como una de las 32 plataformas
educativas en línea más innovadoras. A la hora de registrarse se crea una cuenta
donde la persona debe identificarse como profesor, estudiante o padre de
alumno. No exige instalación ni configuración local en el equipo ya que todo está
basado en una aplicación en la red.(Edmodo, 2014)

1.3. PLANTEAMIENTO DEL PROBLEMA

1.3.1. IDENTIFICACIÓN DEL PROBLEMA

El costo elevado por el uso de la plataforma actual conlleva a muchos gastos el cual
no permite la manipulación de los datos a nivel Administrador, limitando el uso y

5 - 120
capacidad de la plataforma, además de tener un doble esfuerzo en las capacitaciones
dando notas erróneas al personal.

1.3.2. FORMULACIÓN DEL PROBLEMA

El tiempo y costos de la plataforma actual para realizar las diferentes capacitaciones

causan un doble esfuerzo por parte del departamento de capacitaciones y para la
empresa convirtiéndose en un proceso largo en cual debe pagar horas extras en caso
de que la capacitación sea de manera urgente.
Al no tener el control total de las mismas, causa errores tanto en la calificación como
en la capacitación de la fuerza de ventas lo que imposibilita un uso adecuado de las
mismas.

1.4. OBJETIVOS

1.4.1. OBJETIVO GENERAL

Desarrollar una plataforma de aprendizaje online aplicando redes neuro-difusas para

la capacitación mediante el acceso a material digital al personal de fuerza de ventas
de Droguería INTI optimizando recursos, tiempos y costos.

1.4.2. OBJETIVOS ESPECÍFICOS

• Generar y analizar el levantamiento de información necesaria, para cumplir

con los requerimientos de la empresa, en cuanto a posibles tecnologías a usar,
costos, limitaciones.
• Diseñar la plataforma de aprendizaje de acuerdo a los requerimientos de la
empresa.
• Desarrollar la estructura de la red neuro-difusa para su aplicación en la
plataforma de aprendizaje a fin de optimizar los procesos asociados a la
capacitación.

6 - 120
 • Integrar todos los elementos de la plataforma para la realización de pruebas
funcionales para su implementación.

1.4.3. ACCIONES DEL PROYECTO

Las acciones para lograr el objetivo de generar y analizar el levantamiento de

información necesaria, para cumplir con los requerimientos de la empresa, en cuanto
a posibles tecnologías a usar, costos y limitaciones serán:
• Revisión bibliográfica, que permitirá identificar los requerimientos del sistema.
• Reuniones con los encargados del área de capacitaciones.
• Esquematización de información recolectada.

Esto permitirá ver los aspectos de los cuales forma parte la capacitación y seguimiento
del personal fuerza de ventas.

Las acciones para lograr el objetivo de diseñar la plataforma de aprendizaje de

acuerdo a los requerimientos de la empresa serán:
• Diseño de la interfaz gráfica y experiencia de usuario.
• Diseño de la arquitectura de la plataforma.
• Diseño de la base de datos.

Esto ayudará a encontrar diseños requeridas y necesarias para poder diseñar la

plataforma.

Las acciones para lograr el objetivo de desarrollar la red neuro-difusa para su

aplicación en la plataforma de aprendizaje a fin de optimizar los procesos asociados a
la evaluación serán:
• Desarrollo de la plataforma en lenguaje de programación, una vez ya
reconocidas las variables y flujo de capacitación se procede a la programación
y construcción de la plataforma.
• Diseño de la red neuro-difusa.

7 - 120
 • Formalización de la red neuro-difusa.

Esto ayudará a tener el desarrollo de la red neuro-difusa.

Las acciones para lograr el objetivo de integrar todos los elementos de la plataforma
para la realización de pruebas funcionales para su implementación serán:

• Se realizará diferentes tipos de pruebas para la verificación del correcto

funcionamiento de la plataforma.
• Corrección antes posibles fallos que vaya a presentas en las pruebas.
• Se implementará la plataforma en la infraestructura de la empresa.

Esto permitirá controlar el funcionamiento correcto del sistema.

1.5. JUSTIFICACIÓN

En los últimos años se ha analizado la posibilidad de implementar una nueva

alternativa de educación ya que la anterior tenia muchas fallas.
• Justificación Teórica: El trabajo de grado se justifica teóricamente debido a
que el mismo cumple con el perfil de Ingeniería en Sistemas, debido a que se
implementa tecnologías de información y comunicación, realizando la
planeación, análisis, diseño, implementación, prototipos, conocimiento,
resolviendo problemas con sentido de reto, motivación, flexibilidad.
• Justificación Metodológica: El trabajo de Grado se justifica desde el método
científico por los siguientes motivos: Al ser una está una acción para ver el
comportamiento de los empleados se necesita de la observación, para
identificar la mejor manera de realizar la plataforma de capacitación y sea de
fácil uso e intuitiva.
• Justificación Práctica: Con la plataforma de capacitación se podrá hacer un
seguimiento al personal de fuerza de ventas el cual permitirá ahorrar tiempo

8 - 120
 sin necesidad de una doble revisión y este será de fácil acceso para todo el
personal de la empresa.
• Justificación Institucional: El presente trabajo ayudará a mejorar la manera
de capacitación y evaluación a su personal cada que este sea necesario según
los requerimientos de la empresa. Esto mediante la aplicación de una
plataforma digital el cual permitirá al personal ser capacitado y evaluado desde
cualquier lugar, utilizando redes neuro-difusas para la capacitación y entrega
de material digital. Este proyecto beneficiara a la empresa para la optimización
recursos y tiempos al momento de la capacitación del personal.

1.5.1. JUSTIFICACIÓN SOCIAL

Realizar la implementación de la plataforma, permitirá que la interacción con esta sea

más amigable y de fácil uso, ayudando de gran manera al personal de fuerza de ventas
con la reducción de tiempo sin la necesidad de tener doble revisión u evaluación,
teniendo en cuenta que la red neuro-difusa apoyará para la entrega de material digital
según las notas que se obtuvo en las evaluaciones que realiza la empresa, mejorando
de gran manera la capacitación del personal teniendo un resultado al momento y no
después de un tiempo prolongado.

Estos recursos pueden ayudar a mejorar el desempeño laboral, formas de

comunicación, sin importar el tiempo y la distancia del personal de fuerza de ventas.

1.5.2. JUSTIFICACIÓN ECONOMICA

El poder contar con una plataforma de capacitación y evaluación ayudará de gran

manera a reducir tiempos en evaluaciones y capacitaciones, este al contar con una
red neuro difusa permitirá que la plataforma funcione de mejor manera teniendo
resultados al instante.

De igual manera se reducirán costos con el uso de la plataforma abaratando el costo

que se tenia sin la misma, ya que este no solo requería de un pago por servicios sino
9 - 120
que debían ser revisados por segunda vez ya que se contaba con problemas al
momento de la evaluación.

1.5.3. JUSTIFICACIÓN TÉCNICA

El presente proyecto se justifica técnicamente, ya que ayudará en el área de ventas
en la empresa, a que pueda ser capacitado desde el lugar que este se encuentre sin
necesidad de que este deba esperar por una respuesta por más de 1 día.

Con la plataforma ya en funcionamiento se podrá observar un mejor manejo de

recursos y tiempos para el departamento de capacitaciones y para el personal de
fuerzas de ventas además de que se contará con una red neuro-difusa que apoyará
en la entrega de material digital según las notas que se obtuvo en las evaluaciones.

1.6. ALCANCE

Los alcances permiten hacerse una idea de lo que se quiere lograr con el desarrollo la
plataforma basada en redes neuro-difusas.

1.6.1. ALCANCE TEMÁTICO

La plataforma se generará y diseñará a través de requerimientos y entrevistas que se

realizaran con los encargados del área de tal manera que permita la construcción de
la plataforma, lo que favorecerá en la capacitación y evaluación al personal de fuerza
de ventas logrando un mejor rendimiento en estos.

1.6.1.1. Área y Líneas de Investigación

El área de investigación es el de sistemas de información y conocimiento debido a la

capacitación y evaluación que se hará al personal de fuerza de ventas para la
optimización de tiempo.

10 - 120
Teniendo como línea de investigación las redes neuro-difusas que apoyará en la
entrega de material digital según las notas que se obtuvo en las evaluaciones.

1.6.1.2. Tema Específico

Desarrollo plataforma, red neuro-difusa, capacitación, evaluación.

1.6.2. ALCANCE GEOGRÁFICO

El universo de estudio del presente trabajo, pretende abarcar al personal de fuerza de

ventas de Droguería INTI sede La Paz, debido a que esta población es la que necesita
de este apoyo para ahorrar tiempo y mejorar las ventas.

1.6.3. ALCANCE TEMPORAL

El alcance temporal en cuanto al análisis de información se realizará una recopilación

de información de los últimos 4 años, para la bibliografía se buscará información de
los últimos 5 años.

Para el desarrollo este plantea recolectar información en la Primera gestión del 2021
y hacer pruebas en la Segunda gestión del 2021

1.6.4. ALCANCE INSTITUCIONAL

La plataforma de capacitación y evaluación será aplicada para el personal de fuerza

de ventas de Droguería INTI.

1.6.5. LIMITACIONES

• El estudio se hará solamente al personal de fuerza de ventas de Droguería

INTI.

• Se considerarán los datos proporcionados por la empresa.

11 - 120
CAPÍTULO II. MARCO
TEÓRICO
 CAPITULO 2
MARCO TEÓRICO

2.1. INTELIGENCIA ARTIFICIAL

2.1.1. Definición

La inteligencia Artificial es el estudio de la ideas que permiten ser inteligentes a los

ordenadores (Winston, 1984)

Parte de la informática que estudia procesos simbólicos, razonamientos no algoritmos y

representaciones simbólicas del conocimiento (Buchanan, Feigenbaum, 1970).

En cualquier caso, en la IA como ciencia y tecnología se fueron acumulando conocimientos

sobre cómo emular las diversas capacidades del ser humano para exhibir
comportamientos inteligentes y se han desarrollado sistemas cada vez más
perfeccionados que reproducen parcialmente dichas capacidades. Así, el estudio de
sensores y mecanismos de intercambio de información con el exterior constituyen, por si
mismos, pujantes áreas de investigación y aplicaciones prácticas. También la robótica,
como especialidad 16 relacionada con máquinas móviles capaces de interactuar
inteligentemente con su entorno y manipular objetos, suele considerarse parcialmente en
el ámbito de la Inteligencia Artificial.

De esta manera, la Inteligencia Artificial naturalmente es el conjunto de habilidades

cognitivas e intelectivas realizadas por el cerebro humano para comprender el mundo que
rodea a una persona, interpretar sus señales e informaciones, resolver los constantes
problemas de diverso tipo que plantea el quehacer diario, representar y acumular

12 - 120
experiencia y conocimiento, aprender y generar nuevo conocimientos a partir del bagaje
disponible mediante diversos modos de razonamiento, etc. (Pino & otros, 2001)

La Inteligencia Artificial es una rama de la Informática que trata de enfocar el concepto de

Inteligencia en las máquinas. Según el Diccionario de la Real Academia Española,
Inteligencia es: “Potencia Intelectual, facultad de entender, de conocer, de entender o
comprender.”

La I.A persigue dos clases de metas: Metas Científicas, al saber cómo funciona el Cerebro
Humano y de Ingeniería, ya que persigue el objetivo de crear sistemas Inteligentes.
Algunas personas creen que las placas de silicio (Circuitos) no podrán pensar jamás y que
la materia cerebral está diseñada explícitamente para ello, como se ve en la Figura 1.
(Escobano, 2000)

Figura 1 El Cerebro y la Ingeniería

Fuente: Áreas de la IA

2.1.2. Categorías de la Inteligencia Artificial

Stuart Russell y Peter Norvig diferencian estos tipos de la inteligencia artificial:

• Sistemas que piensan como humanos. - Estos sistemas tratan de emular el

pensamiento humano; por ejemplo, las redes neuronales artificiales. La
13 - 120
 automatización de actividades que vinculamos con procesos de pensamiento
humano, actividades como la Toma de decisiones, Resolución de problemas y
aprendizaje.
• Sistemas que actúan como humanos. - Estos sistemas tratan de actuar como
humanos; es decir, imitan el comportamiento humano; por ejemplo, la robótica. El
estudio de cómo lograr que los computadores realicen tareas que, por el momento,
los humanos hacen mejor.
• Sistemas que piensan racionalmente. - Es decir, con lógica (idealmente), tratan de
imitar o emular el pensamiento lógico racional del ser humano; por ejemplo, los
sistemas expertos. El estudio de los cálculos que hacen posible percibir, razonar y
actuar.
• Sistemas que actúan racionalmente (idealmente). – Tratan de emular de forma
racional el comportamiento humano; por ejemplo, los agentes inteligentes. Está
relacionado con conductas inteligentes en artefacto.

2.2. LÓGICA DIFUSA

La lógica difusa es un planteamiento que permite evaluar cuantitativamente el valor de

verdad/falsedad de una afirmación, en contraste con la descripción cualitativa bi-estable
de la lógica clásica. Este manejo cuantitativo también incluye la agrupación de los valores
de una variable dentro de categorías lingüísticas, asociándolas a valores representativos
de su grado de pertenencia a una categoría mediante funciones de membresía. De una
forma sencilla podemos describir las características de la lógica difusa así (Martín de Río,
2010):

• La lógica difusa está basada en variables lingüísticas, no numéricas

• Es posible y común que existan variaciones no lineales
• El manejo de la certeza de una expresión no es digital (cierto-falso) sino mas bien
análogo.

14 - 120
2.2.1. Definición de Lógica Difusa

La lógica difusa se aplicó a mediados de la década de 1970 por Ebrahim H. Mamdani en

el Queen Mary Collage en Londres. Mamdani diseñó un controlador difuso para un motor
a vapor. Desde entonces el término lógica difusa es sinónimo de cualquier sistema
matemático o computacional que razona con lógica difusa. La noción de sistemas difusos
consiste en que los valores verdaderos (en lógica difusa) o valores de pertenencia (en
conjuntos difusos) se indican en un número entre [0.0, 1.0], donde 0.0 representa falsedad
total y 1.0 significa verdad absoluta (Huilcapi, 2015).

En 1965 Lofti A. Zadeh formula las bases iniciales de la Teoría de Conjuntos Difusos y
ésta experimenta desde entonces un gran desarrollo teórico aplicándose en una variedad
de campos entre los que se encuentran el control automático. Sin embargo es en 1973
cuando Zadeth presenta la teoría básica sobre la cual construir los controladores difusos.
Mamdani y sus colaboradores, siguiendo los trabajos de Zadeh, investigan nuevas
aplicaciones del control difuso e introducen la lógica difusa y las técnicas basadas en
reglas como forma de captar la experiencia humana. Estos conceptos se aplicaron
enseguida a procesos industriales pocos definidos o demasiados complejos para admitir
un modelado analítico convencional. Los procesos sin embargo eran controlados
normalmente por operadores expertos que, mediante reglas de naturaleza imprecisa,
obtenían buenos resultados a pesar de tener que tomar decisiones con información
imprecisa o incompleta. Estos estudios fueron desarrollados muchos más a fondo en
Japón y China y quedaron un poco olvidados en Estados unidos y Europa (Flint, 2001).

Los controladores difusos pueden ser considerados como sistemas con una base de
conocimiento, incorporando el conocimiento humano a través de reglas difusas y funciones
miembro.

La definición de estas reglas y sus funciones están de hecho afectadas a decisiones

subjetivas teniendo una gran influencia sobre el funcionamiento del controlador difuso.
Desde este punto de vista los controladores difusos pueden ser interpretados como un tipo
15 - 120
de sistema de control experto en tiempo real. Una segunda interpretación más adecuada
por las propiedades del análisis de control del controlador difuso es pensar en el como un
sistema con unas leyes de control no lineales e invariantes con el tiempo.

A partir de estas conceptos se han ido introduciendo mejoras en el funcionamiento de los

controladores difusos, para conseguir una mejor aproximación a un controlador óptimo,
incorporando mecanismos de aprendizaje y adaptación de reglas y de funciones miembro.

2.2.2. Sistemas Difusos

Los fundamentos de los sistemas difusos se encuentran en la lógica difusa. La lógica difusa
o borrosa es una técnica de computación flexible que le permite a un computador clasificar
información del mundo real en una escala infinita acotada por los valores falso y verdadero;
tiene por objetivo proporcionar un soporte matemático formal al razonamiento basado en
el lenguaje natural, el cual se caracteriza por tratarse de un razonamiento de tipo
aproximado que hace uso de proposiciones que expresan información de carácter
impreciso.

Algunas características de la lógica difusa que la hacen de tanto interés son 8:

• Es fácil de entender, los conceptos matemáticos son bastante sencillos.

• Es flexible, su escalamiento es sencillo.
• Es tolerante a datos imprecisos.
• Puede modelar funciones no -lineales de complejidad arbitraria.
• Puede ser construida sobre la información de la experiencia de los operarios que
manejan el sistema que se desea automatizar.
• Puede ser complementaria a las técnicas de control convencionales.
• Está basada en el lenguaje utilizado por los humanos.

La lógica difusa debe ser distinguida de la incertidumbre en el sentido en que la lógica

difusa describe la ambigüedad de un evento, mientras que la incertidumbre la ocurrencia
16 - 120
de un evento. Específicamente, el concept o incerteza se refiere a la incerteza
estocástica, que se caracteriza por referirse a eventos bien definidos, por ejemplo,

La probabilidad de que el motor falle es de 80%

La lógica difusa trata con incertezas lingüísticas del tipo:

El motor falla constantemente.

2.3. INGENIERIA DE SOFTWARE

2.3.1. Definición de Software

El software es un conjunto de instrucciones que cuando se ejecutan proporcionan las

características, función y desempeño buscados. Son estructuras de datos que permiten
que los programas manipulen en forma adecuada la información y finalmente es la
información descriptiva tanto en papel como en formas virtuales que describen la operación
y uso de programas (Pressman, 2010).

2.3.2. Dominios de Aplicación

Se tienen siete grandes Dominios de Aplicaciones Software de computadora (Pressman,

2010), de los cuales se mencionan los dos más relevantes para el presente trabajo:

• Software basado en Web. Denominadas también “webapps”; en su forma más

básica son un conjunto de archivos de hipertexto vinculados que proporcionan
información con texto y graficas limitadas, sin embargo, con el surgimiento de Web
2.0 evolucionaron a ambientes de computo sofisticados que permiten su
integración con bases de datos corporativas y aplicaciones de negocios.
(Pressman, 2010).
• Software de inteligencia artificial. Hace uso de algoritmos no numéricos para
resolver problemas complejos cuya solución no es posible de determinar con el
análisis directo o el tratamiento computacional. Esta área incluye aplicaciones de
17 - 120
 robótica, sistemas expertos, reconocimiento de patrones, redes neuronales,
demostración de teoremas y juegos. (Pressman, 2010).

2.3.3. Definición de Ingeniería de software

“La Ingeniería del Software es el establecimiento y uso de principios fundamentales de la

ingeniería con objeto de desarrollar en forma económica software que sea confiable y que
trabaje con eficiencia en máquinas reales”. (Bauer citado en Pressman, 2010).

La ingeniería de software es una tecnología con varias capas. Como se aprecia en la

Figura 2, cualquier enfoque de ingeniería (incluso la de software) debe basarse en un
compromiso organizacional con la calidad. La administración total de la calidad, Six Sigma
y otras filosofías similares alimentan la cultura de mejora continua, y es esta cultura la que
lleva en última instancia al desarrollo de enfoques cada vez más eficaces de la ingeniería
de software.

Figura 2. Capas de Ingeniería de Software

Fuente: Fundamentos de la Ingeniería de Software, Pressman

El fundamento en el que se apoya la ingeniería de software es el compromiso con la

calidad. El fundamento para la ingeniería de software es la capa proceso.

El proceso de ingeniería de software es el aglutinante que une las capas de la tecnología

y permite el desarrollo racional y oportuno del software de cómputo. El proceso define una
estructura que debe establecerse para la obtención eficaz de tecnología de ingeniería de

18 - 120
software. El proceso de software forma la base para el control de la administración de
proyectos de software, y establece el contexto en el que se aplican métodos técnicos, se
generan productos del trabajo (modelos, documentos, datos, reportes, formatos, etc.), se
establecen puntos de referencia, se asegura la calidad y se administra el cambio de
manera apropiada. (Pressman, 2010).

Los métodos de la ingeniería de software proporcionan la experiencia técnica para elaborar

software. Incluyen un conjunto amplio de tareas, como comunicación, análisis de los
requerimientos, modelación del diseño, construcción del programa, pruebas y apoyo. Los
métodos de la ingeniería de software se basan en un conjunto de principios fundamentales
que gobiernan cada área de la tecnología e incluyen actividades de modelación y otras
técnicas descriptivas.

Las herramientas de la ingeniería de software proporcionan un apoyo automatizado o semi

automatizado para el proceso y los métodos. Cuando se integran las herramientas de
modo que la información creada por una pueda ser utilizada por otra, queda establecido
un sistema llamado ingeniería de software asistido por computadora que apoya el
desarrollo de software. (Pressman, 2010).

2.3.4. Lenguaje Unificado de Modelado (UML)

El Lenguaje Unificado de Modelado, conocido como lenguaje UML por sus siglas en ingles
(Unified Modeling Language), describe un estándar para describir un modelo de sistema,
incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema
y aspectos concretos como expresiones de lenguaje de programación, esquema de base
de datos y componentes utilizables. (Fowler & Scott).

UML fue creado por Grady Booch, James Rumbaugh e Ivar Jacobson, quienes por la
década de los años ochenta y principios de los noventa, diseñaron independientemente
una metodología para el análisis y diseño orientado a objetos y a mediados de los años
noventa empezaron a intercambiar ideas para dar la creación de la notación de UML; este
lenguaje prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas
19 - 120
orientados a objetos, y describe la semántica esencial del significado de estos diagramas
y símbolos (Fowler & Scott).

2.3.4.1. Diagramas UML

El lenguaje UML tuvo un gran éxito como estándar, debido a esto se determinó el estándar
UML 2.0 que con las mejoras correspondientes de las primeras versiones de UML, define
13 diagramas UML que se definen en tres clases y dos grupos generales.

• Diagrama Estructural. Muestran los elementos de una especificación que sean

independientes del tiempo. Los diagramas estructurales son: diagrama de clases,
diagrama de estructura de componentes, diagrama de componentes, diagrama de
despliegue, diagrama de objetos y diagramas de paquetes.

• Diagrama de Comportamiento. Permiten exhibir comportamientos de un sistema

o de los procesos de las organizaciones. Incluyen los diagramas de actividad,
estado y de caso de uso.

• Diagrama de Interacción. Es un subconjunto de los diagramas de

comportamiento que permiten enfatizar las interacciones entre los objetos.
Incluyen los diagramas de comunicación, diagramas de vista general de
interacciones, diagramas de secuencia y diagrama de tiempo.

A continuación se presenta una descripción de los diagramas UML que serán utilizados

a) Diagrama de Caso de Uso.- Un diagrama de casos de uso, es definido a

principalmente través del modelado de casos de uso que básicamente son
utilizados para capturar los requisitos funcionales del sistema y lograr documentar
como el usuario percibe el funcionamiento del prototipo. Los diagramas de caso
de uso, están formados por tres elementos que se pueden observar en la Figura
3.:

20 - 120
• Actor: Que representa cualquier elemento que intercambia información con el
sistema, por lo que está fuera de él.

• Caso de Uso: Es una secuencia de intercambios en diálogo con el sistema que

se encuentran relacionadas por su comportamiento.

• Los Arcos: Entre los actores y los casos de uso se denominan arcos de
comunicación.

Figura 3. Diagrama de Caso de Uso

Fuente: Elaboración Propia en Base a Diagrama de Casos de Uso, Fowler & Scott

b) Diagrama de Secuencia. Es uno de los diagramas más efectivos para modelar

interacción entre objetos en un sistema se modela para cada caso de uso. Mientras
que el caso de uso permite el modelado de una vista “de negocio” del escenario,
el diagrama de secuencia contiene detalles de implementación, incluyendo los
objetos y clases que se usan para implementar el escenario, y mensajes pasados
entre los objetos como se ve en la Figura 4.

Muestra los objetos que intervienen en el escenario con líneas discontinuas

verticales, y los mensajes pasados entre los objetos como vectores horizontales.

21 - 120
 Los mensajes se dibujan cronológicamente desde la parte superior y parte inferior;
la distribución horizontal es arbitraria (Popkin software and systems, 2002).

Figura 4. Diagrama de Secuencia

Fuente: Diagrama de Secuencia, Fowler & Scott

c) Diagrama de Clases. Es el diagrama principal en la fase de diseño, debido a que

describen la estructura estática del sistema. Las cosas que existen y que nos
rodean se agrupan naturalmente en categorías o grupo de cosas que tienen
atributos (propiedades) y acciones similares, está formado por varios rectángulos
de este tipo conectados por líneas que representan las asociaciones o maneras
en que se relacionan entre sí, como se muestra en la figura 5.
Muestra un conjunto de clases, interfaces, y colaboraciones y sus relaciones entre
ellos: clase tiene a atributos, métodos y visibilidad; relaciones que puede ser de
herencia, composición, agregación, asociación y uso (Popkin software and systems,
2002).

22 - 120
 Figura 5. Diagrama de Clases

Fuente: Elaboración Propia en Base a Diagrama de Clases, Fowler & Scott, 2000

d) Diagrama de Componentes. Son las dependencias lógicas entre componentes

software, sean éstos componentes fuentes, binarios o ejecutables, controladores
embebidos, etc. Se relacionan con los diagramas de clases, ya que un
componente normalmente se corresponde con una o más, interfaces o
colaboraciones pero el de componentes tiene un nivel más alto de abstracción que
la de clase (Popkin software and systems, 2002).

Los componentes se representan como un clasificador rectangular con la clave

«componente», opcionalmente se puede mostrar como un rectángulo con un icono
en la esquina derecha arriba.
Figura 6. Diagrama de Componentes

Fuente: Diagrama de Componentes, Fowler & Scott, 2000

23 - 120
2.3.5. Pruebas de Software

La prueba es el proceso de ejecución de un programa con la intención de descubrir un

error. Un buen caso de prueba es aquel que tiene una sola probabilidad demostrar un error
no descubierto hasta entonces (Pressman, 2005).

Para el diseño de pruebas de software, se tomarán en cuenta dos para el desarrollo de la

plataforma de aprendizaje: caja blanca, se centra en la organización interna del programa
y de caja negra, se centra en las funciones, entradas y salidas.

2.3.5.1. Prueba de Caja Blanca

La prueba de caja blanca, en ocasiones llamada prueba de caja de cristal, es un método

de diseño que usa la estructura de control descrita como parte del diseño al nivel de
componentes para derivar los casos de prueba. Al emplear los métodos de prueba de caja
blanca, el ingeniero del software podrá derivar casos de prueba que: (Pressman, 2005)

a. Garanticen que todas las rutas independientes dentro del módulo se han ejercitado
por lo menos una vez.

b. Ejerciten los lados verdadero y falso de todas las decisiones lógicas.

c. Ejecuten todos los bucles en sus límites y dentro de sus límites operacionales.

d. Ejerciten estructuras de datos internos para asegurar su validez.

Se basa en el estudio minucioso de toda la operatividad de una parte del sistema,

considerando los detalles procedurales. Se plantean distintos caminos de ejecución
alternativos y se llevan a cabo para observar los resultados y contrastarlos con lo esperado
(Molina, Sánchez, Letelier & Sánchez, 1997).

24 - 120
2.3.5.2. Prueba de Caja Negra

Las pruebas de caja negra, también denominadas, pruebas de comportamiento, se

concentran en los requisitos funcionales del software. Es decir, permiten al ingeniero de
software derivar conjuntos de condiciones de entrada que ejercitarán por completo todos
los requisitos funcionales de un programa. No es una opción frente a las técnicas de caja
blanca. Es, en cambio, un enfoque complementario que tiene probabilidades de descubrir
una clase diferente errores de los que se descubrirían con los métodos de caja blanca
(Pressman, 2005)

Las pruebas de caja negra tratan de encontrar errores en las siguientes categorías:

a. Funciones incorrectas o faltantes.

b. Errores de interfaz.

c. Errores en estructuras de datos o en acceso a bases de datos externas.

d. Errores de comportamiento o desempeño.

e. Errores de inicialización y término.

Los métodos de la caja negra se enfocan los requisitos funcionales del software
permitiendo al ingeniero el disponer de conjuntos de valores de entrada que ejercitan de
forma completa todos los requisitos del programa (Molina, Sánchez, Letelier & Sánchez,
1997).

Después de describir las características importantes de la ingeniería de software que serán

fundamento teórico para la construcción de la plataforma de aprendizaje, a continuación,
se describe el modelo de costes de software que ayudará a analizar la rentabilidad de la
plataforma de aprendizaje.

25 - 120
2.3.6. Costo de Software

El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés Contructutive

Cost Model) es un modelo de estimación de costes de software que incluye tres sub-
modelos donde cada uno ofrece un nivel de detalle y aproximación cada vez mayor, a
medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado
(UPV, 2006).

Este será el modelo utilizado al finalizar el proyecto para estimar los costos del mismo.
Pertenece a la categoría de modelos de subestimaciones basados en estimaciones
matemáticas. Está orientada a la magnitud del producto final, midiendo el "tamaño" del
proyecto, en líneas de código principalmente.

El modelo COCOMO está compuesto por tres sub-modelos de estimación según el nivel
de detalle empleado en su utilización: básico, intermedio y detallado. En los tres sub-
modelos se pretende calcular tres importantes factores para determinar el costo total del
software:

• Esfuerzo (E) necesario para concretar un proyecto de desarrollo de software, que

es expresado en persona/mes y representa los meses de trabajo de una persona
requeridos para desarrollar el proyecto.

• Tiempo de Desarrollo (Tdev) necesario para concertar el desarrollo del software,

expresado en meses.

• Cantidad de Personas (P) promedio para concretar el desarrollo del software,

expresado en personas.

Las ecuaciones que se utilizan en los tres modelos son:

26 - 120
 Ecuación de Esfuerzo

𝐸 = (𝑎𝐾𝑙)𝑏 ∗ 𝑚(𝑋), en personas meses (1)

Ecuación de Tiempo de Desarrollo

𝑇𝑑𝑒𝑣 = 𝑐 ∗ (𝐸)𝑑 , en meses (2)

Ecuación de Cantidad de Personas

𝐸
𝑝 = 𝑇𝑑𝑒𝑣, en personas (3)

Dónde:

E es el esfuerzo requerido por el proyecto, en persona-mes

Tdev es el tiempo requerido por el proyecto, en meses

P es el número de personas requerido por el proyecto

a, b, c y d son constantes con valores definidos en una tabla, según cada submodelo

Kl es la cantidad de líneas de código, en miles.

m(X) Es un multiplicador que depende de 15 atributos

Por otra parte, cada sub-modelo contiene una sub-clasificación de tres modos de
desarrollo, que pueden ser del tipo: orgánico, semi-libre y empotrado (Ruiz, 1999).

• Modo Orgánico: Proyectos donde el tamaño del software no es más de 50

KLCD15 (50.000 líneas de código), desarrollan en base a áreas muy específicas

27 - 120
 y bien conocidas por el equipo participante (normalmente un pequeño grupo de
programadores experimentados)

• Modo Semi-Libre o Semi-Empotrado: Proyectos donde el tamaño del software

tiene un tamaño menor a 300 KLCD (300.000 líneas de código), el grupo de trabajo
de desarrollo puede incluir una mezcla de personas experimentadas y no
experimentadas.

• Modo Empotrado o Rígido: Proyectos donde el tamaño del software es superior

a 3000 KLCD, normalmente compuesto por un grupo de trabajo de desarrollo
numeroso que no necesariamente son experimentadas, los proyectos
correspondientes a este modo suelen presentar exigencia de altos niveles de
fiabilidad y restricciones que pueden estar relacionadas con la funcionalidad y/o
características técnicas.

2.4. CAPACITACIÓN DE PERSONAL

2.4.1. Definición de Capacitación

La capacitación es una actividad planteada y basada en necesidades reales de una

empresa u organización y orientada hacia un cambio en los conocimientos, habilidades y
actitudes del colaborador (Siliceo, 2009)

2.4.2. Características de la Capacitación al Personal

La capacitación se lleva a cabo por profesional que conoce de qué se trata el tema, un
simple cambio de contexto puede influir en el aprendizaje y en las posibilidades de
transferir el conocimiento.

El tiempo requerido para la capacitación puede reducirse drásticamente con una

cuidadosa selección del personal. Pero aun en este caso, los supervisores agrícolas

28 - 120
pueden tener que actuar como entrenadores. La mayoría de los trabajadores prefieren un
trabajo que les permita ampliar sus conocimientos y experiencia (Billikopf, 2006).

La necesidad de capacitación puede manifestarse en:

• Datos de selección de personal;

• Evaluaciones de desempeño;
• Capacidad, conocimientos y experiencia de los trabajadores;
• Introducción de nuevos métodos de trabajo, maquinaria o equipos;
• Planificación para vacantes o ascensos en un futuro.
• Leyes y reglamentos que requieran entrenamiento.

Al establecer un programa de capacitación, el primer paso consiste en coordinar las

necesidades (introducción de un nuevo equipo o maquinaria agrícola) con objetivos de
aprendizaje específicos (al finalizar su capacitación, los trabajadores entrenados sabrán
mantener y manejar el equipo sin peligro). Algunos objetivos pueden cuantificarse mejor,
tal como "el 95% de la fruta cosechada deberá ser apta para ser exportada".

Figura 7. Capacitación del Personal

Fuente: Importancia de la Capacitación

Los elementos para evaluar el cumplimiento de los objetivos deben establecerse desde el
principio. Es necesario determinar las diferencias entre los conocimientos de los

29 - 120
trabajadores y los objetivos propuestos para evitar la repetición de datos conocidos o la
suposición de conocimientos inexistentes.

Cuando se les pregunta a los trabajadores si tienen los conocimientos necesarios para el
puesto, no siempre se obtiene una respuesta veraz. Algunos trabajadores creen que si no
responden afirmativamente, no obtendrán las oportunidades que desean. Otros pueden
ocultar su falta de conocimientos o comprensión por timidez o temor.

Es necesario evaluar la competencia de cada trabajador para que pueda desempeñarse

en forma independiente. El personal debe tener la oportunidad de demostrar sus
conocimientos prácticos sin humillaciones ni riesgos personales. (Billikopf, 2006).

Para que los programas formativos sean eficaces y tanto empresa como trabajadores
consigan los objetivos deseados, se necesita trazar un plan acerca de cómo se van a
formar a los trabajadores. Se hace en 3 fases:

• Fase de entrada: En primer lugar, hay que saber qué formación necesitan los
empleados y para esto hay que conocer sus carencias. Una forma de ver estas
carencias viene de las evaluaciones de desempeño. Con ellas se puede ver si el
personal es realmente eficiente para lo que tiene que realizar. Otras formas de
analizar las posibles carencias son simplemente observando a los empleados,
hablando con ellos o pasando cuestionarios o pruebas escritas.
• Constitución del programa de capacitación: La definición de este programa
está compuesta por las siguientes fases:
• Definir el objetivo.
• Definir el contenido.
• Elegir el método y los recursos humanos y materiales necesarios.
• Periodicidad con la que se impartirá y lugar donde se hará.
• Después de esto se llevarán a cabo las sesiones con un docente especialista
en la materia que interesa.

30 - 120
 • Evaluación: Por último, y no menos importante, se debe evaluar lo que se está
consiguiendo. Hay que ver si los empleados están asimilando la formación y si
realmente les está sirviendo para su día a día. Una vez terminadas las sesiones,
habrá realizar una evaluación oral o escrita para ver si se ha conseguido lo
esperado. Según el resultado se valorará si continuar con la formación,
reorientarla, suspenderla o cambiar por otro tipo de formación que se vea más útil.
Bajo estas líneas te presentamos un vídeo que nos habla sobre la importancia de
que la capacitación sea un aprendizaje práctico donde los empleados estén
involucrados. Si solo se les dan charlas quizá no lo vean útil. Pero si además se
les presentan ejercicios relacionados con su puesto de trabajo donde ellos tengan
que emplear lo aprendido, el proceso de aprendizaje será más rápido.

2.4.3. Beneficios de la Capacitación al Personal

La capacitación permite evitar la obsolescencia de los conocimientos del personal, que

ocurre generalmente entre los empleados más antiguos si no han sido reentrenados.

También permite adaptarse a los rápidos cambios sociales, como la situación de las
mujeres que trabajan, el aumento de la población con títulos universitarios, la mayor
esperanza de vida, los continuos cambios de productos y servicios, el avance de la
informática en todas las áreas, y las crecientes y diversas demandas del mercado.
Disminuye la tasa de rotación de personal, y permite entrenar sustitutos que puedan
ocupar nuevas funciones rápida y eficazmente.

Por ello, las inversiones en capacitación redundan en beneficios tanto para la persona
entrenada como para la empresa que la entrena. Y las empresas que mayores esfuerzos
realizan en este sentido, son las que más se beneficiarán en los mercados
hipercompetitivos que llegaron para quedarse (Frigo, 2011).

Los campos de aplicación de la capacitación son muchos, pero en general entran en una
de las cuatro áreas siguientes:

31 - 120
 a) Inducción: Es la información que se brinda a los empleados recién ingresados.
Generalmente lo hacen los supervisores del ingresante. El departamento de
RRHH establece por escrito las pautas, de modo de que la acción sea uniforme y
planificada.
b) Entrenamiento: Se aplica al personal operativo. En general se da en el mismo
puesto de trabajo. La capacitación se hace necesaria cuando hay novedades que
afectan tareas o funciones, o cuando se hace necesario elevar el nivel general de
conocimientos del personal operativo. Las instrucciones para cada puesto de
trabajo deberían ser puestas por escrito.
c) Formación básica: Se desarrolla en organizaciones de cierta envergadura; procura
personal especialmente preparado, con un conocimiento general de toda la
organización. Se toma en general profesionales jóvenes, que reciben instrucción
completa sobre la empresa, y luego reciben destino. Son los "oficiales" del futuro.
d) Desarrollo de jefes: Suele ser lo mas difícil, porque se trata de desarrollar mas
bien actitudes que conocimientos y habilidades concretas. En todas las demás
acciones de capacitación, es necesario el compromiso de la gerencia. Aquí, es
primordial el compromiso de la gerencia general, y de los máximos niveles de la
organización. El estilo gerencial de una empresa se logra no solo trabajando en
común, sino sobre todo con reflexión común sobre los problemas de la gerencia.
Deberían difundirse temas como la administración del tiempo, conducción de
reuniones, análisis y toma de decisiones, y otros.

En cualquiera de los casos, debe planificarse adecuadamente tanto la secuencia como el

contenido de las actividades, de modo de obtener un máximo alineamiento.

2.4.4. Definición de Capacitación al Personal en la empresa INTI

La capacitación es un conjunto de actividades didácticas orientadas a suplir las

necesidades de la empresa y que se orientan hacia una ampliación de los conocimientos,
habilidades y aptitudes de los empleados (de las diferentes áreas) la cual les permitirá
desarrollar sus actividades de manera eficiente.
32 - 120
2.4.5. Métodos de recolección de datos

Los métodos y técnicas de recolección de datos pueden dividirse en dos categorías:

métodos primarios de recolección de datos y métodos secundarios de recolección de
datos.

2.4.5.1. Métodos de recolección de datos primarios

Los datos primarios se recolectan de la experiencia de primera mano y no se utilizan en el

pasado. Esta información es específica, altamente auténtica y precisa.

Los métodos de recolección de datos primarios pueden dividirse en dos categorías:

métodos cuantitativos y métodos cualitativos.

a) Métodos cuantitativos

Los métodos cuantitativos para la investigación de mercados y la previsión de la

demanda suelen utilizar herramientas estadísticas. Aquí, la demanda se
pronostica sobre la base de datos históricos.

Estos métodos y técnicas de recolección de datos primarios se utilizan

generalmente para hacer pronósticos a largo plazo. Son altamente confiables, ya
que el elemento de subjetividad es mínimo.

• Análisis de series cronológicas o temporales: El término se refiere a un

orden secuencial de valores de una variable, conocido como tendencia a
intervalos de tiempo iguales. Utilizando tendencias, una organización puede
predecir la demanda de sus productos y servicios para el tiempo
proyectado.

• Técnicas de suavizado: En los casos en que la serie temporal carece de

tendencias significativas, se pueden utilizar técnicas de suavizado para
33 - 120
 eliminar una variación aleatoria de la demanda histórica. Esto ayuda a
identificar patrones y niveles de demanda que pueden ser usados para
estimar la demanda futura.

Los métodos más comunes utilizados en las técnicas de suavizado de la

previsión de la demanda son el método de media móvil simple y el método
de media móvil ponderada.

• Método Barométrico: También conocido como el enfoque de los

indicadores principales, este método se utiliza para especular sobre las
tendencias futuras en función de la evolución actual. Cuando un evento
pasado se considera para predecir el evento futuro, el evento pasado
actuaría como un indicador principal.

b) Métodos cualitativos

Los métodos de recolección de datos cualitativos son especialmente útiles en

situaciones en las que no se dispone de datos históricos, no se necesitan números
ni cálculos matemáticos.

La investigación cualitativa está estrechamente relacionada con palabras, sonidos,

sentimientos, emociones, colores y otros elementos que no son cuantificables.

Estas técnicas se basan en la experiencia, el juicio, la intuición, las conjeturas, las

emociones, etc.

Los métodos y técnicas de recolección de datos cuantitativos no proporcionan el

motivo de las respuestas de los participantes, a menudo no llegan a las
poblaciones subrepresentadas y pueden abarcar largos períodos de tiempo para
recopilar los datos. Por lo tanto, es mejor combinar métodos cuantitativos con
métodos cualitativos.

34 - 120
Estos son algunos de los métodos de recolección de datos cualitativos:

• Encuestas:

Las encuestas se utilizan para recopilar datos de la audiencia objetivo y

recoger información sobre sus preferencias, opiniones, elecciones y
comentarios relacionados con tus productos y servicios.

La mayoría de los programas de creación de encuestas a menudo ofrecen

una amplia gama de tipos de preguntas para seleccionar.

También puedes utilizar una plantilla de encuesta ya preparada para ahorrar

tiempo y esfuerzo. Las encuestas en línea se pueden personalizar según la
marca de la empresa cambiando el tema, el logotipo, etc.

Existen diversos métodos de distribución de encuestas, como vía correo

electrónico, sitio web, aplicación offline, código QR, redes sociales, etc.
Dependiendo del tipo y la fuente de su audiencia, puede seleccionar el
canal.

Un panel de encuestas puede proporcionar estadísticas relacionadas con la

tasa de respuesta, la tasa de finalización, los filtros basados en la
demografía, las opciones de exportación y uso compartido, etc.

Una vez recopilados los datos, el software para encuestas puede generar
varios tipos de informes y ejecutar algoritmos analíticos para descubrir
información oculta.

• Sondeos:

35 - 120
Los sondeos se componen de una pregunta de opción única o múltiple.
Cuando se requiere tener un pulso rápido de los sentimientos de la
audiencia, puedes ir a las encuestas. Debido a que son de corta duración,
es más fácil obtener respuestas de la gente.

También se pueden integrar en varias plataformas. Una vez que los

encuestados responden a la pregunta, también se les puede mostrar cómo
se encuentran en comparación con las respuestas de los demás.

• Entrevistas:

En este método, el entrevistador hace preguntas cara a cara o por teléfono

a los encuestados. En las entrevistas cara a cara, el entrevistador hace una
serie de preguntas al entrevistado en persona y anota las respuestas.

En caso de que no sea posible conocer a la persona, el entrevistador puede

apoyarse en una entrevista telefónica.

A diferencia de los otros métodos de recolección de datos, este es

adecuado cuando sólo hay unos pocos encuestados. Es demasiado largo y
tedioso repetir el mismo proceso si hay muchos participantes.

• Técnica Delphi:

En él, los expertos del mercado reciben las estimaciones y suposiciones de

los pronósticos realizados por otros expertos de la industria. Pueden
reconsiderar y revisar sus propias estimaciones e hipótesis sobre la base
de la información proporcionada.

• Focus Group:

36 - 120
 Es otro de los métodos y técnicas de recolección de datos en donde un
pequeño grupo de personas, alrededor de 8-10 miembros, se reúnen para
discutir las áreas comunes del problema con un moderador que regula la
discusión.

Cada participante aporta sus puntos de vista sobre el tema en cuestión. Al

final de la discusión, el grupo llega a un consenso.

• Cuestionario:

Un cuestionario es un conjunto impreso de preguntas, abiertas o cerradas,

que los encuestados deben responder en función de sus conocimientos y
experiencia con el tema.

El cuestionario es parte de la encuesta, mientras que el objetivo final de un

cuestionario puede o no ser una encuesta.

2.4.5.2. Métodos y técnicas de recolección de datos secundarias

Los métodos y técnicas de recolección de datos secundarios son los datos que se han
utilizado en el pasado. El investigador puede obtener datos de las fuentes tanto internas
como externas a la organización.

Fuentes internas de datos secundarios:

• Registros de salud y seguridad de la organización

• Declaraciones de misión y visión

• Estados Financieros

• Revistas
37 - 120
 • Informe de ventas

• Software CRM

• Resúmenes ejecutivos

Fuentes externas de datos secundarios:

• Informes de los gobiernos

• Comunicados de prensa

• Revistas de negocios

• Bibliotecas

• Internet

La recolección de datos secundarios también pueden incluir técnicas cuantitativas y

cualitativas. Estos se encuentran fácilmente disponibles y, por lo tanto, son menos lentos
y caros en comparación con los datos primarios.

Sin embargo, en el caso de los métodos secundarios de recogida de datos, no se puede

verificar la autenticidad de los datos recogidos.

2.5. METODOLOGÍA TDD

2.5.1. TDD

El desarrollo de software plantea muchos desafíos a los equipos de trabajo, estos retos
van desde entender lo que el mercado y los clientes necesitan, hasta brindar soluciones

38 - 120
integrales que cubran todos los aspectos de una organización manteniendo los costos
controlados y brindando valor a las organizaciones.

En los comienzos de la industria del software la metodología más utilizada era el desarrollo
en cascada, en la cual se planteaban los requerimientos inicialmente y se avanzaba en
etapas. Con la incorporación del software a todos los aspectos de la vida estos
requerimientos comenzaron a cambiar a un ritmo acelerado, volviendo obsoleta la
metodología que había imperado. Acompañando esta evolución de la industria apareció
“Programación Extrema”(XP) (Beck, 1999).

Como parte de XP, Test Driven Development (TDD) es una práctica iterativa de diseño de
software orientado a objetos, que fue presentada por Kent Beck y Ward Cunningham,
quienes la definieron como el núcleo de XP.

l Test Desarrollo impulsado - TDD - Desarrollo Orientado a Pruebas es el desarrollo de

software orientado a objetos que incluye Naciones Unidas ciclo desarrollado con pruebas
constantes, se emplea en las metodologías ágiles, en las veces que se escriba código
parezca superar las pruebas que se han especificado con anterioridad, y en algunas
ocasiones sustituyen la especificación de requisitos.

EL TDD se subdivide en tres fases:

• Escribir las pruebas antes del desarrollo del código

• Automatización de las pruebas escritas
• Refactorización del código

39 - 120
 Figura 8. Test-Driven Development

Fuente: Importancia de la Capacitación

2.5.2. CARACTERÍSTICAS

Test Driven Development (Desarrollo Dirigido por Pruebas) es una disciplina iterativa e
incremental de diseño y programación, donde cada nueva línea de código se escribe en
respuesta a una prueba fallida que el propio programador ha programado. Es parte
medular del desarrollo ágil de código derivado de XP, donde resulta en una práctica crítica,
y de los principios del Manifiesto Ágil. Apoyada en la popularidad de XP, Test Driven
Development ha tenido gran difusión mundial en los últimos años, pudiéndose adoptarse
dentro de cualquier otro tipo de proceso de desarrollo de Software. Su principal objetivo es
obtener “Código limpio que trabaje”(Beck, 1999).

Las características del Test Driven Development son:

Evitar escribir código innecesario, se intenta escribir el mínimo posible, y si el código

pasa una prueba y falla, da una idea de cómo modificar nuestra lista de requerimientos
agregando nuevos.

40 - 120
Generar pruebas para cada funcionalidad hace que el desarrollador confíe en el código
escrito. Esto facilita futuras modificaciones, ya que si se logra asegurar el paso de todas
las pruebas se obtendrá un código que funcione correctamente.

TDD requiere que el desarrollador haga fallar los casos de prueba. Se intenta asegurar
el funcionamiento de los casos de prueba y de esta forma pueda recoger un error.

EL desarrollo guiado por pruebas (TDD) puede proporcionar un gran valor agregado en
la creación de software, produciendo aplicaciones de calidad y en menos tiempo.

TDD tiene la capacidad de avanzar en pequeños pasos, permite al desarrollador

centrarse en la tarea actual y hacer que el test pase.

Todo el proyecto se encuentra cubierto de pruebas, aumentado la confianza sobre lo

desarrollado.

2.5.3. CICLO DE DESARROLLO DEL TDD

A continuación, se describe el ciclo de desarrollo del TDD y los niveles aplicables de

esta técnica. (Araújo, 2007), (Jurado, 2010).

Test Driven Development (TDD) es una disciplina iterativa e incremental de diseño

y programación. Es parte fundamental del desarrollo ágil derivado de XP, su
principal objetivo es obtener “Código limpio que trabaje”

TDD puede ser aplicado en dos niveles (Mugridge, 2006):

• Nivel de micro-iteraciones: En el nivel de micro-Iteraciones el desarrollo es guiado

por pruebas unitarias diseñadas por el programador, (Mugridge, 2006) señala los
siguientes pasos:
• Rápidamente agregar una prueba.
• Correr todas las pruebas y comprobar que solo la nueva falla.
41 - 120
 • Hacer un pequeño cambio.
• Correr todas las pruebas y comprobar que pasan satisfactoriamente.
• Reconstruir para remover duplicaciones.

Los pasos anteriormente mencionados se describen en el siguiente diagrama de

actividad de la Figura 9.

Figura 9. Ciclo TDD

Fuente: Beck, TDD

El algoritmo descrito en la anterior ilustración:

• Escribir la especificación del requisito (el ejemplo, el test).

• Implementar el código según dicho ejemplo.

42 - 120
 • Re factorizar para eliminar duplicidad y hacer mejoras.

Escribir la especificación del requerimiento

Después de tener claro cuál es el requisito, el programador lo expresa en forma de

código. La primera interrogante que se plantea es:

¿Cómo implementar un test para un código que no existe?, para esto se debe
desarrollar la habilidad de imaginar cómo sería el código del SUT si ya estuviera
implementado y cómo se comprobará su efectividad bajo unapetición.

Lógicamente en esta fase el test no pasará, debido a la falta de una clase a al que
haga referencia el test.

Implementar el código según dicho ejemplo

Una vez codificado el test, implemente el mínimo necesario para que el test pase. Es
recomendable aplicar la programación por intención (Programming by intention) práctica
extraída de XP, la cual implica no detenerse a pensar cómo conseguir un objetivo, sino en
lo que se debe hacer para conseguir el objetivo. (Anderson, 2000)

Re factorizar para eliminar duplicidad y hacer mejoras

(Martin, 2002) Define la refactorización como una práctica que se enfoca en mejorar el
código existente, de manera disciplinada, sin alterar su funcionalidad externa, para hacer
más fácil de entender y modificar. De esta forma la reconstrucción no significa reescribir el
código, sino rastrear el código en busca de líneas duplicadas, además de verificar si el
código cumple con ciertos principios de diseño, para este fin se puede implementar los
criterios de S.O.L.I.D. (Jurado, 2010)

• Nivel Iteración o Funcional:

43 - 120
 En este nivel el desarrollo es guiado por pruebas de aceptación (ATDD) (Jurado,
2010), se menciona los siguientes pasos:

• El usuario especifica pruebas antes que las funcionalidades sean

implementadas.
• Una vez que el código es escrito la prueba sirve como un criterio de
aceptación.

2.5.4. RESULTADO DE DESARROLLO DEL TDD

Los detractores de TDD argumentan que no se puede utilizar esta metodología en grandes
proyectos, este punto se puede contrastar con lo que dice Carlos Ble Jurado: “¿Y TDD
sirve para proyectos grandes?

Un proyecto grande no es sino la agrupación de pequeños sub- proyectos y es ahora

cuando toca aplicar aquello de divide y vencerás (Jurado, 2010). El tamaño del proyecto
no guarda relación con la aplicabilidad de TDD.

En los grandes proyectos será necesario contar con un equipo de mayor tamaño para
implementar TDD. Investigadores de la Escuela de Computación y Ciencias Matemáticas
de la Universidad de Auckland en Nueva Zelanda realizaron un trabajo (Buchan,
2014)basados en entrevistas a diferentes empresas que previamente a implementar TDD
desarrollaban software con metodología en cascada. En este trabajo se propuso
determinar qué beneficios y desafíos se perseguían como resultado de la implementación
de TDD.

2.5.4.1. ASPECTOS POSITIVOS

Como aspectos positivos se encontraron los siguientes:

44 - 120
• Código de calidad: Todos los entrevistados encontraron que el hecho de
disponer de las pruebas previamente predispone a los desarrolladores a escribir
código significativo de forma simple y limpia en comparación con el uso de la
técnica tradicional de escribir las pruebas después de escribir el código. La
percepción es que TDD hace que los desarrolladores adquieran hábitos que hagan
que cada vez escriban mejor código. Por otra parte, TDD también es percibido
como custodio de la calidad ante las presiones que se generan para entregar
código terminado. Investigadores suecos encontraron que la calidad del código
mejora en los casos que se escriben primero las pruebas.
• Aplicaciones de Calidad: El aumento de la confiabilidad del código se ve
como un beneficio que se deriva de la implementación de TDD. Esto es resultado
de que los desarrolladores deben dedicar tiempo a escribir los casos límites que
prueben el código, no solamente los casos más comunes. Esto conlleva el
aumento de cobertura y densidad de las pruebas, algo que no es captado cuando
las pruebas se implementan a posteriori. Esta mayor cobertura es vista como
resultado de aplicar TDD, algo que no es percibido en TL ya que muchas veces ni
siquiera se dispone del tiempo para escribir las pruebas. En estudios realizados
en Suecia no se encontraron diferencias significativas en la calidad del producto
entre TDD y TL, solamente encontraron algunas diferencias en la cantidad de test-
cases positivos, concluyendo que esto se puede deber a que TDD es una
metodología de diseño y no de pruebas.
• Productividad: este estudio encontró además que todos los entrevistados
coincidieron en que se incrementó la productividad en relación con sus
experiencias previas. Ven esto como resultado de que escribir las pruebas
previamente e ir incrementando cada funcionalidad de a una por vez generan que
haya menos trabajo, comparando con TL. Utilizando TDD la productividad se
incrementa si se compara con no escribir los test o escribir los test luego del
código. De todas maneras, el mismo trabajo no denota grandes diferencias en
cuanto a la cantidad de código que se genera y la cobertura de las pruebas en los
casos en que las mismas son escritas.
45 - 120
 • Calidad en Comunicación: TDD contribuye a disminuir los defectos y mejora
la comunicación entre el cliente y los desarrolladores, tal como ha podido
comprobar en el caso la aplicación de TDD en sistemas embebidos.

2.5.5. Metodología SCRUM

Scrum es una metodología ágil de desarrollo de proyectos, que toma su nombre y

principios de Hirotaka Takeuchi e Ikujijo Nonaka a mediadosde los 80.

En el año de 1986 Hirotaka e Ikujijo publicaron el artículo “The New Product Development
Game” (Hirotaka & Nonaka, 1986), el cual dio a conocer una nueva forma de gestionar
proyectos en las que la agilidad, flexibilidad, y la incertidumbre son los principales
elementos.

Nonaka y Takeuchi realizaron una investigación en la cual denotaron que en empresas

tecnológicas que, estando en el mismo ambiente que se encontraban otras empresas,
realizaban productos en menos tiempo, con mayor calidad y menos coste. (Gallego, 2010)

Al inicio este modelo surgió para el desarrollo de productos tecnológicos, pero también se
emplea en entornos de trabajo con:

• Incertidumbre:

Sobre una variable se plantea los objetivos que se desea alcanzar sin detallar las
estrategias a seguir. Generalmente esto genera un reto, y sobre las dudas que
nacen la motivación decrecen en el equipo de trabajo.

• Auto Organización:

Los equipos de trabajo tienden a organizarse solos, sin necesitar roles para la
gestión del proyecto

46 - 120
 • Control Moderado:

Se define controles para enmarcar el trabajo bajo el “Auto Control entre iguales”
para evitar que se desvié el trabajo a fines no comunes, pero sin impedir la
creatividad de los integrantes del grupo de trabajo.

• Transmisión del conocimiento:

Entre todos se aprende, las personas superan poco a poco los proyectos y lo
aprendido es transmitido al grupo de trabajo.

Todas las mencionadas son situaciones frecuentes en el desarrollo de sistemas

de software.

Además, esta práctica fue llamada SCRUM debido a una observación realizada por
Nonaka y Takeuchi sobre renombradas empresas como Honda, HP, Canon, etc., en las
cuales los productos no seguían un ciclo, con un grupo encargado de supervisar cada una
de las etapas, si no que se basan en requerimientos muy generales y el producto es
desarrollado por un equipo multidisciplinario que trabaja desde el inicio hasta el fin del
proyecto.

Se realizó una comparación de este estilo de trabajo, con la colaboración que hacen los
jugadores de Rugby y el manejo de una formación denominada SCRUM.

SCRUM considera como una metodología ágil, se basa en la creación de ciclos breves
para el desarrollo, que se conocen como Iteraciones y dentro de Scrum se llamarán
“SPRINTS”.

Antes de describir el ciclo de desarrollo de Scrum es primordial conocer las 5 fases que
definen el ciclo de desarrollo ágil:

47 - 120
 • Concepto: se concreta de forma general las características del producto y se
asigna el equipo que se confiará su desarrollo.

• Especulación: se presenta la información obtenida para asignar disposiciones,

estableciendo límites que marcan el desarrollo del producto.

• Exploración: Se Realiza un incremento operativo al producto, poniendo en

marcha las funcionalidades de la fase de especulación.

• Revisión: el equipo evalúa todo lo desarrollado y es verificado con el objetivo

deseado. El equipo de revisión puede ser: las partes interesadas del proyecto,
gestores, desarrolladores y, en ocasiones los clientes.

• Cierre: se entrega en las fechas acordadas una versión del producto deseado. Al
tratarse de una versión no significa que es la culminación del proyecto, al
contrario, se recepta opiniones y sugerencias para mejorar el producto.

Figura 10. Ciclo de Scrum

Fuente: Reserv, 2010

2.5.5.1. Componentes de Scrum

Los componentes del desarrollo del Scrum se agrupan en fases y roles, que más
adelante se describirá de forma más concisa.

48 - 120
Scrum se divide generalmente en 3 fases, que se entiende como reuniones. Las
reuniones forman los pilares de esta metodología junto con los roles y el control de la
evolución del proyecto.

Las Reuniones.

• Planificación del Backlog.

Se diseña un documento que especifica los requerimientos del proyecto bajo un

orden de prioridad.

Además, se define la planificación para el Sprint 0, para esto se define sus

objetivos y el trabajo que hay que hacer en esta iteración.

El conjunto de características que forman parte de cada Sprint vienen definidas

por el Backlog, que es un conjunto de requisitos de alto nivel que definen el trabajo
que se debe realizar.

Dichos elementos para el Backlog son determinados durante la reunión de Sprint

Planning, dentro de la reunión el Product Owner identifica y resalta los principales
elementos del Backlog que desea ver finalizados. El equipo al frente del proyecto
determina si los objetivos son alcanzables en el Sprint 0, si no lo fuera pasaría al
Sprint1. Durante el tiempo que se establezca para el Sprint, nadie puede cambiar
el Backlog, esto significa que los requerimientos se mantendrán estáticos.

• Seguimiento del Sprint.

Para esta fase se realizan reuniones diarias, donde se responde a las 3 preguntas
para evaluar el avance de las tareas:

• ¿Qué trabajo se realizó desde la reunión anterior?

49 - 120
 • ¿Qué trabajo se hará hasta una nueva reunión?

• Inconvenientes que han surgido y qué hay que resolver para poder
continuar. (el encargado de apoyar este punto es el Scrum Master).

• Revisión del Sprint.

Terminado el Sprint se realiza una revisión del incremento que se ha desarrollado,

para esto se presenta los resultados finales y una primera versión, esto ayuda a la
retro-Alimentación con el cliente.

2.5.5.2. Elementos de Scrum

Los elementos que forman a Scrum son (Gómez, 2010):

• Product Backlog: lista de necesidades del cliente ordenas prioritariamente.

• Sprint Backlog: lista de tareas que se desarrollan en un Sprint.

• Incremento: Parte añadida o desarrollada en un Sprint, es una parte terminada y

totalmente operativa.

Figura 2.5.1 Elementos de Scrum

Fuente: Metodología Scrum

50 - 120
Product Backlog.

Es una lista en la que se detalla todas las funcionalidades o requisitos en forma priorizada,
estos requisitos ira adquiriendo en forma secuencial el producto.

Esta lista es creada por el cliente y el Scrum Master, quien indicará el coste aproximado
para completar un requisito, y además contendrá todo lo que aporte un valor final al
producto.

Las principales características que esta lista debe tener (Gallego, 2009):

• Contendrá los objetivos del producto, se suele usar para expresarlos las historias
de usuario

• En cada objetivo, se indicará el valor que le da el cliente y el coste estimado; de

esta manera, se realiza la lista, priorizando por valor y coste, se basará en el ROI.

• En la lista se tendrán que indicar las posibles iteraciones y los realces que se han
indicado al cliente.

• La lista ha de incluir los posibles riesgos e incluir las tareas necesarias para
solventarlos.

En primordial que antes de empezar el primer Sprint se definan cuáles van a ser los
objetivos del producto y tener la lista de los requisitos ya definida.

Posterior a la definición de los requisitos se tendrá que acordar cuando un requisito está
terminado o completo.

El Product Backlog irá evolucionando mientras el producto exista en el mercado. Esta es

la forma para evolucionar y tener un valor de producto para el cliente suficiente para ser

51 - 120
competitivo.

Historias de usuario.

Son las descripciones de las funcionalidades que va a tener el Software.

Las Historias de usuario, serán el resultado de la colaboración entre el cliente y el equipo,

e irán evolucionando durante toda la vida del proyecto.

Las historias de usuario se componen de tres frases denominadas “las 3 C”:

• Card: Será una breve descripción escrita que servirá como recordatorio.

• Conversation: Es una conversación que servirá para asegurarse de que se ha

entendido bien todo, y concretar el objetivo.

Confirmation: Tests funcionales para fijar detalles que sean relevantes e indicar cuál va
a ser límite.

En cuanto al formato, un modelo podría ser como el que se muestra en la figura 11:

Descripción de las partes de las historias de usuario:

• ID: Identificador de la Historia de Usuario.

• TÍTULO: Título descriptivo de la historia de usuario.

• DESCRIPCIÓN: Descripción sintetizada de la historia de Usuario.

• ESTIMACIÓN: Evaluación del coste de implementación en unidades de desarrollo.

Estas unidades representan el tiempo teórico que se haya estimado al comienzo
del proyecto.
52 - 120
 Figura 11. Historia de Usuario

Fuente: Metodología Scrum

• PRIORIDAD: Prioridad en la implementación de la historia de Usuario respecto al

resto de las historias de usuario. A mayor número, mayor prioridad. Otra
aproximación a la priorización de tareas se hace a través del método MoSCoW:

• M – Must: se debe completar este requerimiento para finalizar el proyecto.

• S – Should: se debe completar este proyecto por todos los medios, pero el
éxito del proyecto no depende de él.

• C – could: se deberá completar este requerimiento si su implementación no

afecta la consecución de los objetivos principales del proyecto.

• W – Would: se puede completar este requerimiento si sobra tiempo de

desarrollo.

53 - 120
 • DEPENDENCIAS: Una Historia de Usuario no deberá ser dependiente de otra
historia, pero a veces es inevitable. En este apartado se indicarán los ID’s de
las tareas de las que depende una tarea.

Sprint Backlog.

Es la lista de tareas que elabora el equipo durante la planificación de un Sprint. Se asignan

las tareas a cada persona y el tiempo que queda para terminarlas.

De esta manera el proyecto se descompone en unidades más pequeñas y se puede

determinar o ver en qué tareas no se está avanzando e intentar eliminar el problema.

Figura 12. Sprint Backlog

Fuente: Metodología Scrum

Funcionamiento de la lista:

54 - 120
 • Es una lista ordenada por prioridades para el cliente.

• Puede haber dependencias entre una tarea y otra, por lo tanto, se tendrá que
diferenciar de alguna manera.

• Todas las tareas tienen que tener un coste semejante que será entre 4-16 horas.

Incremento.

Representa los requisitos que se han completado en una iteración y que son perfectamente
operativos. Según los resultados que se obtengan, el cliente puede ir haciendo los cambios
necesarios y replanteando el proyecto.

2.6. METODOLOGÍA BUCHANAN

Se hará uso de la Metodología de Buchanan, con consta de 6 fases.

2.6.1. Identificación

Estas tareas son importantes para determinar que lenguaje y que sistema se usara. El
ingeniero de conocimiento debe sentirse razonablemente cómodo respecto del dominio
del problema, como para conversar inteligentemente con el experto. En síntesis: (Martínez,
2009).

• Se identificarán a los participantes y los roles, recursos, fuentes de conocimiento.

• Se establecen las facilidades computacionales y presupuestarias.
• Se identifican objetivos y metas.

2.6.2. Conceptualización

Se analizan los conceptos vertidos por el experto de campo con el objetivo de identificar y
caracterizar el problema informalmente. Significa que, por medio de entrevistas con el
55 - 120
experto, con el objetivo de identificar y caracterizar el problema informalmente. El experto
de campo y el ingeniero de conocimiento definen el alcance, es decir, que problemas a
resolver. (Martínez, 2009).

2.6.3. Formalización

Una vez definido adecuadamente el problema, el ingeniero de conocimiento empieza a

determinar los principales conceptos del dominio que se requieren para realizar cada una
de las tareas que va a resolver el sistema. El ingeniero de conocimiento debe prestar
atención al experto de campo para encontrar la estructura básica que el experto utiliza
para resolver el problema.

La estructura del conocimiento indica que tareas y términos está usando y la estrategia
indica cómo y cuándo el sistema debe establecerlas. Por lo tanto:

• Se identifican los aspectos relevantes y más importantes.

• El resultado de formalizar el diagrama de información conceptual y los elementos
sub problemas es una especificación parcial para construir un prototipo de la base
del conocimiento.

2.6.4. Implementación

El ingeniero de conocimiento debe formalizar el conocimiento obtenido del experto. Esta

tarea implica definir qué arquitectura permitirá una mejor organización del conocimiento.
Es necesario elegir la organización, lenguaje y medio ambiente de programación
adecuados para la aplicación particular.

Se definen los conceptos primitivos, con la forma de representación elegida. Este es el

primer paso hacia la implementación del prototipo.

56 - 120
El ingeniero de conocimiento deberá a medida que se desarrolla el prototipo seguir lo
siguiente (Martínez, 2009):

a) Que el formalismo usado sea el apropiado para reflejar los conceptos y el

proceso de inferencia del experto.

b) Que las características particulares de construcción del lenguaje capturen

exactamente los aspectos estructurales más importantes de los conceptos usados
por el experto.

c) Que la estructura del control del lenguaje al activar las reglas refleje la
estrategia usada por el experto.

d) Que las reglas reflejen asociaciones y métodos que:

▪ Son los usados por el experto.

▪ Son modelos aceptables de dichos métodos.

Se formaliza el conocimiento obtenido del experto y se elige la organización, el lenguaje y

el ambiente de programación.

2.6.5. Testeo

Se observa el comportamiento del prototipo, el funcionamiento de la base de conocimiento

y la estructura de las inferencias, verificándose que el sistema posea eficiencia. (Martínez,
2009).

Se refina el sistema prototipo, depurando la base de conocimientos, refinando reglas,

rediseñando la estructura del conocimiento, o reformulando conceptos básicos, con el
objetivo de capturar información adicional que haya proporcionado el experto. También se

57 - 120
consultan en esta etapa otros expertos para corroborar, controlar, ampliar y refinar el
prototipo.

2.6.6. Revisión del Prototipo

Cuando el prototipo ha crecido tanto que resulta difícil de manejar el ingeniero de

conocimiento rediseña un sistema más eficiente. Este nuevo sistema deberá refinarse y
extenderse a fin de completar el desarrollo del sistema. (Martínez, 2009).

Figura 13. Etapas de la Metodología Buchanan

Fuente: Martínez, 2009

58 - 120
CAPÍTULO III. MARCO
PRÁCTICO
 CAPÍTULO 3
MARCO PRÁCTICO

3.1. DISEÑO METODOLÓGICO

Para el desarrollo de la plataforma de aprendizaje online aplicando redes neuro-difusas

presentado, se precisa de dos metodologías, una para la realización de la red neuronal y
otra para el sistema de desarrollo que establezca los pasos a seguir para dar cumplimiento
a la finalidad del proyecto.

A continuación, en la siguiente Tabla 1 se define los objetivos, tareas y productos

entregables de las metodologías.

Se pasará al desarrollo de la plataforma de aprendizaje online para lo cual se utilizará una

metodología ágil que permita ejecutar las tareas con mayor flexibilidad, identificando fallas
y subsanándolas en el proceso, obteniendo así mejores resultados al momento del
cumplimiento de objetivos trazados en el proyecto, por lo cual SCRUM se encuentra
desglosada en sus diferentes etapas que son:

Pregame, Game y Postgame respectivamente. Tomando en cuenta las diferentes tareas y

productos entregables los cuales ayudan a un mejor entendimiento al momento de mostrar
los avances en las diferentes etapas que se encuentran en SCRUM logrando así la
generación de la documentación, que ayudara a un mejor entendimiento del presente
proyecto.

Tabla 1. Tabla de Desarrollo

FASES
ETAPAS TAREA PRODUCTO ENTREGABLE
SCRUM

59 - 120
IDENTIFICACIÓN DE LA SITUACIÓN
Análisis de la plataforma de
Tabla de Requisitos
aprendizaje

Revisión y Análisis de Definición y Descripción de

ACTUAL

Requisitos Actores

Prototipo de Interfaz de
Identificación de Roles
Usuario

PLANIFICACIÓN Identificación de Procesos Tabla de Roles

Tabla de Procesos

Establecimiento de la pila del

Pila del producto
producto.
Conceptualización

PRE-GAME

Identificación del caso de uso Diagrama de Casos de uso de

de alto nivel Alto Nivel

Diagrama de Casos de Uso

Especificación de Historias de Expandidos
Usuario
Especificación de los casos
de uso
DISEÑO Y ARQUITECTURA

Determinación de la
Arquitectura del Modelo de la
Red Neuro-Difusa
Formalización

Desarrollo de la red neuro-

difusa

Constitución de los Datos de

Entrada y Salida

60 - 120
 Algoritmo Back Propagation
aplicado

Entrenamiento de la Red
Neuro-Difusa

Esquema de la Arquitectura
Diseño y Arquitectura del del Sistema
Sistema
Implementación

Diagrama de despliegue
Diseño de la arquitectura de
Diseño de la base de datos
la base de datos
SPRINT 1: Gestión de

Planificación del Sprint 1 Tabla de la Pila del Sprint 1

Usuarios

Pila del Sprint Código de desarrollo

Desarrollo del módulo Tabla de pruebas

Revisión del módulo

SPRINT 3: Resultados SPRINT 2: Gestión de

Planificación del Sprint 2 Tabla de la Pila del Sprint 2

GAME

Pila del Sprint Código de desarrollo

del Aprendizaje de la Medicamentos

Desarrollo del módulo Tabla de pruebas

Validación

Revisión del módulo

Planificación del Sprint 3 Tabla de la Pila del Sprint 3

Red Neuro-Difusa

Pila del Sprint Código de desarrollo

Desarrollo del módulo Tabla de pruebas

Revisión del módulo

POST-
Cierre Análisis de Riesgos Tabla de riesgos
GAME

Fuente: Elaboración Propia.

61 - 120
3.1.1. Tipo y Método de Investigación

• Tipo de investigación

Se empleará la Investigación aplicada1 para la teoría del desarrollo de la red neuro-

difusa y el tratamiento de la información.

Este tipo de investigación es la que se va a utilizar ya que en este proyecto no se

manipulará a la muestra que en este caso son personas.

• Tipo de estudio

Se hará un Estudio Descriptivo, dado que se analizará al personal de Droguería

INTI para poder estudiar como es su comportamiento con y sin la plataforma.

• Métodos

TDD o Test-Driven Development (Desarrollo dirigido por pruebas) es una

práctica de programación que consiste en escribir primero las pruebas
(generalmente unitarias), después escribir el código fuente que pase la prueba
satisfactoriamente y, por último, re factorizar el código escrito.

Con esta práctica se consigue entre otras cosas: un código más robusto, más
seguro, más mantenible y una mayor rapidez en el desarrollo. (Herranz, 2016)

Scrum es un marco de trabajo para desarrollo ágil de software que se ha

expandido a otras industrias.

1
La investigación aplicada es el tipo de investigación en la cual el problema está establecido y es conocido por el investigador, por lo que utiliza la
investigación para dar respuesta a preguntas específicas.
62 - 120
 Es un proceso en el que se aplican de manera regular un conjunto de buenas
prácticas para trabajar colaborativamente, en equipo y obtener el mejor resultado
posible de proyectos, caracterizado por:
• Adoptar una estrategia de desarrollo incremental, en lugar de la
planificación y ejecución completa del producto.
• Basar la calidad del resultado más en el conocimiento tácito de las personas
en equipos auto organizados, que en la calidad de los procesos empleados.
• Solapar las diferentes fases del desarrollo, en lugar de realizar una tras otra
en un ciclo secuencial o en cascada. (Abellan, 2017)

• Técnicas
Para la recopilación de información se aplicarán las técnicas de:
• Revisión documental: Se caracteriza porque en su ejecución recurre a
diferentes tipos de documentos y a partir de ellos, recolecta, elige, analiza
y demuestra resultados congruentes.
• Entrevista: La entrevista es una conversación dirigida, con un propósito
específico y que usa un formato de preguntas y respuestas. Se establece
así un diálogo, pero un diálogo peculiar, asimétrico, donde una de las partes
busca recoger informaciones y la otra se llega a presentar como fuente de
estas informaciones.
• Encuesta: Es una técnica que se lleva a cabo mediante la aplicación de un
cuestionario a una muestra de personas. Las encuestas proporcionan
información sobre las opiniones, actitudes y comportamientos de los
ciudadanos.

63 - 120
3.2. INGENIERÍA DEL PROYECTO

3.2.1. Identificación

La etapa de identificación permite visualizar de manera global la problemática en la que se

enfoca el presente trabajo de grado y la situación actual del proceso de detección del
estrés. Esta sección se describe las fuentes que fueron consideradas para la obtención de
la información necesaria para establecer claramente la problemática principal del presente
proyecto.

3.2.1.1. Planteamiento del Problema

Durante el planteamiento del problema se describen las fuentes de información

consideradas para el planteamiento del problema del presente trabajo de grado.

• Fuentes de información: Para el proceso de obtención de información es necesario

que, durante el desarrollo de la plataforma de aprendizaje, se consideraron dos
tipos de fuentes de información.
• Fuentes primarias: La obtención de información por parte de los
capacitadores. Por el cual se procedió a realizar entrevistas al mismo.
• Los elementos que caracterizan a las entrevistas se llevaron a cabo con el
capacitador, son los siguientes:
• El Entrevistado. El entrevistado es representado por el Jefe de
capacitaciones de Droguería INTI, Lic. Walter Rubín de Celis.
• El Entrevistador. El entrevistador es representado por el estudiante del
presente proponente.
• El Tema. Los temas que se trataron fueron con respecto a las
capacitaciones dadas al personal de ventas, periodos temas, etc. Véase
fotos en el Anexo A, que será parte de la conceptualización del tema.
Para continuar con la recolección de información se hizo un a entrevista
al Jefe de Innovación tecnológica.
64 - 120
 • El Entrevistado. El entrevistado es representado por el Jefe de
Innovación Tecnológica de Droguería INTI, Lic. Milton Limachi Espejo.
• El Entrevistador. El entrevistador es representado por el estudiante del
presente proponente.
• El Tema. Los temas que se trataron fueron con respecto a las
capacitaciones dadas al personal de ventas, periodos temas, etc. Véase
fotos en el Anexo B.
Los objetivos principales de las entrevistas realizadas al experto humano
(Capacitador) fueron:
• Indagar sobre los procesos y elementos que interactúan al momento de
realizar las capacitaciones.
• Conocer la forma de capacitación hasta el momento.
• Fuentes secundarias: El conocimiento de las fuentes secundarias fue
obtenido gracias a libros, revistas, documentos electrónicos, diversos
sitios web de diferentes organizaciones y universidades, todo con
respecto a la capacitación del personal de fuerza de ventas en una
empresa.
• Identificación del Problema: Para realizar la identificación y planteamiento del
problema se realizó una entrevista al jefe de capacitaciones, por lo cual se puede
observar en el capítulo I (Generalidades) del presente trabajo.

3.2.1.2. Situación Actual

El análisis, diseño y construcción de la plataforma de aprendizaje online aplicando redes

neuro-difusas requiere tener un adecuado y profundo conocimiento del proceso enseñanza
y capacitación al personal de fuerza de ventas.

En consecuencia, se describirá a continuación el proceso general de atención y los

involucrados, además del proceso de capacitación al personal de fuerza de ventas.

65 - 120
 a) Identificación de actores

Los diferentes actores que se encuentran interactuando con el sistema actual, tienen
asignadas tareas y accesos, que son necesarios para la capacitación, los cuales serán
explicados en la tabla 2:

Tabla 2. Actores.

ACTOR DETALLE

Capacitador Es encargado del área de capacitaciones, crea,

actualiza cursos de acuerdo con una línea
curricular y diferentes áreas de mejora del área de
fuerza de ventas.

Jefe de Realiza un control del aprovechamiento académico

Área
del personal de fuerza de ventas. Se encarga de
analizar la información presente en la plataforma.

Usuario Es el personal siendo capacitado, en la mayoría de

los casos esta persona pertenece al área de fuerza
de ventas. Realiza evaluaciones, trivias, consume
material digital y tiene un control constante.

Fuente: Elaboración Propia

Para el presente trabajo se usará la metodología SCRUM para lo cual se debe identificar
a los roles y artefactos considerados en el “sprint 0”.
66 - 120
 b) Identificación de Roles

Se tomará en cuenta los roles identificados en la tabla 3 para la aplicación web.

Tabla 3. Roles en la Plataforma Web.

PERSONAL PERFIL TAREAS

Capacitador Administrador · Creación y modificación de cursos desde la

plataforma Web,

· Control del aprovechamiento académico del

personal de fuerza de ventas.

Jefe de Jefe de · Control de los datos dentro de la plataforma.

Área Capacitaciones
· Administración de tiempos de evaluación y
realización de cursos.

· Gestión de preguntas dentro de la plataforma.

· Planificación de currícula para determinado

personal del área de fuerza de ventas.

Fuente: Elaboración Propia

Se tomará en cuenta los roles identificados en la tabla 4 para la aplicación móvil.

Tabla 4. Roles de la aplicación móvil

PERSONAL PERFIL TAREAS

67 - 120
 · Consumo de cursos mediante la aplicación
Usuario Usuario Personal
de Fuerza de móvil.
Ventas · Consumo de material digital de acuerdo a
líneas farmacéuticas establecidas por la
institución.
· Realizar evaluaciones periódicas para brindar
información acerca del aprovechamiento
académico del usuario.

Fuente: Elaboración Propia

3.2.3. Identificación de Flujo de Capacitaciones en INTI

En el presente trabajo se emplea la investigación descriptiva. Para el cual, Se realizó la

recolección de información mediante la entrevista y observación que trata del tema, la
finalidad es obtener un conocimiento significativo en todo lo referente a la capacitación y
evaluación del personal de fuerza de ventas de Droguería INTI.

68 - 120
 Figura 14. Diagrama de Flujo de las Capacitaciones

Fuente: Elaboración Propia

Como se observa en la figura 14, en resultado al método de investigación, se puede

observar el flujo de las capacitaciones hasta el momento.

3.2.4. Requerimientos del Sistema

Los requisitos establecidos en la tabla 4 para el desarrollo de la plataforma de aprendizaje

propuesto fueron obtenidos mediante la entrevista directa con el jefe de capacitaciones y
verificando que permita el cumplimiento de los objetivos establecidos en el presente trabajo
de grado.

El sistema que se encuentra en vigencia en Droguería INTI fue adquirido, el cual, en la

actualidad, mediante las entrevistas se pudo observar que este tiene un costo muy

69 - 120
elevado, además que este no cubre con los requerimientos que actualmente se encuentran
en la tabla 5.

Tabla 5. Requisitos del Sistema

No. Requisitos del Sistema

R1 La plataforma, tanto en la parte web como en la parte móvil debe contar con autenticación
de usuario mediante nombre y contraseña

R2 El sistema debe ser independiente a sistemas armados de la empresa, permitiendo así la

modificación.

R3 El sistema web dentro de la plataforma debe contar con login solamente para
capacitadores y jefes de capacitación.

R4 Por medio de la aplicación web se debe poder realizar carga de archivos, y por medio de
la aplicación móvil, consumir los mismos.

R5 La plataforma debe permitir realizar la creación, la toma de diferentes cursos y

evaluaciones.

R6 Las respuestas a las evaluaciones deben ser guardadas en la base de datos.

R7 Las evaluaciones deben ser calificadas automáticamente.

R8 En la aplicación web se pueda gestionar y administrar las trivias.

Fuente: Elaboración Propia

70 - 120
3.2.5. Definición de Procesos

Una vez definidos los requerimientos y teniendo en conocimiento sobre los actores que
interactúan en el sistema, se procederá con la definición de los procesos del sistema (Tabla
5). Definiendo un proceso como un conjunto de actividades mutuamente relacionadas o
que al interactuar transforman elementos de entrada y los convierten en resultados.

Tabla 6. Proceso de las capacitaciones en INTI

PROCESO TAREAS

Autenticación · Ingreso mediante usuario y contraseña.

Gestión de Cursos · Buscar y listar cursos

· Crear cursos

· Modificar cursos.

Gestión de Evaluaciones · Buscar y listar evaluaciones

· Crear evaluación según tipo de curso

· Modificar evaluación

· Realizar calificación automática de evaluaciones según requerimiento.

Gestión de Materiales · Carga de documentos para la visualización de los usuarios.

· Carga de videos para la creación de trivias dinámicas.

71 - 120
 Consumo de cursos · Consumo de material digital dentro del curso.

· Realización de evaluaciones y trivias.

· Consumo de diferentes artículos.

Fuente: Elaboración Propia

Para una mejor definición de los procesos de la plataforma propuesta se realizará la

construcción de los diagramas de caso de uso de alto nivel, presentado en la figura 15.
que ilustra los actores involucrados en el sistema, funcionalidades del sistema y las
relaciones de inclusión y extensión entre los mismos.

3.2.6. Establecimiento de la Pila del Producto

Para armar la Pila del Producto se desarrollaron las historias de usuario durante las
reuniones con el Jefe de área de capacitaciones, llevadas a cabo en las instalaciones de
Droguería INTI, y por Microsoft Teams, identificando al personal involucrado que desarrolla
las capacitaciones, donde se identifico a los usuarios, jefe de capacitaciones y al
capacitador. Para armar la pila del producto se organizó por prioridad y proporcionando
una pre-estimación del esfuerzo necesario como se ve en la Tabla 6.

Tabla 7. Pila del Producto.

ID PRIORIDAD DESCRIPCIÓN

HU1 Alta Autenticación para la aplicación web mediante usuario y

contraseña.

72 - 120
HU2 Alta La plataforma debe contar la carga de material.

HU3 Alta La plataforma de igual manera debe contar con una

gestión de cursos, carga, subida y creación de cursos.

HU4 Alta Gestión de evaluaciones, crear, editar una evaluación por

parte del capacitador.

HU5 Media Gestión de Calificaciones, se requiere que el resultado de

la calificación sea de inmediato una vez termine la
evaluación o según requerimientos.

HU6 Alta Autenticación de usuario mediante correo y contraseña

para la aplicación móvil.

HU7 Alta Visualización de cursos mediante la aplicación móvil para

el personal de fuerza de ventas.

HU8 Alta Toma de evaluaciones por parte del personal de fuerza de

ventas.

Fuente: Elaboración Propia

73 - 120
3.2.7. Construcción de la Red Neuro difusa

Para la construcción de la red neuro difusa se utilizaron tres variables principalmente, estas
variables afectan el comportamiento directamente de las funciones que se ejecutan en la
red neuro difusa.

Antes de listar las variables de la red neuro difusa, es necesario entender la siguiente idea:

En la aplicación móvil que será de uso del personal de fuerza de ventas, existirán
diferentes tipos de preguntas, el contenido de la pregunta puede ser un video, una imagen,
o un texto, de la misma forma el contenido de las respuestas a dicha preguntas puede
variar, siendo así un texto o una imagen, la combinación de todos estos tipos genera las
siguientes combinaciones con un área a la que ese tipo de pregunta evalúa mas.

Tabla 8. Combinación de Preguntas.

Tipo Respuesta\ Video Texto Imagen

TipoPregunta

Imagen Área Área Área Acción

Entendimiento Memorización

Texto Área Acción Área Área

Entendimiento Memorización

Fuente: Elaboración Propia

Las áreas de memorización, entendimiento, y acción significan lo siguiente:

• Memorización: El estudiante tiene la capacidad de poder memorizar conceptos y

palabras clave.
• Entendimiento: El estudiante tiene la capacidad de entender los contenidos que
fueron brindados en el curso.

74 - 120
 • Acción: El estudiante tiene un razonamiento lógico, y es capaz de tomar acciones
de acuerdo a contenido que fue brindado en el curso.

Teniendo en cuenta estos conceptos, podemos decir que existe una medición en cuanto a
las respuestas que tenga el estudiante en una evaluación, brindando asi un porcentaje de
respuestas correctas de acuerdo un área, por ejemplo, una evaluación puede constar de
30 preguntas, las cuales según la combinación de preguntas y respuestas, tendría 10 de
memorización, 10 de entendimiento y 10 de acción, de las cuales el estudiante contesta
correctamente 6 de memorización 2 de entendimiento y 8 de acción, dando así un
porcentaje de:

- 60% Memorización
- 20% Entendimiento
- 80% Acción

Este porcentaje será incluido en nuestras variables para los procesos internos que tenga
nuestra red neuronal difusa

A continuación, se listan las variables incluidas:

• Porcentaje de preguntas correctas área memorizacion

• Porcentaje de preguntas correctas área entendimiento
• Porcentaje de preguntas correctas área acción
• Porcentaje total de preguntas correctas

Mediante estas variables nosotros podemos utilizar diferentes reglas IF THEN, siguiendo
el siguiente sistema de inferencia difuso.

75 - 120
 Figura 15. Flujo de la red Neuro difusa.

Fuente: Elaboración Propia

La interfaz de rusificación será la encargada de transformar las entradas reales dentro de

grados de igualdad con valores lingüísticos, mientras que la interfaz de defusificacion será
la encargada de transformar los resultados difusos de la inferencia dentro de una salida
real.

El sistema de inferencia difuso tendrá diferentes pasos de razonamiento difuso los cuales
se listan a continuación:

1. Comparar las variables de entrada para obtener los valores de membresía, en otras
palabras, la fuzzificación.
2. Combinar valores de membresía para obtener fuerza de disparo de cada regla,
también llamado peso.
3. Una vez se tenga el proceso anterior se genera la consecuencia calificada de cada
regla dependiendo la fuerza de disparo.
4. Se conjunta la consecuencia para producir una salida real o en otras palabras se
realiza la defusificacion.

Los procesos listados anteriormente funcionaran de acuerdo a colección de reglas difusas

con la siguiente forma:

Ecuación de Colección de reglas difusas

76 - 120
 R(l) u : IF x1 is Al 1 and . . . and xn is Al n, THEN y is B (4)

donde Al i es un conjunto difuso en Ui ⊂ R y Bl es un conjunto difuso en V ⊂ R, y x = (x1,

x2,...,xn) ∈ U son las variables de entrada al sistema difuso y y ∈ V es la salida del sistema
difuso.

Para la funcionalidad en la parte de la red neuronal se utilizarán perceptrones multicapa,

estos son posiblemente el tipo mas conocido de redes neuronales unidireccionales, las
cuales tienen tres capas, una capa de entrada, una capa de salida y una capa intermedia
o capa oculta.

Las neuronas j que se encuentran presentes en la capa de entrada actúan como buffers
para redirigir señales de entrada Xi a neuronas en capa oculta, en la capa oculta cada
neurona suma todas sus señales de entrada Xi y después sopesarlas con el peso de las
conexiones Wji, se calcula la salida yj, como una función f de la suma:

Ecuación de Sumatoria de pesos

𝑦𝑗 = 𝑓(∑ 𝑤𝑗𝑖 𝑥𝑖 ) (5)

Teniendo estos dos conceptos y uniéndolos podemos aplicar el siguiente flujo:

Figura 16. Diseño de la Red Neuro Difusa.

Fuente: Elaboración Propia

77 - 120
3.2.8. Identificación del Caso de Uso de Alto Nivel

Para tener una mejor comprensión del funcionamiento de la plataforma a continuación se

desarrolla el diagrama de caso de uso de alto nivel en la figura 17, el cual refleja de manera
general al sistema y a los actores involucrados en el proceso.

En este proyecto para la aplicación web se identifico 2 roles explicados en la Tabla 3, que
son: Jefe de Capacitaciones, Capacitador. Asimismo se identificó 5 módulos a desarrollar,
los mismos reflejan la dependencia y asociación tanto con lo actores como con los otros
casos.

Figura 17. Caso de Uso de Alto Nivel Web

Fuente: Elaboración Propia

78 - 120
Para la aplicación móvil se identifico 1 rol explicado en la Tabla 4, que es: Usuario de
Personal de Ventas. Asimismo se identificó 5 módulos a desarrollar, los mismos reflejan
la dependencia y asociación tanto con lo actores como con los otros casos.

Figura 18. Caso de Uso de Alto Nivel Móvil

Fuente: Elaboración Propia

3.2.9. Planificación del Sprint 1: Autenticación de Usuario (Web)

En la Tabla 8 se muestra el Sprint 1: Autenticación de Usuario que refleja las tareas

realizadas, especificadas en las historias de usuario y priorizadas en la pila del producto.

79 - 120
 Tabla 9. Pila del sprint 1: Autenticación de usuario

PILA DEL PRODUCTO OBJETIVO

DEL
SPRINT 1

HISTORIA TAREA RESPONSABLE ESTIMADO ESTADO Autenticación

EN de Usuario
DE HORAS

USUARIO

HU1 Generar Programador 2 Terminado 2

procedimiento
almacenado
para
autenticación
de usuario

HU1 Creación de Programador 2 Terminado 2

endpoint para
autenticación
de usuario

HU1 Creación y Programador 1 Terminado 1

configuración

80 - 120
 de Json Web
Token

HU1 Creación de Programador 5 Terminado 5

interfaz de
usuario y
consumo de
endpoint para
autenticación
de usuario

Fuente: Elaboración Propia

A continuación, en la tabla 10 se especificará la Historia de Usuario de la autenticación de

Usuario para una mejor comprensión del módulo Autenticación de Usuario.

Tabla 10. Historia de usuario HU1: Autenticación de usuarios (Web)

HISTORIA DE USUARIO: HU1 AUTENTICACION DE USUARIOS

(Web)

COMO: Jefe de capacitaciones, capacitador

QUIERO: Acceder al sistema con contraseña, generación de sesiones de seguridad, y

validar los json web tokens para uso correcto en la aplicación web.

PARA: Controlar el acceso al sistema

VALIDACIÓN:

• Desarrollar un login con acceso mediante usuario y contraseña.

• Redirigir a la vista principal para la administración de la plataforma.

81 - 120
 Fuente: Elaboración Propia

A continuación, se presentará los diagramas de casos de uso expandido de la

autenticación de Usuario:

Figura 19. Caso de Uso Expandido Autenticación de Usuarios

Fuente: Elaboración Propia

Para un mejor entendimiento en la tabla 11. Especificación del caso de uso expandido
autenticación de usuario se detalla el proceso.

Tabla 11. Especificación del caso de uso: Autenticación de Usuarios (Web)

IDENTIFICADOR: Caso de Uso – CU1

CASO DE USO: Autenticación de Usuarios

DESCRIPCIÓN: Caso de uso de autenticación de usuarios en
el cual el jefe de capacitaciones y el

82 - 120
 capacitador acceden a las funcionalidades
de acuerdo a rol en la aplicación web.
ACTOR: Jefe de capacitación, capacitador
PRECONDICIONES: Hacer uso de usuarios ya registrados en la
base de datos de la empresa
POST CONDICIONES: Validaciones e ingreso a la aplicación web
FLUJO PRINCIPAL
ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA
En la pantalla de autenticación de usuario Realiza validaciones para determinar si el
inserta usuario y contraseña, apretar el usuario y la contraseña son correctos, en
botón de ingresar. caso de que no sean correctos muestra un
mensaje de que el usuario y la contraseña
no son correctos, en caso que sea correcto
se obtiene un json web token para la
validación de seguridad y se redirige a la
pantalla principal con las opciones de la
plataforma.

Fuente: Elaboración Propia

Para el desarrollo de las funcionalidades del sprint se realizaron las siguientes pruebas
unitarias siguiendo la metodología tdd.

Tabla 12. Pruebas Sprint 1: Autenticación de Usuarios (Web)

PRUEBA ARRANGE ACT ASSERT

UsuCorrectoContraCorrecta_NoDevu Usuario y Llamada de Autenticación

elveError Contraseña métodos para correcta
autenticacion

83 - 120
 UsuCorrectoContraIncorrecta_Devuel Usuario y Llamada de Autenticación
veError Contraseña métodos para incorrecta
autenticación

UsuIncorrectoContraIncorrecta_Devu Usuario y Llamada de Autenticación

elveError Contraseña métodos para incorrecta
autenticación

UsuIncorrectoContraIncorrecta_Devu Usuario y Llamada de Autenticación

elveError Contraseña métodos para incorrecta
autenticación

Fuente: Elaboración Propia

3.2.10. Planificación del Sprint 2: Cargado de Material (Web)

En la Tabla 12 se muestra el Sprint 2: Cargado de Material que refleja las tareas realizadas,
especificadas en las historias de usuario y priorizadas en la pila del producto.

Tabla 13. Pila del sprint 2: Cargado de Material

PILA DEL PRODUCTO OBJETIVO

DEL SPRINT
2

HISTORIA TAREA RESPONSABLE ESTIMADO ESTADO Cargado de

DE EN HORAS Material
USUARIO

HU2 Generar Programador 3 Terminado 3

procedimientos
almacenados
para

84 - 120
 almacenamiento
de información
de archivo.

HU2 Creación de Programador 3 Terminado 3

endpoints para
subida de
archivos

HU2 Creación de Programador 4 Terminado 4

interfaces de
usuario para
subida de
archivos
HU2 Implementación Programador 5 Terminado 5
de consumo de
endpoints para
subida de
archivos en
aplicación web

Fuente: Elaboración Propia

A continuación, en la tabla 14 se especificará la Historia de Usuario de la autenticación de

Usuario para una mejor comprensión del módulo Cargado de Material.

Tabla 14. Historia de usuario HU2: Carga de Material (Web)

HISTORIA DE USUARIO: HU2 CARGA DE MATERIAL (Web)

COMO: Jefe de capacitaciones

QUIERO: Cargar archivos de diferentes extensiones

PARA: Que sean añadidos en cursos para poder ser consumidos como contenido de
clase y contenido de preguntas.
VALIDACIÓN:

85 - 120
 • Cargar archivo pdf en interfaz de material
• Cargar archivo jpg en interfaz de imágenes
• Cargar archivo mp4 en interfaz videos de clase
• Cargar archivo mp4 en interfaz videos de preguntas
• Listar archivos pdf, jpg, mp4 cargados

Fuente: Elaboración Propia

A continuación, se presentará los diagramas de casos de uso expandido de la cargado de

Material:

Figura 20. Caso de Uso Expandido: Cargado de Material.

Fuente: Elaboración Propia

Para un mejor entendimiento en la tabla 15. Especificación del caso de uso expandido
gestor de usuario se detalla el proceso.

Tabla 15. Especificación del caso de uso: Carga de Material (Web).

IDENTIFICADOR: Caso de Uso – CU2

CASO DE USO: Carga de Material

86 - 120
DESCRIPCIÓN:
ACTOR:
PRECONDICIONES:
POST CONDICIONES:
FLUJO PRINCIPAL
ACCIÓN DEL ACTOR
En la pantalla principal el jefe de
capacitaciones elige opciones para
cargar imágenes, videos para
contenido, videos para preguntas y
documentos
En la pantalla de carga de imágenes,
aprieta botón para seleccionar imagen
En la pantalla de carga de videos para
contenido, aprieta botón para
seleccionar video
En la pantalla de carga de videos para
pregunta, aprieta botón para
seleccionar video
87 - 120
Caso de uso de carga de material en el
cual el jefe de capacitaciones tiene la
posibilidad de realizar la carga de archivos
de diferente tipo como ser mp4, jpg, pdf,
estos archivos estarán asociados a un
curso que ya haya sido creado.
Los archivos podrán ser visualizados en la
aplicación móvil, de acuerdo al curso que
hayan sido relacionados, siendo utilizados
como apoyo a diferentes dinámicas.
Jefe de capacitaciones
Acceso a un espacio digital donde guardar
los archivos que sean cargados
Revisión de los archivos cargados
mediante diferentes listados en la
aplicación web
ACCIÓN DEL SISTEMA
Redirige a pantalla según la opción
seleccionada.
Aparece alerta para seleccionar imagen
con restricción de imágenes solamente de
tipo jpg
Aparece alerta para seleccionar video con
restricción de videos solamente de tipo
mp4
Aparece alerta para seleccionar video con
restricción de videos solamente de tipo
mp4
 En la pantalla de carga de materiales
(documentos) aprieta botón para
seleccionar documento
Aprieta botón de cargar seleccionados,
presente en pantallas de cargar
imágenes, cargar videos para
contenido, cargar videos para
preguntas y cargar documentos
Aparece alerta para seleccionar video con
restricción de videos solamente de tipo jpg
Carga archivos que hayan sido
seleccionados de acuerdo a las
restricciones correspondientes, una vez la
carga haya sido completada
correctamente, la pantalla se recarga y se
puede ver el archivo un listado de
cargados.

Fuente: Elaboración Propia

Para el desarrollo de las funcionalidades del sprint se realizaron las siguientes pruebas
unitarias siguiendo la metodología tdd.

Tabla 16. Pruebas Sprint 2: Carga de material (Web)

PRUEBA ARRANGE ACT ASSERT

SubidaDeMaterial_Imagen Imagen para Llamada de Existe nueva

subida métodos para información en
subida de la BD de la
imagenes imagen subida

SubidaDeMaterial_Video Video para Llamada de Existe nueva

subida métodos para información en
subida de la BD del video
videos subido

88 - 120
 SubidaDeMaterial_Documento Documento Llamada de Existe nueva
para subida métodos para información en
subida de la BD del
documentos documento
subido

ListarArchivos_Imagen Tipo de archivo Llamada de Lista de

para listar método para archivos de tipo
listar archivos imagen

ListarArchivos_Video Tipo de archivo Llamada de Lista de archivo

para listar método para de tipo video
listar archivos

ListarArchivos_Documento Tipo de archivo Llamada de Lista de archivo

para listar método para de tipo
listar archivos documento

Fuente: Elaboración Propia

3.2.11. Planificación del Sprint 3: Gestión de Cursos (Web)

En la Tabla 17 se muestra el Sprint 3: Gestión de Cursos que refleja las tareas realizadas,
especificadas en las historias de usuario y priorizadas en la pila del producto.

Tabla 17. Pila del sprint 3: Gestión de Cursos.

PILA DEL PRODUCTO OBJETIVO

DEL SPRINT
3

89 - 120
HISTORIA TAREA RESPONSABLE ESTIMADO ESTADO Gestión de
DE EN HORAS cursos
USUARIO

HU3 Generar Programador 4 Terminado 4

procedimientos
almacenados
para CRUD
cursos
HU3 Creación de Programador 4 Terminado 4
endpoints para
CRUD cursos

HU3 Creación de Programador 6 Terminado 6

interfaz de
usuario para
listado de cursos

HU3 Creación de Programador 5 Terminado 5

interfaz de
usuario para
creación y
edición de
cursos

HU3 Creación de Programador 4 Terminado 4

interfaz de
usuarios para la
visualización del
detalle de
cursos

HU3 Integración de Programador 8 Terminado 8

endpoints CRUD
cursos en
aplicación web

Fuente: Elaboración Propia

90 - 120
A continuación, en la tabla 18 se especificará la Historia de Usuario de la cargado de cursos
para una mejor comprensión del módulo Cargado de Cursos.

Tabla 18. Historia de usuario HU3: Gestión de Cursos (Web)

HISTORIA DE USUARIO: HU3 GESTION DE CURSOS (Web)

COMO: Jefe de capacitaciones

QUIERO: Crear, editar, listar y administrar cursos de tipo privado y publico

PARA: Que sean consumidos en la aplicación para el aprovechamiento

del personal de fuerza de ventas.
VALIDACIÓN:

• Crear un curso
• Administrar estudiantes dentro de un curso
• Administrar contenido en documento y video para el curso
• Editar un curso

Fuente: Elaboración Propia

A continuación, se presentará los diagramas de casos de uso expandido de gestión de

cursos.
Figura 21. Caso de Uso Expandido: Gestión de Cursos.

Fuente: Elaboración Propia

91 - 120
Para un mejor entendimiento en la tabla 19. Especificación del caso de uso expandido
gestión de cursos se detalla el proceso.

Tabla 19. Especificación del caso de uso: Gestión de Cursos (Web)

IDENTIFICADOR: Caso de Uso – CU3

CASO DE USO: Gestión de cursos

DESCRIPCIÓN:
ACTOR:
PRECONDICIONES:
POST CONDICIONES:
FLUJO PRINCIPAL
ACCIÓN DEL ACTOR
En la pantalla principal el jefe de
capacitaciones elige la opción de cursos
Aprieta botón crear curso publico
Aprieta botón crear curso privado
Aprieta botón crear curso dentro de
formularios de creación de curso
Aprieta tarjeta de curso dentro del listado
de cursos
Caso de uso de gestión de cursos, en el cual
el jefe de capacitaciones tiene la posibilidad de
crear, modificar habilitar/deshabilitar cursos,
puede listar, ver el contenido detalladamente y
realizar distintas configuraciones dentro del
curso
Jefe de capacitaciones
Tener acceso a diferentes procedimientos en
BD
Visualización y gestión de diferentes cursos
ACCIÓN DEL SISTEMA
Redirige a una vista donde se encuentran
todos los cursos privados y todos los cursos
públicos, aparece un listado y botones para ver
detalle, crear curso públicos y privados
Redirige a pantalla con un formulario para
crear curso publico
Redirige a pantalla con formulario para crear
curso privado
Crea curso, y una vez creado el curso creado
correctamente, redirige a pantalla con listado
de cursos
Redirige a pantalla de detalle de curso donde
se ve información de curso y permite acceder
a otras funcionalidades de la aplicación.

Fuente: Elaboración Propia

92 - 120
Para el desarrollo de las funcionalidades del sprint se realizaron las siguientes pruebas
unitarias siguiendo la metodología tdd.

Tabla 20. Pruebas Sprint 3: Gestión de cursos (Web)

PRUEBA ARRANGE ACT ASSERT

CrearCurso_Publico Titulo, titulo corto, Llamada de método Existe nueva

descripción, fecha para la creación de información en la BD
inicio, fecha fin curso del curso publico
creado

CrearCurso_Privado Titulo, titulo corto, Llamada de método Existe nueva

descripción, fecha para la creación de información en la BD
inicio, fecha fin curso del curso privado
creado

ListarCursos_Publico Tipo de curso para Llamada de método Lista de cursos de

listar para el listado de tipo publico
cursos

ListarCursos_Privado Tipo de curso para Llamada de método Lista de cursos de

listar para el listado de tipo publico
cursos

DeshabilitarCurso Id de curso a Llamada de método El curso esta

deshabilitar para deshabilitar deshabilitado en la
curso BD

Fuente: Elaboración Propia

93 - 120
3.2.12. Planificación del Sprint 4: Gestión de Evaluación (Web)

En la Tabla 21 se muestra el Sprint 4: Gestión de Evaluación que refleja las tareas

realizadas, especificadas en las historias de usuario y priorizadas en la pila del producto.

Tabla 21. Pila del sprint 4: Gestión de Evaluación.

PILA DEL PRODUCTO OBJETIVO

DEL SPRINT
4

HISTORIA TAREA RESPONSABLE ESTIMADO ESTADO Gestión de

DE EN HORAS Evaluación
USUARIO

HU4 Generar Programador 4 Terminado 4

procedimientos
almacenados
para CRUD
evaluaciones
HU4 Creación de Programador 4 Terminado 4
endpoints para
CRUD
evaluaciones

HU4 Creación de Programador 6 Terminado 6

interfaz de
usuario para
listado de
evaluaciones
HU4 Creación de Programador 5 Terminado 5
interfaz de
usuario para
creación y
edición de
evaluaciones

94 - 120
 HU4 Creación de Programador 4 Terminado 4
interfaz de
usuario para
creación y
edición de trivias

HU4 Creación de Programador 8 Terminado 8

interfaz de
usuario para
manejo y
lanzamientos de
trivias en tiempo
real
HU4 Creación de Programador 4 Terminado 4
canal de
comunicación en
tiempo real
mediante
websockets
HU4 Creación de Programador 4 Terminado 4
interfaz de
usuario para
habilitación de
preguntas en
trivias con
websockets

Fuente: Elaboración Propia

A continuación, en la tabla 22 se especificará la Historia de Usuario de la cargado de cursos

para una mejor comprensión del módulo Gestión de Evaluación.

Tabla 22. Historia de usuario HU4: Gestión de evaluaciones (Web)

HISTORIA DE USUARIO: HU4 GESTION DE EVALUACIONES (Web)

COMO: Jefe de capacitaciones

95 - 120
QUIERO: Crear, editar, listar y administrar evaluaciones y trivias

PARA: Que sean consumidos en la aplicación para verificar el aprovechamiento del

personal de fuerza de ventas.
VALIDACIÓN:

• Crear un curso
• Administrar estudiantes dentro de un curso
• Administrar contenido en documento y video para el curso
• Editar un curso

Fuente: Elaboración Propia

A continuación, se presentará los diagramas de casos de uso expandido de gestión de

Evaluación.

Figura 22. Caso de Uso Expandido: Gestión de Evaluación.

Fuente: Elaboración Propia

96 - 120
Para un mejor entendimiento en la tabla 23. Especificación del caso de uso expandido
gestión de evaluación se detalla el proceso.

Tabla 23. Especificación del Caso de Uso: Gestión de Evaluaciones (Web)

IDENTIFICADOR: Caso de Uso – CU4

CASO DE USO: Gestión de evaluaciones

DESCRIPCIÓN: Caso de uso de gestión de evaluaciones en el
cual el jefe de capacitaciones, tiene la
posibilidad de crear evaluación de acuerdo a
cronograma
ACTOR: Jefe de capacitaciones

PRECONDICIONES: Debe existir un curso creado donde poder

asociar la evaluación a gestionar
POST CONDICIONES: Visualización y configuración de curso creado
o existente
FLUJO PRINCIPAL
ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA
En la pantalla de detalle de curso el jefe de Redirige a una pantalla donde se muestra un
capacitaciones elige la opción de listado de las evaluaciones existentes
evaluaciones

En la pantalla de detalle de curso el jefe de Redirige a una pantalla donde se muestra un

capacitaciones elige la opción de trivias
Aprieta botón de crear evaluación dentro de
pantalla de evaluaciones existentes
Aprieta botón de crear trivia dentro de
pantalla de trivias existentes
Aprieta botón de crear evaluación/trivia
dentro de formularios de creación
listado de las trivias existentes
Redirige a pantalla con formulario dinámico
para creación de evaluaciones
Redirige a pantalla con formulario dinámico
para creación de evaluaciones
Redirige a pantalla de listado
evaluaciones/trivia

Fuente: Elaboración Propia

Para el desarrollo de las funcionalidades del sprint se realizaron las siguientes pruebas
unitarias siguiendo la metodología tdd.

97 - 120
 Tabla 24. Pruebas Sprint 4: Gestión de evaluaciones (Web)

PRUEBA ARRANGE ACT ASSERT

CrearEvaluacion_Evaluacion Titulo, Llamada de Existe nueva

preguntas método para la información en
creación de la BD de la
evaluación de evaluación
tipo evaluación creada

CrearEvaluacion_Trivia Titulo, Llamada de Existe nueva

preguntas método para la información en
creación de la BD de la
evaluación de evaluación de
tipo trivia tipo trivia creada

ListarEvaluacion_Evaluacion Tipo de Llamada de Lista de

evaluación para método para el evaluaciones de
listar listado de tipo general
evaluaciones

ListarEvaluacion_Trivia Tipo de Llamada de Lista de

evaluación para método para el evaluaciones de
listar listado de tipo trivia
evaluaciones

HabilitarTrivia Id de evaluación Llamada al La trivia se

para habliitar método para el activa en tiempo
real

98 - 120
 manejo de
websockets

DeshabilitarTrivia Id de evaluación Llamada al La trivia se

para método para el deshabilita en
deshabilitar manejo de tiempo real
websockets

Fuente: Elaboración Propia

3.2.13. Planificación del Sprint 5: Gestión de Calificaciones (Web)

En la Tabla 25 se muestra el Sprint 5: Gestión de Calificaciones que refleja las tareas

realizadas, especificadas en las historias de usuario y priorizadas en la pila del producto.

Tabla 25. Pila del sprint 5: Gestión de Calificación.

PILA DEL PRODUCTO OBJETIVO

DEL SPRINT
5

HISTORIA TAREA RESPONSABLE ESTIMADO ESTADO Gestión de

DE EN HORAS Calificación.
USUARIO

HU5 Generar Programador 4 Terminado 4

procedimientos
almacenados
para calificación
automática de
evaluaciones

99 - 120
 HU5 Creación de Programador 5 Terminado 5
endpoints para
generación de
calificaciones

HU5 Diseño de red Programador 6 Terminado 6

neuronal para
entrega dei
material
automático
HU5 Implementación Programador 4 Terminado 4
de red neuronal
para entrega de
material
automático

Fuente: Elaboración Propia

A continuación, en la tabla 26 se especificará la Historia de Usuario de la cargado de cursos

para una mejor comprensión del módulo Gestión de Calificaciones.

Tabla 26. Historia de usuario HU5: Gestión de Calificaciones (Web)

HISTORIA DE USUARIO: HU6 GESTION DE CALIFICACIONES(Web)

COMO: Jefe de capacitaciones, capacitador

QUIERO: Listar y editar calificaciones de los estudiantes

PARA: Realizar un control del aprovechamiento académico que esta teniendo el

personal de fuerza de ventas
VALIDACIÓN:

• Listar calificaciones de los estudiantes

• Editar calificaciones de los estudiantes cuando se requiera

Fuente: Elaboración Propia

100 - 120
A continuación, se presentará los diagramas de casos de uso expandido de gestión de
calificaciones.

Figura 23. Caso de Uso Expandido: Gestión de Calificaciones.

Fuente: Elaboración Propia

Para un mejor entendimiento en la tabla 27. Especificación del caso de uso expandido
gestión de calificación se detalla el proceso.

Tabla 27. Especificación del caso de uso: Gestión de Calificaciones (Web)

IDENTIFICADOR: Caso de Uso – CU5

CASO DE USO: Gestión de calificaciones

DESCRIPCIÓN: Caso de uso de gestión de calificaciones en
el cual el jefe de capacitaciones y el
capacitador pueden ver las calificaciones de
los estudiantes que realizaron evaluaciones
y además se tiene la opción de corregir
notas en caso de que haya habido algún
error de calificación.

101 - 120
 ACTOR: Jefe de capacitaciones, capacitador
PRECONDICIONES: Debe existir un curso y una evaluación
creada con estudiantes, además de
respuestas en la misma
POST CONDICIONES: Revisión de listado de calificaciones
FLUJO PRINCIPAL
ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA
En la pantalla de detalle de evaluación, Redirige a pantalla de calificaciones, esta el
elige opción de calificaciones listado de las personas que realizaron la
evaluación y la fecha en la que realizaron la
evaluación.
En la pantalla de calificaciones, aprieta Se deshabilita evaluación y genera
botón de generar calificaciones y terminar calificaciones de los estudiantes en el curso
evaluación

Fuente: Elaboración Propia

Para el desarrollo de las funcionalidades del sprint se realizaron las siguientes pruebas
unitarias siguiendo la metodología tdd.

Tabla 28. Pruebas Sprint 5: Gestión de Calificaciones (Web)

PRUEBA ARRANGE ACT ASSERT

GenerarCalificaciones Id de evaluación a Llamada de Existe

generar calificaciones método nueva
para la información
generación en la BD de
de las
calificacione calificacione
s s creadas

102 - 120
 AlimentacionRedCalificacione CalificacionesEstudiant Llamada de Existe
s_ es método nueva
para información
alimentació en la BD de
n de red los datos
neuronal que
procesará la
red
neuronal

Fuente: Elaboración Propia

3.2.14. Planificación del Sprint 6: Autenticación de usuario (Móvil)

En la Tabla 29 se muestra el Sprint 6: Autenticación de usuario que refleja las tareas

realizadas, especificadas en las historias de usuario y priorizadas en la pila del producto.

Tabla 29. Pila del sprint 6: Autenticación de Usuario.

PILA DEL PRODUCTO OBJETIVO DEL

SPRINT 6

HISTORIA TAREA RESPONSABLE ESTIMADO ESTADO Autenticación

DE EN HORAS de Usuario
USUARIO

HU6 Generar Programador 4 Terminado 4

procedimientos
almacenados
para calificación
automática de
evaluaciones

103 - 120
 HU6 Creación de Programador 5 Terminado 5
endpoints para
generación de
calificaciones

HU6 Diseño de red Programador 6 Terminado 6

neuronal para
entrega dei
material
automático
HU6 Implementación Programador 4 Terminado 4
de red neuronal
para entrega de
material
automático

Fuente: Elaboración Propia

A continuación, en la tabla 30 se especificará la Historia de Usuario de la cargado de cursos

para una mejor comprensión del módulo Autenticación de usuario.

Tabla 30. Historia de usuario HU6: Autenticación de usuarios (Móvil)

HISTORIA DE USUARIO: HU6 AUTENTICACION DE USUARIOS

(Móvil)

COMO: Jefe de capacitaciones, capacitador

QUIERO: Acceder al sistema con contraseña, generación de sesiones de seguridad, y

validar los json web tokens para uso correcto en la aplicación web.

PARA: Controlar el acceso al sistema

VALIDACIÓN:

• Desarrollar un login con acceso mediante usuario y contraseña.

• Redirigir a la vista principal para la administración de la plataforma.

Fuente: Elaboración Propia

104 - 120
A continuación, se presentará los diagramas de casos de uso expandido de autenticación
de usuarios.

Figura 24. Caso de Uso Expandido: Autenticación de Usuarios (Móvil).

Fuente: Elaboración Propia

Para un mejor entendimiento en la tabla 31. Especificación del caso de uso expandido de
autenticación de usuarios se detalla el proceso.

Tabla 31. Especificación del caso de uso: Autenticación de Usuarios (Móvil)

IDENTIFICADOR: Caso de Uso – CU6

CASO DE USO: Autenticación de Usuarios

DESCRIPCIÓN: Caso de uso de autenticación de usuarios en
el cual el personal de fuerza de ventas
accede a las funcionalidades de acuerdo a
rol en la aplicación móvil.
ACTOR: Personal de fuerza de ventas
PRECONDICIONES: Hacer uso de usuarios ya registrados en la
base de datos de la empresa
POST CONDICIONES: Validaciones e ingreso a la aplicación movil

105 - 120
 FLUJO PRINCIPAL
ACCIÓN DEL ACTOR
En la pantalla de autenticación de usuario
inserta usuario y contraseña, apreta el
botón de ingresar.
ACCIÓN DEL SISTEMA
Realiza validaciones para determinar si el
usuario y la contraseña son correctos, en
caso de que no sean correctos muestra un
mensaje de que el usuario y la contraseña
no son correctos, en caso que sea correcto
se obtiene un json web token para la
validación de seguridad y se redirige a la
pantalla principal con las opciones de la
plataforma.

Fuente: Elaboración Propia

Para el desarrollo de las funcionalidades del sprint se realizaron las siguientes pruebas
unitarias siguiendo la metodología tdd.

Tabla 32. Pruebas Sprint 6: Autenticación de Usuarios (Móvil)

PRUEBA ARRANGE ACT ASSERT

UsuCorrectoContraCorrecta_NoDevuelveError Usuario y Llamada de Autenticación

Contraseña métodos para correcta
autenticación

UsuCorrectoContraIncorrecta_DevuelveError Usuario y Llamada de Autenticación

Contraseña métodos para incorrecta
autenticación

UsuIncorrectoContraIncorrecta_DevuelveError Usuario y Llamada de Autenticación

Contraseña métodos para incorrecta
autenticación

106 - 120
 UsuIncorrectoContraIncorrecta_DevuelveError Usuario y Llamada de Autenticación
Contraseña métodos para incorrecta
autenticación

Fuente: Elaboración Propia

3.2.15. Planificación del Sprint 7: Visualización de Cursos (Móvil)

En la Tabla 33 se muestra el Sprint 7: Visualización de cursos que refleja las tareas

realizadas, especificadas en las historias de usuario y priorizadas en la pila del producto.

Tabla 33. Pila del sprint 7: Visualización de cursos (Móvil).

PILA DEL PRODUCTO OBJETIVO

DEL SPRINT
7

HISTORIA TAREA RESPONSABLE ESTIMADO ESTADO Visualización

DE EN HORAS de cursos
USUARIO

HU7 Consumir Programador 4 Terminado 4

endpoints para
listado de cursos
privados y
públicos
HU7 Desarrollo de Programador 4 Terminado 4
interfaz de
usuario de
listado de cursos
privados y
públicos

107 - 120
 HU7 Desarrollo de Programador 3 Terminado 3
interfaz de
usuario de
detalle de curso

HU7 Consumo de Programador 4 Terminado 4

endpoint para
registro y
abandono de
cursos publicos

Fuente: Elaboración Propia

A continuación, en la tabla 34 se especificará la Historia de Usuario de Visualización de

cursos.

Tabla 34. Historia de usuario HU7: Visualización de cursos (Móvil).

HISTORIA DE USUARIO: HU6 VISUALIZACION DE CURSOS (Móvil)

COMO: Personal de fuerza de ventas

QUIERO: Visualizar los cursos privados en los que los responsables capacitadores me
agregaron y también tener la posibilidad de capacitarme por mi cuenta mediante
la opción de cursos públicos.

PARA: Nivelar mi nivel académico en la empresa, además de poder informar mi

aprovechamiento de acuerdo a las herramientas que se me brindan.
VALIDACIÓN:

• Visualizar cursos públicos y cursos privados

• Visualizar el detalle de cursos privados y públicos
• Realizar un registro a cursos públicos

Fuente: Elaboración Propia

A continuación, se presentará los diagramas de casos de uso expandido de visualización

de cursos.

108 - 120
 Figura 25. Caso de Uso Expandido: Visualización de Cursos (Móvil).

Fuente: Elaboración Propia

Para un mejor entendimiento en la tabla 35. Especificación del caso de uso expandido de
visualización de cursos se detalla el proceso.

Tabla 35. Especificación del caso de uso: Autenticación de Usuarios (Móvil)

IDENTIFICADOR: Caso de Uso – CU1

CASO DE USO: Autenticación de Usuarios

DESCRIPCIÓN: Caso de uso de autenticación de usuarios en
el cual el jefe de capacitaciones y el
capacitador acceden a las funcionalidades
de acuerdo a rol en la aplicación web.
ACTOR: Jefe de capacitación, capacitador
PRECONDICIONES: Hacer uso de usuarios ya registrados en la
base de datos de la empresa
POST CONDICIONES: Validaciones e ingreso a la aplicación web
FLUJO PRINCIPAL
ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA

109 - 120
 En la pantalla de autenticación de usuario
inserta usuario y contraseña, apreta el
botón de ingresar.
Realiza validaciones para determinar si el
usuario y la contraseña son correctos, en
caso de que no sean correctos muestra un
mensaje de que el usuario y la contraseña
no son correctos, en caso que sea correcto
se obtiene un json web token para la
validación de seguridad y se redirige a la
pantalla principal con las opciones de la
plataforma.

Fuente: Elaboración Propia

Para el desarrollo de las funcionalidades del sprint se realizaron las siguientes pruebas
unitarias siguiendo la metodología tdd.

Tabla 36. Pruebas Sprint 7: Visualización de cursos (Móvil)

PRUEBA ARRANGE ACT ASSERT

ListarCursos_Publico Ninguno Consumo de endpoint Lista de cursos

listar cursos públicos

ListarCursos_Privado Ninguno Consumo de endpoint Lista de cursos

listar cursos privados

RegistrarACurso_Publico Id de curso publico Consumo de endpoint El proceso no devuelve

para registrarse a curso ningún error
publico

AbandonarCurso_Publico Id de curso publico Consumo de endpoint El proceso no devuelve

para abandonar curso ningún error
publico

Fuente: Elaboración Propia

110 - 120
3.2.16. Planificación del Sprint 8: Toma de Evaluación (Móvil)

En la Tabla 37 se muestra el Sprint 8: Toma de Evaluación que refleja las tareas realizadas,
especificadas en las historias de usuario y priorizadas en la pila del producto.

Tabla 37. Pila del sprint 8: Toma de Evaluación (Móvil).

PILA DEL PRODUCTO OBJETIVO

DEL SPRINT
8

HISTORIA TAREA RESPONSABLE ESTIMADO ESTADO Toma de

DE EN HORAS Evaluación
USUARIO

HU8 Consumo de Programador 4 Terminado 4

endpoint para
listado de
evaluaciones
por estudiante
HU8 Desarrollo de Programador 5 Terminado 5
interfaz de
usuario para
listado de
evaluaciones
por estudiante
HU8 Consumo de Programador 6 Terminado 6
endpoints para
ingreso a
evaluacion

HU8 Desarrollo de Programador 5 Terminado 5

interfaz de
usuario de
preguntas

HU8 Consumo de Programador 4 Terminado 4

endpoints para
envió de
respuestas de
evaluación

111 - 120
 HU8 Consumo de Programador 4 Terminado 4
endpoints para
la obtención de
nota después de
realizar
evaluación

HU8 Desarrollo de Programador 3 Terminado 3

interfaz de
usuario para
visualización de
nota de
estudiante

Fuente: Elaboración Propia

A continuación, en la tabla 38 se especificará la Historia de Usuario de Toma de

Evaluación.

Tabla 38. Historia de usuario HU8: Toma de Evaluación (Móvil).

HISTORIA DE USUARIO: HU6 VISUALIZACION DE CURSOS (Móvil)

COMO: Personal de fuerza de ventas

QUIERO: Interactuar con las evaluaciones creadas por los responsables capacitadores.

PARA: Informar el aprovechamiento académico que estoy teniendo en los cursos

además de
VALIDACIÓN:

• Visualizar cursos públicos y cursos privados

• Visualizar el detalle de cursos privados y públicos
• Realizar un registro a cursos públicos

Fuente: Elaboración Propia

A continuación, se presentará los diagramas de casos de uso expandido de visualización

de cursos.

112 - 120
 Figura 26. Caso de Uso Expandido: Toma de Evaluaciones (Móvil).

Fuente: Elaboración Propia

Para un mejor entendimiento en la tabla 39. Especificación del caso de uso expandido de
toma de evaluaciones se detalla el proceso.

Tabla 39. Especificación del caso de uso: Toma de Evaluación (Móvil).

IDENTIFICADOR: Caso de Uso – CU8

CASO DE USO: Toma de evaluaciones

DESCRIPCIÓN: Caso de uso de toma de evaluaciones en el
cual el personal de fuerza de ventas puede
realizar evaluaciones, mandar respuestas a
preguntas, y ver calificaciones de acuerdo a
la evaluación que fue realizada
ACTOR: Personal de fuerza de ventas
PRECONDICIONES: Debe existir una evaluación en la BD y esta
no debe haber sido respondida
anteriormente
POST CONDICIONES: Mensaje de confirmación de que la
evaluación se realizo correctamente

113 - 120
 FLUJO PRINCIPAL
ACCIÓN DEL ACTOR
En la pantalla de cursos al elegir la opción
de evaluaciones o trivias
En la pantalla de Gestión de
Medicamentos el Súper-Administrador
elige la opción Apretar tarjeta de
evaluación
Apretar respuesta tipo, texto, imagen
ACCIÓN DEL SISTEMA
Redirige a una pantalla en la cual se puede
ver un listado de las trivias o evaluaciones
que se pueden realizar.
Redirige a conjunto de pantallas de
preguntas
Almacena la respuesta localmente para su
futuro envío, en caso que la respuesta
apretada sea de la ultima pregunta, la
evaluación se envía y muestra la calificación
del estudiante en la evaluación

Fuente: Elaboración Propia

Para el desarrollo de las funcionalidades del sprint se realizaron las siguientes pruebas
unitarias siguiendo la metodología tdd.

Tabla 40. Pruebas Sprint 8: Toma de evaluaciones (Móvil)

PRUEBA ARRANGE ACT ASSERT

ListarEvaluaciones_Evaluacion Ninguno Consumo de Lista de

endpoint listar evaluaciones
evaluaciones de tipo general

ListarEvaluaciones_Trivia Ninguno Consumo de Lista de

endpoint listar evaluaciones
evaluaciones de tipo trivia

114 - 120
 ListarEstructuraEvaluacion Id de Consumo de Datos
evaluación endpoint para estructurados
obtener las acerca de
preguntas y la evaluación
estructura de la
evaluación

EnviarRespuestas_Evaluacion Id de Llamada al El proceso no

evaluación, método para devuelve
respuestas mapear las ningún error
respuestas
seleccionadas y
consumir el
endpoint con la
información
estructurada

VerNotas_Evaluacion Id de Consumo de Calificaciones

evaluación, Id endpoint para del estudiante
de usuario obtener las en la
notas de la evaluación
evaluación seleccionada

Fuente: Elaboración Propia

3.3. DISEÑO DEL SISTEMA PROPUESTO

El diseño del sistema propuesto pertenece a la fase de Pre-game de la metodología Scrum

de acuerdo a los establecido en el plan de trabajo del presente capitulo

115 - 120
3.3.5. Diseño y Arquitectura del Sistema

En este punto se considera el diseño y la arquitectura del sistema, y para su comprensión

a continuación en la Figura 27 se refleja el Esquema de la arquitectura de la plataforma, el
cual está conformado por tres capas: la primera capa contiene el acceso al sistema por
parte de los usuarios desde una interfaz diseñada en un navegador, la segunda está
constituida por el servidor, procesa los datos y permite la conexión entre usuarios y la base
de datos, y finalmente la tercera capa que contiene el gestor de base de datos el cual
almacena todos los datos del sistema.
Figura 27. Arquitectura de la plataforma

Fuente: Elaboración Propia

3.3.6. Diseño de la Base de Datos

En la presente sección se describirá el diseño, que tiene como objetivo convertir los
esquemas conceptuales locales en un esquema lógico global que se ajuste al modelo de
sistema de gestión de base de datos sobre el que se implementará en la plataforma.
116 - 120
Para el diseño de la base de datos se utilizó el modelo relacional, el cual considera la base
de datos como una colección de relaciones, donde la relación es considerada una tabla
compuesta por filas, y cada fila con un conjunto de campos. En la figura 28 se representa
el Modelo Relacional de la base de datos de la plataforma de aprendizaje online.

Figura 28. Diseño de la Base de Datos.

ArchivoCurso
acuId
arcId
UsuarioCurso
ucoId curId

usuId acuEstado

curId
ucoFecha
ucoEstado

Archivo
arcId
tiaId
arcTitulo
Curso
curId arcExtension

ticId arcDireccion
TipoCurso curTituloCompleto arcEstado
ticId arcFecha
curTituloCorto
ticNombre curDescripcion
ticEstado curFechaInicio
TipoMaterial curFechaFin
timId TipoPregunta
curFecha
timDescripcion tipId TipoArchivo
curEstado
timEstado tipDescripcion tiaId

tipEstado tiaDescripcion
tiaEstado

Lanzamiento
LanzamientoPregunta
lanId
lapId
evaId MaterialCurso
lanId macId
lanTitulo
evpId matId
lanFecha
lapEstado curId
lanEstado
macEstado

EvaluacionPregunta
evpId Evaluacion
EvaluacionResultado
evaId evaId
ereId
evpContenido curId
evaId
evpEstado tieId
usuId
evpArchivo evaTitulo
ereNota
evaTiempo
ereFecha
evaFecha
ereEstado
evaEstado

HistorialPregunta EvaluacionUsuarioRespuesta
Usuario hipId eurId
EvaluacionRespuesta
usuId usuId evaId
evrId
usuNombre evpId evpId TipoEvaluacion
evpId
tieId
hipEstado evrId
evrContenido
tieDescripcion
usuId
evrImagen
tieEstado
eurMinimizada
evrCorrecta
eurEstado
evrEstado
eurEstadoRespondido
eurFecha

Fuente: Elaboración Propia

3.4. INTERFAZ GRÁFICA DE LA PLATAFORMA

La interfaz de usuario es el enlace entre la plataforma de aprendizaje y el usuario, que es

el personal de fuerza de ventas. Para que el desarrollo de la plataforma de aprendizaje
sea una herramienta efectiva, debe incorporar mecanismos eficientes, para mostrar y
obtener de forma fácil y agradable.

117 - 120
La presente plataforma tiene opciones para el usuario pueda realizar las debidas
consultas, modificación y borrado de datos mediante menús adecuados, para tener una
mejor comunicación del usuario y el sistema.

Conforme a la metodología de Scrum a continuación se presentan las Interfaces Gráficas

de Usuario (GUI) diseñadas con Adobe XD

En la figura 29 se muestra la interfaz del Login donde se realizara el inicio de sesión para
el ingreso a la plataforma.

Figura 29. Pantalla de Login.

Fuente: Elaboración Propia

En la figura 30 se muestra la interfaz de pantalla de Inicio en la cual se eligió la opción de

Estudio.

118 - 120
 Figura 30. Pantalla de Inicio Opción: Estudio.

Fuente: Elaboración Propia

Figura 31. Pantalla de Búsqueda de Cursos.

Fuente: Elaboración Propia

En la figura 31 se ve el listado de cursos existentes en la plataforma, además de un

buscador por nombre y un filtro por línea medica.
119 - 120
En la figura 32 se muestra el detalle del curso, con opciones de administrar usuarios y
poder crear trivias y evaluaciones.

Figura 32. Pantalla de Detalle de Curso.

Fuente: Elaboración Propia.

120 - 120
BIBLIOGRAFIA
BIBLIOGRAFÍA

• Carlos Ble Jurado, “Diseño Ágil con TDD”, eBook. Primera Edición. Enero
2010
• K. Beck, "Aim, fire [test-first coding]," Software, IEEE, vol. 18, pp. 87-89,
2001.
• Buchan, J., Li, L., & MacDonell, S.G. (2011), “Causal Factors, Benefits and
Challenges of TestDriven Development: Practitioner Perceptions, in
Proceedings of the 18th Asia-Pacific Software Engineering Conference
(APSEC 2011)”. Hochiminh City, Vietnam, IEEE Computer Society Press.
• Jurado, C. B. (2010). Diseño Agil con TDD.

• Kent Beck, (2002) “Test Driven Development: By Example”, Addison-Wesley

Professional.
• Fernández, C., Baptista, L., & Hernández, S. (2003). "Metodología de la
Investigación" (6 ed.). México D.F., México: McGraw-Hill Interamericana.
Recuperado el 2 de marzo de 2021.
• Kent Beck, (1999). “Extreme Programming Explained: Embrace Change”,
Addison-Wesley Professional.
• Böhrt, M. (2000). "Capacitación y desarrollo de los recursos humanos:
reflexiones integradoras". Revista. Ciencia y Cultura, (1), 1-2. Recuperado el
24 de febrero 2021, de
http://www.scielo.org.bo/scielo.php?script=sci_arttext&pid=S2077-
33232000000200015
ANEXO A
 ENTREVISTA A JEFE DE INNOVACION TECNOLOGICA

Nombre: Lic. Milton Limachi Espejo Cargo: Jefe de Innovación

Tecnológica

1. ¿Qué área de Droguería INTI S.A. esta solicitando el proyecto?

R.- El área que esta solicitando el proyecto es el área de capacitaciones.
2. ¿Cuál es la idea básica del proyecto solicitado?
R.- La idea básica del proyecto solicitado es una plataforma educativa de
capacitaciones online, esta debe ser sencilla permitiendo la creación de
cursos, evaluaciones y que las mismas sean corregidas automáticamente.
3. ¿Qué tipo de aplicaciones se necesitan para que el producto satisfaga las
necesidades del área que requiere la solución?
R.= Para que el proyecto sea tomado como terminado es necesario que se
cuente con una aplicación web administrativa y una aplicación móvil que
permitirá al personal tomar diferentes cursos.
4. ¿Cuántos usuarios utilizaran el proyecto desarrollado?
R.- Primeramente, se empezará con un pequeño sector en La Paz, luego la
plataforma será utilizada a nivel nacional.

Analisis de la entrevista:

El sistema que se requiere es una plataforma online para capacitaciones, esta debe
permitir ser configurable en su totalidad, sin depender de otras tecnologías.
ANEXO B
ENTREVISTA A JEFE DE CAPACITACIONES

Nombre: Lic. Walter Rubin de Celis Cargo: Jefe de Capacitaciones

1. ¿Se cuenta actualmente con una plataforma?

R.- Si, actualmente se cuenta con una plataforma para realizar cursos y
evaluaciones.

2. ¿Cuál es el motivo por el cual se requiere una plataforma propia, en vez de seguir
haciendo uso de la que se tiene actualmente?

R.- La plataforma actual no es configurable totalmente, muchas veces tiene errores en

la corrección de exámenes, además de no contar con una buena estructura en la base
de datos, no es personalizable, muchas veces es lenta, y la interfaz de usuario es difícil
de manejar, estos problemas causan que las calificaciones a diferentes evaluaciones
no sean confiables.

3. ¿Qué cosas debería permitir realizar la plataforma?

R.- De la parte web la plataforma debería poder permitir la administración de cursos,

poder crear cursos, evaluaciones, además de controlar las calificaciones que se
generan en las mismas. Se debe permitir la configuración de preguntas dinámicas, de
forma amigable, tal que no parezca que el estudiante esta realizando una evaluación
y parezca mas un juego.

4. ¿Cuál es el flujo de las capacitaciones que se tiene actualmente?

R.- Actualmente el flujo de capacitaciones es el siguiente, cada vez que existe nuevo
material para poder crear cursos, se analiza el contenido que tendrán los mismos, se
crea un curso mediante los capacitadores y además, se dictan clases, en los cursos
existen evaluaciones, mayormente llamadas mediciones, las cuales permiten medir el
aprovechamiento académico del estudiante, de acuerdo a las notas nosotros podemos
entregar material para reforzar el estudio.

5. ¿Por qué son importantes las capacitaciones en Droguería INTI S.A.?

R.- Las capacitaciones en Droguería INTI S.A. son importantes porque permiten la
actualización y obtención de conocimientos de trabajadores de diferentes áreas,
permitiendo también igualar los conceptos y que al hablar acerca de un tema todos
hablen en una misma línea.

6.- ¿Por qué es necesario que las capacitaciones se puedan realizar en línea?

R.- Porque el personal esta acostumbrado a pasar este tipo de cursos, las
capacitaciones en línea permiten que el estudiante pueda tomar material en cualquier
lugar, además de permitirle estudiar en todo momento, así pudiendo ser aprovechado
en tiempos libres y sin barreras.

Análisis de la entrevista:

El área de capacitaciones es muy importante en Droguería INTI S.A debido a que

permite la nivelación del conocimiento del personal de diferentes áreas, el área de
fuerza de ventas tiene todo el conocimiento en cuanto manuales, medicamentos y
otros productos se refiere por lo que mantenerlos capacitados con información actual
es vital para la empresa.

122 - 120