Desarrollo de Un Gestor de Contenidos Digitales para La Autoformación en Programación 2013

ESCUELA MILITAR DE INGENIERÍA
"MCAL. ANTONIO JOSÉ DE SUCRE"

LA PAZ - BOLIVIA
TRABAJO DE GRADO
DESARROLLO DE UN GESTOR DE CONTENIDOS DIGITALES

PARA LA AUTOFORMACIÓN EN PROGRAMACIÓN
CASO: "CARRERA DE INGENIERÍA DE SISTEMAS - EMI IRPAVI"
JORGE CRISTOBAL CORTEZ CALLE
LA PAZ - 2014
ESCUELA MILITAR DE INGENIERÍA
MCAL. ANTONIO JOSÉ DE SUCRE
“BOLIVIA”
TRABAJO DE GRADO
DESARROLLO DE UN GESTOR DE CONTENIDOS DIGITALES

PARA LA AUTOFORMACIÓN EN PROGRAMACIÓN
CASO: "CARRERA DE INGENIERÍA DE SISTEMAS - EMI IRPAVI"
Postulante: JORGE CRISTOBAL CORTEZ CALLE
TRABAJO DE GRADO
PRESENTADO COMO
REQUISITO PARCIAL PARA
OPTAR EL TITULO DE
LICENCIATURA EN
INGENIERÍA DE SISTEMAS.
TUTOR: Ms. Ing. SERGIO TORO TEJADA
LA PAZ - 2014
ÍNDICE
CAPITULO I GENERALIDADES ................................................................................ 1
1.1. Introducción ................................................................................................ 2
1.2. Antecedentes ............................................................................................ 3
1.2.1. Antecedentes Institucionales .................................................................... 3
1.2.2. Antecedentes Históricos........................................................................... 4
1.2.3. Antecedentes Académicos ..................................................................... 11
1.3. Descripción del caso de estudio.............................................................. 12
1.3.1. Reseña Histórica ..................................................................................... 12
1.3.2. Marco Legal ............................................................................................. 14
1.3.3. Misión y Visión de la EMI ........................................................................ 15
1.3.3.1. Misión ....................................................................................................... 15
1.3.3.2. Visión ....................................................................................................... 15
1.3.4. Referencias de un LMS........................................................................... 15
1.3.5. Descripción del caso de estudio ............................................................. 16
1.3.6. Descripción de la Problemática .............................................................. 18
1.4. Planteamiento del Problema ...................................................................... 19
1.4.1. Problema principal................................................................................... 19
1.4.2 Problemas secundarios .............................................................................. 19
1.5. Objetivos ..................................................................................................... 20
1.5.1. Objetivo principal ..................................................................................... 20
1.5.2. Objetivos secundarios ............................................................................. 20
1.6. Hipótesis ..................................................................................................... 20
1.6.1. Determinación de variables ....................................................................... 20
1.6.1.1. Variable Independiente ............................................................................ 21
i
1.6.1.2. Variable Dependiente ............................................................................... 21
1.6.1.3. Variable interviniente ................................................................................ 21
1.6.2. Matriz de Consistencia ............................................................................ 21
1.7. Justificación ................................................................................................ 21
1.7.1. Justificación Técnica ............................................................................... 21
1.7.2. Justificación Tecnológica ........................................................................ 22
1.7.3. Justificación Operativa ............................................................................ 22
1.8. Alcances y limites ....................................................................................... 22
1.8.1. Alcance Geográfico ................................................................................. 22
1.8.2. Alcance Temporal ................................................................................... 22
1.8.3. Limites...................................................................................................... 23
1.9. Aportes ........................................................................................................ 23
CAPITULO II MARCO REFERENCIAL .................................................................... 24
2.1. ESCUELA MILITAR DE INGENIERÍA ....................................................... 25
2.1.1. Acerca de la EMI ..................................................................................... 25
2.1.1.1. Quienes somos......................................................................................... 25
2.1.1.2. Misión........................................................................................................ 25
2.1.1.3. Visión ........................................................................................................ 25
2.1.1.4. Objetivo Institucional ................................................................................ 26
2.1.1.5. Historia ...................................................................................................... 26
2.1.2. Palabras del Rector ................................................................................. 27
2.1.2.1. No tratamos de educar, simplemente inspiramos ................................... 27
2.1.3. Convenios interinstitucionales (Nacional e Internacional) ..................... 28
2.1.4. Bienestar universitario ............................................................................. 29
2.1.5. Unidad Académica La Paz ...................................................................... 30
ii
2.1.5.1. Campus Universitario ............................................................................... 32
2.1.5.2. Director de la Unidad Académica de La Paz .......................................... 32
2.1.6. Ingeniería en Sistemas ........................................................................... 32
2.1.6.1. Perfil profesional ....................................................................................... 32
2.1.6.2. Misión de Ingeniería de sistemas ............................................................ 32
2.1.6.3. Objetivo de Ingeniería de Sistemas ......................................................... 33
2.1.6.4. Competencias por áreas .......................................................................... 33
CAPITULO III MARCO TEÓRICO ............................................................................ 34
3.1 TEORÍA DE SISTEMAS ................................................................................ 35
3.1.1. Desarrollos............................................................................................... 36
3.1.2. Ámbito metamórfico de la teoría ............................................................. 36
3.1.2.1. Descripción del propósito ......................................................................... 36
3.1.2.2. Descripción del uso .................................................................................. 37
3.1.3. Aplicación ................................................................................................ 38
3.2. SISTEMA .................................................................................................... 39
3.3. INGENIERÍA DE SISTEMAS ..................................................................... 39
3.3.1. Otras definiciones .................................................................................... 40
3.3.2. Campos relacionados ............................................................................. 41
3.3.2.1. Sistemas de Información.......................................................................... 41
3.3.2.2. Investigación de operaciones .................................................................. 42
3.3.2.3. Ingeniería de sistemas cognitivos............................................................ 42
3.4. INGENIERÍA DE SOFTWARE ................................................................... 43
3.4.1. Implicaciones socioeconómicas ............................................................. 45
3.4.2. Metodología ............................................................................................. 46
3.4.2.1. Etapas del proceso................................................................................... 46
iii
3.4.3. Modelos y filosofías de desarrollo de software ...................................... 50
3.4.3.1. Naturaleza de la IS ................................................................................... 51
3.4.4. Responsabilidad ...................................................................................... 52
3.5. EDUCACIÓN A DISTANCIA ...................................................................... 52
3.5.1. Características......................................................................................... 53
3.5.2. Ventajas de la educación a distancia ..................................................... 54
3.5.2.1. Ventajas .....................................................Error! Bookmark not defined.
3.5.3. Roles en la educación a distancia .......................................................... 55
3.5.4. Educación semipresencial ...................................................................... 57
3.5.5. Educación a distancia en Hispanoamérica ............................................ 58
3.5.5.1. Argentina .................................................................................................. 58
3.5.5.2. Bolivia ....................................................................................................... 60
3.5.5.3. Chile .......................................................................................................... 60
3.5.5.4. Colombia ................................................................................................... 61
3.5.5.5. España ...................................................................................................... 62
3.5.5.6. México....................................................................................................... 63
3.5.5.7. Perú .......................................................................................................... 65
3.5.5.8. Puerto Rico ............................................................................................... 66
3.5.5.9. República Dominicana ............................................................................. 67
3.5.5.10. Venezuela ............................................................................................. 68
3.6. SISTEMA DE GESTIÓN DE CONTENIDOS............................................. 68
3.6.1. Otras consideraciones iniciales .............................................................. 69
3.6.2. Funcionamiento ....................................................................................... 70
3.6.3. Gestión de usuarios ................................................................................ 70
3.6.4. Tipos de gestores de contenidos ............................................................ 70
iv
3.6.5. Iniciativas de estandarización ................................................................. 71
3.6.6. Ventajas y Oportunidades ....................................................................... 72
3.7. SISTEMA DE GESTION DE APRENDIZAJE ............................................ 72
3.7.1. Características......................................................................................... 73
3.7.1.1. Propósito ................................................................................................... 73
3.7.1.2. LMS y CMS comparación ........................................................................ 74
3.7.1.3. LMS y LCMS comparación ...................................................................... 75
3.7.1.3. LMS como el término omnipresente ........................................................ 77
3.7.2. Aspectos técnicos ....................................................................................... 77
3.7.3. Aprender industria de gestión ................................................................. 77
3.8. SISTEMA DE GESTION DE CONTENIDOS DE APRENDIZAJE ............ 79
3.9. METODOLOGÍA SCRUM .......................................................................... 80
3.9.1. Características de Scrum ........................................................................ 80
3.9.2. Roles en Scrum ....................................................................................... 82
3.9.2.1. Roles Principales ...................................................................................... 82
3.9.2.2. Roles Auxiliares ........................................................................................ 82
3.9.3. Reuniones en Scrum ............................................................................... 83
3.9.3.1. Daily Scrum o Stand-up meeting ............................................................. 83
3.9.3.2. Scrum de Scrum ....................................................................................... 84
3.9.3.3. Reunión de Planificación del Sprint (Sprint Planning Meeting) .............. 84
3.9.3.4. Reunión de Revisión del Sprint (Sprint Review Meeting) .......................... 85
3.9.3.5. Retrospectiva del Sprint (Sprint Retrospective) ...................................... 85
3.9.4. Sprint........................................................................................................ 85
3.9.5. Documentos ................................................................................................ 86
3.9.5.1. Product backlog ........................................................................................ 86
v
3.9.5.2. Sprint backlog ........................................................................................... 86
3.9.5.3. Burn down chart ....................................................................................... 86
3.9.6. Scrum aplicado al desarrollo de software .............................................. 87
3.9.7. ¿Cuándo se utiliza?................................................................................. 88
3.9.6. Beneficios ................................................................................................ 88
3.9.7. El proceso ................................................................................................ 89
3.9.7.1. Planificación de la iteración ..................................................................... 90
3.9.7.2. Ejecución de la iteración .......................................................................... 90
3.9.7.3. Inspección y adaptación........................................................................... 91
3.10. MÉTODOS .................................................................................................. 92
3.10.1. Método científico ...................................................................................... 92
3.10.1.1. Descripciones del método científico ..................................................... 93
3.10.2. Método hipotético-deductivo .................................................................... 94
3.10.3. Método de Razonamiento inductivo ........................................................ 97
3.11. TÉCNICAS .................................................................................................. 99
3.11.1. La técnica de la entrevista ....................................................................... 99
3.11.1.1. Definición de entrevista ........................................................................ 99
3.11.1.3. Etapas de entrevista ........................................................................... 101
3.11.2. La técnica de la encuesta y el cuestionario .......................................... 101
3.11.2.1. Desarrollo ............................................................................................ 103
3.11.2.2. Algunos procedimientos para aplicar el cuestionario ........................ 106
3.12. Arquitectura de software .......................................................................... 107
3.12.1. Arquitectura ............................................................................................ 107
3.12.2. Breve reseña histórica ........................................................................... 108
3.12.3. Modelos o vistas ..................................................................................... 109
vi
3.12.4. Arquitecturas más comunes .................................................................. 109
3.13. Lenguaje Unificado de Modelado ............................................................ 110
3.13.1. Estandarización de UML ........................................................................ 111
3.13.2. Tipos de Diagramas de UML ................................................................. 112
3.13.2.1. Estructura ............................................................................................ 112
3.13.2.2. Comportamiento.................................................................................. 112
3.13.2.3. Interacción ........................................................................................... 112
3.13.3. Críticas a UML ........................................................................................ 113
3.13.4. Historia .................................................................................................... 113
3.13.4.1. Antes de UML 1.x ............................................................................... 113
3.13.4.2. UML 1.x ............................................................................................... 114
3.13.4.3. UML 2.x ............................................................................................... 115
3.14. Sistema de gestión de bases de datos .................................................... 115
3.14.1. Introducción ............................................................................................ 116
3.14.2. Historia .................................................................................................... 116
3.14.2.1. Sistemas de navegación de 1960 ...................................................... 117
3.14.2.2. Sistemas relacionales de 1970 .......................................................... 118
3.14.2.3. Sistemas SQL de finales de la década 1970 ..................................... 120
3.14.2.4. Sistemas orientados a objetos de 1980 ............................................. 121
3.14.2.5. Sistemas NoSQL de 2000 .................................................................. 122
3.14.2.6. Sistemas XML 2010 ............................................................................ 122
3.14.3. Componentes ......................................................................................... 122
3.14.4. Lenguajes de modelación ...................................................................... 123
3.14.4.1. Estructura jerárquica ........................................................................... 124
3.14.4.2. Estructura en red ................................................................................ 124
vii
3.14.4.3. La estructura relacional ...................................................................... 125
3.14.4.4. La estructura multidimensional ........................................................... 125
3.14.4.5. La estructura orientada a objetos ....................................................... 125
3.14.5. Lenguajes de consulta ........................................................................... 126
3.14.6. Arquitectura ............................................................................................ 126
3.15. Número índice........................................................................................... 128
3.15.1. Aproximación .......................................................................................... 128
3.15.2. Propiedades ........................................................................................... 129
3.15.3. Índices simples y complejos .................................................................. 130
CAPITULO IV MARCO PRÁCTICO ....................................................................... 131
4.1. ANÁLISIS DE LA SITUACIÓN ACTUAL ................................................. 133
4.1.1. Análisis de la Institución ........................................................................... 133
4.1.1.1. Especificación del proceso de enseñanza aprendizaje. ....................... 137
4.1.2. Análisis del sistema propuesto ............................................................. 139
4.2. DETERMINACIÓN DE REQUISITOS...................................................... 142
4.2.1. Especificación de requisitos.................................................................. 142
4.2.3. Identificación de roles y tareas ............................................................. 143
4.3. ANÁLISIS DEL SISTEMA ........................................................................ 144
4.3.1. Especificación de escenarios. .............................................................. 144
4.3.2. Diseño de procesos............................................................................... 152
4.3.3. Diseño de Secuencia ............................................................................ 156
4.4. DISEÑO DEL SISTEMA ........................................................................... 160
4.4.1. Diseño Conceptual ................................................................................ 161
4.4.1.1. Esquema Conceptual ............................................................................. 161
4.4.2 Diseño Navegacional................................................................................ 162
viii
4.4.2.1 Diseño de la Arquitectura ....................................................................... 162
4.4.2.2. Desarrollo de la Topología Navegacional ............................................. 164
4.4.2.3. Diseño de la Base de Datos .................................................................. 167
4.4.2.4. Diseño de la Interfaz .............................................................................. 168
4.5. PRUEBA DE HIPOTESIS ........................................................................ 171
CAPITULO V ESTUDIO COSTO BENEFICIO....................................................... 187
5.1. DETERMINACION DE COSTOS ............................................................. 188
5.1.1. Costos Fijos ........................................................................................... 188
4.1.1.1. Costos de licencia de software. ............................................................. 189
4.1.1.2. Costos de Hardware............................................................................... 189
4.1.1.3. Costos de desarrollo de Software.......................................................... 189
4.1.2. Costos Variables ................................................................................... 193
4.1.2.1. Costos de Investigación ......................................................................... 193
4.1.2.2. Costos de Material de Escritorio ............................................................ 194
5.2. Estimación de los beneficios .................................................................... 195
5.2.1. Beneficios Tangibles ............................................................................. 195
5.2.2. Beneficios Intangibles ........................................................................... 197
5.3. Relación Costo Beneficio ......................................................................... 197
CAPITULO VI CONCLUCIONES Y RECOMENDACIONES................................. 150
6.1. CONCLUCIONES ..................................................................................... 151
6.2. Recomendaciones .................................................................................... 152
ix
Índice de Figuras
Figura 1.1 Portal de la EMI ....................................................................................... 16
Figura 4.1 enseñanza Dentro del Aula ................................................................... 135
Índice de Tablas
Tabla 4.1 Plan de Desarrollo del Proyecto ............................................................. 132
x
CAPITULO I
GENERALIDADES
1
Resumen
En este capítulo se presentan los lineamientos

generales del trabajo de grado, relativos a los
antecedentes, problemas, objetivos, hipótesis,
justificaciones y alcances que posteriormente serán
fundamentados para su culminación.
1.1. INTRODUCCIÓN
El sistema de aprendizaje es el alma de la sociedad humana, el cual siempre está

buscando nuevas herramientas y métodos de enseñanza con el fin de adoptarlos
al proceso de aprendizaje, con la finalidad de mejorarlo. En tal sentido una de las
herramientas para este objetivo es la del aprendizaje electrónico, el cual fomenta
la educación a distancia como medio de enseñanza flexible independientemente
del tiempo y espacio. Actualmente este modelo de educación tiene aceptación en
instituciones educativas universitarias, como alternativa para ampliar la cobertura
académica e incrementar los niveles de acceso.
De hecho el núcleo (core) de la educación a distancia o auto formación son los

denominados Sistemas de gestión de contenidos (LMS1 por sus siglas en inglés
Learning Management System) que proporcionan una herramienta para
automatizar, destinada a la administración de los materiales de estudio en formato
de almacenamiento electrónico o digital. Cabe hacer mención que la
implementación de la gestión de contenidos digitales es responsabilidad absoluta
del docente, instructor o facilitador que dicta la materia.
El presente proyecto de grado desarrolla un sistema para la gestión de contenidos

digitales para el aprendizaje del lenguaje de programación JAVA2, el mismo que
tiene como base el modelo de seguimiento académico basado en competencias el
1
LMS: Sistemas de Gestor del Aprendizaje
2
Lenguaje de Programación
2
cual permitirá el acceso ilimitado de los estudiantes de la carrera de ingeniería de
sistemas de la EMI3, para promover la actualización constante de los mismos.
1.2. ANTECEDENTES
A continuación se presenta una descripción de los antecedentes institucionales

que permiten identificar la problemática a ser tratada en el presente Trabajo de
Grado. Además se presenta la descripción de diferentes Proyectos anteriormente
realizados de similar temática tanto en trabajos académicos internacionales como
también en nuestro medio, a fin de especificar las diferencias con el presente
proyecto.
1.2.1. Antecedentes Institucionales
El caso de estudio del presente proyecto se centra en la Escuela Militar de

Ingeniería, el actualmente cuenta con una plataforma de educación virtual, la
misma destinada a nivel de diplomados y posgrados de estudios en educación
superior. El propósito del presente programa de Diplomado emitido bajo la
modalidad virtual, es brindar a los participantes conocimientos necesarios para el
adecuado ejercicio de la docencia universitaria.
Otra de las herramientas a mencionarse es la biblioteca virtual de la EMI, que

permite el acceso a toda la comunidad universitaria, esta herramienta permite a
los usuarios realizar búsquedas referenciales de material bibliográfico y su
respetiva reserva de préstamos de libros.
Este portal cuenta con 4 secciones fundamentales, ellas son:
Búsquedas temáticas; donde el usuario podrá buscar determinado material

bibliográfico de acuerdo a la catalogación que se realizó con cada uno de estos
materiales
3
Escuela Militar de Ingeniería
3
Búsquedas expertas; donde el usuario podrá buscar determinado material
bibliográfico de acuerdo a distintos criterios, tales como autor, titulo, editorial y
otros.
El servicio S.A.I. (Servicio de Alerta e Información); donde el usuario podrá ver

todas las actualidades, novedades de la biblioteca.
El relevamiento de información acerca de las plataformas virtuales de contenidos

con las que cuenta la EMI, presentan las siguientes limitantes:
 El acceso a una plataforma de autoaprendizaje se encuentra restringida a

nivel de cursos de postgrado, este aspecto inspiro al autor del presente
proyecto a desarrollar una plataforma destinada a los estudiantes de pregrado
de la EMI. Commented [L1]: Consultar a Sergio Toro, si sería
conveniente colocar el contexto, “para la emi en la carrera de
 La plataforma de la biblioteca virtual, puede ser accedida remotamente desde ingeniería de sistema ….”
el portal web de la EMI, pero el acceso al contenido específico, solo puede ser
consultado de manera presencial en las dependencias de la institución en
horarios de oficina, lo cual dificulta la obtención de la información necesaria en
casos de horarios fuera de oficina en los que regularmente el estudiante de pre
o postgrado realiza procesos de investigación. Adicionalmente una de las
funcionalidades de dicha herramienta, es la de poder descargar los contenidos
en formato PDF; funcionalidad que no se encuentra activada dentro la misma.
 Un aspecto a tomar en cuenta son los contenidos desactualizados que se
encuentran en dichas plataformas, ya que los mismos datan del año 2004 a
2005.
Los aspectos antes mencionados fueron tomados en cuenta para que los
contenidos llenados dentro de la presente herramienta sean de entera
responsabilidad del docente encargado de la materia.
1.2.2. Antecedentes Históricos
La educación siempre ha sido uno de los aspectos esenciales en todas las

sociedades durante la trayectoria de las épocas en la historia del Mundo. En esa
4
línea de tiempo, hay que destacar los años 1990, ya que fueron momentos donde
el aprendizaje se torna como un concepto de alcance globalizado, donde los
límites en tiempo, espacio y zona territorial dejaron de ser delimitantes para lograr
una formación educativa ( Alvarado, A.; Falcón, D.; Fontela, M.; Lozano, J. &
Vivanco, C., 2010). De esta forma, la humanidad recibe el nuevo Siglo XXI, con la
demanda de un nuevo mercado educativo, que solicita el incremento de recursos
de aprendizaje en línea “On-Line” con contenidos de alta calidad en todos los
servicios.
Actualmente la tecnología permite a los expertos, desarrollar de forma continua,

contenidos digitales que pueden ser accedidos mediante soluciones tecnológicas,
este modelo de acceso a la información es denominado como aprendizaje a
distancia en línea “On-Line”.
Este concepto es definido por los expertos como una modalidad de aprendizaje a
distancia, dentro de un sistema de formación interactivo por medio del Internet
para desarrollar programas de aprendizaje. Esto es, porque el “E-Learning”
requiere de los medios electrónicos-digitales para lograr llegar a un estudiante a
distancia o de forma remota (no presencial). Esta modalidad se ejecuta de dos
formas: “E-Learning”, cuando el conocimiento se distribuye de manera exclusiva
vía Internet, y “B-Learning4” o “Blended Learning”, cuando se combina el
aprendizaje a distancia con el aprendizaje presencial.
De esta forma, varias instituciones educativas han adoptado ambas modalidades

(“E-Learning y “B-Learning”). Esto es, porque han encontrado que en sus ventajas
principales les ofrece: la reducción de costos para brindar cursos a más número
de participantes que en el aula de clases tradicional, el ahorro en seminarios y
capacitación, la flexibilidad de horarios, permite al estudiante calendarizar el curso
según su realidad y disponibilidad, interacción activa entre el estudiante y el
profesor durante el curso, hace del aprendizaje un proceso activo y dinámico. Este
tipo de interacción se ofrece generalmente por medio de foros de discusión,
videoconferencias, chat, correo electrónico, blog, y otros medios de participación.
4
Modalidad Semipresencial
5
De esta forma, la sociedad está viviendo el desarrollo de un nuevo estilo de
aprender, que facilita a más personas el continuar su capacitación y desarrollo
profesional. Por ello, a medida que se han desarrollado las tecnologías y se hacen
más populares en el uso y aplicación para aprender efectivamente, se han creado
alternativas para que el “E-Learning” responda a las necesidades y demandas
académicas-administrativas de las instituciones que han adoptado la modalidad.
De esta forma, el comercio del aprendizaje a distancia por medio del “E-Learning”
también se han incrementado, creando plataformas tecnológicas que optimicen el
uso de los contenidos y reduzcan los costos administrativos (Berson & Associates,
2009).
Una de las alternativas para la implementación de este modelo de aprendizaje es

“LMS” Sistemas de administración para el aprendizaje, mediante un programa que
se instala en un servidor que permita a los usuarios docentes administrar la
información que se va almacenando, de esta forma se logra contar con un
repositorio de información digital que es distribuida a los estudiantes de la
materia, al mismo tiempo permite controlar las actividades, ejecuciones y datos
provistos para la educación o formación presencial y en línea “On-Line”. Las
funciones principales de los “LMS” está el gestionar, administrar y dirigir los
usuarios, recursos, actividades de formación académica y sus contenidos,
administrar los accesos a los contenidos, controlar y dar seguimiento del proceso
educativo, realizar las evaluaciones, generar los informes de la ejecución realizada
durante cada curso o actividad educativa, gestionar los servicios de comunicación
(como lo son los foros de discusión, videoconferencias, chats, comunicación por
correo electrónico, blogs, entre otros). Claro está, sin dejar a un lado, que estos
programas están desarrollados para que se compartan y ejecuten a través del
Internet (Eduteka, 2007).
Para ver con detenimiento cómo se ha evolucionado a esta nueva forma de

educar y aprender, hay que dar un vistazo en la historia. Si se realiza un viaje por
el tiempo, se pueden destacar varios sucesos importantes en la trayectoria del
desarrollo de lo que hoy se reconoce como los “LMS”. Primeramente, se puede
6
generalizar que los “LMS” han ido evolucionando desde los años 1960, con el
sistema de PLATO5 desarrollado en la Universidad de Illinois en Urbana-
Champaign, y que ahora cuenta con los derechos de propiedad de PLATO
Learning. Luego, para 1963 Orange Coast College en California trabaja el
programa de OCC, financiado por el Gobierno Federal para la organización de las
Profesiones de la Ley de Desarrollo para Capacitar y Desarrollar el Currículo
Nacional para el Procesamiento de Datos, capacitando a 100 profesores. Luego,
IBM6 introduce el “Coursewriter” un sistema interactivo en línea “CAI”, donde
incluye herramientas para el manejo de un curso, los roles de los usuarios como
instructor, administrador, estudiante y la comunicación entre estos. En este
estudio, IBM contó con la participación de la Universidad de Stanford. Este
sistema se probó a mediados de los 70 entre Italia y los Estados Unidos con una
escuela internacional. Mientras tanto, en Londres se desarrolló lo que se conoció
como el “Havering Computer Managed Learning System”, logrando para 1980
sobre 10,000 estudiantes y 100 educadores participando en el mismo. Mientras,
en 1973 “Trinity University7” en Texas logra mantener 1500 variables de data, en
lo que denominaron como el sistema de información estudiantil, donde se incluía
información personal de los estudiantes y facultad, los cursos, el calendario,
matrícula y catálogo de la institución, llegando a ser un “Interaction Course
Management System”. Mientras tanto, en los Estados Unidos surge la primera
universidad virtual conocida como “Litoral Community College”. Mientras la
Universidad Abierta del Reino Unido imparte tres cursos en línea a través del
proyecto Cicerón, y luego estos desarrollan el sistema de “Telewriting” en el
proyecto Cíclope. Para 1980, surge “SuccessMaker” como el sistema para el
kínder al 12vo. grado, de gestión del aprendizaje con énfasis en la lectura,
escritura y matemáticas. En la Universidad de Montreal se ofrece el sistema
conocido como “CAFÉ”, donde los estudiantes estudiaban a su propio ritmo
(Berson & Associates, 2009).
5
Lógica de Operaciones Escolares Automatizadas Programadas(Lógica Programada para la
Enseñanza de Operaciones Automatizadas),
6
Máquinas de Negocios Internacionales (International Business Machines)
7
http://web.trinity.edu/
7
Ahora bien, en el 1980 se lanza el inicio de lo que hoy día se conoce de forma
más sofisticada como “LMS”, fue el Administrador de Aprendizaje o “TLM8”. Este
incluyó distintos roles de los estudiantes, instructores, asistentes educativos, y los
administradores. Este sistema se podía acceder de forma remota vía telefónica,
con un estudiante o un profesor como un emulador de terminal. El sistema tenía
una capacidad de prueba, con un banco de pruebas sofisticadas, y generaba las
actividades prácticas basadas en una base de datos estructurada con objetivos de
aprendizaje. Los instructores y los estudiantes se podían comunicar por medio del
terminal. Los instructores podían bloquear los estudiantes o publicar mensajes. El
“TLM9” se utilizó ampliamente en el Instituto Alberta de Tecnología del Sur y en
“Bow Valley College”, ambos ubicados en Canadá. Para el 1984, Apple10 financia
el primer círculo de aprendizaje en línea creado por la Universidad de California,
San Diego y escuelas en Japón, Israel, México, California y Alaska. En el 1987 en
Noruega, se comenzó el primer curso en línea de educación a distancia con su
propio “Learning Management System”. Por otro lado, en Minneapolis se creó lo
que se conoce como Authorware Inc., una versión para Macintosh y luego otra
para PC, denominado como "Curso de Acción” (Berson & Associates, 2009).
Para el 1995 Murray Goldberg comenzó el desarrollo de WebCT11 en la

Universidad de Columbia en Vancouver, Canadá. WebCT pasó a convertirse en
uno de los entornos de aprendizaje más utilizado durante finales de 1990 a
principios de 2000. Mientras que en 1996 Glenn Jones, Presidente, y Bernard
Luskin, rector fundador de Jones de la Universidad Internacional, inicia lo que es
“Jones International University”, la cual se convirtió en la primera universidad
acreditada totalmente basado en web. En la Universidad de Colonia desde 1997,
se desarrolla el software de código abierto bajo la licencia GPL12 (primera edición:
ILIAS 1.6). Junto con los desarrolladores de otras universidades de Renania del
Norte Westfalia, el equipo de ILIAS fundó la iniciativa “Campus Source” para
8
Modelado a nivel de transacción
9
Modelado de Nivel de Transacción
10
Empresa multinacional estadounidense que diseña y produce equipos electrónicos y software
11
Herramientas para Cursos Web
12
Licencia Publica General
8
promover el desarrollo de los LMS de código abierto y software para la enseñanza
en las universidades. Mientras tanto, Blackboard Inc. presenta una solicitud de
patente relativa a los sistemas de apoyo basados en Internet y los métodos de la
educación y adquiere Mad Duck Technologies LLC13, los desarrolladores de la
"Web del Curso en una Caja". En el otoño de 2000, el “LMS” de código abierto
OLAT desarrollado en la Universidad de Zurich, ganó el Premio de Medida, por su
concepto pedagógico. Los laboratorios de Cyber Learning14, Inc. se fundan para
dar paso a su principal producto, ANGEL Learning Management System (“LMS”).
Por otro lado, en el campo de las plataformas con propietario comercial, Microsoft
lanza su más reciente ofrecimiento programado, SharePoint LMS (Berson &
Associates, 2009).
Mientras tanto, en el mundo de “Código Abierto” se desarrolló el proyecto

Claroline, iniciado en la Universidad Católica de Lovaina (Bélgica) por Thomas De
Praetere y fue apoyado financieramente por la Fundación Lovaina, partiendo de
las necesidades de los docentes y los estudiantes. Claroline está construido sobre
sólidos principios pedagógicos que permite una gran variedad de configuración,
incluyendo la ampliación del aula tradicional y el aprendizaje colaborativo en línea.
De esta plataforma, surge Dokeos y del mismo, tan reciente como en enero de
2010, la más reciente y destacada aplicación, Chamilo. Ahora se ve claramente
cómo en las últimas décadas, especialmente desde el 2002 hasta el 2010, se ha
proliferado el agresivo desarrollo de plataformas “LMS”, especialmente de código
abierto como lo son: ATutor, Moodle, Sakai, OLAT, Ganesha, DoceboLMS, ELML,
Fle3, Claroline, Dokeos, Chamilo, entre otros (González, 2002).
Ahora bien, las instituciones en el año 2010 les ha surgido una nueva situación, el
no saber decidir cuál “LMS” es la mejor alternativa para adoptar y cumplir con las
expectativas académicas y administrativas. Esto es, por la gran variedad de
alternativas que ahora existen, entre los productos comerciales con propietario y
los de código abierto, para cubrir la gran demanda de estudiantes interesados en
estudiar por medio de la modalidad de “E-Learning” versus la gran variedad de
13
Tecnologías Madduck, Control de Enlace Lógico
14
La Fundación Nacional de Educación (NEF) sin fines de lucro.
9
comercios que se han lanzado a suplir dicha necesidad, y ofertarla a las
instituciones educativas con la calidad que estos últimos buscan. Pero, surge otra
variable a esta situación, los programados de “LMS” que las empresas desarrollan,
son parte de una respuesta a la evolución tecnológica en la educación. Por lo
tanto, estas alternativas traen consigo un alto nivel de competitividad y
globalización, provocando en este mercado de los “LMS” una competencia
continua y cambiante. Por lo que, cada día las instituciones tienen el reto de
evaluar con mayor efectividad y eficacia, su mejor alternativa de “LMS” (Grupo
Conforsa, 2010).
De esa forma, hoy día las instituciones educativas cuentan con nuevos retos ante
estas modalidades educativas: ser efectivos y eficaces en su planificación, toma
de decisiones, evaluación y definición de futuro. Ya que deben responder a las
alternativas académicas y administrativas que cobijen a un estudiantado global,
cambiante y competitivo, utilizando un “LMS” bajo la modalidad del “E-Learning” y
el “B-Learning”. Hay que destacar, que las instituciones educativas solo pueden
mitigar y minimizar el efecto de la dinámica cambiante de las versiones de “LMS”
que adopten, considerando que estos siempre van a continuar evolucionando, y
en un gran caso de estos, mejorando sus competidores comerciales y de código
abierto “OpenSource” (Grupo Conforsa, 2010). Así es que la institución debe
evaluar con detenimiento el gran paso que tomará al adoptar el “LMS” para su
modalidad de “E-Learning y “B-Learning”. Por ello, es importante considerar una
serie de aspectos de máxima trascendencia, a la hora de garantizar el éxito en
proyectos de esta naturaleza. Primeramente, la institución debe conocer el
enfoque tecnológico propuesto por las empresas que se han identificado como
potenciales proveedores. Además, debe contemplar ciertos puntos fundamentales:
si poseen tecnología sólida, estable y suficientemente contrastada con
experiencias constatables; si se trata de una empresa que entiende los procesos
de aprendizaje además de la tecnología; cuál es el compromiso de esta empresa
con la región en la que opera; si tiene un modelo de negocios con sentido para el
ámbito en el cual opera; y si realmente está gestionando el conocimiento
(maestrodelweb, 2010; González, 2002).
10
La revista “Learning Review15” ofrece una generalización para tener en cuenta al
momento de la implantación de proyectos de “E-Learning”, y los factores que se
deben considerar para la selección del producto a utilizar. Ellos recomiendan, que
en el proceso de implantación de un proyecto de gestión del conocimiento en línea
“On-line”, y no importando cuál sea la aplicación (una plataforma de “ELearning”,
una biblioteca digital, un administrador de conocimientos, o una solución de “M-
Learning16”), el factor tecnológico debe ser considerado tanto a nivel de
aplicaciones como de contenidos. También, hay que tener en cuenta cuáles son
las necesidades específicas de cada programa académico y sus cursos, el perfil
de los estudiantes, de los docentes, y las necesidades de la administración, para
que la plataforma de “E-Learning” responda a cada uno de ellos. Por otra parte, el
costo de su implantación y qué alternativas cuenta el suplidor de la plataforma
para ofrecer las actualizaciones y nuevas necesidades que les surja a la institución
en el futuro. Finalmente y no menos importante, un plan de capacitación en el uso
adecuado de la plataforma, y si hay problemas o cambios en una o varias
aplicaciones en la misma, que les ofrezca apoyo al usuario o mejor conocido como
“Help Desk” para las necesidades técnicas y académicas, así se mitigarán las
dificultades del uso y manejo ineficiente de todos los usuarios en la plataforma
(Watson & Watson, 2007).
Como expresa Farley, lo más importante en este esquema de “LMS”, es el que las
instituciones acepten el reto que les impone la sociedad del conocimiento,
afrontando, diseñando, construyendo y liderando los nuevos procesos que se
orienten a la sociedad. (Biscay, 2010).
1.2.3. Antecedentes Académicos
El sistema de enseñanza virtual para el Museo San Francisco creado por la

estudiante Nancy Corina Jurado Laime, de fecha 18 de diciembre de 2009, trabajo
realizado en la UMSA. Dicho proyecto utilizó el método de Ingeniería WEB basada
15
http://www.learningreview.com/
16
Aprendizaje Móvil
11
en UML que proporciona un modelado compacto y apropiado para la
documentación.
Sistema de Educación Multimedia de Idiomas a Distancia conectada y no

Conectada a Internet desarrollado por Juan Carlos Cuellar Sonco estudiante de la
UMSA en fecha 20 de noviembre del 2011, desarrollo un sistema que está basada
en el internet y sistemas multimedia como apoyo a los sistemas de enseñanza no
presencial.
Diseño e implementación de una Intranet para la Universidad de Aquino Bolivia

creado por Miguel Ángel Paredes Loza estudiante de la EMI en la gestión 2001
presento el siguiente trabajo que se basa en una conexión de redes privadas que
utilizan la tecnología de Internet para compartir dentro de una organización parte
de sus sistemas de información y sistemas operacionales.
Sistema experto para la enseñanza del idioma aymara creado por Maribel Deysi
Paucara Morales estudiante de la EMI en la gestión 2003, que está dirigido a los
estudiantes del sistema escolar, el proyecto persigue implementar un nuevo
método de aprendizaje de un idioma en específico, dando así lugar a un nuevo
sistema de enseñanza de un idioma nativo.
Cada uno de los trabajos antes mencionados son un aporte significativo al campo
de la educación a distancia, para el acceso a los mismos solo se lo puede realizar
de forma física, con lo cual se evidencia que no se puede acceder virtualmente al
contenido de los mismos, convirtiéndose en una simple referencia de
investigación, de igual forma no se puede contactar a los investigadores de cada
uno de los trabajos, lo que ocasiona que se pierdan posibilidades reales de
emprendimiento laboral y empresarial.
1.3. DESCRIPCIÓN DEL CASO DE ESTUDIO
1.3.1. Reseña Histórica
12
Después de la contienda del Chaco y a partir del año 1936, se hicieron manifiestas
en el interior del Ejército de Bolivia, iniciativas para establecer organizaciones de
formación profesional técnica en diferentes niveles, entre las que podemos
destacar las siguientes:
1) Escuela de Transmisiones, en funcionamiento a partir del año 1939 hasta

1944. Formaba Ingenieros en Electricidad. Instituto Geográfico Militar, en
funcionamiento a partir del año 1948 a la fecha forma su propio personal
técnico en el ámbito de la Topografía, mediante la Escuela de Topografía y
Geodesia ′Tcnl. Juan Ondarza′.
2) Escuela Central Técnica en funcionamiento a partir de 1944 a 1953. Formaba

técnicos ferrocarrileros y mecánicos (Viacha).
La sucesión de hechos y acontecimientos referidos anteriormente, dieron lugar a

que el mando considere no sólo necesaria sino legítima y urgente la formación de
oficiales ingenieros en el seno del Ejército. En noviembre de 1946 el Estado Mayor
inició el estudio para la creación de la especialidad de ingeniería con el propósito
de ser incorporada en el Pensum de estudios del Colegio Militar como un arma
más.
El resultado de los estudios analíticos del proyecto dio lugar a la aprobación de la

creación del Arma de Ingeniería, que a partir de enero de 1947 se dicta en el
primer instituto del Ejército.
Si bien del Colegio Militar egresaba una serie de Ingenieros de Combate, se

consideró, en el marco de los análisis efectuados en el más alto nivel del Estado
Mayor del Ejército, que era necesario organizar un instituto de carácter académico
superior destinado exclusivamente a la formación académica en el campo de la
Ingeniería, en sus distintas especialidades y con miras a la utilización contributiva,
tanto en tiempo de paz como en tiempo de guerra.
El año 1948 se presentó un proyecto para organizar un curso de habilitación,

consistente en dos años de estudio, destinado a habilitar como ingenieros a los
13
tenientes y subtenientes egresados del Colegio Militar en el arma de Ingeniería y
paralelamente otro de similares características de un año de estudio para formar
ingenieros de combate como ser los aspirantes civiles.
Un año después, en 1949, se organizó en la guarnición de La Paz un Batallón

básico, en el que participaron personal que ya vencieron cursos de carácter
técnico o estaban asistiendo a este tipo de cursos en las diferentes escuelas
técnicas del Ejército. Este Batallón se convirtió posteriormente en la “Escuela
Central Técnica” con asiento en la localidad ferroviaria de Viacha. Sin embargo en
el marco del objetivo básico, los oficiales que se encontraban destinados en la
referida escuela, fueron trasladados al edificio de la Avenida Arce en la ciudad de
La Paz, que actualmente alberga a las instancias superiores de la EMI.
El año 1950, como resultado de un proceso de estudios organizacionales y

analíticos que se efectuaron en el interior del Ejército, consultando modelos de
institutos de ingeniería militar en funcionamiento de Brasil, EE.UU. y México, el
Estado Mayor de Ejército de Bolivia determinó como un paso necesario y positivo
en sus proyecciones, la creación de un instituto técnico de nivel académico, con
funcionamiento independiente y con la responsabilidad de formar oficiales del
Ejército en las especialidades de Ingeniero Constructor y Geodesta.
1.3.2. Marco Legal
De conformidad a lo establecido en los planes del Estado Mayor del Ejército y por
gestiones del mismo, mediante Decreto Supremo Nº 02226 del 26 de octubre de
1950, el Gobierno del Presidente Don Mamerto Urriolagoitia, determinó la creación
de la ESCUELA MILITAR DE INGENIERÍA, otorgándole el nombre de “Mariscal
Antonio José de Sucre”, en homenaje a quien fuera uno de los primeros
Ingenieros Militares.
14
Posteriormente en fecha 10 de noviembre de 1951 por determinación del
Congreso Nacional, el Decreto Nº 02226 fue elevado a rango de Ley de la Nación
Nº. 286, que consolida constitucionalmente la creación de la E.M.I. Concomitante
con las anteriores disposiciones legales, fue dictado el Decreto Supremo Nº 02397
del 13 de febrero de 1951, por el que se reconoce a los egresados de la Escuela
Militar de Ingeniería el título de Ingeniero en Provisión Nacional, “con todas las
ventajas, derechos y garantías” de acuerdo a disposiciones constitucionales, leyes
y decretos vinculados al tema.
El Decreto Supremo de 5 del mayo de 1953 aprobó el Reglamento Orgánico de la

Escuela, en el que se especificaba la misión, organización, atribuciones y
obligaciones de su personal en la estructuración de la enseñanza y el Plan de
Estudios.
1.3.3. Misión y Visión de la EMI
1.3.3.1. Misión
Formar y especializar profesionales de excelencia, con valores éticos, morales y

cívicos; caracterizados por su responsabilidad, liderazgo y disciplina; promoviendo
la interacción social, la investigación científica y tecnológica para contribuir al
desarrollo integral del país.
1.3.3.2. Visión
Ser la Universidad con mayor presencia a nivel Nacional, con prestigio

internacional y oferta académica en diversas áreas de conocimiento.
1.3.4. Referencias de un LMS
15
Un sistema de gestión de aprendizaje es un software instalado en un servidor web
que se emplea para administrar, distribuir y controlar las actividades de formación
no presencial (o aprendizaje electrónico) de una institución u organización.
Las principales funciones del sistema de gestión de aprendizaje son: gestionar

usuarios, recursos así como materiales y actividades de formación, administrar el
acceso, controlar y hacer seguimiento del proceso de aprendizaje, realizar
evaluaciones, generar informes, gestionar servicios de comunicación como foros
de discusión, videoconferencias, entre otros.
Un sistema de gestión de aprendizaje generalmente no incluye posibilidades de

autoría (crear sus propios contenidos), sino que se focaliza en gestionar
contenidos creados por fuentes diferentes. La labor de crear los contenidos para
los cursos se desarrolla mediante un Learning Content Management System
(LCMS).
La mayoría de los sistemas de gestión de aprendizaje funcionan con tecnología

web.
1.3.5. Descripción del caso de estudio
En la Escuela Militar de Ingeniería en lo que va de la educación cuenta con una

biblioteca virtual y educación virtual.
Figura 1.1 Portal de la EMI
16
Portal de
la EMI
Biblioteca Posgrado
Virtual Virtual
Fuente: Portal de la EMI
Elaboración: Propia
a. Biblioteca Virtual.- Este portal tiene por objetivo leer y observar libros y
trabajos de grado en formato PDF que se encuentren cargados en el portal, brinda
la facilidad de reservar los libros que se encuentren en la biblioteca de la EMI, las
cuales tienen un tiempo de validez de 24 horas. Las nuevas oportunidades que
brinda este portal al estudiante de la Escuela Militar de Ingeniería es la posibilidad
de compartir el material bibliográfico con la que cuenta la Universidad. Por otro
lado estaría abierta la posibilidad de realizar las mismas actividades con otros
casos de estudios superiores de nuestro medio.
b. Educación Virtual.- El portal cuenta con todo lo necesario para la educación

virtual, solo que se encuentre enfocado a los estudiantes de posgrados, brindando
así conocimiento necesarios sobre las asignaturas y ofertas académicas, las
cuales han dado sus frutos en varias versiones presenciales, y es por esta razón
que se implementa esta nueva experiencia, con el fin de proporcionar una
alternativa de calidad a las aspiraciones profesionales.
La misión de la carrera es la de formar profesionales de excelencia en ingeniería

de sistemas con valores éticos, morales y cívicos caracterizados por su
responsabilidad social, liderazgo, pensamiento reflexivo, critico innovador y
17
creativo, competitivo con el desarrollo sustentable del país dotados de
conocimientos teórico-prácticos fundamentados en:
 La teoría general de sistemas

 Las tecnologías de información y comunicación.
Proporcionar los medios, métodos, técnicas y tecnologías necesarios al proceso

de enseñanza y aprendizaje de manera que:
 Posibiliten la investigación científica tecnológica de proyectos y sistemas multi,

trans e interdisciplinarios.
 Proporcionen soluciones a las problemáticas de la tecnología de información y
comunicaciones.
La descripción del objeto en estudio, puede vislumbrarse el establecimiento de los

límites del objeto de investigación en términos de espacio, tiempo y universo.
c. Espacio: la carrera ingeniería de sistemas de la EMI que se encuentra en La

Paz Bolivia por la zona sur en Irpavi al lado del Mega Center.
d. Tiempo: el presente trabajo de grado se implementa en un periodo de un año

academico.
e. Universo: la investigación se desarrolla para los estudiantes de 2º año de la

carrera de ingeniería de sistemas de la EMI con el propósito de identificar los
hechos o fenómenos que limitan la actualización constante de la materia de
programación java.
1.3.6. Descripción de la Problemática
La Escuela Militar de Ingeniería cuenta con dos portales mencionados

anteriormente en la descripción del caso de estudio, los mismos se restringen a
repositorios de información referencial, lo cual no permite a los estudiantes tener
acceso a los contenidos, de igual forma estas herramientas no cuentan con sitios
18
de discusión y análisis de la información, esto dificulta identificar y establecer
nuevos temas de investigación requeridos por la población estudiantil.
1.4. PLANTEAMIENTO DEL PROBLEMA
1.4.1. Problema principal
La alta complejidad de acceso a la información por parte de los estudiante a las

actuales plataformas con las que cuenta la EMI, no proporcionan contenidos de
JAVA lo que limita al estudiante a no poder realizar una autoformación (consultas,
repasos, mecanismos para el seguimiento y autoevaluación) a distancia,
independientemente del lugar y hora (OFF LINE OFF TIME) para aprender a
programar en JAVA.
1.4.2 Problemas secundarios
 La jefatura de carrera y los docentes no pueden identificar en forma oportuna y

objetiva las carencias y el grado de conocimiento adquirido por el estudiante. Al
no contar con un medio (sistema) que les permita hacer un seguimiento de
aprovechamiento y evaluaciones permanentes.
 Los contenidos digitales que se cuentan actualmente no son administrados por
los docentes de la materia del lenguaje de programación JAVA lo cual
ocasiona que el estudiante no disponga del material adecuado según el avance
de la materia.
 Los estudiantes no tienen la posibilidad de autoevaluarse y detectar en forma
temprana sus carencias cognitivas.
 Los estudiantes no cuentan con herramientas que les permita promover la
educación compartida/colaborativa, que fomenten la discusión de los temas
tratados en el lenguaje de programación JAVA.
19
1.5. OBJETIVOS
1.5.1. Objetivo principal
Desarrollar un sistema gestor de contenidos digitales para formar a los estudiantes

de la EMI en el lenguaje de programación java.
1.5.2. Objetivos secundarios
 Brindar información que permita identificar en forma oportuna y objetiva las

carencias y el grado de aprovechamiento adquirido por el estudiante en el
lenguaje de programación JAVA.
 Administrar el contenido digital para que el instructor o facilitador brinde
material complementaria para la autoformación/autoevalución en JAVA.
 Permitir la autoformación/autoevaluación y la educación
compartida/colaborativa para que el estudiante pueda acceder a los contenidos
de cada curso independientemente del lugar o la hora de su preferencia.
 Administrar la organización de cursos, asignar permisos y obtener las
estadísticas necesarias y requeridas para facilitar la información a los usuarios
del sistema
1.6. HIPÓTESIS
El gestor de contenidos digitales, coadyuvará en la autoformación/autoevaluación

del lenguaje de programación en JAVA, incrementando el aprovechamiento
general de los estudiantes que lo utilicen, en comparación a quienes no lo hagan
en al menos un 20%.
1.6.1. Determinación de variables
A continuación, se muestran las diferentes variables que intervienen en la

Hipótesis correspondiente.
20
1.6.1.1. Variable Independiente
Desarrollo del Sistema Gestor de Contenidos Digitales para el acceso a la materia

de Programación JAVA.
1.6.1.2. Variable Dependiente
Incrementar el aprovechamiento de aprendizaje de los estudiantes en al menos un

20%.
1.6.1.3. Variable Interviniente
Carrera de Ingeniería de sistemas de la EMI.
1.6.2. Matriz de Consistencia
PROBLEMA OBJETIVO HIPÓTESIS

La alta complejidad de
acceso a la información por
Desarrollar un sistema
parte de los estudiantes a
las actuales plataformas gestor de contenidos El gestor de contenidos
con las que cuenta la EMI, digitales
digitales
no proporcionan contenidos
de JAVA
PROVOCA PARA COADYUVARA
Que el estudiante no pueda En la
realizar una autoformación autoformación/autoevalua
(consultas, repasos, ción del lenguaje de
mecanismos para el Formar a los programación en JAVA,
seguimiento y estudiantes de la EMI incrementando el
autoevaluación) a distancia, en el lenguaje de aprovechamiento general
independientemente del programación java. de los estudiantes que lo
lugar y hora (OFF LINE utilicen, en comparación
OFF TIME) para aprender a a quienes no lo hagan en
programar en JAVA. al menos un 20%.
1.7. JUSTIFICACIÓN
1.7.1. Justificación Técnica
21
El desarrollo de un Sistema de gestor de contenidos digitales podrá ser utilizado
desde el internet, en equipos como computadoras, laptops o tecnología móvil
(como ser tablets y celulares con características que soporten el sistema) lo que
coadyuvará a disminuir las dificultades que afronta un estudiante que llega a la
universidad con limitados conocimientos previos o dudas en el desarrollo de la
materia JAVA.
1.7.2. Justificación Tecnológica
Con el pasar del tiempo la ciencia y la tecnología nos brindan herramientas de

trabajo que nos facilitan las actividades cotidianas de cada día, pero que el ser
humano en su gran mayoría no le brindan un buen uso, solo uno inadecuado.
El uso de la materia de programación en JAVA es porque el mismo mercado así lo

requiere ya que la misma se encuentra entre los más usados en el ámbito laboral,
desde equipos eléctricos (como las lavadoras eléctricas), hasta equipos
servidores.
1.7.3. Justificación Operativa
El Plan de este proyecto es proporcionar a los estudiantes y a la sociedad en su

conjunto una fuente de información que apoye el aprendizaje individualizado
complementario.
1.8. ALCANCES Y LIMITES
1.8.1. Alcance Geográfico
El presente proyecto será aplicado en la Escuela Militar de Ingeniería “EMI”

ubicado en Irpavi de la ciudad de La Paz.
1.8.2. Alcance Temporal
El presente proyecto se llevará a cabo con un tiempo de realización de un año, es

decir que el proyecto concluirá al finalizar el año académico, por los datos
22
obtenidos, la programación del sistema y la compatibilidad en distintos
navegadores y dispositivos.
1.8.3. Limites
El presente proyecto de grado concluirá con el desarrollo de un gestor de

contenidos digitales donde se subirán documentos de cualquier formato (pdf, doc,
etc.), también se tomara una evaluación de los temas avanzados.
1.9. APORTES
Proporcionar una plataforma de aprendizaje web-móvil que apoye el aprendizaje

individualizado complementario apoyando a los estudiantes en el desarrollo de sus
clases y dudas sobre ciertos temas de avance.
23
CAPITULO II
MARCO
REFERENCIAL
24
Resumen
En este capítulo se menciona todo acerca de la EMI

como ser la misión, visión, historia, de las carreras y una
en especial la carrera de ingeniería de sistemas como la
misión y objetivos de la misma carrera; y palabras de la
Dirección.
2.1. ESCUELA MILITAR DE INGENIERÍA
2.1.1. Acerca de la EMI
2.1.1.1. Quienes somos
El año 1950, como resultado de un proceso de estudios organizacionales y

analíticos el Estado Mayor del Ejército de Bolivia determinó la creación de un
Instituto Técnico de nivel académico, con la responsabilidad de formar oficiales del
Ejército, ampliándose la oferta académica en el año 1980.
Por resolución de la VIII Conferencia de Universidades, la Universidad Boliviana

reconoció a la Escuela Militar de Ingeniería como Institución Autorizada y
Facultada para la formación de ingenieros y le otorgan la potestad de extender
Diplomas Académicos y Títulos en Provisión Nacional.
2.1.1.2. Misión
Formar y especializar profesionales de excelencia con valores éticos, morales y

cívicos; caracterizados por su responsabilidad social, liderazgo y disciplina,
promoviendo la interacción social, la investigación científica y tecnológica, a fin de
participar activamente en el desarrollo integral y sostenible del país.
2.1.1.3. Visión
Ser la Universidad de mayor presencia en el país, con prestigio internacional y

oferta académica en diversas áreas del conocimiento.
25
2.1.1.4. Objetivo Institucional
Fortalecer el prestigio de la Escuela Militar de Ingeniería en la formación y

especialización profesional a nivel nacional e internacional.
2.1.1.5. Historia
Mediante el D.S. 2226 en el año 1950 y posterior Ley 286 del 10 de Noviembre de
1951, como resultado de un proceso de estudios organizacionales realizados por
el Ejército de Bolivia, como consecuencia de necesidades estratégicas
identificadas durante la Guerra del Chaco y en base a modelos de institutos de
Ingeniería Militar de Brasil, EE.UU. y México, el Estado Mayor del Ejército
determinó la creación de la Escuela Militar de Ingeniería con la responsabilidad de
formar oficiales del Ejército en las especialidades de Ingeniero Constructor y
Geodesta; otorgándole el nombre de “Mariscal Antonio José de Sucre”, en
homenaje a quien fuera uno de los primeros ingenieros militares.
La Escuela Militar de Ingeniería “Mcal. Antonio José de Sucre”, en base a las

necesidades insatisfechas identificadas para emprender el Desarrollo Nacional, va
ampliando su oferta académica creando nuevas carreras como: Ingeniería en
Sistemas Electrónicos, Ingeniería Industrial, Ingeniería Agronómica, Ingeniería de
Sistemas, Ingeniería Comercial, Ingeniería Ambiental, Ingeniería Agroindustrial e
Ingeniería Petrolera.
A partir de 1980 se autoriza la ampliación de la oferta académica a estudiantes

civiles bachilleres para su profesionalización en las diferentes especialidades de
Ingeniería.
En la década de los 90 se crean los tecnológicos de Informática y de Sistemas

Electrónicos, con la finalidad de formar técnicos Medios y Superiores, cuyo
alcance es para el personal de estudiantes civiles, suboficiales y sargentos.
26
2.1.2. Palabras del Rector
2.1.2.1. No tratamos de educar, simplemente inspiramos
Como Rector de la Escuela Militar de Ingeniería, los invito a conocer los recursos
educativos que están a disposición de nuestra comunidad universitaria y a
integrarse a nuestra familia universitaria con una experiencia de más de 60 años
formando profesionales del más alto nivel académico, donde recibirán una
educación humanística, científica y tecnológica, de calidad internacional.
Se asegura, que aquí se lograran sus más caros anhelos personales y de trabajo,
manteniendo en mente que los éxitos y los triunfos se logran con esfuerzo,
dedicación y sacrificio. Nuestra excelencia educativa se ha logrado gracias a la
calidad e innovación de nuestros programas académicos, al compromiso de
nuestros directivos, personal administrativo y a la preparación y dedicación de
nuestros docentes.
La característica fundamental es el trabajo en el área académica, en ciencia y

tecnología, lo que evidencia nuestra constante actualización y producción
científica. En el área administrativa continuamos implementando una mejor
infraestructura y equipamiento que está a disposición de nuestros estudiantes.
En la búsqueda por ampliar el proceso educativo, se establecido relaciones

interinstitucionales nacionales e internacionales que permiten ir a la vanguardia
en los avances científicos y tecnológicos más relevantes en el mundo actual.
Estas características proveen a la Universidad no solo imagen, sino también
acreditación y credibilidad ante la comunidad boliviana, garantizando a los
estudiantes una formación académica acorde con el cambio y las exigencias de
nuestro país. Es por eso el en formar mejores profesionales y personas para que
aporten en forma afectiva al desarrollo de nuestro país y transitar por la senda del
éxito.
27
En este contexto nos basamos en la calidad de los docentes y en el desarrollo de
un modelo de enseñanza-aprendizaje que asegure que los valores permanentes
de la persona humana se conjuguen con las habilidades y destrezas de un
profesional preparado para actuar positivamente en las necesarias
transformaciones sociales, ambientales, económicas y culturales.
En más de 60 años de vida, nuestra sociedad boliviana ha visto egresar de

nuestras aulas a ingenieros y técnicos, pero sobre todo a hombres y mujeres
educados integralmente en lo profesional y lo personal, ubicando al ser humano
como valor primordial. Es por eso que nuestros alumnos y graduados son la
principal fuente de orgullo, pues ellos y ellas son quienes con sus logros
mantienen en alto el prestigio de esta Institución.[Marquina A, 2010]
2.1.3. Convenios interinstitucionales (Nacional e Internacional)
La Escuela Militar de Ingeniería tiene diferentes convenios académicos, de

práctica empresarial, de implementación de proyectos entre otros, con entidades
reconocidas Nacional e Internacionalmente. Estas entidades son:
 Insa Lyón 17(Francia)
 Universidad de Sevilla 18(España)
 Instituto de Enseñanza Superior del Ejército Argentino 19(Argentina)
 Pontificia Universidad Católica de Rio de Janeiro20 (Brasil)
 Institut Teknologi Bandung21 (Indonecia)
 Universidad del Estado de Ohio 22(USA)
17
http://www.insa-lyon.fr/
18
http://www.us.es/
19
http://www.iese.edu.ar/
20
http://www.puc-rio.br/index.html
21
http://www.itb.ac.id/
22
http://www.osu.edu/
28
 Aduana Nacional de Bolivia
 Administradora Boliviana de Carreteras (ABC)
 Yacimiento Petrolíferos Fiscales Bolivianos (YPFB)
 Gobiernos Municipales
 Agencia Nacional de Hidrocarburos (ANH)
Entre otros convenios beneficiando a la Comunidad Universitaria.
2.1.4. Bienestar universitario
Entre los servicios de bienestar estudiantil, la Escuela Militar de Ingeniería cuenta

con:
a. Gabinete Psicológico. Servicio asistencial que pretende responder a las

demandas de carácter psicológico y social que se plantean en la comunidad
universitaria.
b. Seguro Universitario. Muchos estudiantes universitarios se arriesgan a no
tener cobertura de salud porque se ven jóvenes, con buena salud, y
relativamente libres de enfermedades. Pero, a cualquier edad es importante
tener acceso a la atención de salud cuando se necesita. La Escuela Militar de
Ingeniería, ofrece un Seguro Médico Universitario.
c. Biblioteca. La biblioteca universitaria constituye un servicio clave de apoyo a
la educación y la investigación.
d. Deportes. Esta práctica no sólo es competitiva, sino que frecuentemente se
dirige hacia la realización de actividades de recreación deportiva para emplear
el tiempo de ocio de forma saludable.
e. Transporte. Son líneas de autobús especialmente dedicadas al transporte de
estudiantes a la Escuela Militar de Ingeniería.
f. Peluquería. Al ser una Escuela Militar, donde rige la disciplina, los estudiantes
cuentan con un servicio de Peluquería.
29
g. Gimnasio. Se podrás realizar actividades de acondicionamiento físico, bajo el
lema ¨Mente sana en cuerpo sano¨.
h. Coro Polifónico de la EMI. Ser parte del coro polifónico, significa que está
estructurado por grupos de personas que cantan a dos, tres, cuatro o más
voces con arreglos que se basan en reglas y normas de Armonía. Todo esto en
manos del Maestro José Lanza Salazar.
2.1.5. Unidad Académica La Paz
A partir de la apertura del ingreso a estudiantes civiles en 1981, la Escuela Militar

de Ingeniería (EMI) ha ampliado significativamente su accionar, diversificando su
oferta académica, como consecuencia, recibiendo en sus aulas a una población
estudiantil cada vez más numerosa.
Inicialmente con sede única en la ciudad de La Paz, sus actividades residían en el

edificio histórico situado en la Av. Arce.
A partir del año 2000, debido a una creciente demanda social, se crean las
Unidades Académicas de Santa Cruz, Cochabamba, Riberalta,
consecuentemente, se consolida el funcionamiento de la UNIDAD ACADÉMICA
LA PAZ con la inauguración del Campus Universitario ubicado en Alto Irpavi (Urb.
La Pradera), dotado de espacios y ambientes modernos para el desarrollo de las
actividades inherentes al proceso de enseñanza-aprendizaje.
Como institución pública, preocupada por la permanente reinversión de recursos

en la mejora de la educación superior, en el año 2012 se ha inaugurado un nuevo
edificio ubicado en Irpavi (lado Megacenter).
Asimismo, en el orden estrictamente académico todas las Carreras se someten

continuamente a procesos de autoevaluación y evaluación interna. Como
30
resultado, nuestros programas han logrado la certificación de calidad
(acreditación) con participación de pares académicos nacionales e internacionales.
Finalmente en la búsqueda de resolver necesidades institucionales y sociales, se

ha ampliado la oferta académica a nuevas especialidades.
Las Carreras que se ofrecen en la Unidad Académica La Paz son:
 Ingeniería Civil.
 Ingeniería Geográfica.
 Ingeniería Industrial.
 Ingeniería en Sistemas Electrónicos.
 Ingeniería Comercial.
 Ingeniería en Sistemas.
 Ingeniería Ambiental.
 Ingeniería Petrolera.
 Ingeniería Financiera.
 Ingeniería Económica.
 Ingeniería Mecatrónica.
 Ingeniería en Telecomunicaciones.
 Ingeniería de Materiales.
 Ingeniería Química.
 Ingeniería Mecánica.
31
2.1.5.1. Campus Universitario
Irpavi / La Paz
Telf: 2775536 - 2799502
Fax: 2773774
lapaz@adm.emi.edu.bo
2.1.5.2. Director de la Unidad Académica de La Paz
Cnl. DAEN. Álvaro A. Ríos Oliver
2.1.6. Ingeniería en Sistemas
2.1.6.1. Perfil Profesional
El Ingeniero de Sistemas graduado de la EMI realiza el diseño, desarrollo,

implementación, evaluación, mantenimiento, soporte y retiro de sistemas con
enfoque sistémico y visión emprendedora; aplicando nuevas tecnologías de
información y comunicación; realizando el modelado y automatización de
sistemas; desarrollando sistemas de gestión empresarial y de producción
orientados a la toma de decisiones que optimicen los procesos, con creatividad,
liderazgo y pensamiento crítico en un entorno complejo, conflictivo y
multidisciplinario.
2.1.6.2. Misión de Ingeniería de Sistemas
Formar profesionales de excelencia en Ingeniería de Sistemas con valores éticos,

morales y cívicos; caracterizados por su responsabilidad social, liderazgo,
pensamiento reflexivo-critico, innovador y creativo, comprometidos con el
desarrollo sustentable del país. Dotados de conocimientos teórico - prácticos
fundamentados en: La Teoría General de Sistemas y Las Tecnologías de
Información y Comunicaciones.
32
2.1.6.3. Objetivo de Ingeniería de Sistemas
Comprometer todos los esfuerzos de la gestión académica y administrativa a fin

de establecer el escenario idóneo para la formación de profesionales en ingeniería
de sistemas de la más alta calidad.
2.1.6.4. Competencias por áreas
 Formula soluciones tecnológicas realizando la planeación, análisis, diseño,

desarrollo, implementación, evaluación, mantenimiento, soporte y retiro de
sistemas de información y conocimiento.
 Implementa sistemas de redes de computadoras y comunicaciones, realizando
su planeación, diseño y evaluación.
 Aplica el modelado, la simulación y la optimización de procesos, realizando la
automatización, fabricación, gestión y explotación de sistemas.
 Desarrolla sistemas de gestión, aplicando la Teoría General de Sistemas, los
fundamentos, métodos, técnicas de las ciencias empresariales y de Ingeniería
necesarias en la optimización de procesos en las organizaciones.
33
CAPITULO III
MARCO TEÓRICO
34
Resumen
En este capítulo se presentan las bases teóricas para el

desarrollo del marco práctico construido por el método de
desarrollo de software, particularmente en educación a
distancia, sistemas de gestión de contenidos digitales y
temas relacionados con el E-Learning.
3.1 TEORÍA DE SISTEMAS
La Teoría de Sistemas es el estudio interdisciplinario de los sistemas, en general,

con el propósito de dilucidar los principios que pueden ser aplicados a todo tipo de
sistemas en todos los niveles anidados en todos los campos de la investigación.
Entre W. Ross Ashby 23y Norbert Wiener 24desarrollaron la teoría matemática de la

comunicación y control de sistemas a través de la regulación de la
retroalimentación (cibernética), que se encuentra estrechamente relacionada con
la Teoría de control. En 1950 Ludwig von Bertalanffy 25plantea la Teoría general de
sistemas. En 1970 René Thom 26y E.C. Zeeman 27plantean la Teoría de las
catástrofes, rama de las matemáticas de acuerdo con bifurcaciones en sistemas
dinámicos, que clasifica los fenómenos caracterizados por súbitos
desplazamientos en su conducta.
En 1980 David Ruelle, Edward Lorenz, Mitchell Feigenbaum, Steve Smale y

James A. Yorke describen la Teoría del Caos, una teoría matemática de sistemas
dinámicos no lineales que describe bifurcaciones, extrañas atracciones y
movimientos caóticos. John H. Holland, Murray Gell-Mann, Harold Morowitz, W.
Brian Arthur, y otros en 1990 plantean el Sistema adaptativo complejo (CAS), una
nueva ciencia de la complejidad que describe surgimiento, adaptación y auto-
23
(Londres, 1903 - 1972) fue un médico y neurólogo inglés, que contribuyó decisivamente a la consolidación de
la cibernética moderna y creó el primer homeostato.
24
Fue un matemático estadounidense, conocido como el fundador de la cibernética.
25
Fue un biólogo y filósofo austríaco, reconocido fundamentalmente por su teoría de sistemas.
26
Matemático francés fundador de la teoría de las catástrofes.
27
Es un matemático británico de origen japonés conocido por su trabajo en la topología geométrica y teoría de la
singularidad
35
organización. Fue establecida fundamentalmente por investigadores del Instituto
de Santa Fe y está basada en simulaciones informáticas. Incluye sistemas de
multiagente que han llegado a ser una herramienta importante en el estudio de los
sistemas sociales y complejos. Es todavía un activo campo de investigación.
3.1.1. Desarrollos
Aunque la TGS surgió en el campo de la Biología, pronto se vio su capacidad de

inspirar desarrollos en distintas disciplinas y se apreció su influencia en la
aparición de otras nuevas. Así se ha ido constituyendo el amplio campo de la
sistémica o de las ciencias de los sistemas, con especialidades como la
cibernética, la teoría de la información, la teoría de juegos, la teoría del caos o la
teoría de las catástrofes. En algunas, como la última, ha seguido ocupando un
lugar prominente la Biología.
Más reciente es la influencia de la TGS28 en las Ciencias Sociales. Destaca la

intensa influencia del sociólogo alemán Niklas Luhmann29, que ha conseguido
introducir sólidamente el pensamiento sistémico en esta área.
3.1.2. Ámbito metamórfico de la teoría
3.1.2.1. Descripción del propósito
La teoría general de sistemas en su propósito más amplio, contempla la

elaboración de herramientas que capaciten a otras ramas de la ciencia en su
investigación práctica. Por sí sola, no demuestra ni deja de mostrar efectos
prácticos. Para que una teoría de cualquier rama científica esté sólidamente
fundamentada, ha de partir de una sólida coherencia sostenida por la TGS. Si se
cuenta con resultados de laboratorio y se pretende describir su dinámica entre
distintos experimentos, la TGS es el contexto adecuado que permitirá dar soporte
a una nueva explicación, que permitirá poner a prueba y verificar su exactitud. Por
esto se la ubica en el ámbito de las metateorías.
28
Teoría General De Sistemas
29
Sociólogo alemán.
36
La TGS busca descubrir isomorfismos en distintos niveles de la realidad que
permitan:
 Usar los mismos términos y conceptos para describir rasgos esenciales de

sistemas reales muy diferentes; y encontrar leyes generales aplicables a la
comprensión de su dinámica.
 Favorecer, primero, la formalización de las descripciones de la realidad; luego,

a partir de ella, permitir la modelización de las interpretaciones que se hacen
de ella.
 Facilitar el desarrollo teórico en campos en los que es difícil la abstracción del

objeto; o por su complejidad, o por su historicidad, es decir, por su carácter
único. Los sistemas históricos están dotados de memoria, y no se les puede
comprender sin conocer y tener en cuenta su particular trayectoria en el
tiempo.
 Superar la oposición entre las dos aproximaciones al conocimiento de la

realidad:
o La analítica, basada en operaciones de reducción.
o La sistémica, basada en la composición.
La aproximación analítica está en el origen de la explosión de la ciencia desde el

Renacimiento, pero no resultaba apropiada, en su forma tradicional, para el
estudio de sistemas complejos.
3.1.2.2. Descripción del uso
El contexto en el que la TGS se puso en marcha, es el de una ciencia dominada

por las operaciones de reducción de las características del método analítico.
Básicamente, para poder manejar una herramienta tan global, primero se ha de
partir de una idea de lo que se pretende demostrar, definir o poner a prueba.
Teniendo claro el resultado (partiendo de la observación en cualquiera de sus
37
vertientes), entonces se le aplica un concepto que, lo mejor que se puede asimilar
resultando familiar y fácil de entender, es a los métodos matemáticos conocidos
como mínimo común múltiplo y máximo común divisor. A semejanza de estos
métodos, la TGS trata de ir desengranando los factores que intervienen en el
resultado final, a cada factor le otorga un valor conceptual que fundamenta la
coherencia de lo observado, enumera todos los valores y trata de analizar todos
por separado y, en el proceso de la elaboración de un postulado, trata de ver
cuántos conceptos son comunes y no comunes con un mayor índice de repetición,
así como los que son comunes con un menor índice de repetición. Con los
resultados en mano y un gran esfuerzo de abstracción, se les asignan a conjuntos
(teoría de conjuntos), formando objetos. Con la lista de objetos completa y las
propiedades de dichos objetos declaradas, se conjeturan las interacciones que
existen entre ellos, mediante la generación de un modelo informático que pone a
prueba si dichos objetos, virtualizados, muestran un resultado con unos márgenes
de error aceptables. En un último paso, se realizan las pruebas de laboratorio. Es
entonces cuando las conjeturas, postulados, especulaciones, intuiciones y demás
sospechas, se ponen a prueba y nace la teoría.
Como toda herramienta matemática en la que se opera con factores, los factores
enumerados que intervienen en estos procesos de investigación y desarrollo no
altera el producto final, aunque sí pueden alterar los tiempos para obtener los
resultados y la calidad de los mismos; así se ofrece una mayor o menor
resistencia económica a la hora de obtener soluciones.
3.1.3. Aplicación
La principal aplicación de esta teoría está orientada a la empresa científica cuyo

paradigma exclusivo venía siendo la Física. Los sistemas complejos, como los
organismos o las sociedades, permiten este tipo de aproximación sólo con muchas
limitaciones. En la aplicación de estudios de modelos sociales, la solución a
menudo era negar la pertinencia científica de la investigación de problemas
relativos a esos niveles de la realidad, como cuando una sociedad científica
prohibió debatir en sus sesiones el contexto del problema de lo que es y no es la
38
conciencia. Esta situación resultaba particularmente insatisfactoria en Biología,
una ciencia natural que parecía quedar relegada a la función de describir, obligada
a renunciar a cualquier intento de interpretar y predecir, como aplicar la teoría
general de los sistemas a los sistemas propios de su disciplina.
3.2. SISTEMA
Un sistema (del latín systēma, proveniente del griego σύστημα) es un objeto
complejo cuyos componentes se relacionan con al menos algún otro componente;
puede ser material o conceptual. Todos los sistemas tienen composición,
estructura y entorno, pero sólo los sistemas materiales tienen mecanismo, y sólo
algunos sistemas materiales tienen figura (forma). Según el sistemismo, todos los
objetos son sistemas o componentes de otro sistema. Por ejemplo, un núcleo
atómico es un sistema material físico compuesto de protones y neutrones
relacionados por la interacción nuclear fuerte; una molécula es un sistema material
químico compuesto de átomos relacionados por enlaces químicos; una célula es
un sistema material biológico compuesto de orgánulos relacionados por enlaces
químicos no-covalentes y rutas metabólicas; una corteza cerebral es un sistema
material biológico compuesto de neuronas relacionadas por potenciales de acción
y neurotransmisores; un ejército es un sistema material social y parcialmente
artificial compuesto de personas y artefactos relacionados por el mando, el
abastecimiento, la comunicación y la guerra; el anillo de los números enteros es
un sistema conceptual algebraico compuesto de números positivos, negativos y el
cero relacionados por la suma y la multiplicación; y una teoría científica es un
sistema conceptual lógico compuesto de hipótesis, definiciones y teoremas
relacionados por la correferencia y la deducción (implicación).
3.3. INGENIERÍA DE SISTEMAS
La ingeniería de sistemas es un modo de enfoque e interdisciplinario que permite

estudiar y comprender la realidad, con el propósito de implementar u optimizar
sistemas complejos. Puede también verse como la aplicación tecnológica de la
teoría de sistemas a los esfuerzos de la ingeniería, adoptando en todo este trabajo
39
el paradigma sistémico. La ingeniería de sistemas integra otras disciplinas y
grupos de especialidad en un esfuerzo de equipo, formando un proceso de
desarrollo centrado.
La ingeniería de sistemas es, la aplicación de las ciencias matemáticas y físicas

para desarrollar sistemas que utilicen económicamente los materiales y fuerzas de
la naturaleza para el beneficio de la humanidad.
Una de las principales diferencias de la ingeniería de sistemas respecto a otras

disciplinas de ingeniería tradicionales, consiste en que la ingeniería de sistemas
no construye productos tangibles. Mientras que los ingenieros civiles podrían
diseñar edificios o puentes, los ingenieros electrónicos podrían diseñar circuitos,
los ingenieros de sistemas tratan con sistemas abstractos con ayuda de las
metodologías de la ciencia de sistemas, y confían además en otras disciplinas
para diseñar y entregar los productos tangibles que son la realización de esos
sistemas.
Otro ámbito que caracteriza a la ingeniería de sistemas es la interrelación con

otras disciplinas en un trabajo transdisciplinario.
De manera equivocada algunas personas confunden la ingeniería de sistemas con

las ingenierías de computación o en informática, cuando ésta es mucho más
cercana a la electrónica y la mecánica cuando se aplica.
Actualmente existe gran controversia respecto a los estudios que se realizan en

las universidades, sobre todo en Sudamérica, pues los estudios son similares a los
de Ingeniería de Computación o Informática.
3.3.1. Otras definiciones
Una definición especialmente completa -y que data de 1974 - nos la ofrece un

estándar militar de las fuerzas aéreas estadounidenses sobre gestión de la
ingeniería (MIL-STD-499B Systems Engineering).
40
Ingeniería de sistemas es la aplicación de esfuerzos científicos y de ingeniería
para:
 integrar parámetros técnicos relacionados para asegurar la compatibilidad de

todas las interfaces de programa y funcionales de manera que optimice la
definición y diseño del sistema total;
 integrar factores de fiabilidad, mantenibilidad, seguridad, supervivencia,

humanos y otros en el esfuerzo de ingeniería total a fin de cumplir los objetivos
de coste, planificación y rendimiento técnico.
Ingeniería de Sistemas es un conjunto de metodologías para la resolución de

problemas mediante el análisis, diseño y gestión de sistemas.
Es el conjunto de recursos humanos y materiales a través de los cuales se

recolectan, almacenan, recuperan, procesan y comunican datos e información con
el objetivo de lograr una gestión eficiente de las operaciones de una organización.
3.3.2. Campos relacionados
Muchos de los campos relacionados podrían ser considerados con estrechas

vinculaciones a la ingeniería de sistemas. Muchas de estas áreas han contribuido
al desarrollo de la ingeniería de sistemas como área independiente.
3.3.2.1. Sistemas de Información
Un sistema de información o (SI) es un conjunto de elementos que interactúan

entre sí con el fin de apoyar las actividades de una empresa o negocio. No
siempre un Sistema de Información debe estar automatizado (en cuyo caso se
trataría de un sistema informático), y es válido hablar de Sistemas de Información
Manuales. Normalmente se desarrollan siguiendo Metodologías de Desarrollo de
Sistemas de Información.
41
El equipo computacional: el hardware necesario para que el sistema de
información pueda operar. El recurso humano que interactúa con el Sistema de
Información, el cual está formado por las personas que utilizan el sistema.
Un sistema de información realiza cuatro actividades básicas: entrada,

almacenamiento, procesamiento y salida de información.
Es la actualización de datos reales y específicos para la agilización de

operaciones en una empresa.
3.3.2.2. Investigación de operaciones
La investigación de operaciones o (IO) se enseña a veces en los departamentos

de ingeniería industrial o de matemática aplicada, pero las herramientas de la IO
son enseñadas en un curso de estudio en Ingeniería de Sistemas. La IO trata de la
optimización de un proceso arbitrario bajo múltiples restricciones. Se presentan las
ideas fundamentales en las que se basa el enfoque de sistemas, los tipos de
problemas de sistemas y las metodologías más adecuadas para abordarlos.
3.3.2.3. Ingeniería de sistemas cognitivos
La ingeniería de sistemas cognitivos es una rama de la ingeniería de sistemas que

trata los entes cognitivos, sean humanos o no, como un tipo de sistemas capaces
de tratar información y de utilizar recursos cognitivos como la percepción, la
memoria o el procesamiento de información. Depende de la aplicación directa de
la experiencia y la investigación tanto en psicología cognitiva como en ingeniería
de sistemas. La ingeniería de sistemas cognitivos se enfoca en cómo los entes
cognitivos interactúan con el entorno. La ingeniería de sistemas trabaja en la
intersección de:
1. El desarrollo de la sociedad en esta nueva era.
2. Los problemas impuestos por el mundo.
3. Las necesidades de los agentes (humano, hardware, software).
42
4. La interacción entre los varios sistemas y tecnologías que afectan (y/o son
afectados por) la situación.
Algunas veces designados como ingeniería humana o ingeniería de factores

humanos, esta rama además estudia la ergonomía en diseño de sistemas. Sin
embargo, la ingeniería humana suele tratarse como otra especialidad de la
ingeniería que el ingeniero de sistemas debe integrar.
Habitualmente, los avances en ingeniería de sistemas cognitivos se desarrollan en

los departamentos y áreas de informática, donde se estudian profundamente e
integran la inteligencia artificial, la ingeniería del conocimiento y el desarrollo de
interfaces hombre-máquina (diseños de usabilidad) de la ciencia.
El Ingeniero de sistemas habitualmente aprende a programar, para dirigir a

programadores y al momento de la creación de un programa debe saber y tener
en cuenta los métodos básicos como tal, por eso es importante que aprenda a
programar pero su función realmente es el diseño y planeación, de todo lo
referente al sistema o redes, su mantenimiento, efectividad, respuesta y
tecnología.
3.4. INGENIERÍA DE SOFTWARE
Ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y

cuantificable al desarrollo, operación y mantenimiento de software; el estudio de
estos enfoques y la aplicación de la ingeniería al software. Es la aplicación de la
ingeniería al software, ya que integra matemáticas, ciencias de la computación y
prácticas cuyos orígenes se encuentran en la ingeniería.30
Se pueden citar otras definiciones enunciadas por prestigiosos autores:
30
ACM (2006). Computing Degrees & Careers. ACM. Consultado el 23 de noviembre de 2010.
43
 Ingeniería de software es el estudio de los principios, metodologías para el
desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)
 Ingeniería de software es la aplicación práctica del conocimiento científico al

diseño; construcción de programas de computadora y a la documentación
asociada requerida para desarrollar, operar y mantenerlos. Se conoce también
como desarrollo de software o producción de software (Bohem, 1976).
 Ingeniería de software trata del establecimiento de los principios y métodos de

la ingeniería a fin de obtener software de modo rentable, que sea fiable y
trabaje en máquinas reales (Bauer, 1972).
En el 2004, en los Estados Unidos, la Oficina de Estadísticas del Trabajo (U. S.

Bureau of Labor Statistics) contó 760.840 ingenieros de software de computadora.
El término "ingeniero de software", sin embargo, se utiliza en forma genérica en el
ambiente empresarial, y no todos los ingenieros de software poseen realmente
títulos de ingeniería de universidades reconocidas.
Algunos autores consideran que "desarrollo de software" es un término más

apropiado que "ingeniería de software" para el proceso de crear software.
Personas como Pete McBreen (autor de "Software Craftmanship") cree que el
término IS implica niveles de rigor y prueba de procesos que no son apropiados
para todo tipo de desarrollo de software.
Indistintamente se utilizan los términos "ingeniería de software" o "ingeniería del

software". En Hispanoamérica el término usado normalmente es el primero de
ellos.
La creación del software es un proceso intrínsecamente creativo y la ingeniería del

software trata de sistematizar este proceso con el fin de acotar el riesgo del
44
fracaso en la consecución del objetivo creativo por medio de diversas técnicas que
se han demostrado adecuadas en base a la experiencia previa.
La IS se puede considerar como la ingeniería aplicada al software, esto es, por

medios sistematizados y con herramientas preestablecidas, la aplicación de ellos
de la forma más eficiente para la obtención de resultados óptimos; objetivos que
siempre busca la ingeniería. No es sólo de la resolución de problemas, sino más
bien teniendo en cuenta las diferentes soluciones, elegir la más apropiada.
3.4.1. Implicaciones socioeconómicas
La ingeniería de software afecta a la economía y las sociedades de variadas

formas.
 Económicamente
En los Estados Unidos, el software contribuyó a una octava parte de todo el

incremento del PIB durante la década de 1990 (alrededor de 90,000 millones de
dólares por año), y un noveno de todo el crecimiento de productividad durante los
últimos años de la década (alrededor de 33.000 millones de dólares
estadounidenses por año). La ingeniería de software contribuyó a US$ 1 billón de
crecimiento económico y productividad en esa década. Alrededor del globo, el
software contribuye al crecimiento económico en formas similares, aunque es
difícil de encontrar estadísticas fiables.
Además, con la industria del lenguaje está hallando cada vez más campos de
aplicación a escala global.
45
 Socialmente
La ingeniería de software cambia la cultura del mundo debido al extendido uso de

la computadora. El correo electrónico (E-mail), la WWW y la mensajería
instantánea permiten a la gente interactuar en nuevas formas. El software baja el
costo y mejora la calidad de los servicios de salud, los departamentos de
bomberos, las dependencias gubernamentales y otros servicios sociales. Los
proyectos exitosos donde se han usado métodos de ingeniería de software
incluyen a GNU/Linux, el software del transbordador espacial, los cajeros
automáticos y muchos otros.
3.4.2. Metodología
Un objetivo de décadas ha sido el encontrar procesos y metodologías, que sean

sistemáticas, predecibles y repetibles, a fin de mejorar la productividad en el
desarrollo y la calidad del producto software.
3.4.2.1. Etapas del proceso
La ingeniería de software requiere llevar a cabo numerosas tareas agrupadas en

etapas, al conjunto de estas etapas se le denomina ciclo de vida. Las etapas
comunes a casi todos los modelos de ciclo de vida son las siguientes:
a. Análisis de requisitos
Extraer los requisitos de un producto de software es la primera etapa para crearlo.

Mientras que los clientes piensan que ellos saben lo que el software tiene que
hacer, se requiere habilidad y experiencia para reconocer requisitos incompletos,
ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se
plasma en el documento ERS, Especificación de Requisitos del Sistema, cuya
estructura puede venir definida por varios estándares, tales como CMMI.
46
Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las
principales entidades que participarán en el desarrollo del software.
La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es

una parte crucial; de esta etapa depende en gran medida el logro de los objetivos
finales. Se han ideado modelos y diversos procesos de trabajo para estos fines.
Aunque aún no está formalizada, ya se habla de la Ingeniería de requisitos.
No siempre en la etapa de "análisis de requisitos" las distintas metodologías de

desarrollo llevan asociado un estudio de viabilidad y/o estimación de costes. El
más conocido de los modelos de estimación de coste del software es el modelo
COCOMO
b. Especificación
La especificación de requisitos describe el comportamiento esperado en el

software una vez desarrollado. Gran parte del éxito de un proyecto de software
radicará en la identificación de las necesidades del negocio (definidas por la alta
dirección), así como la interacción con los usuarios funcionales para la
recolección, clasificación, identificación, priorización y especificación de los
requisitos del software.
Entre las técnicas utilizadas para la especificación de requisitos se encuentran:
 Caso de uso.
 Historias de usuario.
Siendo los primeros más rigurosos y formales, las segundas más ágiles e
informales.
47
c. Arquitectura
La integración de infraestructura, desarrollo de aplicaciones, bases de datos y

herramientas gerenciales, requieren de capacidad y liderazgo para poder ser
conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El
rol en el cual se delegan todas estas actividades es el del Arquitecto.
El arquitecto de software es la persona que añade valor a los procesos de

negocios gracias a su valioso aporte de soluciones tecnológicas.
La arquitectura de sistemas en general, es una actividad de planeación, ya sea a

nivel de infraestructura de red y hardware, o de software.
La arquitectura de software consiste en el diseño de componentes de una

aplicación (entidades del negocio), generalmente utilizando patrones de
arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre
las entidades del negocio y además poder ser validado, por ejemplo por medio de
diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se
construirá una aplicación de software. Para ello se documenta utilizando
diagramas, por ejemplo:
 Diagramas de clases.
 Diagramas de base de datos.
 Diagrama de despliegue.
 Diagrama de secuencia.
Siendo los dos primeros los mínimos necesarios para describir la arquitectura de
un proyecto que iniciará a ser codificado. Depende del alcance del proyecto,
complejidad y necesidades, el arquitecto elige qué diagramas elaborar.
48
Las herramientas para el diseño y modelado de software se denominan CASE,
(Computer Aided Software Engineering) entre las cuales se encuentran:
 Enterprise Architect.
 Microsoft Visio for Enterprise Architects.
d. Programación
Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería
de software, pero no necesariamente es la que demanda mayor trabajo y ni la más
complicada. La complejidad y la duración de esta etapa está íntimamente
relacionada al o a los lenguajes de programación utilizados, así como al diseño
previamente realizado.
e. Prueba
Consiste en comprobar que el software realice correctamente las tareas indicadas

en la especificación del problema. Una técnica de prueba es probar por separado
cada módulo del software, y luego probarlo de forma integral, para así llegar al
objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por
alguien distinto al desarrollador que la programó, idealmente un área de pruebas;
sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En
general hay dos grandes formas de organizar un área de pruebas, la primera es
que esté compuesta por personal inexperto y que desconozca el tema de pruebas,
de esta forma se evalúa que la documentación entregada sea de calidad, que los
procesos descritos son tan claros que cualquiera puede entenderlos y el software
hace las cosas tal y como están descritas. El segundo enfoque es tener un área
de pruebas conformada por programadores con experiencia, personas que saben
sin mayores indicaciones en qué condiciones puede fallar una aplicación y que
pueden poner atención en detalles que personal inexperto no consideraría.
49
f. Documentación
Todo lo concerniente a la documentación del propio desarrollo del software y de la

gestión del proyecto, pasando por modelaciones (UML),diagramas de casos de
uso, pruebas, manuales de usuario, manuales técnicos, etc. todo con el propósito
de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al
sistema.
g. Mantenimiento
Fase dedicada a mantener y mejorar el software para corregir errores descubiertos

e incorporar nuevos requisitos. Esto puede llevar más tiempo incluso que el
desarrollo del software inicial. Alrededor de 2/3 del tiempo de ciclo de vida de un
proyecto31 está dedicado a su mantenimiento. Una pequeña parte de este trabajo
consiste en eliminar errores (bugs); siendo que la mayor parte reside en extender
el sistema para incorporarle nuevas funcionalidades y hacer frente a su evolución.
3.4.3. Modelos y filosofías de desarrollo de software
La ingeniería de software dispone de varios modelos, paradigmas y filosofías de

desarrollo, en los cuales se apoya para la construcción del software, entre ellos se
puede citar:
 Modelo en cascada o Clásico (modelo tradicional).
 Modelo de prototipos.
 Modelo en espiral.
 Desarrollo por etapas.
 Desarrollo iterativo y creciente o Iterativo e Incremental.
31
Pressman, Roger S. (2003). “El proceso”. Ingeniería del Software, un enfoque Práctico, Quinta
edición edición
50
 RAD (Rapid Application Development).
 Desarrollo concurrente.
 Proceso Unificado.
 RUP (Proceso Unificado de Rational).
 XP (programación Extrema).
3.4.3.1. Naturaleza de la IS
La ingeniería de software tiene que ver con varios campos en diferentes formas:
a. Matemáticas
Los programas tienen muchas propiedades matemáticas. Por ejemplo la

corrección y la complejidad de muchos algoritmos, son conceptos matemáticos
que pueden ser rigurosamente probados. El uso de matemáticas en la IS es
llamado métodos formales.
b. Creación
Los programas son construidos en una secuencia de pasos. El hecho de definir

propiamente y llevar a cabo estos pasos, como en una línea de ensamblaje, es
necesario para mejorar la productividad de los desarrolladores y la calidad final de
los programas. Este punto de vista inspira los diferentes procesos y metodologías
que se encuentran en la IS.
c. Gestión de Proyectos
El desarrollo de software de gran porte requiere una adecuada gestión del

proyecto. Hay presupuestos, establecimiento de tiempos de entrega, un equipo de
profesionales que liderar. Recursos (espacio de oficina, insumos, equipamiento)
51
por adquirir. Para su administración se debe tener una clara visión y capacitación
en Gestión de Proyectos.
d. Arte
Los programas contienen muchos elementos artísticos. Las interfaces de usuario,

la codificación, etc. Incluso la decisión para un nombre de una variable o una
clase. Donald Knuth es famoso por argumentar a la programación como un arte.
3.4.4. Responsabilidad
La responsabilidad en la ingeniería del software es un concepto complejo, sobre

todo porque al estar los sistemas informáticos fuertemente caracterizados por su
complejidad, es difícil apreciar sus consecuencias.
En la ingeniería del software la responsabilidad será compartida por un grupo

grande de personas, que comprende desde el ingeniero de requisitos, hasta el
arquitecto software, y contando con el diseñador, o el encargado de realizar las
pruebas. Por encima de todos ellos destaca el director del proyecto. El software
demanda una clara distribución de la responsabilidad entre los diferentes roles que
se dan en el proceso de producción.
El ingeniero del software tiene una responsabilidad moral y legal limitada a las
consecuencias directas.
3.5. EDUCACIÓN A DISTANCIA
La educación a distancia es una forma de enseñanza en la cual los estudiantes no

requieren asistir físicamente al lugar de estudios. En este sistema de enseñanza,
el alumno recibe el material de estudio (personalmente, por correo postal, correo
electrónico u otras posibilidades que ofrece Internet). Al aprendizaje desarrollado
con las nuevas tecnologías de la comunicación se le llama aprendizaje electrónico.
52
Dependiendo del centro de estudios, los estudiantes pueden acudir físicamente
para recibir tutorías, o bien deben realizar exámenes presenciales. Existe
educación a distancia para cualquier nivel de estudios, pero lo más usual es que
se imparta para estudios universitarios.
3.5.1. Características
La educación a distancia se caracteriza por la flexibilidad de sus horarios, pues el

mismo estudiante organiza su tiempo de estudio, lo cual requiere cierto grado de
autodisciplina. Esta flexibilidad de horarios a veces está limitada en ciertos cursos
que exigen participación en línea, en horarios o espacios específicos.
Otra característica de la educación a distancia es el uso de las Tecnologías de la

Información y la Comunicación (TIC) para formar comunidades o redes de estudio
donde los individuos pueden interactuar, para discutir sobre diversos temas y a la
vez adquirir conocimientos con modernas herramientas de trabajo. También es
imprescindible tener una nueva visión de los roles que desempeñan los docentes
y los estudiantes en esta modalidad de estudio, el docente deja de ser el
protagonista, convirtiéndose en un facilitador del proceso educativo y le cede el
paso al estudiante, el cual debe tener un compromiso firme con su propio proceso
de formación.
Una de las universidades de educación a distancia más antigua es el Instituto

Federal de Capacitación del Magisterio de México, fundado en 1945 y considerado
la escuela normal más grande del mundo pues por razones históricas para el país
tuvo que formar a más de 90.000 profesores de educación primaria en servicio
que carecían del título para ejercer la docencia. Está también la Universidad de
Sudáfrica, que lleva ofreciendo este servicio desde 1946. En el Reino Unido, la
más grande es la Open University, que se fundó en 1969. En España, la
Universidad Nacional de Educación a Distancia comenzó sus actividades en 1973
y un año más tarde, en Alemania, se fundó la Fern Universität Hagen. Estas cuatro
53
universidades tienen más de 100.000 estudiantes, lo que es posible gracias al bajo
costo que supone la educación a distancia.
Entre los antecedentes de la educación a distancia están los cursos por

correspondencia, que se iniciaron por la necesidad de impartir enseñanza a
estudiantes en lugares aislados, en los que no era posible construir un colegio.
Tales cursos se ofrecieron al nivel de primaria y secundaria, en ellos, a menudo,
eran los padres quienes supervisaban el progreso educativo del estudiante.
En la actualidad, existen diversos factores que determinan el crecimiento de la

educación a distancia,32 entre los que destacan:
 Reducción del costo de las computadoras y de las telecomunicaciones.
 Mayores facilidades para que la población acceda a la tecnología.
 Utilización de interfaces más amigables como la multimedia.
 Aumento de la demanda educativa.
 La creación de nuevas entidades educativas, así como el incremento de

mayores instalaciones físicas (aulas), no es proporcional al crecimiento
demográfico.
3.5.2. Ventajas de la educación a distancia
 Elimina las barreras geográficas, la población puede acceder a este tipo de

educación independientemente de donde resida.
 Es accesible para personas adultas con estudios postergados.
32
NUEVAS TECNOLOGÍAS, EDUCACIÓN A DISTANCIA Y LA MERCANTILIZACIÓN DE LA
FORMACIÓN, Revista Iberoamericana de Educación
54
 Proporciona flexibilidad en el horario ya que no hay hora exacta para acceder a
la información, lo cual facilita la organización del tiempo personal del
estudiante, respetando la vida familiar, social y laboral.
 Reduce costos al evitar gastos de traslados o residencia en un lugar diferente.
 Incorpora herramientas tecnológicas para el manejo de la información, las

cuales son necesarias para desempeñarse profesionalmente en la sociedad en
constante cambio, tales como las plataformas virtuales.33
 El estudiante desarrolla una alta capacidad para autorregular su propio

aprendizaje favoreciendo así sus actitudes y valores de responsabilidad,
disciplina y compromiso para lograr ser autónomo.
 El rol del estudiante es activo pues desarrolla estrategias intelectuales

importantes para realizar tareas colaborativas, comunicarse efectivamente, ser
creativo e innovador.
 El asesor lleva un seguimiento riguroso del estudiante empleando diversos

instrumentos para evaluarlo respetando el ritmo de trabajo del estudiante.
3.5.3. Roles en la educación a distancia
Entre los diversos roles que se pueden presentar en un equipo de educación a

distancia se pueden mencionar los siguientes:
 Coordinador general: Responsable de articular los procesos de todo el

equipo. Establece el cronograma de actividades, propone las tareas a realizar,
planifica y controla el normal funcionamiento del proyecto.
33
Plataformas virtuales de aprendizaje:
55
 Experto en contenidos: Docente a cargo del curso y experto en contenidos
del tema a ser impartido a distancia. De acuerdo con la manera en que se
entienda en cada región, país o cultura, el experto en contenidos cambia su
rol, por ejemplo, en Bolivia (en educación a distancia) es la persona que
redacta, produce los módulos y las unidades temáticas, es decir es un
verdadero científico dedicado a la producción intelectual.
 Docente tutor: Apoya en la administración, guiando y orientando al estudiante.

Se dedica a realizar textos, es decir, construye los módulos que son parte del
curso. Esta misma persona puede llegar a ser el que guía a los participantes;
pero en caso de no contar con su apoyo, es el tutor (una persona entendida en
el tema, pero que no necesariamente produce los contenidos de los módulos)
quien puede ejercer como aquella persona que guíe el proceso educativo a
distancia. El docente tutor a distancia debe tener unas habilidades diferentes
del docente que se dedique a la formación presencial; algunas de ellas pueden
ser el dominio sobre las tecnologías de la información y la comunicación,
conocimientos para organizar y gestionar cursos en línea, lo que ello
representa (grupos de discusión, foros, debates, etc.). Debe tener una
capacidad de comunicación escrita bastante depurada, debido a que el
estudiante no es presencial y por tanto, no se puede interaccionar igualmente
con él.
 Asesor de diseño: Pedagogo especialista que ayuda al docentes a

seleccionar los medios necesarios y diseñar actividades, también es conocido
como el diseñador instruccional.
 Asesor en tecnología: Apoya al equipo de docentes, seleccionando las

herramientas tecnológicas adecuadas para el logro por parte del estudiante,
para los objetivos del aprendizaje propuesto, también es conocido como
tecnopedagogo.
56
 Productor de nuevas tecnologías: Apoya en la producción del material
audiovisual que enriquece las clases. Es el encargado de mediatizar los
contenidos.
 Diseñador gráfico: Selecciona los recursos gráficos adecuados para los

cursos virtuales.
 Evaluador del sistema: Tiene a su cargo la evaluación de todo el sistema

(materiales, tutores, alumnos y administración en general), también puede
proponer medidas correctivas para solucionar inconvenientes que se hayan
producido durante el curso a distancia.
 Estudiante: Uno de los roles más importantes en el sistema de educación

abierta es el estudiante, pues es quien debe contar con disposición de trabajo
en equipo, administración en su tiempo y realizar las actividades en tiempo y
forma, pero sobre todo en tener una motivación de crecimiento en cuanto a su
vida académica.
3.5.4. Educación semipresencial
En esta modalidad, los estudiantes puedan acceder a una educación sin la

necesidad de presentarse físicamente en la institución educativa todos los días.
Por lo tanto, es una excelente opción para quienes trabajan, o bien, para aquellos
que su labor en casa no les permite estar mucho tiempo en la escuela.
Esto con la ventaja de tener una educación sin las limitaciones de un horario o
lugar, ya que en cualquier parte la persona puede estudiar con la única condición
de que tiene que asistir periódicamente a tutoría para aclarar dudas, realizar
actividades de evaluación o tomar alguna clase o materia. La ventaja que tiene
este modelo es que el alumno va desarrollando su aprendizaje de una manera un
57
poco más autónoma, ya que la investigación es indispensable. En otras palabras,
el estudiante es capaz de regir y proyectar el proceso de su propio aprendizaje.
En la educación semipresencial el estudiante asiste periódicamente a sesiones en

la universidad o instituto, con el fin de estar al corriente de las actividades de los
estudiantes, atender sus dudas e inquietudes, aumentar la formalidad, poner en
práctica ciertos conocimientos, entre otros. Estas horas, por ser pocas, se limitan a
orientaciones por parte de los profesores y a resolver dudas. La eficacia del
programa se debe a la eficiencia del alumno, es decir, se determina según la
capacidad del estudiante para organizar su propio tiempo y ritmo de estudio.
El aprendizaje se monitorea por medio de tutorías, las cuales pueden ser de dos
tipos: presenciales y virtuales. La evaluación se implementa de acuerdo a cada
curso. Existen clases virtuales que pueden ser de una a más veces por semana; y
presenciales, que se destinan regularmente para realizar exámenes parciales y
finales.
Las escuelas abiertas podrían ser un ejemplo de este modelo ya que sólo se
asiste una vez a la semana con el docente, si existe alguna duda. El estudiante
estudia el contenido que se le otorga y presenta los exámenes correspondientes
hasta terminar con el plan de estudios sin necesidad de realizar más actividades
que éstas.
3.5.5. Educación a distancia en Hispanoamérica
3.5.5.1. Argentina
En América Latina, Argentina es pionera de la educación a distancia, teniendo su

primera universidad brindando contenidos desde la década del 80. Ésta fue la
Universidad Nacional de Mar del Plata, con educación a distancia desde 1985 y en
1988 surge el Curso Educador Abierto.
58
El Ministerio del Interior posee un Servicio de Educación a Distancia (SEAD)
atendiendo mediante el dictado de Educación General Básica (EGB) a los hijos de
argentinos que temporalmente tengan que residir en el exterior, para facilitar su
reinserción en el sistema educativo argentino.
A nivel medio existen iniciativas como el "Proyecto de Educación Adultos 2000"

del Gobierno de la Ciudad de Buenos Aires lanzado en octubre del 1998
procurando estudios de nivel secundario a aquellas personas que no lo hayan
iniciado o completado, sin obligatoriedad de asistencia a clases.
En 1999 se crea el "Servicio de Educación a Distancia del Ejército Argentino"

(SEADEA), tiene como característica que la institución es dueña de la totalidad de
los recursos disponibles habiendo diseñado y desarrollado la Plataforma Educativa
Digital (PED), en la que incluyeron 3 campus: Educación Superior, Técnico
Profesional Militar y EGB Polimodal. También ofrece diversos cursos como
idiomas.
La educación a distancia en Argentina a nivel universitario se encuentra

insuficientemente desarrollada y la mayoría de los programas que complementan
otros, requieren asistencia a la universidad.
El número de universidades públicas que ofrecen educación a distancia creció un

62 % entre 2000 y 2002. Cerca de un 85 % de universidades argentinas ofrecen
alguna forma de actividad de educación a distancia.
Los programas de educación a distancia se han diseñado exclusivamente para el

mercado argentino, con poco impacto internacional. En Argentina, las acciones del
CONEAU han ayudado a detener la aparición de instituciones extranjeras y
programas académicos externos que se ofrecen directamente o a través de
convenios con universidades locales.
59
3.5.5.2. Bolivia
Aunque muchos de los países tienen mayor experiencia en lo que hoy llamamos
e-learning, en Bolivia existen varias experiencias de educación a distancia. La
mayoría de las instituciones trabajan vía moodle, es decir plataforma; sin embargo
la UNSXX tiene experiencia en la educación a distancia a través del programa de
educación a distancia para maestros normalistas.
En Bolivia muchas universidades pertenecientes al estado que impartiendo clases

de EaD, entre las que destacan: Universidad Técnica de Oruro y la Universidad
Andina Simón Bolívar.
Además también hay experiencias en otras universidades, como la Universidad

Mayor de San Simón.
En la Educación Alternativa de Adultos, el gobierno promueve la educación a

distancia a nivel técnico mediante el Portal Educativo de Bolivia y la experiencia en
la formación en Bachillerato Humanístico de instituciones como la Fundación
Educativa CIFA, beneficiando a ciudadanos que no tienen acceso, por diversos
motivos, a un establecimiento educativo físicamente y también a la población
migrante en países como Argentina, Brasil, Chile, España, Italia, Suiza, etc.
3.5.5.3. Chile
En Chile, es posible estudiar a distancia en varias instituciones de nivel terciario y

superior. La alternativa en educación básica no es reconocida por el Ministerio de
Educación, lo que obliga a los estudiantes de estos esquemas a rendir exámenes
libres para validar su avance.
60
3.5.5.4. Colombia
En Colombia existe una amplia tradición de educación a distancia, la cual se inició

por un lado con las Escuelas Radiofónicas de la Cadena Radial Radio Sutatenza
que estaba dirigida principalmente a la población campesina, y por otro lado, a
partir de la fundación de Inravisión en 1963, entidad que afianzó el modelo de
primaria por televisión y los programas educativos para adultos, los cuales se
emitían en gran medida por la cadena 7 (canal uno), y por el canal 11 (ahora
Señal Colombia). Estos planes estuvieron vigentes y al aire hasta finales de la
década de los 90. Posteriormente se desarrollaron actividades en varias
universidades, siendo pionera la Universidad Santo Tomás, actualmente esta
institución es la única en Colombia que bajo la metodología a Distancia goza de
una Acreditación Institucional de Alta Calidad. El Primer Claustro Universitario de
Colombia, como también se le conoce a esta universidad, cuenta con 27 CAU
(Centros de Atención Universitaria) donde el estudiante puede asistir a tutorías
personalizadas con expertos. La Unisur fue una experiencia inicialmente popular
en Bogotá y posteriormente se apoyó su crecimiento durante el gobierno de
Belisario Betancur, cambiándose su denominación a Universidad Nacional Abierta
y a Distancia (UNAD) y ampliándose su cubrimiento a todo el país siendo la única
en Colombia dedicada exclusivamente a la educación a distancia. La UNAD ofrece
a sus estudiantes dos mediaciones: una con encuentros tradicionales, donde el
estudiante se dirige a un centro de educación a distancia a reunirse con su grupo y
su tutor, la otra a través del campus virtual, a través de aulas virtuales, donde el
estudiante ingresa desde cualquier lugar del planeta.
También se encuentra el IDEAD (Instituto de Educación a Distancia de la

Universidad del Tolima), con sede en la ciudad de Ibagué. La Universidad Antonio
Nariño también fue pionera en su modelo de educación a distancia y hoy en día
muchas universidades tienen sistemas de educación a distancia ampliándose
cada día por las facilidades que brindan las TIC.
61
La ESAP (Escuela Superior de Administración Pública) dio comienzo a sus
programas a distancia de pregrado en 1983. El programa inicial tenía 6 semestres
y daba el título de Tecnólogo en Administración Municipal. Luego se desarrolló el
ciclo profesional en 1988 y se otorgaba el título de administrador público municipal
y regional. En 1998 se autorizó por el Ministerio de Educación un nuevo programa
llamado APT (Administración Pública Territorial).
También la ESAP ofrece programas de posgrado (especializaciones) a distancia

que administra mediante las direcciones territoriales (15 en todo el país).
3.5.5.5. España
En España, la educación superior a distancia de ámbito estatal está encomendada

a la Universidad Nacional de Educación a Distancia, conocida por sus siglas
UNED. Se trata de la universidad española con mayor número de estudiantes
matriculados y se encuentra por detrás de la Open University inglesa. Posee una
metodología específica y presencia en todo el territorio nacional.
En Cataluña se creó en 1999 la Universidad Abierta de Cataluña (UOC), con una

metodología de enseñanza similar aunque haciendo un uso más intensivo de las
posibilidades de la informática e Internet. Su oferta educativa se orienta hacia
carreras técnicas relacionadas con la comunicación, la informática y las nuevas
tecnologías, sin descuidar otras enseñanzas más tradicionales.
En Madrid se aprobó el 8 de junio de 2006 la Universidad a Distancia de Madrid

(UDIMA), con orientación hacia la aplicación de las nuevas tecnologías a la
educación. Su principal accionista es la Escuela de Negocios del Centro de
Estudios Financieros.
En la capital española, también el Instituto Madrileño de Formación (IMF) dicta

cursos y carreras en modalidad a distancia (así como también presencial y
62
semipresencial). Está enfocado especialmente en gestión administrativa y
energías renovables.
El 14 de diciembre de 2007 se aprobó en la Comunidad Valenciana la VIU

(Universidad Internacional Valenciana), una universidad online audiovisual en
Internet con profesorado de gran prestigio internacional.
En La Rioja se aprobó el 12 de septiembre de 2008 la Universidad Internacional

de La Rioja (UNIR), caracterizada por la enseñanza a distancia y cuyo
funcionamiento se asienta en las tecnologías de la información y de las
comunicaciones. La UNIR propone un modelo de enseñanza exclusivo, moderno y
virtual mediante el uso de plataformas de e-learning.
Además de estas universidades han surgido numerosos emprendimientos

privados que con sus cursos cortos han aportado un dinamismo mayor al
eLearning ya que proveen cursos menos costosos que de las universidades, y
muchas veces cubren necesidades que las universidades no brindan. Por ejemplo
la matricula abierta todo el año implica que los estudiantes puedan matricularse
todo el año y comenzar al lunes siguiente de la fecha de matrículada.
3.5.5.6. México
México fue el primer país en desarrollar programas abiertos para educación media
superior. En educación básica existen algunos programas con varias décadas de
experiencia en esta modalidad. El Instituto Politécnico Nacional (IPN) ha
incursionado en la modalidad a distancia a nivel licenciatura. Mediante la
plataforma educativa los estudiantes interactúan entre sí, con el docente, se
realizan tareas, trabajos en equipo, exámenes, tal como en el sistema
escolarizado. En 1972, la Universidad Nacional Autónoma de México (UNAM)
fundó el sistema Universidad Abierta, una alternativa con un alto nivel académico
que permite a los estudiantes estudiar sin asistir a las aulas, esto se amplía en la
coordinación de Educación Abierta a Distancia. Los beneficios de la tecnología
63
aplicada a las comunicaciones, como el internet, han ampliado la cobertura de la
educación a distancia y ha constituido el sistema Universidad Abierta y a
Distancia.
La CUAED (Coordinación de Universidad Abierta y Educación a Distancia) tuvo su

origen en 1972. En 2003, debido a otro acuerdo que reorganiza la estructura
administrativa de la UNAM se reorganiza la CUAED, la cual continuará realizando
las funciones contempladas en el Estatuto del Sistema Universidad Abierta de la
UNAM, pero además dará apoyo a los programas formales, escolarizados y
abiertos y no formales (continua, que se realizaran en línea y a distancia, así como
ofrecer actividades académicas en línea y a distancia. Se contempla también
contar con un Consejo Asesor que le apoyará para establecer la normatividad
académica para las modalidades abierta y a distancia, y opinar sobre los
proyectos de educación abierta y a distancia.
Esta modalidad tiene como misión: Promover la innovación educativa en las

escuelas y facultades de la UNAM al aprovechar los beneficios de las tecnologías
digitales; fomentar la inclusión de grupos vulnerables en programas educativos
pertinentes y de calidad e impulsar la investigación interdisciplinaria con énfasis en
sistemas y ambientes educativos, además de propiciar la formación de recursos
humanos de excelencia para atender las demandas de la sociedad
contemporánea.
La Coordinación de Universidad Abierta y Educación a Distancia (CUAED)

implementó cursos propedéuticos para estudiante de nuevo ingreso para
instruirlos acerca de la manera de realizar el estudio universitario en línea y el uso
de las herramientas tecnológicas (foros grupales, asesoría en línea, bibliotecas
virtuales, etc.). Cada grupo cuenta con un asesor para guiar y evaluar el
desempeño de los estudiantes a lo largo del curso. Cada curso cuenta con tres
temas tanto para la educación abierta como a distancia, con las actividades
64
planteadas para desarrollar las habilidades necesarias para la licenciatura, para
finalizarse en un lapso de tres semanas.
Con el paso del tiempo se creó la educación a distancia y se ha ido

perfeccionando una forma de enseñanza en la cual no hay que estar
presentándose en un salón de clases a diario es una buena alternativa de estudio
para aquellas personas que por distintas razones no pueden ir a una aula escolar
y desean seguir con sus estudios, dando la flexibilidad de estudiar sin tener que
viajar a una escuela lejos del lugar donde vives.
En 2009 se creó el Programa de Educación Superior Abierta y a Distancia, que fue

el antecedente directo de la actual Universidad Abierta y a Distancia de México,
institución creada por decreto presidencial, el 20 de enero de 2012, para ofrecer
servicios educativos de nivel superior para cualquier mexicano que haya concluido
su educación media superior y esté interesado en alguna de las carreras que
ofrece la universidad, sin importar en qué lugar del mundo se encuentre.
3.5.5.7. Perú
En el Perú, el Ministerio de Educación a través del portal Perú Educa brinda

diversos recursos educativos a distancia:
 Desarrollo Profesional Docente: Cursos virtuales de capacitación para

profesores.
 Recursos Tecnológicos OLPC: Aulas virtuales diseñadas para la enseñanza a

través de las computadoras portátiles OLPC.
 Educación Secundaria Rural a Distancia.
Existen numerosas universidades peruanas que ofrecen educación a distancia en

pregrado: La Universidad Nacional Hermilio Valdizán, la Universidad Alas
Peruanas, la Universidad de Huánuco, la Universidad Inca Garcilaso de la Vega, la
65
Universidad Jaime Bausate y Meza, la Universidad José Carlos Mariátegui, la
Universidad Peruana Los Andes, la Universidad Privada TELESUP, la Universidad
San Ignacio de Loyola y la Asociación Nacional de Educación a Distancia.
Entre las universidades que dictan diplomaturas y maestrías a distancia, destacan:

La Pontificia Universidad Católica del Perú, la Universidad Antonio Ruiz de
Montoya, la Universidad Católica de Santa María, la Universidad Católica Sedes
Sapientiae, la Universidad Peruana de Ciencias Aplicadas (UPC), la Universidad
de San Martín de Porres y la Universidad Tecnológica del Perú.
Asimismo, la educación superior técnico-profesional también incluye carreras

virtuales, tal es el caso del Servicio Nacional de Adiestramiento en Trabajo
Industrial (SENATI), el Instituto Nacional de Investigación y Capacitación de
Telecomunicaciones (INICTEL), el Instituto Peruano de Administración de
Empresas (IPAE), el Instituto Superior Tecnológico TECSUP y el Instituto Superior
Tecnológico TELESUP.
Debido al gradual crecimiento de esta modalidad, actualmente la plataforma de

mayor aceptación como Moodle tiene ya su paralelo oficial en el Perú y es
adoptada cada vez más por los institutos, universidades, instituciones estatales y
empresa privada.
3.5.5.8. Puerto Rico
La UIPR (Universidad Interamericana de Puerto Rico) con frecuencia conocida por

la forma abreviada Inter es un sistema universitario privado de Puerto Rico. Fue
fundada en el pueblo de San Germán (Puerto Rico) en 1912. Está compuesta por
nueve campus y dos escuelas especializadas.
66
La Inter es la institución privada más grande de la isla y de todo el Caribe, y en el
año 1944 se convirtió en la primera institución fuera de los Estados Unidos en ser
acreditada por la Middle States Association of Colleges and Schools.
Posee 45 programas exclusivos, que van desde grados asociados en

Emergencias Médicas, Fotografía, Tecnología Científica óptica; bachilleratos en
Música Popular, Tecnología de los Alimentos, Administración de Pequeños
Negocios, Biotecnología, y maestrías en Anestesiología, Bellas Artes, Comercio
Electrónico, Justicia Criminal, y Negocios Internacionales.
Es la única institución en el Caribe en ofrecer un programa de Ciencia Aérea y la

única con una Escuela de Optometría en el Caribe y Latinoamérica, siendo la
principal proveedora de optometristas bilingües en el mundo.
3.5.5.9. República Dominicana
La Secretaría de Estado de Educación conjunto a otras entidades

gubernamentales ha pactado un convenio con el Instituto Tecnológico y de
Estudios Superiores de Monterrey para impartir el programa Prepanet, a través de
los Centros Tecnológicos Comunitarios dirigidos por el Despacho de la Primera
Dama. Dicho programa consiste en cursar el bachillerato a través de un programa
y sistema curricular totalmente en línea. El público al cual se dirige el proyecto es
a aquellas personas de escasos recursos residentes en comunidades alejadas,
que por razones de trabajo y familia no pueden acceder a la educación de
bachillerato en los centros físicos correspondientes.
Desde sus orígenes, la UAPA (Universidad Abierta para Adultos) se definió como
una modalidad educativa innovadora, que ofrece Educación Superior de calidad a
una población adulta, que tiene dificultades para estudiar en una universidad
comercial; su enfoque educativo es semipresencial y a distancia.
67
La acción docente que se desarrolla en la UAPA se fundamenta en el principio de
responsabilidad compartida entre el participante y el facilitador. La metodología
empleada es activa participativa y las técnicas de aprendizaje se basan en la
actividad de los que aprenden. Tiene como principal medio didáctico para facilitar
el aprendizaje el material impreso, el cual es utilizado con la guía y la orientación
del facilitador.
3.5.5.10. Venezuela
La Universidad Nacional Abierta fue creada el 27 de septiembre de 1977,

mediante Decreto Presidencial No. 2398, de la misma fecha. Es una Universidad
oficial con alcance nacional que forma parte de las Instituciones del Subsistema de
Educación Superior del país. De acuerdo con lo que establece su Reglamento,
esta institución se define como una Universidad Nacional experimental lo cual
obedece a lo referido en la Ley de Universidades vigente en el país, en cuanto a la
posibilidad que tiene la UNA de ensayar nuevas orientaciones y estructuras
organizativas en Educación Superior.
La UNA constituye, asimismo, un sistema de educación abierta y a distancia

(SEAD) de alcance nacional, organizado para democratizar y masificar el acceso a
la educación, a amplios sectores de la población del país que están imposibilitados
para atender un programa de estudios bajo la modalidad presencial debido a la
existencia de barreras geográficas, de impedimentos físicos y de cualquier otra
índole, o a la imposibilidad de compatibilizar sus obligaciones familiares y
laborales con los estudios, sin interferencias entre unas y otras.
3.6. SISTEMA DE GESTIÓN DE CONTENIDOS
Un sistema de gestión de contenidos (o CMS, del inglés Content Management

System) es un programa que permite crear una estructura de soporte (framework)
para la creación y administración de contenidos, principalmente en páginas web,
por parte de los administradores, editores, participantes y demás roles.
68
Consiste en una interfaz que controla una o varias bases de datos donde se aloja
el contenido del sitio web. El sistema permite manejar de manera independiente el
contenido y el diseño. Así, es posible manejar el contenido y darle en cualquier
momento un diseño distinto al sitio web sin tener que darle formato al contenido de
nuevo, además de permitir la fácil y controlada publicación en el sitio a varios
editores. Un ejemplo clásico es el de editores que cargan el contenido al sistema y
otro de nivel superior (moderador o administrador) que permite que estos
contenidos sean visibles a todo el público.
3.6.1. Otras consideraciones iniciales
Entendido como un sistema de soporte a la gestión de contenidos; ya que, en

realidad, son las estrategias de comunicación las que realmente llevan a gestionar
contenidos y publicidad de forma efectiva; los sistemas informáticos pueden
proporcionar las herramientas necesarias para la publicación en línea, o bien
incluir servicios de soporte a la toma de decisiones por lo que a la gestión de
contenidos se refiere.
El gestor de contenidos se aplica generalmente para referirse a sistemas de

publicación, pudiendo subestimarse las funcionalidades de soporte y
mantenimiento. La correcta implantación del sistema, con arreglo a las
necesidades del cliente es necesaria, y es necesita entender el proyecto de un
portal web en el seno de un proyecto de comunicación estructurado y bien
planteado.
La elección de la plataforma correcta será vital para alcanzar los objetivos del
cliente, ya que exentan particularidades diferenciales tanto en su adaptabilidad a
esquemas gráficos como la posible integrabilidad de funcionalidades y
extensiones adicionales.
El posicionamiento en buscadores está relacionado con el volumen de contenidos

de un portal y con la forma en la que éste se presenta. Es importante tener eso en
69
cuenta para la estructura del portal para garantizar un correcto posicionamiento
orgánico.
3.6.2. Funcionamiento
Un sistema de administración de contenidos funciona en el servidor web en el que

esté alojado el portal. El acceso al gestor se realiza generalmente a través del
navegador web, y se puede requerir el uso de FTP para subir contenido.
Cuando un usuario accede a una URL, se ejecuta en el servidor esa llamada, se

selecciona el esquema gráfico y se introducen los datos que correspondan de la
base de datos. La página se genera dinámicamente para ese usuario, el código
HTML final se genera en esa llamada. Normalmente se predefinen en el gestor
varios formatos de presentación de contenido para darle la flexibilidad a la hora de
crear nuevos apartados e informaciones.
3.6.3. Gestión de usuarios
Dependiendo de la plataforma elegida se podrán escoger diferentes niveles de

acceso para los usuarios; yendo desde el administrador del portal hasta el usuario
sin permiso de edición, o creador de contenido. Dependiendo de la aplicación
podrá haber varios permisos intermedios que permitan la edición del contenido, la
supervisión y reedición del contenido de otros usuarios, etc.
El sistema de gestión de contenidos controla y ayuda a manejar cada paso de este

proceso, incluyendo las labores técnicas de publicar los documentos de uno o más
sitios. En muchos sitios con estos sistemas una sola persona hace el papel de
creador y editor, como por ejemplo en los blogs personales.
3.6.4. Tipos de gestores de contenidos
Los gestores de contenido se pueden clasificar según diferentes criterios:
70
3.6.4.1. Por sus características
 Según el lenguaje de programación empleado, como por ejemplo Active Server

Pages, Java, PHP, ASP.NET, Ruby On Rails, Python, PERL
 Según la licencia: Código abierto o Software propietario
3.6.4.2. Por su uso y funcionalidad
 Blogs; pensados para páginas personales.
 Foros; pensados para compartir opiniones.
 Wikis; pensados para el desarrollo colaborativo.
 Enseñanza; plataforma para contenidos de enseñanza on-line.
 Comercio electrónico; plataforma de gestión de usuarios, catálogo, compras y

pagos.
 Publicaciones digitales.
 Difusión de contenido multimedia.
3.6.5. Iniciativas de estandarización
Dentro de los portales se han realizado procesos de estandarización encaminados

a la homogeneización en las interfaces de programación de los mismos de tal
manera que un servicio desarrollado para un portal pueda ejecutarse en cualquier
otro portal compatible con el estándar. El objetivo es obtener portales
interoperables evitando desarrollo propietario.
Las dos iniciativas más importantes son la Portlet Specification API JSR-168, la
Content Repository API JSR-170.
71
3.6.6. Ventajas y Oportunidades
El gestor de contenidos facilita el acceso a la publicación de contenidos a un rango

mayor de usuarios. Permite que sin conocimientos de programación ni
maquetación cualquier usuario pueda añadir contenido en el portal web.
Además permite la gestión dinámica de usuarios y permisos, la colaboración de

varios usuarios en el mismo trabajo, la interacción mediante herramientas de
comunicación.
Los costes de gestión de la información son muchos menores ya que se elimina

un eslabón de la cadena de publicación, el maquetador. La maquetación es hecha
al inicio del proceso de implantación del gestor de contenidos.
La actualización, backup y reestructuración del portal son mucho más sencillas al

tener todos los datos vitales del portal, los contenidos, en una base de datos
estructurada en el servidor.
3.7. SISTEMA DE GESTION DE APRENDIZAJE
Un Sistema de Gestión de Aprendizaje (LMS) es una aplicación de software para

la administración, documentación, seguimiento, elaboración de informes y la
entrega de e-learning cursos de educación o programas de formación.34
LMS es una gama de sistemas para la gestión de los registros de capacitación y

educación con el software para la distribución en línea cursos universitarios o
mezclado / híbrida a través de Internet con características de colaboración en
línea. Colegios y universidades utilizan LMS para ofrecer cursos en línea y
aumentar los cursos en el campus. Departamentos de formación de negocios
utilizan LMS para impartir formación en línea, así como automatizar el
mantenimiento de registros y el registro de los empleados.
34
Ellis, Ryann K. (2009), Guía de Campo de Aprendizaje de Sistemas de Gestión , ASTD Circuitos Aprendizaje
72
3.7.1. Características
3.7.1.1. Propósito
La clave para entender la diferencia entre el LMS y otros términos de educación

informática es entender la naturaleza sistémica de LMS. LMS es el marco que se
encarga de todos los aspectos del proceso de aprendizaje. Un LMS es la
infraestructura que ofrece y gestiona contenido educativo, identifica y evalúa el
aprendizaje individual y organizacional y los objetivos de formación, seguimiento
del progreso hacia el logro de esos objetivos, y recoge y presenta datos para
supervisar el proceso de aprendizaje de la organización en su conjunto.35 Un LMS
ofrece un contenido, pero también se ocupa de inscripción para los cursos de golf,
administración, análisis de brecha de competencias, seguimiento y presentación
de informes.36
La mayoría de LMSs son basados en la Web para facilitar el acceso a los

contenidos y la administración de aprendizaje. También son utilizados por las
instituciones educativas para mejorar y apoyar la enseñanza en el aula y ofrecer
cursos para una mayor población de estudiantes. Los LMSs son utilizados por las
industrias reguladas (por ejemplo, servicios financieros y biofarmacéuticas) para la
capacitación en el cumplimiento. Estudiante de auto-servicio (por ejemplo, el
registro automático en la formación dirigida por un instructor), la formación de flujo
de trabajo (por ejemplo, la notificación del usuario, la aprobación del administrador
y la gestión de lista de espera), la provisión de aprendizaje en línea (por ejemplo,
la formación basada en ordenador , leer y entender), la evaluación on-line, gestión
de la educación profesional continua (CPE), el aprendizaje en colaboración (por
ejemplo, uso compartido de aplicaciones, hilos de discusión), y la gestión de los
recursos de formación (por ejemplo, profesores, instalaciones, equipos), son
dimensiones importantes de aprendizaje de Sistemas de Gestión.
35
Szabo, Micheal; Flesher, K. (2002). "Teoría y Práctica CMI: Raíces históricas de Learning Management Systems"
36
Gilhooly, Kym (16). "El e-learning eficaz" Computerworld
73
Algunos proveedores de LMS incluyen los "sistemas de gestión del rendimiento",
que abarcan los empleados tasaciones, gestión de competencias, habilidades,
análisis de deficiencias, la planificación de la sucesión y las evaluaciones
multirater (es decir, las opiniones de 360 grados).Las técnicas modernas emplean
el aprendizaje basado en competencias para descubrir las brechas de aprendizaje
y guía de selección de materiales de capacitación.
En el mercado comercial, el Aprendizaje y los Sistemas de Gestión de rendimiento

incluyen la contratación y la funcionalidad de recompensa.
Un robusto LMS debería ser capaz de hacer lo siguiente:
 Centralizar y automatizar la administración.
 Usar el autoservicio y los servicios de autoguias.
 Ensamblar y entregar contenidos de aprendizaje rápido.
 Consolidar las iniciativas de formación en una solución escalable basada en la

web plataforma.
 Portabilidad y normas de apoyo.
 Personalizar el contenido y permitir la reutilización del conocimiento.
3.7.1.2. LMS y CMS comparación
El uso inadecuado de un LMS en la literatura es quizás comúnmente asociado con

las aplicaciones informáticas que nos identifican como sistemas de gestión de
cursos (CMS). Estos sistemas se utilizan principalmente para el aprendizaje en
línea o semipresencial, el apoyo a la colocación de los materiales de los cursos en
línea, la asociación de estudiantes con cursos, seguimiento del rendimiento de los
estudiantes, el almacenamiento de envíos de los estudiantes y la mediación de la
comunicación entre los estudiantes, así como su instructor. Parte de esta misma
74
funcionalidad se puede ver dentro de un LMS, por lo que es comprensible que la
confusión puede existir sobre las diferencias entre los dos tipos de sistemas. Sin
embargo, la naturaleza sistémica de un LMS no limita su funcionalidad a la de un
CMS.37
3.7.1.3. LMS y LCMS comparación
El enfoque de un LMS es ofrecer cursos en línea o entrenamiento para

principiantes, mientras que la gestión de los estudiantes, hacer el seguimiento de
su progreso y rendimiento en todo tipo de actividades de formación. Un LMS no se
utiliza para crear el contenido del curso.
Por el contrario, un aprendizaje Content Management System (LCMS) es una

tecnología de software relacionado que proporciona un entorno multiusuario,
donde los desarrolladores, autores, diseñadores instruccionales y expertos en la
materia podrán crear, almacenar, reutilizar, gestionar y realizar la entregar digital
de contenidos de un repositorio de objetos central. Un LCMS se centra en el
desarrollo, la administración y publicación de los contenidos que típicamente se
entrega a través de un LMS. Los usuarios pueden crear y reutilizar contenidos de
e-learning y reducir la duplicación de los esfuerzos de desarrollo.
En lugar de desarrollar cursos completos y su adaptación a múltiples audiencias,

un LCMS proporciona la capacidad de las instancias de cursos individuales que
desea modificar y publicar para diferentes usuarios en el mantenimiento de
versiones y la historia. Los objetos almacenados en el repositorio centralizado
pueden ponerse a disposición de los desarrolladores de cursos y expertos en el
tema en toda la organización para su posible reutilización y reutilizar. Esto elimina
los esfuerzos de desarrollo duplicados y permite el montaje rápido de contenido
personalizado. Algunos sistemas cuentan con herramientas para ofrecer y
37
Watson, William R. (2007)
75
gestionar dirigida por un instructor de formación en línea sincrónica y asincrónica
basada en objeto de aprendizaje metodología.
LCMSs proporcionan herramientas para la creación y reutilización o re-propositivo

de contenido (objetos de aprendizaje mutados o OVM), así como espacios
virtuales para la interacción de los estudiantes (por ejemplo, foros de discusión,
salas de chat y web conferencias en vivo).Tecnología LCMS puede ser utilizado
en conjunto con un LMS, o como una aplicación independiente para las iniciativas
que requieren un rápido desarrollo y distribución de contenidos de aprendizaje de
aprendizaje.
Mientras LMS y LCMS productos tienen diferentes fortalezas y debilidades, por lo

general, abordar las siguientes áreas de funcionalidad:
a. LMS Funcionalidad
 Registro y Administración Estudiantil
 Gestión de Eventos Capacitación (es decir, la programación, el seguimiento y

la entrega WBT)
 Plan de Estudios y Certificación
 Habilidades y Gestión de Competencias
 Reporting
 Gestión de Registro de Capacitación
 Cursos Authoring
b. LCMS Funcionalidad
 Desarrollo de contenido colaborativo basada en plantillas
 Gestión de Contenidos facilitado (es decir, la indexación y la reutilización)
76
 Publicación
 La integración de flujo de trabajo
 Interfaz automatizada con un LM
3.7.1.3. LMS como el término omnipresente
A pesar de esta distinción, los LMS término se utiliza a menudo para referirse
tanto a un LMS y un LCMS, aunque la LCMS es realmente una solución
complementaria a un LMS. Ya sea como plataformas independientes o como un
producto resultante de la fusión, LCMSs trabajan con LMS para desarrollar y
entregar contenido de los cursos a los estudiantes. Debido a la falta de
estandarización de la industria, además de ser una industria joven, los productos
que combinan LCMS y LMS atributos pueden ser referidos como Curso de
sistemas de gestión (CMS), Sistemas de Gestión de Aprendizaje (LMS) y LMS /
LCMS. Blackboard Inc. se refiere actualmente a la plataforma Blackboard Learn
como LMS (Blackboard Inc., 2013). En este momento, LMS representa el término
ubicuo para un producto que contiene atributos de ambos un LMS y un LCMS, ya
sea para uso CMS o LMS.
3.7.2. Aspectos técnicos
La mayoría de LMSs son basados en la Web, construidas con una variedad de

plataformas de desarrollo, como Java/J2EE, Microsoft. NET o PHP. Por lo general,
emplean el uso de una base de datos como MySQL , Microsoft SQL Server o
Oracle como back-end. Aunque la mayoría de los sistemas se desarrollen
comercialmente y tienen licencias de software comercial hay varios sistemas que
tienen una licencia de código abierto.
3.7.3. Aprender industria de gestión
En el mercado relativamente nuevo LMS, los proveedores comerciales para

aplicaciones corporativas y la educación van de nuevos operadores a los que se
77
introdujo en el mercado en los años noventa. Además de los paquetes
comerciales, muchos de código abierto soluciones están disponibles.
En el mercado de la educación superior a partir del otoño de 2011, la pizarra es el

proveedor líder con una cuota de mercado de 51%, con Moodle (19%) y
Desire2Learn (11%) los próximos dos proveedores más grandes.38 Muchos
colegios y universidades en línea están eCollege clientes.En el mercado
corporativo, los seis mayores proveedores de LMS representan aproximadamente
el 50% del mercado, con SuccessFactors Learning, Saba Software y SumTotal
Systems son los tres mayores proveedores.
Además de los restantes pequeños LMS vendedores de productos, la formación

de empresas de outsourcing, las empresas vendedores de planificación de los
recursos, y las firmas consultoras compiten por parte del mercado de gestión de
aprendizaje. Aproximadamente el 40 por ciento de las organizaciones de
formación de Estados Unidos informó de que tienen un LMS instalado, una cifra
que no ha cambiado significativamente en los últimos dos años.
La mayoría de los compradores de LMS utilizan una herramienta de autoría para

crear su contenido de e-learning, que se aloja entonces en un LMS. En muchos
casos LMS incluyen una herramienta de creación de primitivas para la
manipulación de contenidos básicos. Para los compradores avanzadas de
creación de contenido debe elegir un software de edición que se integra con su
LMS para que su contenido sea acogido. Hay herramientas de autor en el
mercado, que se reúnen AICC y SCORM normas y por lo tanto el contenido
creado en herramientas de este tipo se puede alojar en una AICC o SCORM LMS
certificados. En mayo de 2010, había validado ADL SCORM 301 productos
certificados, mientras que 329 productos eran compatibles.
38
Perfil del Mercado LMS, CampusComputing, 2011.
78
Evaluación de LMS es una tarea compleja y de investigación significativa admite
diferentes formas de evaluación, incluyendo processess iterativo en el que las
experiencias y enfoques de aprendizaje de los alumnos son evaluados.39
Consideraciones en la selección de un LMS / LCMS se han revisado.
3.8. SISTEMA DE GESTION DE CONTENIDOS DE

APRENDIZAJE
Un Sistema de Gestión de Contenidos de Aprendizaje-LCMS (Learning Content

Management System, en inglés) es una aplicación de software que combina las
capacidades de gestión de cursos de un LMS con las capacidades de
almacenamiento y creación de contenidos de un CMS. Los LCMS se acercan a la
denominación en castellano de “campus virtuales”. Permite la creación y el
desarrollo eficiente de contenidos para el aprendizaje proporcionando las
herramientas necesaria a autores, diseñadores instruccionales y expertos del
tema.
Tal y como se define específicamente: “el LCMS se utiliza para crear y manejar el
contenido de una parte de un programa de educación, por ejemplo un curso”.
Normalmente se crean partes de contenido en forma de módulos que se pueden
personalizar, manejar, y que se pueden usar en diferentes ocasiones (son los
denominado objetos de aprendizaje u OAs). Así, en lugar de apoyar el desarrollo
totalizador de cursos, lo que hace un LCMS es ayudar a diseñadores
instruccionales a crear módulos o bloques de contenido reutilizable (OAs), que
luego se distribuirán según convenga en cada caso, por los diseñadores de los
cursos. Por otro lado, cabe comentar que el LCMS sigue los estándares de la
enseñanza digital IMS, AICC y SCORM.
39
Ellis, R.; Calvo, RA (2007)
79
3.9. METODOLOGÍA SCRUM
Scrum 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 un proyecto. Estas prácticas se apoyan unas a otras y su
selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas

por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está
especialmente indicado para proyectos en entornos complejos, donde se necesita
obtener resultados pronto, donde los requisitos son cambiantes o poco definidos,
donde la innovación, la competitividad, la flexibilidad y la productividad son
fundamentales.
Scrum también se utiliza para resolver situaciones en que no se está entregando

al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes
se disparan o la calidad no es aceptable, cuando se necesita capacidad de
reacción ante la competencia, cuando la moral de los equipos es baja y la rotación
alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o
cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de
producto.
3.9.1. Características de Scrum
SCRUM es un modelo de referencia que define un conjunto de prácticas y roles, y

que puede tomarse como punto de partida para definir el proceso de desarrollo
que se ejecutará durante un proyecto. Los roles principales en Scrum son el
ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de
proyecto, el ProductOwner, que representa a los stakeholders (interesados
externos o internos), y el Team que incluye a los desarrolladores.
80
Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es
definida por el equipo), el equipo crea un incremento de software potencialmente
entregable (utilizable). El conjunto de características que forma parte de cada
sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel
priorizados que definen el trabajo a realizar. Los elementos del Product Backlog
que forman parte del sprint se determinan durante la reunión de Sprint Planning.
Durante esta reunión, el Product Owner identifica los elementos del Product
Backlog que quiere ver completados y los hace del conocimiento del equipo.
Entonces, el equipo determina la cantidad de ese trabajo que puede
comprometerse a completar durante el siguiente sprint.2 Durante el sprint, nadie
puede cambiar el Sprint Backlog, lo que significa que los requisitos están
congelados durante el sprint.
Scrum permite la creación de equipos autoorganizados impulsando la

colocalización de todos los miembros del equipo, y la comunicación verbal entre
todos los miembros y disciplinas involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los

clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo
llamado requirements churn), y que los desafíos impredecibles no pueden ser
fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum
adopta una aproximación pragmática, aceptando que el problema no puede ser
completamente entendido o definido, y centrándose en maximizar la capacidad del
equipo de entregar rápidamente y responder a requisitos emergentes.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum,

que van desde notas amarillas "post-it" y pizarras hasta paquetes de software.
Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y
requiere muy poco esfuerzo para comenzarse a utilizar.
81
3.9.2. Roles en Scrum
3.9.2.1. Roles Principales
El Product Owner representa la voz del cliente. Se asegura de que el equipo

Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product
Owner escribe historias de usuario, las prioriza, y las coloca en el Product
Backlog.
a. ScrumMaster (o Facilitador)
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los

obstáculos que impiden que el equipo alcance el objetivo del sprint. El
ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que
actúa como una protección entre el equipo y cualquier influencia que le distraiga.
El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El
ScrumMaster es el que hace que las reglas se cumplan.
b. Equipo de desarrollo
El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de

3 a 9 personas con las habilidades transversales necesarias para realizar el
trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).
3.9.2.2. Roles Auxiliares
Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol
formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo
deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es
la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros
interesados (stakeholders). Es importante que esa gente participe y entregue
82
retroalimentación con respecto a la salida del proceso a fin de revisar y planear
cada sprint.
a. Stakeholders (Clientes, Proveedores, Vendedores, etc)
Se refiere a la gente que hace posible el proyecto y para quienes el proyecto

producirán el beneficio acordado que justifica su producción. Sólo participan
directamente durante las revisiones del sprint.
b. Administradores (Managers)
Es la gente que establece el ambiente para el desarrollo del producto.
3.9.3. Reuniones en Scrum
3.9.3.1. Daily Scrum o Stand-up meeting
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto

se llama daily standup o Stand-up meeting. El scrum tiene unas guías específicas:
 La reunión comienza puntualmente a su hora.
 Todos son bienvenidos, pero sólo los involucrados en el proyecto pueden

hablar.
 La reunión tiene una duración fija de 15 minutos, de forma independiente del

tamaño del equipo.
 La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
Durante la reunión, cada miembro del equipo contesta a tres preguntas:3
 ¿Qué has hecho desde ayer?
 ¿Qué es lo que harás hasta la reunión de mañana?
83
 ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el
papel del ScrumMaster recordar estos impedimentos).
3.9.3.2. Scrum de Scrum
Cada día normalmente después del “Daily Scrum”:
 Estas reuniones permiten a los grupos de equipos discutir su trabajo,

enfocándose especialmente en áreas de solapamiento e integración.
 Asiste una persona asignada por cada equipo.
La agenda será la misma que la del Daily Scrum, añadiendo además las
siguientes cuatro preguntas:
 ¿Qué ha hecho tu equipo desde nuestra última reunión?
 ¿Qué hará tu equipo antes que nos volvamos a reunir?
 ¿Hay algo que demora o estorba a tu equipo?
 ¿Estás a punto de poner algo en el camino del otro equipo?
3.9.3.3. Reunión de Planificación del Sprint (Sprint Planning Meeting)
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del
Sprint” se lleva a cabo.
 Seleccionar qué trabajo se hará
 Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que
tomará hacer el trabajo.
 Identificar y comunicar cuánto del trabajo es probable que se realice durante el

actual Sprint
 Ocho horas como límite
84
Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión
del Sprint” y la “Retrospectiva del Sprint”
3.9.3.4. Reunión de Revisión del Sprint (Sprint Review Meeting)
 Revisar el trabajo que fue completado y no completado
 Presentar el trabajo completado a los interesados (alias “demo”)
 El trabajo incompleto no puede ser demostrado
 Cuatro horas como límite
3.9.3.5. Retrospectiva del Sprint (Sprint Retrospective)
Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual
todos los miembros del equipo dejan sus impresiones sobre el sprint recién
superado. El propósito de la retrospectiva es realizar una mejora continua del
proceso. Esta reunión tiene un tiempo fijo de cuatro horas.
3.9.4. Sprint
El Sprint es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado

que la duración de los sprints sea constante y definida por el equipo con base en
su propia experiencia. Se puede comenzar con una duración de sprint en particular
(2 o 3 semanas) e ir ajustándolo con base en el ritmo del equipo, aunque sin
relajarlo demasiado. Al final de cada sprint, el equipo deberá presentar los avances
logrados, y el resultado obtenido es un producto potencialmente entregable al
cliente. Asimismo, se recomienda no agregar objetivos al sprint o sprint backlog a
menos que la falta de estos objetivos amenace al éxito del proyecto. La constancia
permite la concentración y mejora la productividad del equipo de trabajo.
85
3.9.5. Documentos
3.9.5.1. Product backlog
El product backlog es un documento de alto nivel para todo el proyecto. Contiene

descripciones genéricas de todos los requerimientos, funcionalidades deseables,
etc. priorizadas según su retorno sobre la inversión (ROI). Es el qué va a ser
construido. Es abierto y solo puede ser modificado por el product owner. Contiene
estimaciones realizadas a grandes rasgos, tanto del valor para el negocio, como
del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a
ajustar la línea temporal (KEV) y, de manera limitada, la prioridad de las diferentes
tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que
requiera menor tiempo de desarrollo tendrá probablemente más prioridad, debido a
que su ROI será más alto.
3.9.5.2. Sprint backlog
El sprint backlog es un documento detallado donde se describe el cómo el equipo

va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en
horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de
16 horas, deberá ser dividida en otras menores. Las tareas en el sprint backlog
nunca son asignadas, son tomadas por los miembros del equipo del modo que les
parezca oportuno.
3.9.5.3. Burn down chart
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de
requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint.
Dibujando una línea que conecte los puntos de todos los Sprints completados,
podremos ver el progreso del proyecto. Lo normal es que esta línea sea
descendente (en casos en que todo va bien en el sentido de que los requisitos
están bien definidos desde el principio y no varían nunca) hasta llegar al eje
horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos
86
pendientes de ser completados en el Backlog). Si durante el proceso se añaden
nuevos requisitos la recta tendrá pendiente ascendente en determinados
segmentos, y si se modifican algunos requisitos la pendiente variará o incluso
valdrá cero en algunos tramos.
3.9.6. Scrum aplicado al desarrollo de software
Aunque surgió como modelo para el desarrollo de productos tecnológicos, también

se emplea en entornos que trabajan con requisitos inestables y que requieren
rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados
sistemas de software.
Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel

Corporation (Empresa que en los macro-juegos de compras y fusiones se
integraría en VMARK, luego en Informix y finalmente en Ascential Software
Corporation). En 1995 lo presentó junto con Ken Schwaber como proceso formal,
también para gestión del desarrollo de software en OOPSLA 95. Más tarde, en
2001 serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de
software scrum está considerado como modelo ágil por la Agile Alliance.
La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que
son:
 Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e

Interesados.
 Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint
(Sprint Backlog), Incremento.
 Reuniones: Planificación del sprint, Revisión diaria, Revisión del sprint.
 Sprint
87
3.9.7. ¿Cuándo se utiliza?
Con la metodología Scrum el cliente se entusiasma y se compromete con el

proyecto dado que lo ve crecer iteración a iteración. Asimismo le permite en
cualquier momento realinear el software con los objetivos de negocio de su
empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio
de cada nueva iteración sin ningún problema.
Esta metódica de trabajo promueve la innovación, motivación y compromiso del

equipo que forma parte del proyecto, por lo que los profesionales encuentran un
ámbito propicio para desarrollar sus capacidades.
3.9.6. Beneficios
 Cumplimento de expectativas: El cliente establece sus expectativas

indicando el valor que le aporta cada requisito / historia del proyecto, el equipo
los estima y con esta información el Product Owner establece su prioridad. De
manera regular, en las demos de Sprint el Product Owner comprueba que
efectivamente los requisitos se han cumplido y transmite se feedback al
equipo.
 Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de

requerimientos generados por necesidades del cliente o evoluciones del
mercado. La metodología está diseñada para adaptarse a los cambios de
requerimientos que conllevan los proyectos complejos.
 Reducción del Time to Market: El cliente puede empezar a utilizar las

funcionalidades más importantes del proyecto antes de que esté finalizado por
completo.
88
 Mayor calidad del software: La metódica de trabajo y la necesidad de
obtener una versión funcional después de cada iteración, ayuda a la obtención
de un software de calidad superior.
 Mayor productividad: Se consigue entre otras razones, gracias a la

eliminación de la burocracia y a la motivación del equipo que proporciona el
hecho de que sean autónomos para organizarse.
 Maximiza el retorno de la inversión (ROI): Producción de software

únicamente con las prestaciones que aportan mayor valor de negocio gracias
a la priorización por retorno de inversión.
 Predicciones de tiempos: Mediante esta metodología se conoce la velocidad

media del equipo por sprint (los llamados puntos historia), con lo que
consecuentemente, es posible estimar fácilmente para cuando se dispondrá
de una determinada funcionalidad que todavía está en el Backlog.
 Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más

valor en primer lugar y de conocer la velocidad con que el equipo avanza en el
proyecto, permite despejar riesgos eficazmente de manera anticipada.
3.9.7. El proceso
En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones

de un mes natural y hasta de dos semanas, si así se necesita). Cada iteración
tiene que proporcionar un resultado completo, un incremento de producto final que
sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo
solicite.
El proceso parte de la lista de objetivos/requisitos priorizada del producto, que

actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos
89
balanceando el valor que le aportan respecto a su coste y quedan repartidos en
iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad de
lo que se desarrolla y el retorno de inversión mediante la replanificación de
objetivos del producto, que realiza durante la iteración con vista a las siguientes
iteraciones.
Las actividades que se llevan a cabo en Scrum son las siguientes:
3.9.7.1. Planificación de la iteración
El primer día de la iteración se realiza la reunión de planificación de la iteración.

Tiene dos partes:
1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista

de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente
las dudas que surgen y selecciona los requisitos más prioritarios que se
compromete a completar en la iteración, de manera que puedan ser
entregados si el cliente lo solicita.
2. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de

tareas de la iteración necesarias para desarrollar los requisitos a que se ha
comprometido. La estimación de esfuerzo se hace de manera conjunta y los
miembros del equipo se autoasignan las tareas.
3.9.7.2. Ejecución de la iteración
Cada día el equipo realiza una reunión de sincronización (15 minutos máximo).
Cada miembro del equipo inspecciona el trabajo que el resto está realizando
(dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos
que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias
que permitan cumplir con el compromiso adquirido. En la reunión cada miembro
del equipo responde a tres preguntas:
90
 ¿Qué he hecho desde la última reunión de sincronización?
 ¿Qué voy a hacer a partir de este momento?
 ¿Qué impedimentos tengo o voy a tener?
Durante la iteración el Facilitador se encarga de que el equipo pueda cumplir con

su compromiso y de que no se merme su productividad.
 Elimina los obstáculos que el equipo no puede resolver por sí mismo.
 Protege al equipo de interrupciones externas que puedan afectar su

compromiso o su productividad.
3.9.7.3. Inspección y adaptación
El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene

dos partes:
1. Demostración (4 horas máximo). El equipo presenta al cliente los requisitos

completados en la iteración, en forma de incremento de producto preparado
para ser entregado con el mínimo esfuerzo. En función de los resultados
mostrados y de los cambios que haya habido en el contexto del proyecto, el
cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la
primera iteración, replanificando el proyecto.
2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera

de trabajar y cuáles son los problemas que podrían impedirle progresar
adecuadamente, mejorando de manera continua su productividad. El
Facilitador se encargará de ir eliminando los obstáculos identificados.
91
3.10. MÉTODOS
3.10.1. Método científico
El método científico (del griego: -μετά = hacia, a lo largo- -οδός = camino-; y del
latín scientia = conocimiento; camino hacia el conocimiento) es un método de
investigación usado principalmente en la producción de conocimiento en las
ciencias. Para ser llamado científico, un método de investigación debe basarse en
la empírica y en la medición, sujeto a los principios específicos de las pruebas de
razonamiento.40 El Oxford English Dictionary, dice que el método científico es: "un
método o procedimiento que ha caracterizado a la ciencia natural desde el siglo
17, que consiste en la observación sistemática, medición y experimentación, y la
formulación, análisis y modificación de las hipótesis."
El método científico está sustentado por dos pilares fundamentales. El primero de

ellos es la reproducibilidad, es decir, la capacidad de repetir un determinado
experimento, en cualquier lugar y por cualquier persona. Este pilar se basa,
esencialmente, en la comunicación y publicidad de los resultados obtenidos (por
ej. en forma de artículo científico). El segundo pilar es la refutabilidad. Es decir,
que toda proposición científica tiene que ser susceptible de ser falsada o refutada
(falsacionismo). Esto implica que se podrían diseñar experimentos, que en el caso
de dar resultados distintos a los predichos, negarían la hipótesis puesta a prueba.
La falsabilidad no es otra cosa que elmodus tollendo tollens del método hipotético
deductivo experimental. Según James B. Conant, no existe un método científico.
El científico usa métodos definitorios, métodos clasificatorios, métodos
estadísticos, métodos hipotético-deductivos, procedimientos de medición, etcétera.
Y según esto, referirse al método científico es referirse a este conjunto de tácticas
empleadas para constituir el conocimiento, sujetas al devenir histórico, y que
eventualmente podrían ser otras en el futuro.41 Ello nos conduce tratar de
sistematizar las distintas ramas dentro del campo del método científico.
40
Rules for the study of natural philosophy", Newton 1999
41
Gregorio Klimovsky, Las desventuras del conocimiento científico
92
3.10.1.1. Descripciones del método científico
Por proceso o "método científico" se entiende aquellas prácticas utilizadas y

ratificadas por la comunidad científica como válidas a la hora de proceder con el
fin de exponer y confirmar sus teorías. Las teorías científicas, destinadas a
explicar de alguna manera los fenómenos que observamos, pueden apoyarse o no
en experimentos que certifiquen su validez. Sin embargo, hay que dejar claro que
el mero uso de metodologías experimentales, no es necesariamente sinónimo del
uso del método científico, o su realización al 100%. Por ello, Francis Bacon definió
el método científico de la siguiente manera:
1. Observación: Observar es aplicar atentamente los sentidos a un objeto o a

un fenómeno, para estudiarlos tal como se presentan en realidad, puede
ser ocasional o causalmente.
2. Inducción: La acción y efecto de extraer, a partir de determinadas

observaciones o experiencias particulares, el principio particular de cada
una de ellas.
3. Hipótesis: Planteamiento mediante la observación siguiendo las normas

establecidas por el método científico.
4. Probar la hipótesis por experimentación.
5. Demostración o refutación (antítesis) de la hipótesis.
6. Tesis o teoría científica (conclusiones).
Así queda definido el método científico tal y como es normalmente entendido, es

decir, la representación social dominante del mismo. Esta definición se
corresponde sin embargo únicamente a la visión de la ciencia denominada
positivismo en su versión más primitiva. Empero, es evidente que la exigencia de
la experimentación es imposible de aplicar a áreas de conocimiento como la
vulcanología, la astronomía, la física teórica, etcétera. En tales casos, es suficiente
la observación de los fenómenos producidos naturalmente, en los que el método
93
científico se utiliza en el estudio (directo o indirecto) a partir de modelos más
pequeños, o a partes de éste.
Por otra parte, existen ciencias no incluidas en las ciencias naturales,

especialmente en el caso de las ciencias humanas y sociales, donde los
fenómenos no sólo no se pueden repetir controlada y artificialmente (que es en lo
que consiste un experimento), sino que son, por su esencia, irrepetibles, por
ejemplo la historia. De forma que el concepto de método científico ha de ser
repensado, acercándose más a una definición como la siguiente: "proceso de
conocimiento caracterizado por el uso constante e irrestricto de la capacidad
crítica de la razón, que busca establecer la explicación de un fenómeno
ateniéndose a lo previamente conocido, resultando una explicación plenamente
congruente con los datos de la observación".
Así, por método o proceso científico se entiende aquellas prácticas utilizadas y

ratificadas por la comunidad científica como válidas a la hora de proceder con el
fin de exponer y confirmar sus teorías, como por ejemplo los Postulados de Koch
para la microbiología. Las teorías científicas, destinadas a explicar de alguna
manera los fenómenos que observamos, pueden apoyarse o no en experimentos
que certifiquen su validez.
3.10.2. Método hipotético-deductivo
El único método reconocido universalmente para obtener información científica es

el método científico, procedimiento derivado de la práctica y la experiencia de
muchas generaciones, aplicable a las ciencias formales: matemáticas (álgebra,
aritmética, etc.) y lógica. Consta de observación, hipótesis, experimentación y
teoría. Cuando la teoría se hace lo suficientemente amplia y sólida, capaz de dar
explicación a una gran cantidad de fenómenos y relaciones de causa-efecto y
también de rebatir racionalmente cualquier crítica, se llega a la ley. En algunas
áreas del conocimiento es materialmente imposible llevar a cabo experimentos
controlados en relación a un determinado fenómeno. Así ocurre, por ejemplo, en la
geología o la astronomía, lengua e historia. No obstante, en esos casos la
94
observación precisa y reproducible sustituye al experimento y las teorías se
consideran válidas cuando: a) Son capaces asociar racionalmente muchos hechos
en apariencia independientes. b) Logran predecir la existencia de relaciones y
fenómenos no detectados hasta el momento. (González Arias A. y Horta Rangel F.
A. Ciencia, pedagogía y cultura científica. Elementos 87, 2012, p. 3-11. Accesible
en www.elementos.buap.mx)
Algunos han dado en tratar de renombrar, reformular o redescubrir el método

científico llamándolo método hipotético-deductivo, para así proporcionarle un
carácter aparentemente novedoso, sin reconocer lo que verdaderamente han
avanzado las ideas sobre la ciencia. Sin embargo, un enunciado como el siguiente
no es más que la descripción del conocido método científico, donde ‘deducción’
hace las veces de ‘teoría’ y ‘verificación’ el de ‘experimento’. Compare el lector: "El
método hipotético-deductivo es el procedimiento o camino que sigue el
investigador para hacer de su actividad una práctica científica. El método
hipotético-deductivo tiene varios pasos esenciales: observación del fenómeno a
estudiar, creación de una hipótesis para explicar dicho fenómeno, deducción de
consecuencias o proposiciones más elementales que la propia hipótesis, y
verificación o comprobación de la verdad de los enunciados deducidos
comparándolos con la experiencia".
Este método obliga al científico a combinar la reflexión racional o momento

racional (la formación de hipótesis y la deducción) con la observación de la
realidad o momento empírico (la observación y la verificación). Tradicionalmente, a
partir de las ideas de Francis Bacon, se consideró que la ciencia partía de la
observación de hechos y que de esa observación repetida de fenómenos
comparables, se extraían por inducción las leyes generales que gobiernan esos
fenómenos. En él se plantea una hipótesis que se puede analizar deductiva o
inductivamente".
Posteriormente Karl Popper (1902-1994) rechaza la posibilidad de elaborar leyes

generales a partir de la inducción y sostuvo que en realidad esas leyes generales
son hipótesis que formula el científico, y que se utiliza el método inductivo de
95
interpolación para, a partir de esas hipótesis de carácter general, elaborar
predicciones de fenómenos individuales.
En esta concepción del método científico es central la falsabilidad de las teorías

científicas (esto es, la posibilidad de ser refutadas por la experimentación). En el
método hipotético deductivo, las teorías científicas nunca pueden considerarse
verdaderas, sino a lo sumo «no refutadas».
Sin embargo, Mario Bunge ha señalado que la falsabilidad, o mejor aún, la

refutabilidad, no puede ser el único sello de la cientificidad porque entonces: a)
todas las teorías falsas deberían considerarse científicas, lo que es absurdo, b) no
se puede exigir refutabilidad directa a las teorías de elevado nivel y c) la
cientificidad supone mucho más que la comprobabilidad. Pone como ejemplos
para a) la astrología, refutada hace siglos sin que nunca fuera científica. Y para b)
el que teorías tales como la teoría general de campos, la de los sistemas lineales,
la teoría general del control y la teoría general de la información, son tan generales
que por sí solas son incomprobables, aunque pueden hacerse indirectamente
comprobables mediante su especificación (Bunge, M. Las pseudociencias, ¡vaya
timo! Editorial Laetoli, Pamplona, España, 2010. P. 184). En vez del criterio de
Popper, Bunge propone 12 condiciones que debe cumplir cualquier campo de
investigación científica fáctica para ser reconocida como tal. Todo campo de
investigación que no cumpla las 12 condiciones es acientífico. Una semiciencia o
protociencia es aquel campo que las satisface de manera aproximada, mientras
que todo campo no científico, pero que se publicita como tal, es pseudocientífico
(Ibidem, pp.130-132).
Note que en lo siguiente se invierte el orden lógico del experimento y la teoría. En

las ciencias factuales es requisito indispensable contrastar la hipótesis con la
realidad (experimento, ensayo) antes de llegar a alguna conclusión.
3.10.2.1. Fases del método hipotético-deductivo
1. Observación
2. Planteamiento de hipótesis
96
3. Deducciones de conclusiones a partir de conocimientos previos
4. Verificación
Los pasos 1 y 4 requieren de la experiencia, es decir, es un proceso empírico;

mientras que los pasos 2 y 3 son racionales. Por esto se puede afirmar que el
método sigue un proceso Inductivo, (en la observación) deductivo, (en el
planteamiento de hipótesis y en sus deducciones) y vuelve a la inducción para su
verificación. En el caso de que todas y cada una de las variables puedan ser
objeto de estudio, el último paso sería una inducción completa que daría paso a
una ley universal. En caso contrario la inducción es incompleta, y por tanto la ley
obtenida sería una ley probabilística.
3.10.3. Método de Razonamiento inductivo
El objeto de estudio de la lógica inductiva es el estudio de las pruebas que

permiten medir la probabilidad inductiva de los argumentos así como de las reglas
para construir argumentos inductivos fuertes. A diferencia del razonamiento
deductivo, en el razonamiento inductivo no existe acuerdo sobre cuando
considerar a un argumento como válido. De este modo, se hace uso de la noción
de "fuerza inductiva", que hace referencia al grado de probabilidad de que una
conclusión sea verdadera cuando sus premisas son verdaderas. Así, un
argumento inductivo es fuerte cuando es altamente improbable que su conclusión
sea falsa si las premisas son verdaderas.42
Tradicionalmente se consideraba (y en muchos casos todavía se considera) que el

razonamiento inductivo es una modalidad del razonamiento que consiste en
obtener conclusiones generales a partir de premisas que contienen datos
particulares o individuales. Por ejemplo, a partir de la observación repetida de
objetos o acontecimientos de la misma índole se establece una conclusión general
para todos los objetos o eventos de dicha naturaleza.43
Sin embargo, esa definición, en el presente y en lógica, ya no está en uso: “Como

ya mencionamos, a veces se expresa la diferencia entre deducción e inducción
42
González Labra (Editora), María José (2012). Psicología del Pensamiento.
43
Diccionario de filosofía de Juan Carlos González García; Jacob Buganza; Julián Velarde L
97
diciendo que la segunda, contrariamente a la primera, “va de lo particular a lo
general”. Si con ello se quiere decir que en un argumento inductivo válido las
premisas son siempre todas afirmaciones particulares y la conclusión es una
afirmación general (esto es, cuantificacional), no es cierto”.44 “A pesar que muchos
diccionarios definen razonamiento inductivo como razonamiento que deriva
principios generales a partir de observaciones específicas, este uso está
obsoleto”.45
Lo anterior, es dado que es posible tanto enunciar proposiciones inductivas en

forma "deductiva" como de manera que no corresponden formalmente a lo que
clásicamente se consideraba razonamiento inductivo.
Consecuentemente la definición actual de inducción es más compleja e incluye

tipos de razonamiento que van más allá de la simple progresión de lo particular a
lo general. Esos tipos de razonamiento pueden ser descritos como aquellos que
indican algún tipo de apoyo o aval a la conclusión, pero no una Implicación lógica.
En otras palabras, son razonamientos que sugieren verdad, pero no la aseguran.
Más bien, las premisas de un razonamiento lógico inductivo indican cierto grado
de apoyo (probabilidad inductiva) para la conclusión, pero no implicación.46
Consecuentemente, en el presente, “mucho de la inferencia sintética o contingente

ahora se toma como inductiva, algunas autoridades van tan lejos como a
considerar toda inferencia contingente como inductiva. “47 (ver Juicios analíticos y
sintéticos). (y ver Peirce en "La inducción como probabilidad" más abajo)
Muchos consideran que, a pesar que la inducción no puede ser validada (ver
Problema de la inducción y más abajo), dado que expande nuestro conocimiento
del mundo real, es parte indispensable del método científico: "La gran ventaja de
la inducción no es que se puede justificar o validar, como puede la deducción,
pero que, con cuidado y un poco de suerte, puede corregirse, como otros métodos
no lo hacen." (ver más abajo).
44
José A. Díez, C. Ulises Moulines (1997- 2008)
45
Internet Encyclopedia of Philosophy
46
James Hawthorne (2011)
47
John Vickers (2010) en Standford Enciclopedia of Philosophy: The Problem of Induction
98
3.11. TÉCNICAS
3.11.1. La técnica de la entrevista
La entrevista según todos los psicólogos, es el instrumento más empleado en

todas las ramas de la psicología aplicada. Hay de muchos tipos: entrevista de
evaluación, psicología laboral, investigación social, Psicología clínica...Los
conductistas en un tiempo no admitieron la entrevista, aunque en los últimos años
tuvieron que reconocer su importancia.(años 50). La paradoja está, en que es el
estudio de investigación empírico sobre el instrumento que más se utiliza y que
menos se conoce debido a su complejidad y diversidad. Investigación programas
de formación (1986) en ellas se destacan tres elementos básicos:
1. Formación teórica que permita saber analizar la situación donde se realiza la

entrevista. Los problemas metodológicos se pueden evitar al tener en cuenta el
marco teórico en el que se inscriben los objetos a analizar. En razón de las metas
planteadas la entrevista se realizará de forma estructurada o no estructurada y el
método a seguir será más o menos directivo.
2. Análisis y discusión de entrevistas grabadas.
3. Ejercicios de los conocimientos adquiridos mediante juego de roles y mediante

entrevistas auténticas que posteriormente serán analizadas y supervisadas.
3.11.1.1. Definición de entrevista
La entrevista es una conversación con un propósito (metas).Una entrevista es una

conversación donde entran en contacto dos personas, este contacto debe al
menos ser consciente para el entrevistador y abarca tanto interrelaciones verbales
como no verbales: " No es un encuentro entre iguales ya que está basada en la
distinción de roles entre dos participantes; uno sobre el que pesa la mayor
responsabilidad al conducir la entrevista, (entrevistador) y el entrevistado.
Aunque el entrevistador pueda haber solicitado la entrevista como consecuencia

de sus propias motivaciones o necesidades, de ese modo introduce sus objetivos
99
personales dentro del intercambio, las metas de la entrevista con un sistema están
determinadas por el entrevistador.
Los objetivos más frecuentes de la entrevista son:
-Extraer el máximo de información del entrevistado (entrevista laboral).
-Proporcionar información al entrevistado (en orientación).
-Evaluación del entrevistador o epidemiología
-Influir o modificar el concepto del entrevistado. (Entrevista terapéutica)
La entrevista terapéutica es una técnica empleada en Psicoterapia, cuyo objetivo

consiste en observar y analizar las condiciones del paciente para después integrar
la información obtenida de cara al tratamiento de sus dificultades psicológicas.
Puede definirse como un tipo peculiar de interrelación cuyo acontecer se fragua y

desarrolla a través de la comunicación que se establece entre paciente y
terapeuta.
Las peculiaridades que adopta esta técnica difieren considerablemente en función

de:
-Las condiciones en que se desarrolla
-Las condiciones demográficas e institucionales
-El marco teórico en el que se sitúe cada uno.
3.11.1.2. Concepto de entrevista
La ESTRUCTURA es el grado hasta el cual el entrevistador determina el

contenido de la entrevista y el desarrollo de la misma.
La estructura puede ser (situada en un continuo):
DIRECTIVIDAD _________________________NO DIRECTIVIDAD
100
Las entrevistas serán más o menos directivas dependiendo de la meta que se
propongan.
ESTRUCTURAS DIRECTIVAS. El formato se parece a un interrogatorio informal

(rígido, suelen ser cuestionarios).El objetivo es conseguir el máximo de
información.
ESTRUCTURAS NO DIRECTIVAS. El objetivo es conseguir que el cliente se

sienta lo más cómodo posible y espontáneo y lleve a cabo una autoexploración de
cualquier tema. El investigador interfiere lo mínimo posible, adaptándose a lo que
el investigador plantea. En una entrevista real se da cualquier punto intermedio
(historial) y a este tipo se le llaman entrevistas guiadas.
La estructura puede variar a lo largo de la entrevista y esta dependerá del marco

teórico (Los conductistas suelen ser más directivos que los fenomenalistas)
La entrevista es dinámica, fluida, es compleja pero cuando se intenta teorizar se

necesita sesgar y se habla de tres
3.11.1.3. Etapas de entrevista
1. Etapa de contacto. Crear un "rapport" y preocuparse para que las condiciones

sean las más adecuadas.
2. Llevar a cabo el trabajo que nos proponemos dependiendo de la entrevista.
3. Etapa de despedida y cierre. Crear un espacio de tiempo para resumir todo lo

que ha sucedido en la entrevista, aclarar dudas o planificar futuras entrevistas.
3.11.2. La técnica de la encuesta y el cuestionario
Conocemos a la metodología como la ciencia que nos enseña a dirigir los

procesos de forma óptima para alcanzar los resultados con mayor eficiencia y
eficacia. Ella nos ofrece también los métodos y procedimientos para realizar la
investigación científica con la calidad requerida.
101
El logro de toda investigación científica está dado por la solución de un problema
científico, en alcanzar los objetivos y en la comprobación de la hipótesis, por lo
que el éxito de todo lo anterior expuesto depende de la selección de los métodos,
los procedimientos y técnicas de la investigación de forma rigurosa.
En toda investigación científica los métodos son el hilo conductor entre el

investigador y el objeto de estudio es por ello que hay que poner el mayor énfasis
en la selección de los métodos propios de la investigación y su organización.
a. El método: es el camino por donde transitamos para lograr una estructura

lógica del proceso, de forma tal que podamos incidir en el objeto para
transformarlo.
b. Los procedimientos: son los componentes del método que se adecuan a las
condiciones específicas en que se va a desarrollar el método, o sea, es el modo
de ejecutar las operaciones.
c. La técnica: es una operación del método que se relaciona con el medio y que
se usa en la investigación para recolectar, procesar y analizar la información sobre
el objeto de estudio.
Los métodos de la investigación científica se desglosan de la siguiente forma:
Métodos teóricos, métodos empíricos y los métodos estadísticos matemáticos. Los

mismos están siempre relacionados de forma dialéctica, o sea, uno no puede
desarrollarse sin el otro en cualquier proceso de investigación.
d. Los métodos teóricos: Nos permiten desarrollar una teoría sobre el objeto de
estudio, o sea, como podemos hacer una abstracción de las características y
relaciones del objeto que nos expliquen los fenómenos que se investigan.
e. Los métodos empíricos: Incluyen una serie de procedimientos prácticos sobre

el objeto, que nos permiten revelar las características fundamentales y las
relaciones esenciales de este, que son accesibles a la contemplación sensorial, lo
cual se fundamenta en la experiencia y se expresa en un lenguaje determinado.
102
f. El método estadístico matemático: Nos permite a través de tablas y cálculos
matemáticos medir los resultados de los datos recopilados por medio de los
instrumentales aplicados.
En cualquier investigación científica, en la etapa de recolección de datos, se usa

un grupo de técnicas e instrumentales a través de los cuáles podemos obtener y
medir la información recopilada sobre un grupo de parámetros que queremos
determinar, partiendo del diseño de la investigación, la muestra adecuada en
concordancia con el problema científico a resolver y la hipótesis planteada,
teniendo muy en cuenta las variables seleccionadas.
Existen varias técnicas e instrumentales para la recopilación de datos que se usan

en las investigaciones científicas. En este trabajo específicamente nos referiremos
a la técnica de la encuesta y el cuestionario como instrumental.
3.11.2.1. Desarrollo
La Encuesta es una técnica de recogida de información por medio de preguntas

escritas organizadas en un cuestionario impreso.
Se emplea para investigar hechos o fenómenos de forma general y no particular.
La encuesta a diferencia de la entrevista, el encuestado lee previamente el

cuestionario y lo responde por escrito, sin la intervención directa de persona
alguna de las que colaboran en la investigación.
La encuesta, una vez confeccionado el cuestionario no requiere de personal

calificado a la hora de hacerla llegar al encuestado. A diferencia de la entrevista la
encuesta cuenta con una estructura lógica, rígida que permanece inalterable a lo
largo de todo el proceso investigativo. Las repuestas se recogen de modo especial
y se determinan del mismo modo las posibles variantes de respuestas estándares,
lo que facilita la evaluación de los resultados por métodos estadísticos.
Según su estructura las encuestas pueden ser:
103
 Estandarizadas
 Semi estandarizadas
 No estandarizadas
 Según las vías de obtención de la información:
 Directa: Se aplica directa al sujeto.
 Indirecta: Se aplica por correo, teléfono, etc.
a. Pasos fundamentales al elaborar una encuesta:
Determinación de los objetivos específicos.
Selección del tipo de encuesta.
Diseño del cuestionario.
Pilotaje del cuestionario.
Condiciones indispensables para su realización.
Aplicación del instrumento a la muestra.
Evaluación de la muestra recogida.
b. Aspectos que debemos conocer sobre el diseño del cuestionario:
La consigna o demanda de cooperación (debe ser honesto, directo y concreto)
Preguntas a hacer según su función:
1. De contenido: Está relacionada con el objeto de investigación.
2. De control: Comprueba la consistencia y veracidad de la respuesta del sujeto.
104
3. De filtro: Permite al investigador saber si el sujeto conoce o no acerca de la
temática.
4. De colchón: Es para bajar el nivel de ansiedad, tranquilidad y confianza. Se

hace al principio.
5. Según el grado de libertad:
6. Abierta: Es cuando la respuesta no da límites.
7. Cerrada: Respuesta limitada (Sí o No) puede ser dicotómica o politómica.
8. Según el grado de coincidencia entre objetivo y contenido:
9. Directa: Coincide el objetivo de la pregunta con el objetivo.
10. Indirecta: No se corresponde el objetivo con el contenido.
11. Según la correspondencia de la realidad concreta del sujeto.
12. Condicional: Se indaga opiniones del sujeto respecto a las situaciones que
manejaría el contenido progresivo.
13. Incondicional: Se refiere a situaciones reales que vive el experimento del sujeto
y a sus ideas, opiniones, etc.
Para la secuencia de las preguntas se debe utilizar la teoría del embudo, ir de lo

más simple a lo más complejo.
c. ¿Qué es un cuestionario?
El cuestionario es uno de los instrumentos que sirven de guía o ayuda para

obtener la información deseada, sobre todo a escala masiva.
El mismo está destinado a obtener respuestas a las preguntas previamente

elaboradas que son significativas para la investigación social que se realiza y se
105
aplica al universo, o a muestra, utilizando para ello un formulario impreso, que los
individuos responden por sí mismos.
Mediante el cuestionario se aspira a conocer las opiniones, las actitudes, valores y

hechos respecto a un grupo de personas en específico.
El cuestionario es en fin un instrumento básico de observación en la encuesta y en

la entrevista; en este se formulan unas series de preguntas que permiten medir
una o más variables, posibilitando observar los hechos a través de la valoración
que hace de los mismos el encuestado o el entrevistado, limitándose la
investigación a las valoraciones subjetivas de este.
No obstante, a que este instrumento se limita a la observación simple del

entrevistador o del encuestado, puede ser masivamente aplicado a comunidades y
otros grupos sociales; pudiéndose obtener información sobre una amplia gama de
aspectos o problemas definidos.
La estructura y el carácter del cuestionario lo definen el contenido y la forma de las

preguntas que se les formula a los interrogados.
3.11.2.2. Algunos procedimientos para aplicar el cuestionario
Asegure las condiciones indispensables del local. Preséntese oportunamente.
Explique los propósitos del cuestionario y atienda dudas y objeciones.
Distribuya los cuestionarios y otros aseguramientos requeridos.
Lea detenidamente las instrucciones y de un ejemplo si resulta pertinente.
Pregunte a los sujetos si han comprendido las indicaciones.
Supervisa el trabajo del grupo y auxilia quienes lo requieran.
Recoja los cuestionarios y de las gracias al grupo.
106
a. Algunas recomendaciones para aplicar un cuestionario
Plantee preguntas que estén al nivel de conocimientos de los sujetos.
No utilice un lenguaje rebuscado; presente preguntas directas y sin términos de

difícil comprensión.
Auxilie a quienes tienen dificultades para escribir sus respuestas.
Estimule a los sujetos que no se enfrentan con entusiasmo al cuestionario.
Revise los cuestionarios a la hora de recogerlos y pídale a las personas que

omitieron datos que esperen durante unos minutos más.
No debe ser extenso en cuanto a cantidad de preguntas.
3.12. ARQUITECTURA DE SOFTWARE
En los inicios de la informática, la programación se consideraba un arte y se

desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las
personas, pero con el tiempo se han ido descubriendo y desarrollando formas y
guías generales, con base a las cuales se puedan resolver los problemas. A estas,
se les ha denominado Arquitectura de Software, porque, a semejanza de los
planos de un edificio o construcción, estas indican la estructura, funcionamiento e
interacción entre las partes del software. En el libro "An introduction to Software
Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de
diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de
datos de la computación; el diseño y especificación de la estructura global del
sistema es un nuevo tipo de problema".
3.12.1. Arquitectura
 La Arquitectura del Software es el diseño de más alto nivel de la estructura de

un sistema.
 Una Arquitectura de Software, también denominada Arquitectura lógica,

consiste en un conjunto de patrones y abstracciones coherentes que
proporcionan el marco
107
 Una arquitectura de software se selecciona y diseña con base en objetivos y
restricciones. Los objetivos son aquellos prefijados para el sistema de
información, pero no solamente los de tipo funcional, también otros objetivos
como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros
sistemas de información. Las restricciones son aquellas limitaciones derivadas
de las tecnologías disponibles para implementar sistemas de información.
Unas arquitecturas son más recomendables de implementar con ciertas
tecnologías mientras que otras tecnologías no son aptas para determinadas
arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software
de tres capas para implementar sistemas en tiempo real.
 La arquitectura de software define, de manera abstracta, los componentes que

llevan a cabo alguna tarea de computación, sus interfaces y la comunicación
entre ellos. Toda arquitectura debe ser implementable en una arquitectura
física, que consiste simplemente en determinar qué computadora tendrá
asignada cada tarea.
La arquitectura de software, tiene que ver con el diseño y la implementación de

estructuras de software de alto nivel. Es el resultado de ensamblar un cierto
número de elementos arquitectónicos de forma adecuada para satisfacer la mayor
funcionalidad y requerimientos de desempeño de un sistema, así como
requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y
disponibilidad. [Kruchten, Philippe]
3.12.2. Breve reseña histórica
En los años 1960 ya se acercaba el concepto de arquitectura de software en los

círculos de investigación (por ejemplo, por Edsger Dijkstra). No obstante, toma
popularidad en los años 1990 tras reconocerse la denominada crisis del software y
como tema de interés de la incipiente disciplina de la ingeniería del software.
108
3.12.3. Modelos o vistas
Toda arquitectura de software debe describir diversos aspectos del software.

Generalmente, cada uno de estos aspectos se describe de una manera más
comprensible si se utilizan distintos modelos o vistas. Es importante destacar que
cada uno de ellos constituye una descripción parcial de una misma arquitectura y
es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas
las vistas deben ser coherentes entre sí, evidente dado que describen la misma
cosa.
Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos

para describir una arquitectura. No obstante, existen al menos tres vistas
absolutamente fundamentales en cualquier arquitectura:
 La visión estática: describe qué componentes tiene la arquitectura.
 La visión funcional: describe qué hace cada componente.
 La visión dinámica: describe cómo se comportan los componentes a lo largo

del tiempo y cómo interactúan entre sí.
Las vistas o modelos de una arquitectura de software pueden expresarse

mediante uno o varios lenguajes. El más obvio es el lenguaje natural, pero existen
otros lenguajes tales como los diagramas de estado, los diagramas de flujo de
datos, etc. Estos lenguajes son apropiados únicamente para un modelo o vista.
Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling
Language, lenguaje unificado de modelado) como lenguaje único para todos los
modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser
capaz de describir determinadas restricciones de un sistema de información (o
expresarlas de manera incomprensible).
3.12.4. Arquitecturas más comunes
Generalmente, no es necesario inventar una nueva arquitectura de software para

cada sistema de información. Lo habitual es adoptar una arquitectura conocida en
109
función de sus ventajas e inconvenientes para cada caso en concreto. Así, las
arquitecturas más universales son:
 Monolítica. Donde el software se estructura en grupos funcionales muy

acoplados.
 Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes

independientes pero sin reparto claro de funciones.
 Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor

donde la carga se divide en tres partes (o capas) con un reparto claro de
funciones: una capa para la presentación (interfaz de usuario), otra para el
cálculo (donde se encuentra modelado el negocio) y otra para el
almacenamiento (persistencia). Una capa solamente tiene relación con la
siguiente.
Otras arquitecturas afines menos conocidas son:
 Modelo Vista Controlador.
 En pipeline.
 Entre pares.
 En pizarra.
 Orientada a servicios.
 Dirigida por eventos.
 Máquinas virtuales
3.13. LENGUAJE UNIFICADO DE MODELADO
Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified
Modeling Language) es el lenguaje de modelado de sistemas de software más
conocido y utilizado en la actualidad; está respaldado por el OMG (Object
110
Management Group). Es un lenguaje gráfico para visualizar, especificar, construir
y documentar un sistema. UML ofrece un estándar para describir un "plano" del
sistema (modelo), incluyendo aspectos conceptuales tales como procesos de
negocio, funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programación, esquemas de bases de datos y compuestos
reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o
para describir métodos o procesos. Se utiliza para definir un sistema, para detallar
los artefactos en el sistema y para documentar y construir. En otras palabras, es el
lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar

soporte a una metodología de desarrollo de software (tal como el Proceso
Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o
proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa

Lenguaje Unificado de Modelado, no es programación, solo se diagrama la
realidad de una utilización en un requerimiento. Mientras que, programación
estructurada, es una forma de programar como lo es la orientación a objetos, la
programación orientada a objetos viene siendo un complemento perfecto de UML,
pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes
aspectos de las entidades representadas.
3.13.1. Estandarización de UML
Desde el año 2005, UML es un estándar aprobado por la ISO como ISO/IEC
19501:2005 Information technology — Open Distributed Processing — Unified
Modeling Language (UML) Versión 1.4.2.
111
3.13.2. Tipos de Diagramas de UML
3.13.2.1. Estructura
Acá se presenta una lista de los diferentes tipos de diagramas UML’s que se
conocen:
 Diagrama de clases
 Diagrama de objetos
 Diagrama de componentes
 Diagrama de estructura compuesta
 Diagrama de paquetes
 Diagrama de despliegue
3.13.2.2. Comportamiento
La clasificación de los diagramas comienza por el caso de uso, continuando con la

de actividades y finalizando con la de estados como se muestra en la siguiente
lista:
 Diagrama de casos de uso
 Diagrama de actividades
 Diagrama de estado
3.13.2.3. Interacción
En la interacción de los diagramas UML se las utiliza para trabajos más complejos
y completos donde se trata de demostrar que el sistema está desarrollado de
forma correcta utilizando los siguientes diagramas de la lista
 Diagrama de secuencia
112
 Diagrama de colaboración UML 1.X / Diagrama de comunicación UML 2.0
 Diagrama de tiempo
 Diagrama de interacción
3.13.3. Críticas a UML
 Entorno de desarrollo integrado
 Herramienta CASE
 Técnica de Modelado a Objetos
 Programación orientada a objetos
 XMI, un formato estándar basado en XML para el intercambio de modelos

UML.
 OCL, Lenguaje de especificación para los diferentes modelos en UML.
 Webml, Metodología para el diseño de Sistemas de Información Web.
 Categoría: Herramientas UML
3.13.4. Historia
3.13.4.1. Antes de UML 1.x
Después de que la Rational Software Corporation contratara a James Rumbaugh

de General Electric en 1994, la compañía se convirtió en la fuente de los dos
esquemas de modelado orientado a objetos más populares de la época: el OMT
(Object-modeling technique) de Rumbaugh, que era mejor para análisis orientado
a objetos, y el Método Booch de Grady Booch, que era mejor para el diseño
orientado a objetos. Poco después se les unió Ivar Jacobson, el creador del
método de ingenieríá de software orientado a objetos. Jacobson se unió a Rational
en 1995 después de que su compañía, Objectory AB, fuera comprada por
113
Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque
se sabía de sus constantes discusiones sobre las prácticas metodológicas.
En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba

alentando la adopción de la tecnología de objetos, y para orientarse hacia un
método unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje
Unificado de Modelado abierto. Se consultó con representantes de compañías
competidoras en el área de la tecnología de objetos durante la OOPSLA '96;
eligieron cajas para representar clases en lugar de la notación de Booch que
utilizaba símbolos de nubes.
Bajo la dirección técnica de los Tres Amigos fue organizado un consorcio

internacional llamado UML Partners en 1996 para completar las especificaciones
del Lenguaje Unificado de Modelado (UML), y para proponerlo como una
respuesta al OMG RFP. El borrador de la especificación UML 1.0 de UML Partners
fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML
Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y
administrada por Ed Eykholt, para finalizar las semánticas de la especificación y
para integrarla con otros esfuerzos de estandarización. El resultado de este
trabajo, el UML 1.1, fue presentado ante la OMG en agosto de 1997 y adoptado
por la OMG en noviembre de 1997.
3.13.4.2. UML 1.x
Como notación de modelado, la influencia de la OMT domina UML (por ejemplo el

uso de rectángulos para clases y objetos). Aunque se quitó la notación de "nubes"
de Booch, si se adoptó la capacidad de Booch para especificar detalles de diseño
en los niveles inferiores. La notación de Casos de Uso del Objectory y la notación
de componentes de Booch fueron integradas al resto de la notación, pero la
integración semántica era relativamente débil en UML 1.1, y no se arregló
realmente hasta la revisión mayor de UML 2.0.
114
Conceptos de muchos otros métodos OO fueron integrados superficialmente en
UML con el propósito de hacerlo compatible con todos los métodos OO. Además
el grupo tomó en cuenta muchos otros métodos de la época, con el objetivo de
asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como
resultado, UML es útil en una variedad de problemas de ingeniería, desde
procesos sencillos y aplicaciones de un sólo usuario a sistemas concurrentes y
distribuidos.
El Lenguaje de Modelado Unificado es un estándar internacional:
ISO / IEC 19501:2005 Tecnología de la información - Procesamiento distribuido

abierto - Lenguaje de Modelado Unificado (UML) Versión 1.4.2
3.13.4.3. UML 2.x
UML ha madurado considerablemente desde UML 1.1. Varias revisiones menores

(UML 1.3, 1.4 y 1.5) han corregido defectos y errores de la primera versión de
UML. A estas le ha seguido la revisión mayor UML 2.0 que fue adoptada por el
OMG en 2005.
Aunque UML 2.1 nunca fue lanzado como una especificación formal, las versiones
2.1.1 y 2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009.
UML 2.3 fue lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado
oficialmente en agosto de 2011. UML 2.5 fue lanzado en octubre de 2012 como
una versión "En proceso" y todavía tiene que ser formalmente liberada.
3.14. SISTEMA DE GESTIÓN DE BASES DE DATOS
Un sistema de gestión de bases de datos (SGBD) es un conjunto de programas

que permiten el almacenamiento, modificación y extracción de la información en
una base de datos, además de proporcionar herramientas para añadir, borrar,
modificar y analizar los datos. Los usuarios pueden acceder a la información
usando herramientas específicas de interrogación y de generación de informes, o
bien mediante aplicaciones al efecto Los SGBD también proporcionan métodos
115
para mantener la integridad de los datos, para administrar el acceso de usuarios a
los datos y para recuperar la información si el sistema se corrompe. Permite
presentar la información de la base de datos en variados formatos. La mayoría de
los SGBD incluyen un generador de informes. También puede incluir un módulo
gráfico que permita presentar la información con gráficos y tablas.
Hay muchos tipos de SGBD distintos según manejen los datos y muchos tamaños
distintos según funcionen sobre ordenadores personales y con poca memoria a
grandes sistemas que funcionan en mainframes con sistemas de almacenamiento
especiales.
Generalmente se accede a los datos mediante lenguajes de interrogación,

lenguajes de alto nivel que simplifican la tarea de construir las aplicaciones.
También simplifican la interrogación y la presentación de la información. Un SGBD
permite controlar el acceso a los datos, asegurar su integridad, gestionar el acceso
concurrente a ellos, recuperar los datos tras un fallo del sistema y hacer copias de
seguridad. Las bases de datos y los sistemas para su gestión son esenciales para
cualquier área de negocio, y deben ser gestionados con esmero.
3.14.1. Introducción
Las Bases de Datos generalmente funcionan en ordenadores dedicados. Por las

prestaciones requeridas, generalmente funcionan en ordenadores multi-
procesador con abundante memoria. Para el almacenaje de los datos puede
contar con sistemas de disco propio (DAS), puede conectarse a una red de
almacenamiento (SAN) o conectarse a un sistema de almacenamiento en red
(NAS). Existen aceleradores hardware, usados en grandes sistema de proceso de
transacciones. Los SGBD se encuentran en el corazón de toda aplicación que
maneje datos. Los SGBD se basan en sistemas operativos estándar para efectuar
dichas funciones.
3.14.2. Historia
116
Las Bases de Datos han estado en uso desde los primeros días de los
ordenadores electrónicos. A diferencia de los sistemas modernos, que se pueden
aplicar a datos y necesidades muy diferentes, la mayor parte de los sistemas
originales estaban enfocados a bases de datos específicas y pensadas para ganar
velocidad a costa de perder flexibilidad. Los SGBD originales sólo estaban a
disposición de las grandes organizaciones que podían disponer de los complejos
ordenadores necesarios.
3.14.2.1. Sistemas de navegación de 1960
Según los ordenadores fueron ganando velocidad y capacidad, aparecieron

sistemas de bases de datos de propósito general; a mediados de 1960 ya habían
algunos sistemas en uso. Apareció el interés en obtener un estándar y Charles
Bachman -autor de uno de los primeros productos, el Integrated Data Store (IDS)-
fundó el "Database Task Group" dentro de CODASYL, el grupo responsable de la
creación y estandarización de COBOL. En 1971 publicaron su estándar, que pasó
a ser conocido como la "aproximación CODASYL", y en breve aparecieron
algunos productos basados en esta línea.
La estrategia de CODASYL estaba basada en la navegación manual por un

conjunto de datos enlazados en red. Cuando se arrancaba la base de datos, el
programa devolvía un enlace al primer registro de la base de datos, el cual a su
vez contenía punteros a otros datos. Para encontrar un registro concreto el
programador debía ir siguiendo punteros hasta llegar al registro buscado.
Para responder a preguntas sencillas como "buscar todas las personas en Japón"
el programa debía recorrer todos los datos para escoger los registros correctos.
Esencialmente no existían los conceptos "buscar" ni "encontrar" que sería
inaceptable hoy en día, pero que en los tiempos en que los datos se guardaban en
cintas no era viable llevarlos a la práctica.
Se encontraron soluciones a muchos de esos problemas. El fabricante Prime creó

un SGBD ajustado a CODASYL basado en árboles binarios que atajaba la
117
navegación de registro en registro proveyendo caminos alternativos de acceso.
También aportaba un lenguaje de interrogación muy claro. De hecho no hay razón
para no poder aplicar los conceptos de normalización a bases de datos
CODASYL, pero en último término CODASYL resultaba muy complejo y requería
de mucho esfuerzo y práctica para producir una aplicación útil.
IBM también tenía su SGBD propio en 1968, conocido como IMS. Se trataba de un
software desarrollado para el programa Apolo sobre System/360. IMS tenía
conceptos similares a CODASYL, pero usaba una jerarquía estricta de ordenación
de los datos, frente a la estructura en red de CODASYL. Ambos conceptos fueron
englobados posteriormente en el concepto de Bases de Datos de navegación
debido al modo de acceso a los datos, de hecho Bachman recibió al premio Turing
en 1973 por su ponencia "El programador como navegador".
3.14.2.2. Sistemas relacionales de 1970
Edgar Codd trabajaba en IBM, en una de esas oficinas periféricas que estaba
dedicada principalmente al desarrollo de discos duros. Estaba descontento con el
modelo de navegación CODASYL, principalmente con la falta de operación de
búsqueda. En 1970 escribió algunos artículos en los que perfilaba una nueva
aproximación que culminó en el documento "A Relational Model of Data for Large
Shared Data Banks".
En este artículo descubrió un nuevo sistema para almacenar y trabajar con

grandes bases de datos. En vez de almacenar registros de tipo arbitrario en una
lista encadenada como en CODASYL, la idea de Codd era usar una "tabla" de
registros de tamaño fijo. Una lista encadenada tiene muy poca eficiencia al
almacenar datos dispersos donde algunos de los datos de un registro pueden
dejarse en blanco. El modelo relacional resuelve esto dividiendo los datos en una
serie de tablas -o relaciones- normalizadas, en las que los elementos optativos
han sido extraídos de la tabla principal para que ocupen espacio sólo si lo
necesitan. En este modelo relacional los registros relacionados se enlazan con
una "clave".
118
Un uso común de las Bases De Datos puede mantener una agenda de usuarios,
su nombre, información de acceso, dirección y teléfono. En la solución de
navegación todos esos datos estaría localizados en un solo registro, y las
características no usadas simplemente no estarían en la base de datos. En la
solución relacional, los datos estarían normalizados en una tabla de usuario, una
de teléfono y una de dirección, en la que serían añadidos registros si tuviéramos
que incorporar teléfono y dirección.
Reconciliar toda la información es la clave de este sistema. En el modelo

relacional, una parte de la información se usa como clave, identificando de manera
biunívoca un registro concreto. Cuando se recopila información acerca de un
usuario, se accederá a la información de las tablas optativas buscando mediante
esa clave. Por ejemplo si el nombre de usuario es único, la dirección y número de
teléfono de ese usuario será guardada con el nombre de usuario como clave. La
recopilación de esta información en un solo registro es algo para lo que los
lenguajes tradicionales no están pensados.
Así como el enfoque de navegación requiere programas que realicen bucles para
recolectar registros, el enfoque relacional también los requerirá. La solución de
Codd para los necesarios bucles se basa en un lenguaje orientado a conjuntos,
una sugerencia que más tarde cristalizaría en el ubicuo SQL. Planteó el uso de
una rama del álgebra llamada cálculo de duplas, y demostró que con ella se
podrían realizar todas las operaciones típicas sobre una base de datos, además
de extraer conjuntos de datos de una forma sencilla.
El artículo de Codd cayó en manos de dos personas en Berkeley, Eugene Wong y

Michael Stonebraker. Ellos comenzaron un proyecto llamado INGRES con fondos
asignados a un proyecto de base de datos geográfica programada por los
estudiantes. Comenzando en 1973, INGRES produjo sus primeras versiones de
prueba que estuvieron listas para uso general en 1979. INGRES era muy similar a
System R de IBM en varios aspectos, incluyendo un lenguaje para acceso a los
datos, conocido como QUEL. Con el paso del tiempo, INGRES adopto el estándar
SQL.
119
IBM realizó una implementación de prueba del modelo relacional -PRTV- y una de
producción -Business System 12- ambas descontinuadas. Honeywell escribió
MRDS para Multics, y aparecen también dos nuevas implementaciones: Alphora
Dataphor y Rel. La mayoría de las demás implementaciones de SGBD llamados
relacionales son en realidad SGBD SQL.
En la década de 1970, la Universidad de Michigan comenzó el desarrollo del

MICRO Information Management System basado en el modelo teórico de datos de
D.L. Childs. Micro fue utilizado para gestionar gran cantidad de datos en el
Departamento de trabajo del gobierno US. Corría en mainframe usando Michigan
Terminal System. Estuvo en producción hasta 1998. [Base de datos relacional]
3.14.2.3. Sistemas SQL de finales de la década 1970
IBM comenzó a trabajar a principios de 1970 en un prototipo lejanamente basado

en los conceptos de Codd llamándolo System R. La primera versión estuvo lista en
1974/5, y comenzó así el trabajo en sistemas multi-tabla, en los que los datos
podían disgregarse de modo que toda la información de un registro (alguna de la
cual es opcional) no tiene que estar almacenada en un único trozo grande. Las
versiones multi-usuario siguientes fueron aprobadas por los usuarios en 1978 y
1979, tiempo por el que un lenguaje SQL había sido estandarizado. Las ideas de
Codd se revelaron como operativas y superiores a las de CODASYL, lanzando a
IBM al desarrollo de una verdadera versión de producción de System R, conocido
como SQL/DS, y posteriormente como Database 2 (DB2).
Muchos de los técnicos de INGRES estaban seguros del éxito comercial del
sistema, y formaron sus propias compañías para comercializar el desarrollo pero
con un interfaz SQL. Sybase, Informix, NonStop SQL y la misma INGRES se
vendían como derivados del INGRES original en los años 1980. Incluso el SQL
Server de Microsoft está basado en Sybase, y por consiguiente en INGRES. Sólo
Larry Ellison -el fundador de Oracle- comenzó un nuevo camino basado en el
artículo de IBM sobre System R, y aventajó a IBM sacando al mercado su primera
versión en 1978.
120
Stonebraker aplicó las lecciones de INGRES al desarrollo de una nueva base de
datos -Postgres- conocida ahora como PostgreSQL. PostgreSQL se utiliza para
muchas aplicaciones críticas (los registros de dominios .org y .info lo usan para su
almacenamiento primario, así como grandes compañías e instituciones
financieras).
En Suecia, el artículo de Codd generó la base de datos Mimer SQL en la

universidad de Uppsala. En 1984 este proyecto se consolidó en una compañía
independiente. A principios de 1980, Mimer introdujo la gestión de transacciones
para dar robustez a las aplicaciones, una idea que fue recogida en muchos otros
SGBD. [SQL]
3.14.2.4. Sistemas orientados a objetos de 1980
Durante la década de 1980 el auge de la programación orientada a objetos influyó

en el modo de manejar la información de las bases de datos. Programadores y
diseñadores comenzaron a tratar los datos en las bases de datos como objetos.
Esto quiere decir que si los datos de una persona están en la base de datos, los
atributos de la persona como dirección, teléfono y edad se consideran que
pertenecen a la persona, no son datos extraños. Esto permite establecer
relaciones entre objetos y atributos, más que entre campos individuales.
Otro gran foco de atención durante la década fue el incremento de velocidad y

fiabilidad en el acceso. En 1989, dos profesores de la Universidad de Wisconsin
publicaron un artículo en una conferencia ACM en el que exponían sus métodos
para mejorar las prestaciones de las bases de datos. La idea consistía en replicar
la información importante -y más solicitada- en una base de datos temporal de
pequeño tamaño con enlaces a la base de datos principal. Esto implicaba que se
podía buscar mucho más rápido en la base de datos pequeña que en la grande.
Su mejora de prestaciones llevó a la introducción de la indización, incorporada en
la totalidad de los SGBD. [Base de datos orientada a objetos]
121
3.14.2.5. Sistemas NoSQL de 2000
El siglo XXI trajo una nueva tendencia en las bases de datos: el NoSQL. Esta
tendencia introducía una línea no relacional significativamente diferente de las
clásicas. No requieren por lo general esquemas fijos, evitan las operaciones join
almacenando datos denormalizados y están diseñadas para escalar
horizontalmente. La mayor parte de ellas pueden clasificarse como almacenes
clave-valor o bases de datos orientadas a documentos.
Recientemente ha habido una gran demanda de bases de datos distribuidas con

tolerancia a particiones, pero de acuerdo con el teorema CAP no es posible
conseguir un sistema distribuido que simultáneamente proporcione consistencia,
disponibilidad y tolerancia al particionado. Un sistema distribuido puede satisfacer
sólo dos de las tres restricciones a la vez. Por dicha razón muchas de las bases
de datos NoSQL usan la llamada consistencia eventual para proporcionar
disponibilidad y tolerancia al particionado, con un nivel máximo de consistencia de
datos. Entre las aplicaciones más populares encontramos MongoDB,
MemcacheDB, Redis, CouchDB, Hazelcast, Apache Cassandra y HBase, todas
ellas de código abierto. [NoSQL]
3.14.2.6. Sistemas XML 2010
Las Bases de Datos XML forman un subconjunto de las Bases de Datos NoSQL.
Todas ellas usan el formato de almacenamiento XML, que está abierto, legible por
humanos y máquinas y ampliamente usado para interoperabilidad.
En esta categoría encontramos: BaseX, eXist, MarkLogic Server,

MonetDB/XQuery, Sedna.
3.14.3. Componentes
 El motor de la base de datos acepta peticiones lógicas de los otros

subsistemas del SGBD, las convierte en su equivalente físico y accede a la
base de datos y diccionario de datos en el dispositivo de almacenamiento.
122
 El subsistema de definición de datos ayuda a crear y mantener el
diccionario de datos y define la estructura del fichero que soporta la base de
datos.
 El subsistema de manipulación de datos ayuda al usuario a añadir, cambiar

y borrar información de la base de datos y la interroga para extraer
información. El subsistema de manipulación de datos suele ser el interfaz
principal del usuario con la base de datos. Permite al usuario especificar sus
requisitos de la información desde un punto de vista lógico.
 El subsistema de generación de aplicaciones contiene utilidades para

ayudar a los usuarios en el desarrollo de aplicaciones. Usualmente
proporciona pantallas de entrada de datos, lenguajes de programación e
interfaces.
 El subsistema de administración ayuda a gestionar la base de datos

ofreciendo funcionalidades como almacenamiento y recuperación, gestión de
la seguridad, optimización de preguntas, control de concurrencia y gestión de
cambios.
3.14.4. Lenguajes de modelación
Toda base de datos soportada por un SGBD debe tener unos esquemas
modelados adecuadamente. Coincidiendo con la evolución histórica de las bases
de datos éstas han utilizado distintos modelos. Los SGBD esperan un modelo
determinado para poder acceder de forma simple a la base de datos. Estos
modelos son:
 jerárquico
 en red
 relacional
 multidimensional
123
 de objetos
También se han utilizados listas invertidas.
3.14.4.1. Estructura jerárquica
La estructura jerárquica fue usada en los SGBD de los primeros mainframe. Las
relaciones entre registros forman una estructura en árbol. Esta estructura es
simple pero inflexible ya que las relaciones están confinadas al tipo 1:n. El sistema
IMS de IBM y el RDM Mobile de Raima son ejemplos de bases de datos con
múltiples jerarquías sobre el mismo conjunto de datos. RDM Mobile es un nuevo
diseño de base de datos imbuida para una red de ordenadores móviles. La
estructura jerárquica es usada hoy en día para almacenar información geográfica
principalmente.
El modelo de base de datos jerárquica tiene un esquema en el que los datos se

organizan en una estructura arbórea. Esta estructura permite representar
relaciones padre/hijo: cada padre puede tener varios hijos, pero cada hijo ha de
venir de sólo un padre (las conocidas como relaciones 1:N). Todos los atributos de
un registro específico están asociados a un tipo de entidad. Este modelo fue
creado por IBM en 1960.
En una base de datos una entidad tipo es el término genérico para tabla. Cada
registro individual se representa como una fila, y cada atributo como una columna.
Las entidades tipo se relacionan entre ellas usando correspondencias 1:N.
Actualmente las bases de datos jerárquicas más utilizadas son IMS de IBM y el
Registro de Windows de Microsoft.
3.14.4.2. Estructura en red
Esta estructure contiene relaciones más complejas que las jerárquicas. Admite
relaciones de cada registro con varios que se pueden seguir por distintos caminos.
En otras palabras, el modelo permite relaciones N:N.
124
El modelo en red está concebido como un modo flexible de representar objetos y
sus relaciones. Su cualidad distintiva es que el esquema -visto como un conjunto
de nodos conectados por arcos- no tiene ninguna restricción.
El inventor de este modelo fue Charles Bachman, y el estándar fue publicado en

1969 por CODASYL.
3.14.4.3. La estructura relacional
La estructura relacional es la más extendida hoy en día. Se usa en mainframes,

ordenadores medios y micro-computadores. Almacena los datos en filas (tuplas) y
columnas (atributos). Estas tablas pueden estar conectadas entre sí por claves
comunes. Mientras trabajaba en IBM en 1972, E.F. Codd concibió esta estructura.
El modelo no resulta sencillo de interrogar por el usuario ya que puede requerir
una compleja combinación de tablas.
3.14.4.4. La estructura multidimensional
La estructura multidimensional tiene parecidos a la del modelo relacional, pero en

vez de las dos dimensiones filas-columnas, tiene N dimensiones. Esta estructura
ofrece el aspecto de una hoja de cálculo. Es fácil de mantener y entender ya que
los registros se almacenan del mismo modo como se ven. Sus altas prestaciones
han hecho de ella la base de datos más popular para el proceso analítico de
transacciones en línea (OLAP).
3.14.4.5. La estructura orientada a objetos
La estructura orientada a objetos está diseñada siguiendo el paradigma de los

lenguajes orientados a objetos. De este modo soporta los tipos de datos gráficos,
imágenes, voz y texto de manera natural. Esta estructura tiene gran difusión en
aplicaciones web para aplicaciones multi-media.
Antes de la implantación de los SGBD con estructura orientada a objetos, el

almacenamiento de datos multi-media se basaba en el sistema de ficheros para
organizar, almacenar y procesar los datos. El proceso de ficheros es engorroso,
125
costoso e inflexible. La redundancia de los datos es un inconveniente del proceso
de ficheros ya que los ficheros independientes producen ficheros duplicados con
su implicación en el espacio necesario. Otro inconveniente es la falta de
integración, y la dificultad de mantenimiento. Esto fue encaminado aplicando la
orientación a objetos a los datos.
3.14.5. Lenguajes de consulta
Los lenguajes de consulta de bases de datos y de generación de informes

permiten interrogar a la base de datos, analizar los datos y actualizarlos según los
privilegios de cada usuario. También controla la seguridad de la base de datos
para prevenir accesos no autorizados que vean, borren o cambien los datos.
Mediante el uso de claves se permite el acceso a toda la base de datos o a parte
de ella. A modo de ejemplo, una base de datos de empleados puede contener
todos los datos de los empleados, pero sólo un grupo de usuarios puede estar
autorizado a ver las nóminas mientras que otros pueden estar autorizados a ver
sólo las historias laborales y los datos médicos.
Si el SGBD proporciona un modo de acceder y actualizar la base de datos, así

como de consultarla, éste posibilitará la creación de bases de datos personales.
Sin embargo, le faltaría la capacidad de dejar trazas de las acciones o los
controles necesarios que necesita la base de datos de una gran organización.
Estos controles están sólo disponibles cuando un conjunto de programas
auxiliares supervisan los accesos y actualizaciones de los datos.
3.14.6. Arquitectura
La arquitectura de un SGBD ha de especificar sus componentes (incluyendo su

descripción funcional) y sus interfaces. Trata de conceptos distintos que la
arquitectura de la base de datos. Los componentes principales de un SGBD son:
 Interfaces externos - Medios para comunicarse con el SGDB en ambos

sentidos (E/S) y explotar a todas sus funciones. Pueden afectar a la base de
datos o a la operación del SGBD, por ejemplo:
126
 operaciones directas con la base de datos: definición de tipos, asignación
de niveles de seguridad, actualización de datos, interrogación de la base
de datos...
 operaciones relativas a la operación del SGBD: copia de seguridad y

restauración, recuperación tras una caída, monitoreo de seguridad, gestión
del almacenamiento, reserva de espacio, monitoreo de la configuración,
monitoreo de prestaciones, afinado...
 los interfaces externos bien pueden ser utilizados por usuarios (p.e.
administradores) o bien por programas que se comunican a través de un
API.
 Intérprete o procesador del lenguaje - La mayor parte de las operaciones se

efectúan mediante un lenguaje de base de datos. Existen lenguajes para
definición de datos, manipulación de datos (p.e. SQL), para especificar
aspectos de la seguridad y más. Las sentencias en ese lenguaje se introducen
en el SGBD mediante el interfaz adecuado. Se procesan las expresiones en
dicho lenguaje (ya sea compilado o interpretado) para extraer las operaciones
de modo que puedan ser ejecutadas por el SGBD.
 Optimizador de consultas - Realiza la optimización de cada pregunta y escoge

el plan de actuación más eficiente para ejecutarlo.
 Motor de la base de datos - Realiza las operaciones requeridas sobre la base

de datos, típicamente representándolo a alto nivel.
 Mecanismo de almacenamiento - Traduce las operaciones a lenguaje de bajo

nivel para acceder a los datos. En algunas arquitecturas el mecanismo de
almacenamiento está integrado en el motor de la base de datos.
 Motor de transacciones - Para conseguir corrección y fiabilidad la mayoría de

las operaciones internas del SGBD se realizan encapsuladas dentro de
transacciones. Las transacciones pueden ser especificadas externamente al
127
SGBD para encapsular un grupo de operaciones. El motor de transacciones
sigue la ejecución de las transacciones y gestiona su ejecución de acuerdo con
las reglas que tiene establecidas (p. eg., control de concurrencia y su ejecución
o cancelación).
 Gestión y operación de SGBD - Comprende muchos otros componentes que

tratan de aspectos de gestión y operativos del SGBD como monitoreo de
prestaciones, gestión del almacenamiento, mapas de almacenamiento.
3.15. NÚMERO ÍNDICE
Un número índice es una medida estadística que permite estudiar las

fluctuaciones o variaciones de una magnitud o de más de una en relación al
tiempo o al espacio. Los índices más habituales son los que realizan las
comparaciones en el tiempo, por lo que, como veremos más adelante, los
números índices son en realidad series temporales.
3.15.1. Aproximación
Los números índices nacen de la necesidad de conocer en profundidad la

magnitud de un fenómeno y poder realizar comparaciones del mismo en distintos
territorios o a lo largo del tiempo. Una forma inicial de resolver el problema es
referir cada situación a la anterior, pero esto no hace viable la posibilidad de
comparaciones significativas, al menos directamente, salvo en lo concerniente a
dos de ellas inmediatas. Por esto es más conveniente escoger una situación
determinada como punto de referencia inicial, para remitir a ella todas las demás
observaciones, esta situación se denomina situación base y las comparaciones
que se realizan vienen establecidos a través de un número índice. Los números
índices, o simplemente índices, proporcionan comparaciones entre datos
correspondientes a diferentes situaciones, escalonadas con arreglo a algún criterio
conocido (por ejemplo, por el transcurso del tiempo).
128
Si definimos a como el Número Índice de un determinado valor o bien en el
período t, respecto al período base o, entonces
donde representa el valor del bien en el período t y el valor del bien en el

periodo o.
3.15.2. Propiedades
Uno de los problemas de mayor importancia a la hora de elaborar un número

índice es el conseguir que éste sea adecuadamente representativo, para ello es
preciso que el índice cumpla ciertas propiedades de carácter matemático y reúna
ciertos requisitos en su definición:
 Identidad. Cuando el período base y el de comparación coinciden, el índice

debe ser igual a uno.
 Inversión. Si en un índice se invierten los períodos base y de comparación, el

índice toma el valor recíproco al anterior.
 Circular. Si se multiplica el índice de un período Z con relación a un período Y

por el índice de Y con relación a X, el producto ha de ser el índice de Z con
relación a X.
 Existencia. El índice ha de tomar valores reales y finitos para cualquier valor de

la variable observada.
 Proporcionalidad. El índice elaborado sobre unos determinados valores de una

variable ha de ser proporcional al índice correspondiente a los valores de esa
variable multiplicados por un mismo número K.
 Variación proporcional. Si los valores de la variable varían en una cierta

cuantía, el índice varía proporcionalmente.
129
 Inalterabilidad. Si se introduce una nueva modalidad en el índice complejo, de
tal manera que el valor de éste coincide con el del índice simple de aquella, el
índice complejo no varía.
 Homogeneidad. El valor de un índice no ha de ser afectado por modificaciones

de las unidades de medida.
3.15.3. Índices simples y complejos
Cuando se realiza una comparación entre los valores de una sola magnitud se
obtienen índices simples, En cambio, si se trabaja con más de una magnitud a la
vez, se habla de índices complejos. En los dos casos se comparan siempre dos
situaciones, una de las cuales se considera como referencia. Cuando se trata de
comparaciones temporales, a la situación inicial, se le conoce como periodo base
o referencia, mientras que el periodo objeto de comparación se denomina
corriente o actual. Para elaborar un número índice de carácter simple, se asigna al
periodo que es objeto de referencia el valor 100, de esta manera los números
índices de las distintas observaciones posteriores, no son otra cosa que
porcentajes de cada valor con respecto al de la referencia. Dentro de los índices
complejos se distingue entre índices ponderados y no ponderados, según el peso
que se le de a los distintos valores.
130
CAPITULO IV
MARCO
PRÁCTICO
131
Resumen
En este capítulo se desarrolla en forma práctica, todo el conjunto de

teorías, métodos y técnicas, planteados en el marco teórico en cual
se desarrollan los siguientes puntos: análisis de la situación actual,
diseño del sistema, desarrollo del prototipo, pruebas del sistema y la
prueba de hipótesis.
La Escuela Militar de ingeniería Presenta en el plan de estudios estrategias

metodológicas de enseñanza las cuales describen actividades, recursos, etc. para
facilitar el cumplimiento de los objetivos planteados en el plan de desarrollo.
Para comenzar con el marco practico se tiene el plan de desarrollo del proyecto en
la siguiente tabla 4.1.
Tabla 4.1 Plan de Desarrollo del Proyecto

Etapas Metodología SCRUM Objetivos Desarrollo
1) Análisis de la Recopilación de Revisión de los procesos -Análisis de la Institución
situación actual información de enseñanza y - Especificaciones del
aprendizaje proceso enseñanza y
aprendizaje
2) Determinación de Obtención de requisitos Identificación de -Identificación de
requisitos requisitos, tareas y roles requisitos
-identificación de roles y
tareas
3) Análisis del sistema Identificación de actores Identificar requerimientos - Especificación de
del funcionamiento escenarios
* Casos de uso de alto
nivel
* Casos de uso
expandidos
4) Diseño del sistema - Diseño conceptual Diseño de material - Esquema conceptual
- Diseño Navegacional -Diseño de procesos
- Diseño de interfaz -Diseño de la
abstracta arquitectura
- Desarrollo de la
topología Navegacional
- Desarrollo de la interfaz
abstracta
5) Desarrollo del sistema Construcción del sistema Desarrollo de actividades -Diseño de la interfaz de
y de practicas prototipo
-Manual de Usuario
- Carpeta Técnica
6) Prueba del sistema Pruebas de sistemas Evaluación - Pruebas de software
- Pruebas de hipótesis
Fuente: Elaboración Propia
132
4.1. ANÁLISIS DE LA SITUACIÓN ACTUAL
4.1.1. Análisis de la Institución
El proceso de enseñanza-aprendizaje es un proceso regido por aspectos internos

que describen la interacción e intercambio entre el docente y estudiante, los
cuales se encuentran regidos por determinadas intenciones, y aspectos externos
que se encuentran regidos de acuerdo al contexto social de la institución en la que
ocurre este proceso.
En el modelo de la EMI que se vio en el Marco Referencial representa las

funciones principales de la misma, este se utiliza para identificar los
departamentos centralizados y roles dentro de la institución.
La EMI presenta en el plan de estudios estrategias metodológicas de enseñanza

las cuales describen actividades, recursos, etc. para facilitar el cumplimiento de los
objetivos detallados en la siguiente tabla 4.2
Tabla 4.2 Estrategias Metodológicas de Enseñanza
De Objetivo
El docente debe comunicar en la primera sesión de clases los

objetivos y contenidos mínimos de la asignatura.
SOCIALIZACIÓN
De Contenido
Así mismo, al inicio de cada capítulo el docente informara al

estudiante los objetivos y contenidos del mismo
El docente deberá utilizar las técnicas didácticas adecuadas

según la característica de cada asignatura para conducir el
proceso de enseñanza-aprendizaje con el fin de alcanzar los
TÉCNICAS objetivos planeados.
DIDÁCTICAS
Las técnicas más utilizadas son: exposición, lectura dirigida,
discusión de grupos, corrillos, lluvia de ideas, demostraciones,
debates, estudio de casos, juegos de roles, dinámicas
grupales y otras.
133
Los estudiantes deben realizar actividades dentro y fuera del
aula con el fin de consolidar el aprendizaje de los contenidos
desarrollados y/o propuestos.
ACTIVIDADES
Como ser: investigación, prácticas, trabajos de síntesis
conceptual, reflexiones críticas, análisis y comparación de
teorías y autores, experimentación y otras.
El docente utilizara los recursos didácticos que faciliten su

labor, propicien la comunicación con los estudiantes,
estimulando los sentidos para lograr más fácilmente el
RECURSOS
conocimiento y el desarrollo de destrezas y habilidades.
DIDÁCTICOS
Los recursos didácticos comúnmente utilizados son: pizarrón,
material impreso, proyector multimedia, retroproyector,
equipos de reproducción de video, DVD's y otros.
Fuente: Plan de Estudios de Ingeniería de Sistemas
La socialización, las técnicas didácticas y los recursos didácticos son procesos

que se dan dentro del aula, por tanto su duración concluye una vez concluido el
horario académico como lo detalla en la siguiente figura 4.1.
134
Figura 4.1 enseñanza Dentro del Aula
Fuente: Elaboración propia

En la siguiente figura 4.2 se llega a observar las actividades que se realizan en el
laboratorio pero al igual que las actividades de clases estas se realizan y
concluyen en un determinado horario, por materia y curso.
135
Figura 4.2 Enseñanza dentro del Laboratorio
Fuente: elaboración propia

Por otra parte las actividades que brinda el docente al estudiante son realizadas
fuera del aula como ser: investigación, prácticas, experimentación y otras las
cuales veremos en la siguiente figura 4.3.
136
Figura 4.3 Actividades fuera del aula
Fuente: Elaboración propia

Una vez descrito el Plan de Estudios Académicos en la Escuela Militar de
Ingeniería, se procederá a identificar los aspectos que provoquen un bajo
rendimiento académico en una parte de la población de los estudiantes de la EMI.
4.1.1.1. Especificación del proceso de enseñanza aprendizaje.
En el modelo del proceso educativo de la siguiente figura 4.4 y el flujo grama de la

figura 4.5 se identifican los principales procedimientos que se llevaran a cabo en el
Sistema.
137
Figura 4.4 Modelo de Proceso Educativo
138
En la anterior figura 4.4 se muestra el modelo del proceso educativo que está
conformado por 5 etapas: planificación de unidades, diseño del material, desarrollo
de actividades y evaluación. Mostrando 3 actores interactuando en las respectivas
etapas del proceso educativo.
4.1.2. Análisis del sistema propuesto
Para el presente proyecto se tomó en cuenta más de una posible metodología

para el desarrollo de sistema propuesto que a continuación se podrá ver en la
tabla 4.3.
Tabla 4.3 Selección de Metodología

De acuerdo con los resultados ofrecidos por la anterior tabla se tomó en cuenta la
metodología Scrum por el mayor resultado total a comparación de las otras
metodologías propuestas para el desarrollo del sistema propuesto.
Según la metodología SCRUM una buena forma de analizar la situación actual es

escuchar y resaltar toda la información más importante para el desarrollo correcto
del software. Si realizan pruebas se tiene que preguntar si lo obtenido es lo
deseado, y tenemos que preguntar a quién necesita la información. Tenemos que
escuchar a nuestros clientes cuales son los problemas de su negocio, debemos de
tener una escucha activa explicando lo que es fácil y difícil de obtener, y la
realimentación entre ambos nos ayudan a todos a entender los problemas.
139
El proceso enseñanza y aprendizaje es un proceso establecido por aspectos
internos que describen la interacción e intercambio entre el docente y estudiante,
los cuales se encuentran regidos por determinadas intenciones, y aspectos
externos, de acuerdo al contexto social de la institución en la que ocurren este
proceso.
En esta etapa se analizará la situación actual del caso de estudio a través del
modelado de la misma, para posteriormente identificar los requerimientos
funcionales y no funcionales del presente trabajo de grado, una vez terminado el
análisis estará listo para pasar a la siguiente etapa
Figura 4.5 Flujo Grama de Procesos
140
En la figura 4.5 se mostró el Flujo Grama de Procesos, detallando la secuencia
que sigue el proceso educativo que se mostró en la anterior figura 4.4.
A continuación en la figura 4.6 se presenta más detalladamente la etapa de

planificación de unidades.
Figura 4.6 Flujo Grama Planificación de Unidades

Inicio
Progreso
Comprensión Imitación Elaboración
Motivación Copia Reconocimiento

laminas formación y formación y
escritura construcción
Fin
4.1.4. Definición e historia de los Usuarios
Como el presente proyecto está basado en la metodología SCRUM la fase de

planificación realizará la tarea de definir las historias de usuario.
Número: 1 Usuario: Estudiante
Nombre historia: Miembro del grupo de usuarios a utilizar el Sistema.

Prioridad en negocio: Riesgo en desarrollo:
Alta Baja
Programador responsable: Jorge Cristobal Cortez Calle.
Descripción:
Organiza y prepara su tiempo para la utilización del sistema y sus materiales de
estudio de la materia de programación en JAVA de la universidad de la EMI.
Observaciones:
141
Número: 2 Usuario: Docente
Nombre historia: Miembro del grupo de usuarios que brinda material de estudio.
Media Baja
Descripción:
Prepara y desarrolla el material que será usado por estudiantes de la materia de
programación en java de la universidad de la EMI.
Observaciones:
Número: 3 Usuario: Administrador
Nombre historia: Control y administración de usuarios en el sistema.

Alta Media
Descripción:
Administra las altas y bajas de usuarios en el sistema para la materia de
programación en JAVA de la universidad de la EMI.
Observaciones:
4.2. DETERMINACIÓN DE REQUISITOS

Según la metodología SCRUM la comunicación se realiza de diferentes formas.
Para los programadores el código comunica mejor cuanto más simple sea. El
código auto documentado es más fiable que los comentarios ya que éstos últimos
pronto quedan desfasados con el código a medida que es modificado.
4.2.1. Especificación de requisitos
Los requisitos de la aplicación del proyecto con propósitos de apoyo educativo son
detallados a través de la tabla 4.4
142
Tabla 4.3 Especificación de Requisitos
Requisitos Descripción.
R1 Diseños de pantallas.
R2 Audio y video.
R3 Cargar actividades.
R4 Cargar información.
R5 Control sobre el material.
R6 Acceso al material requerido.
R7 Listado de temas y material disponible.
R8 Información disponible de cada tema.
R9 Presentación de prácticas después del avance del tema.
R10 Evaluación de los conocimientos adquiridos.
R11 Cuantificar las evaluaciones.
R12 Generación de reportes de notas.
4.2.3. Identificación de roles y tareas
En esta sub etapa en análisis deberá introducirse cuidadosamente en el dominio

del sistema de Apoyo, su principal labor será identificar los diferentes roles que
podría cumplir cada uno de los potenciales usuarios de la aplicación del sistema.
Los usuarios juegan roles importantes en cada intercambio de información con el

Sistema de Apoyo que se observa en la Tabla 4.5.
Tabla 4.5 Roles y Tareas

Roles Tareas
Estudiante * T1 Conocer una posible calificación con el desarrollo de las
practicas
* T2 Desarrollar actividades de aprendizaje
* T3 Desarrollar cuestionarios en el sistema
Docente * T4 Planificación de la unidades o temas
* T5 Diseño de material para las unidades
* T6 Control del desarrollo de actividades de los estudiantes
* T7 Supervisar el desarrollo de cuestionarios de los estudiantes
* T8 Evaluar Cualitativamente
143
4.3. ANÁLISIS DEL SISTEMA
En este punto se tendrá que elaborar la planificación por etapas, donde se

aplicarán diferentes iteraciones. Para hacerlo será necesaria la existencia de
reglas que se han de seguir por las partes implicadas en el proyecto para que
todos los usuarios tengan voz y se sientan realmente partícipes de la decisión
tomada.
4.3.1. Especificación de escenarios.
La especificación de escenarios se realizará a través de los casos de uso que

específicamente representa la interacción entre el usuario y el sistema, agrupando
las tareas representadas en los escenarios existentes. Es muy importante que el
análisis identifique cual es la información relevante en cada uno de ellos, para
luego generar un caso de uso coherente.
a) Caso de uso de Alto Nivel
En la siguiente figura 4.7 se tiene el caso de uso de alto nivel que da una
descripción rápida de los principales procesos del Sistema de Aprendizaje
Individualizado.
Figura 4.7 Diagrama de Casos de Uso de Alto Nivel
144
La Tabla 4.6 detalla el Caso de Uso de Alto Nivel del presente Proyecto de Grado
del gestor de contenidos digitales.
Tabla 4.6 Caso de Uso de Alto Nivel

Caso de DESARROLLO DE UN GESTOR DE CONTENIDOS DIGITALES
Uso PARA LA AUTOFORMACIÓN EN PROGRAMACIÓN
CASO: CARRERA DE INGENIERÍA DE SISTEMAS - EMI
IRPAVI
Actores 1. Docente
2. Estudiante
3. Administrador
Descripción El docente es el principal actor que interviene en todos los
procesos directamente.
El estudiante en un usuario primario teniendo una interacción con
los procesos dirigidos al mismo.
El administrador controla el flujo de datos de la Base de Datos de
la lista de usuarios.
El caso de uso en general representa el proceso que llevara a cabo el
sistema de aprendizaje.
A Continuación se verán los casos de uso extendidos, los cuales muestran en
mayor detalle cada uno de los casos de uso de alto nivel, para obtener una mayor
comprensión de los procesos y requerimiento del sistema.
b) Casos de uso Extendidos
Una vez desarrollado el caso de uso de alto nivel se pasa el desarrollo de los
casos de uso extendidos empezando con la siguiente figura 4.8 con el caso de uso
de inicio de sesión.
145
Figura 4.8 Caso de Uso Inicio de Sesión
En la siguiente tabla 4.7 se tiene el detalle del caso de uso de inicio de sesión.
Tabla 4.7 Caso de Uso Inicio de Sesión

Nombre del caso de uso Ingreso al sistema
Actores Los usuarios del sistema (estudiantes,
docente, administrador)
Propósito Ingresa al sistema para seleccionar las
actividades a desempeñar
Curso Normal de Acciones
Acciones del actor Respuesta del Sistema
1. Muestra la página de inicio
2. ingresa ID y contraseña
3. Consulta a la Base de Datos
4. Validación de datos
5. Habilitación de nivel de usuario
6. Accede a la página principal
La siguiente figura 4.9 muestra el caso de uso de gestión de material.
146
Figura 4.9 Caso de Uso Gestión de Material
En la siguiente tabla 4.8 se muestra el detalle del caso de uso de gestión de

material.
Tabla 4.8 Caso de Uso Gestión de Material

Nombre del caso de Uso Planificación
Actores Docente
Propósito Diseñar el material a ser implementado
Resumen Se muestra un lista del material
disponible, seleccionando el más
conveniente
CURSO NORMAL DE ACCIONES
Acciones del Actor Respuesta del Sistema
1. ingreso a la página de gestión de
material
2. Selección y almacenamiento de
Temas
3. Generación de cuestionarios y
evaluaciones
4. Validación de Datos
5. Información almacenada a la Base
de Datos
En la siguiente figura 4.10 se muestra el caso de uso de la Gestión de Usuarios.
147
Figura 4.10 Caso de Uso Gestión de Usuarios
En la siguiente tabla 4.9 se muestra el detalle del caso de uso de Gestión de

Usuarios.
Tabla 4.9 Caso de Uso Gestión de Usuarios

Nombre del caso de Uso Planificación
Actores Administrador
Propósito controla la listas de usuarios
Resumen Administra la lista de usuarios
involucrados en la materia
Acciones del Actor Respuesta del Sistema
1. Ingreso a la página de gestión de
usuarios
2. Lista de Usuarios habilitados en el
sistema
3. Selección de Usuarios involucrados
en la materia
4. Validación de datos
5. Selección almacenada en la Base de
Datos
En la siguiente figura 4.11 se muestra el caso de uso selección y desarrollo de
temas.
148
Figura 4.11 Caso de uso Selección y Desarrollo de Temas
En la siguiente tabla 4.10 se muestra el detalle del caso de uso selección y

desarrollo de temas.
Tabla 4.10 Caso de Uso de Selección y Desarrollo de Temas

Nombre del Caso de Uso Implementación
Actores Estudiante
Propósito Implementar los temas como material
de apoyo
Resumen Es la implementación de los materiales
y los temas para su uso en las etapas
de desarrollo de las clases de la
materia
Acciones del actor Respuesta del sistema
1. El sistema presente lista de temas a
ser seleccionados por el estudiante
2. El estudiante elige el tema que desea 3. El sistema sigue las instrucciones del
desarrollar como una clase estudiante a través de botones que
controlan las acciones de navegación
4. El estudiante ingresa a la primera
etapa de presentación de teoría para
continuar con la práctica y la evaluación
La siguiente figura 4.12 muestra el caso de uso de desarrollo de cuestionarios.
149
Figura 4.12 Caso de Uso Desarrollo de Cuestionarios
La siguiente tabla 4.11 muestra el detalle del caso de uso en Desarrollo de

Cuestionarios.
Tabla 4.11 Caso de Uso Desarrollo en Cuestionarios

Nombre del caso de Uso Implementación
Actores Estudiante
Propósito Llevar a cabo los cuestionarios
Resumen Es la relación de prácticas del tema ya
avanzado para la reafirmación de
conocimientos
Acciones del actor Respuesta del sistema
1. El Sistema presenta una lista de
cuestionarios
2. El estudiante ingresa a la etapa de
resolución de cuestionarios
3. Según los resultados que seleccione
se le otorgara una calificación sobre el
desarrollo del mismo cuestionario
4. El estudiante puede pedir una
explicación sobre las preguntas que no
logro entender
En la siguiente figura 4.13 se muestra el caso de uso de la Evaluación.
150
Figura 4.13 Caso de Uso Evaluación
En la siguiente tabla 4.12 se muestra el detalle del Caso de Uso de Evaluación.
Tabla 4.12 Caso de Uso de Evaluación

Nombre Del Caso de Uso Evaluación
Actores Estudiante
Propósito Evaluar los conocimientos adquiridos
Resumen Se lleva a cabo la presentación de la
evaluación para su respectiva solución
por parte del estudiante, siendo
cuantificado y entrega el resultado de la
evaluación.
Acciones del actor Respuesta del Sistema
1. Evaluación preparada con
anticipación
2. Evaluación Almacenada en el
sistema
3. El sistema muestra una serie de
preguntas de forma aleatoria
4. El estudiante resuelve la evaluación
5. Se compara las respuestas del
estudiante con las del sistema
6. Se cuantifica la evaluación
7. El sistema entrega los resultados de
la evaluación
151
4.3.2. Diseño de procesos
El diseño de procesos se lleva a cabo con el uso de diagramas de actividades que

se presentan a continuación.
a) diagrama de Actividades
Es una forma especial de diagramar de estado usado para modelar una secuencia
de acciones y condiciones tomadas dentro de un proceso.
En la siguiente figura 4.14 se tiene el diagrama de ingreso al sistema donde se

muestra como el cliente ingresa a la página de inicio para que esta se comunique
con el código del programa y autorice el ingreso.
Figura 4.14 Diagrama de actividad de ingreso al sistema

Usuario Sistema Base de Datos
En la siguiente figura 4.15 se muestra el diagrama de actividades de gestión de

contenidos donde se ingresará a la etapa de planificación, selección de los temas
y materiales para el desarrollo de las actividades, para organizar el orden en que
será utilizado o presentado a los estudiantes
152
Figura 4.15 Diagrama de Gestión de Contenidos
Las actividades que se llevarán en el desarrollo del material que simulará una
clase se muestra en la siguiente figura 4.16 en la que comenzará con la
presentación teórica del tema que fue planificado para la material pertinente
destinada a la aplicación de cuestionarios sobre el tema.
Figura 4.16 Diagrama de Actividades de Desarrollo de Actividades

Para la etapa de Desarrollo de Cuestionarios se tiene la siguiente figura 4.17

donde comienza con el ingreso a la lista de cuestionarios para la generación de
153
preguntas que serán respondidas por el estudiante para colaborar al reforzamiento
de sus conocimientos.
Figura 4.17 Diagrama de Actividad de Desarrollo de Cuestionarios


Para la etapa de evaluación se tiene la siguiente figura 4.18 donde comienza con
el ingreso a la evaluación para la generación de preguntas aleatorias ya
almacenadas con anterioridad en el sistema que serán respondidas por el
estudiante para cuantificar sus resultados y así poder medir todos los
conocimientos adquiridos durante la materia.
154
Figura 4.18 Diagrama de Actividad de Evaluación

Para la etapa de gestión de usuarios se tiene la siguiente figura 4.19 donde
comienza con el ingreso a la lista de usuarios que se encuentran involucrados en
la materia.
Figura 4.19 Diagrama de Actividad de Gestión de usuarios

155
4.3.3. DISEÑO DE SECUENCIA
El diseño de secuencias se lleva a cabo con el uso de diagramas de secuencia

que se presentan a continuación.
a) diagramas de Secuencia
Es una forma de diagramar que se usa para modelar una secuencia de acciones y
condiciones tomadas dentro de las secuencias de los diagramas de caso de uso
anteriores.
En la siguiente figura 4.20 nos muestra el diagrama de secuencia de inicio de

sesión en la cual se muestra el funcionamiento y la iteración del usuario con el
sistema y el sistema con la Base de Datos
Figura 4.20 diagrama de secuencia de Inicio de Sesión
En la siguiente figura 4.21 nos muestra el diagrama de secuencia de gestión de

material en la cual se verá el funcionamiento y la iteración del docente con el
sistema y el sistema con la Base de Datos para el almacenamiento del material
necesario de la materia de programación.
156
Figura 4.21 diagrama de secuencia de Gestión de Material

En la siguiente figura 4.22 nos muestra el diagrama de secuencia de gestión de
usuarios en la cual se verá el funcionamiento y la iteración del administrador con el
sistema y el sistema con la Base de Datos para verificar que usuarios están
involucrados en la materia y que usuarios ya no lo están.
Figura 4.22 diagrama de secuencia de Gestión de Usuarios
En la siguiente figura 4.23 nos muestra el diagrama de secuencia de selección y

desarrollo de temas en la cual se verá el funcionamiento y la iteración del
estudiante con el sistema y el sistema con la Base de Datos para la navegación en
157
el material cargado en el sistema para su debida utilización en el desarrollo de la
materia.
Figura 4.23 diagrama de secuencia de Selección y Desarrollo de Temas
En la siguiente figura 4.24 nos muestra el diagrama de desarrollo de cuestionarios

en la cual se muestra el funcionamiento y la iteración del estudiante con el sistema
y el sistema con la Base de Datos para la resolución de actividades practicas al
finalizar un tema de la materia.
158
Figura 4.24 diagrama de secuencia de Desarrollo de Cuestionarios
En la siguiente figura 4.25 nos muestra el diagrama de evaluación en la cual se

muestra el funcionamiento y la iteración del estudiante con el sistema y el sistema
con la Base de Datos para medir los conocimientos adquiridos durante el
desarrollo de una cierta cantidad de temas de la materia.
159
Figura 4.25 diagrama de secuencia de Evaluación
4.4. DISEÑO DEL SISTEMA
El desarrollo es la parte más importante en el proceso de la programación

extrema. Todos los trabajos tienen como objetivo que se programen lo más
rápidamente posible, sin interrupciones y en dirección correcta.
160
También es muy importante el diseño, y se establecen los mecanismos, para que
éste sea revisado y mejorado de manera continuada a lo largo del proyecto, según
se van añadiendo funcionalidades al mismo.
La clave del proceso de desarrollar SCRUM es la comunicación. La mayoría de los

problemas en los proyectos son por falta de comunicación en el equipo.
En este proceso se aplican todos los requisitos identificados anteriormente para

lograr un diseño integro en la aplicación de la teoría planteada.
4.4.1. Diseño Conceptual
4.4.1.1. Esquema Conceptual
Durante esta actividad se construye un esquema conceptual en la siguiente figura

4.26 representado por los objetos del dominio, las relaciones y colaboraciones
existentes, establecidas entre ellos.
161
Figura4.26 Esquema Conceptual
Una vez desarrollado el esquema conceptual se pasa al diseño de procesos.
4.4.2 Diseño Navegacional
4.4.2.1 Diseño de la Arquitectura
La Arquitectura será de dos capas por qué se puede desarrollar en varios niveles
optimizando el servicio al Cliente según la siguiente figura 4.27.
162
Figura 4.27 Arquitectura tres Capas
La Arquitectura que se mostró en la anterior figura cuenta con tres capas: Capa 1
que es el cliente que realiza peticiones al programa, capa 2 que es la capa de
negocio y la Capa 3 que viene a ser la capa de la base de datos.
Tabla 4.13 Arquitectura de tres Capas
Cliente Servidor
Usuario Sistema
Servidor Base de Datos
A continuación se presenta un diagrama general de navegación con los usuarios y

sus rutas de navegación.
163
4.4.2.2. Desarrollo de la Topología Navegacional
En la siguiente figura 4.28 se muestra las conexiones entre las páginas y la

interacción que tiene el sistema, mostrando así el funcionamiento del sistema,
mostrando la página de inicio donde se seleccionaran los temas a navegar.
Figura 4.28 Diagrama Navegacional General

Index
Usuario
Lista de Temas
Evaluación
Presentación de
Temas
Presentación del
Material
Practicas
Temas Evaluación
Lista de Practicas
Descripción de Evaluación
Tema
Resultados de
Evaluación
Resultados de la
Evaluación
En la planificación de actividades en la siguiente figura 4.29 se presentan las

diferentes páginas que se utilizaran como ser: Planificación, Diseño de material,
Diseño de Actividades y de Prácticas para una posterior Evaluación.
164
Figura 4.29 Diagrama de Navegacional Planificación de Actividades
Planificación de
Actividades
Planificación de Diseño del Desarrollo de Desarrollo de Evaluación

Unidades Material Actividades Practicas
Evaluación
- Distinción de - Presentación de - Motivaciones - Ejercicios con tomada cada
Sonidos oraciones - Copia, resultados de cierta cantidad de
- Formas -Material de formación y selección múltiple temas
- Colores Clases escritura - Ejemplos
simples
En la siguiente figura 4.30 se tiene la planificación de unidades que se llevaran a

cabo por el usuario para su realización.
Figura 4.30 Diagrama Navegacional Planificación de Unidades

Planificación de
Unidad
Lista
Lista de Temas
Lista de Practicas
Lista de
Evaluaciones
Presentación de
Temas
Descripción del
tema seleccionado
Para la presentación del tema que se indica en la siguiente figura 4.31 se

selecciona el tema para ver el material disponible del mismo.
165
Figura 4.31 Diagrama Navegacional Presentación de Temas
Presentación de
Temas
Selección
Selección del
material a estudiar
Presentación
Material
En la figura 4.32 siguiente se tiene el desarrollo de prácticas, presentando una

serie de opciones para el desarrollo de prácticas para cada tema.
Figura 4.32 Diagrama Navegacional Desarrollo de Practicas
Material
Presentación
Teórica
Practicas
Presentación de
Preguntas
Reportes
Resultados de la
preguntas
Para la evaluación se muestra en la siguiente figura 4.33, donde podemos notar la

lista de temas de la cual se toma la evaluación y la generación de preguntas.
166
Figura 4.33 Diagrama Navegacional de Evaluación
Evaluación
Lista
Lista de Temas
Preguntas Reporte
Presentación de Resultados de la
preguntas evaluación
4.4.2.3. Diseño de la Base de Datos
El diseño de la Base de Datos, figura 4.34 cuenta con varias tablas entre las que
se tiene acceso para los usuarios donde se les brindara accesos y privilegios
según lo permita el administrador.
167
Figura 4.34 Base de Datos
4.4.2.4. Diseño de la Interfaz
El usuario Tanto como el Estudiante, docente y administrador podrán loguearse

con sus respectivas cuentas, la interfaz para acceder al sistema es la siguiente
figura 4.35.
168
Figura 4.35 Diseño de Inicio
Donde se verifica el tipo de usuario, previamente se proveerá a los usuarios un

código, que no es otro que el proporcionado por la EMI.
En la opción de examen a la que el docente accede para llenar un grupo de

preguntas en la que el programa almacenará para una prueba pertinente
destinada para los estudiantes se muestra en la siguiente figura.
Figura 4.36 Diseño de Examen
169
El administrador tendrá acceso al registro de nuevos usuarios y brindarles sus
respectivos privilegios. Según se ve en la siguiente figura.
Figura 4.37 Diseño de Usuarios
La creación de Materias será realizada por el Administrador, como se ve en la

siguiente figura.
Figura 4.38 Diseño de Materias

170
4.5. PRUEBA DE HIPOTESIS
La hipótesis planteada para el presente trabajo de grado es la siguiente:
“Un gestor de contenidos digitales, coadyuvará en la

autoformación/autoevaluación del lenguaje de programación en JAVA,
incrementando el aprovechamiento de los estudiantes que utilicen el sistema
propuesto en comparación a quienes no lo hagan en al menos un 20%”.
Para realizar la prueba de hipótesis planteada en el presente proyecto de grado se
utilizara el análisis de números índices. Para esto se identifican dos fases, donde
se medirán el antes y el después de la utilización del programa, en la primera fase
se toma como muestra un curso que lleve la materia de JAVA, al cual se dividirán
en dos grupos los cuales al principio se les tomara una misma prueba para ver
cómo están comenzando sin el sistema, una vez tomada la prueba se pasa a la
segunda fase, en la que a un grupo se lo denomina método tradicional y al otro
método de prueba. Para el grupo de método tradicional, a ellos no se les brindara
el programa y sus contenidos de la materia, para el grupo de método de prueba se
les brindaran el acceso al programa y sus respectivos contenidos de la materia.
Una vez transcurrido el tiempo de un mes se tomó una prueba a los 2 grupos para
llegar a observar el cumplimiento de la hipótesis planteada al inicio del presente
proyecto de grado.
Ahora veremos en las siguientes tablas 4.14 y 4.15 los resultados obtenidos para
el grupo del método tradicional, que se realizó con dos cursos distintos pero que a
su vez conocen de la materia de JAVA, para lo cual las pruebas tomadas al inicio
y al final del tiempo establecido de un mes para la materia de JAVA se obtuvieron
los siguientes resultados.
171
Tabla 4.14 Prueba tomada al primer grupo sin Sistema
PRUEBA SIN SISTEMA PRIMERA PRUEBA SEGUNDA PRUEBA

Estudiante 1 40 50
Estudiante 2 60 70
Estudiante 3 50 70
Estudiante 4 10 60
Estudiante 5 20 60
Estudiante 6 50 60
Estudiante 7 60 80
Estudiante 8 40 50
Estudiante 9 50 70
Tabla 4.15 Prueba tomada al segundo grupo sin Sistema
PRUEBA SIN SISTEMA PRIMERA PRUEBA SEGUNDA PRUEBA

Estudiante 1 30 50
Estudiante 2 30 50
Estudiante 3 40 60
Estudiante 4 10 50
Estudiante 5 50 60
Estudiante 6 70 80
Estudiante 7 60 70
Estudiante 8 30 50
Estudiante 9 50 50
Ahora veremos en las siguientes tablas 4.16 y 4.17 los datos que se obtuvieron
para el grupo del método de prueba con el mismo tiempo transcurrido de un mes,
donde también se tomó la misma prueba al inicio y al final del tiempo estimado.
172
Tabla 4.16 Prueba tomada al primer grupo con Sistema
PRUEBA CON SISTEMA PRIMERA PRUEBA SEGUNDA PRUEBA

Estudiante 1 20 70
Estudiante 2 50 80
Estudiante 3 60 80
Estudiante 4 80 100
Estudiante 5 70 100
Estudiante 6 50 100
Estudiante 7 40 90
Estudiante 8 60 90
Estudiante 9 20 70
Tabla 4.17 Prueba tomada al segundo grupo con Sistema
PRUEBA CON SISTEMA PRIMERA PRUEBA SEGUNDA PRUEBA

Estudiante 1 40 80
Estudiante 2 20 70
Estudiante 3 60 80
Estudiante 4 40 80
Estudiante 5 50 80
Estudiante 6 60 80
Estudiante 7 50 90
Estudiante 8 30 70
Estudiante 9 60 90
Una vez obtenidos los datos de los dos grupos se realizó la siguiente tabla 4.18
para obtener el dato que permite validar la hipótesis planteada en el presente
proyecto de grado.
173
Tabla 4.18 Diferencia de Notas de Comparación
PRUEBA SIN SISTEMA PRUEBA CON SISTEMA

PRUEBA SIN PRIMERA SEGUNDA PRIMERA SEGUNDA diferencia diferencia
SISTEMA PRUEBA PRUEBA PRUEBA PRUEBA 1º prueba 2º prueba
Estudiante 1 40 50 20 70 20 20
Estudiante 2 60 70 50 80 10 10
Estudiante 3 50 70 60 80 10 10
Estudiante 4 10 60 80 100 70 40
Estudiante 5 20 60 70 100 50 40
Estudiante 6 50 60 50 100 0 40
Estudiante 7 60 80 40 90 20 10
Estudiante 8 40 50 60 90 20 40
Estudiante 9 50 70 20 70 30 0
Estudiante 10 30 50 40 80 10 30
Estudiante 11 30 50 20 70 10 20
Estudiante 12 40 60 60 80 20 20
Estudiante 13 10 50 40 80 30 30
Estudiante 14 50 60 50 80 0 20
Estudiante 15 70 80 60 80 10 0
Estudiante 16 60 70 50 90 10 20
Estudiante 17 30 50 30 70 0 20
Estudiante 18 50 50 60 90 10 40
SUMATORIA 750 1090 860 1500 330 410
PROMEDIO 41,67 60,56 47,78 83,33 18,33 22,78
GRUPO SIN GRUPO CON DIFERENCIAS

SISTEMA SISTEMA NOTAS FINALES
NOTA PROMEDIO
18,33 22,78 0,24
PRUEBA INICIO
Para la realización de la anterior tabla se utilizó la siguiente fórmula para la

obtención de resultados y obtener el dato estadístico que permite a la hipótesis de
este proyecto de grado ser válida.
174
Si definimos a como el Número Índice de un determinado valor o bien en el
período t, respecto al período base o, entonces
𝑥𝑡 −𝑥𝑜
𝐼𝑜𝑡 =
𝑥𝑜
Donde representa el valor del bien en el período t y el valor del bien en el

periodo o.
175
CAPITULO V
ESTUDIO COSTO
BENEFICIO
187
Resumen
En este capítulo se realizará el análisis costo y beneficio, a fin
de estimar que involucra la realización del trabajo de grado y
contrastar con los beneficios que provee a fin de obtener una
valoración de la justificación económica del mismo, en los
gastos que se utilizan para el desarrollo del sistema de
evaluación.
5.1. DETERMINACION DE COSTOS

El análisis de costos nos permite cuantificar en sacrificio, o esfuerzo económico
que se debe realizar para lograr el objetivo del presente Trabajo de Grado.
Los costos incurridos para el desarrollo general del proyecto de acuerdo a

investigación bibliográfica son aproximados, los cuales se mencionan a
continuación en la figura 5.1.
Figura 5.1 Costo total del Producto
COSTO TOTAL
Costo de licencia DEL PRODUCTO
Costos de Material
de software
de Escritorio
Costo de desarrollo
COSTOS COSTOS
de software
FIJOS VARIABLE
Costo de hardware Costos de

investigación
Fuente: Monasterios
En base a lo anterior mencionado expuesto a continuación se desarrolla al análisis

de los costos empezando por los costos fijos.
5.1.1. Costos Fijos
Los costos fijos son aquellos que permanecen constantes ante la variación de la
cantidad a producir, es decir, que no dependan de cuanto se produzca por que se
mantienen.
188
Para el presente proyecto los costos fijos son: costos de licencia de software,
costo de hardware, costo de desarrollo de software. A continuación se desarrollan
cada una de ellas.
5.1.1.1. Costos de licencia de software.
Los costos estimados para la adquisición de licencia son las siguientes:
Tabla 5.1. Costos de Licencias
COSTOS DE SOFTWARE $us

Windows 7 60,00
SQL Server 2008 209,00
Vmware workstatio 9.1 100,00
Total 369,00
Por lo anterior se puede apreciar que los costos de software son de 369 $us lo
cual a su vez es el costo total de las licencias en el área de software que
permitieron el desarrollo del gestor de contenidos digitales del presente proyecto
de grado.
5.1.1.2. Costos de Hardware
Los costos estimados, para la adquisición de equipos están detallados en la

siguiente tabla 5.2.
Tabla 5.2. Costos de Hardware
COSTOS DE HARDWARE $us

Servidor 5000,00
PC 1200,00
Total 6200,00
La anterior tabla nos muestra los costos de los equipos de hardware y del
correspondiente costo total de la adquisición de los mismos equipos para la
189
implementación del gestor de contenidos y pueda soportar los datos que se
cargaran en el mismo servidor
5.1.1.3. Costos de desarrollo de Software
Para la determinar el costo aproximado del desarrollo del software, se utilizó el

modelo constructivo de costos (COCOMO), que resulta ideal para establecer el
costo monetario del esfuerzo en el desarrollo del sistema propuesto.
El modelo COCOMO incluye a su vez tres sub modelos, los cuales son:
 Modelo básico: este modelo estima de una manera rápida la mayoría de los
proyectos pequeños y medianos. Para este modelo se consideran tres modos
que son ; orgánico, semi-acoplado y empotrado
 Modelo intermedio: en este modelo se introducen quince atributos de costes
para tener en cuenta el entorno de trabajo. Estos atributos se utilizan para
ajustar el coste nominal del proyecto al entorno real, incrementando la
precisión de la estimación.
 Modelo detallado: este modelo puede procesar todas las características del
proyecto para construir una estimación. Incluye dos características principales,
que son los multiplicadores de esfuerzo sensitivo a la fase y la jerarquía del
producto a tres niveles.
Para el proyecto se determinó la utilización del modelo básico ya que es el mejor

que se ajusta a las características del sistema y siendo que este no supera las
50.000 líneas de código.
El modelo COCOMO básico considera tres modos de desarrollo como se

mencionó anteriormente, los cuales utilizan parámetros de métricas de punto de
función. Estos puntos se muestran en la tabla 5.3.
190
Tabla 5.3. Costos de Hardware
MODO a b c d
Orgánico 2,40 1,05 2,50 0,38
Semi-Acoplado 3,00 1,12 2,50 0,35
Empotrado 3,60 1,20 2,50 0,32
Las ecuaciones que se utilizan en el modelo básico para el cálculo del costo del
software son las siguientes.
E = a * (KLCD)b
T = c * Ed
P=E/T
C = P * SM * T
Dónde:
KLCD: cantidad de líneas de código en miles.
E: esfuerzo aplicado en personas / mes.
T: tiempo de desarrollo en meses.
P: número de personas necesarias.
SM: Salario mínimo por persona.
C: coste total de desarrollo del sistema.
a, b, c, d: contantes del modelo COCOMO Básico.
Como primer paso para la aplicación del modelo de COCOMO, se realizó el

conteo exacto de las líneas de código del sistema, cuyo detalle se presenta en la
tabla 5.4.
191
Tabla 5.4: Tamaño del proyecto
Tamaño del Proyecto

Componentes Líneas de código
Líneas programadas 1.197
Líneas de código de comentarios 1.209
Líneas generadas automáticamente 4.251
Total 6.657
Por lo tanto según el número de líneas de código extraído de la tabla anterior se

aproxima a unas 6.657 líneas lo que en kilo líneas de código representa la
siguiente cantidad 6.657.
En base a los resultados obtenidos se pudo aplicar las formulas anteriormente

presentadas. El proceso es el siguiente.
PM = 2,4 * (6,657)1,05
PM= 17,57 personas / mes
Una vez obtenido el esfuerzo aplicado, se utiliza este valor para calcular el tiempo
de desarrollo T.
T = 2,5 * (17,57)0,38
T=7,43 ≈ 8 meses
Se establecen 9 meses como tiempo necesario para el desarrollo del proyecto.
P = 17,57 / 7,43
P = 2,37 ≈ 3 personas
Con los valores del esfuerzo aplicado y el tiempo de desarrollo de obtuvo la

cantidad de personas necesarias para el proyecto que es igual a 3.
C = 3 * 286,53 * 8
C = 6.876,79 $us
192
Considerando a 3 personas, cada una con un sueldo mínimo de mensual de
2.000Bs que son equivalentes a 286,53 $us para el desarrollo del proyecto en 9
meses se calculó el costo total de desarrollo del sistema, el cual asciende a
6.876,79 $us.
5.1.1.4. Costos de Capacitación
La tarea de capacitación incluye tanto la preparación del docente de la materia

como a los mismos estudiantes de la universidad, para la correcta administración
de la herramienta de apoyo. Se estima que esta actividad tendrá un costo de 150
$us y se realizará cada que la universidad así lo requiera, pero se recomendaría
que se realice cada 2 años brindando una conveniente forma de costo operativo.
5.1.1.5. Costos de Soporte
Los costos de soporte incluyen el mantenimiento del sistema por lo menos una vez
cada año, el cual asciende a 200 $us por año y por ende se establece como un
costo operativo para el proyecto.
5.1.2. Costos Variables
Entre estos costos que se han tomado en cuenta como variables se consideran los
costos por elaboración del Trabajo de Grado que son costos de investigación y
costos de materiales de escritorio.
5.1.2.1. Costos de Investigación
Los costos de investigación, están relacionados de forma directa a los gastos que
se realizaron para obtener y recopilar toda la información que se refiere a los
fundamentos tanto teóricos como prácticos que fueron necesarios para la
elaboración del presente Trabajo de Grado. Estos costos mencionados se
encuentran en la tabla 5.5.
193
Tabla 5.5: Costos de Adquisición de Información
Descripción Cantidad Costo Unitario $us Costo total $us

Libros 1 20,00 20,00
Fotocopias 2.000 0,01 20,00
Internet 250 0,28 70,00
Total 110,00
Fuete: Elaboración Propia
5.1.2.2. Costos de Material de Escritorio
En este punto se toma en cuenta los gastos incurridos durante todo el proceso de
análisis, diseño y desarrollo en sus diferentes etapas en la siguiente tabla 5.6.
Tabla 5.6: Costo Material de Escritorio
DESCRIPCION COSTO ($us)

Hojas Bond 80,00
Anillados 33,00
Empastados 30,00
Cartuchos de tinta y la misma tinta 45,00
Fotocopias 15,00
Transporte 55,00
CD 10,00
Total 268,00
A continuación se definen los costos fijos como los costos variables, se hace la
suma para extraer el costo total en la siguiente tabla 5.6.
Tabla 5.6: Costo Material de Escritorio
Factor COSTO ($us)

Costo de hardware 6200,00
Costo de software 369,00
Costo de desarrollo del sistema 6876,79
Costo de capacitación 150,00
Costo de investigación 110,00
Costos de indirectos 268,00
Total 13.973,79
194
5.2. ESTIMACIÓN DE LOS BENEFICIOS
Los beneficios pueden ser tangibles como intangibles, ambos deben tomarse en
cuenta en el sistema:
5.2.1. Beneficios Tangibles
El principal beneficio tangible de la utilización de la herramienta provendrá de la

reducción notable de los costos al brindar la información a los estudiantes.
Para estimar los costos de este beneficio se utilizó el método de valoración, el cual
propone siete pasos para el cálculo de los costos sobre el acceso a la información.
La aplicación de este método se presenta a continuación:
Paso 1. ¿Cuántos sistemas actuales, similares existen al sistema propuesto?
Rp. Dos, Sistema de aprendizaje para posgrado y la biblioteca virtual.
DS = 2
Paso 2. ¿Cuál es el costo de obtención de información por parte de los

estudiantes en cada periodo de clase que brinda el docente?
Rp. El costo de obtención de periodo es de 53 Bs / periodo, lo que equivale a 7,59

$us / periodo. Este dato fue obtenido del área de informática donde dividen a los
docentes en 4 categorías y la categoría más baja se considera el sueldo básico
que paga la universidad.
GC = 7,59 $us / periodo
Paso 3. ¿Cuánto es el costo de la toma de exámenes en el área de prueba?
Rp. Considerando que el curso de prueba es el 3º semestre de la carrera de

Ingeniería de Sistemas que cuenta con 18 estudiantes, el tiempo de la prueba
toma 1,5 de periodos de tiempo, las hojas de pruebas valen 0,50 Bs lo que
equivale a 0,07 $us y el examen vale 0,20 Bs lo que equivale a 0,03 $us
CR=20,56 $us / examen
195
Paso 4. ¿Cuánto costaran los exámenes de un semestre completo?
Rp. Tomando en cuento el dato encontrado en el anterior paso y multiplicándolo

por 3, que son los parciales en los cuales se toman los exámenes el resultado
seria 61,68 $us / exámenes del semestre
RS = 61,68 $us /exámenes semestre
Paso 5. ¿Cuál es al cálculo de los costos totales?
Rp. Este costo ya fue calculado en la anterior sección, el mismo es igual a

14.023,79 $us
DMC = 14.023,79 $us
Paso 6. Ahora solo se calcula el costo de acceso a la información sin el uso de la

herramienta.
Costo Sin Herramienta = DS*CG*CR*RS
Costo Sin Herramienta = 2 * 7,59 * 20,56 * 61,68
Costo Sin Herramienta = 19258,63
Paso 7. Ahora se calcula el costo de acceso a la información con el uso de la

herramienta.
Costo Con Herramienta = (DS * GC) + (CR * RS) + DMC
Costo Con Herramienta = (2 * 7,59) + (20,56 * 61,68) + 14023,79
Costo Con Herramienta = 15307,14
El costo de acceso a la información con el uso de la herramienta genera un ahorro

de 3951,49 $us por semestre, lo que demuestra la efectividad del uso del gestor
de contenidos como una herramienta de apoyo para el estudiante, brindando una
beneficio tangible de 7902,98 $us en el periodo de un año.
196
5.2.2. Beneficios Intangibles
El sistema de evaluación más que producir beneficios de valor monetario,

eliminará la subjetividad, también realizará una evaluación y calificación
automatizada si es que así lo prefiere el mismo docente.
Tabla 5.5: Tabla de beneficios intangibles
BENEFICIOS EN TAREAS DE REGISTRO

 Proporciona un registro de evaluación del estudiante.
 Facilidad en la búsqueda de registro del estudiante.
BENEFICIOS EN TAREAS DE RESULTADOS
 Velocidad de calificación.
 Aporte de preguntas objetivas.
 Registro automatizado del examen.
BENEFICIOS EN LAS TAREAS DE ALMACENAMIENTO
 Registro automatizado de respuestas de exámenes.
 Registro de estudiantes.
 Registro de nota de estudiantes en cada etapa.
BENEFICIOS EN CARÁCTER SOCIAL
 Coadyuva al docente en la calificación.
 Reduce el tiempo de registro de notas.
 Mitiga la corrección de exámenes, ahorrando tiempo.
5.3. RELACIÓN COSTO BENEFICIO

Para determinar la relación costo beneficio se realizó el flujo de caja
correspondiente al proyecto determinándose a su vez el VAN (Valor Actual Neto),
cuya fórmula es la siguiente:
197
𝑁 𝑄𝑛
VAN = −𝐴 + ∑
𝑛=1 (1 + 𝑖)𝑛
Dónde:
Qn: Representa los flujos de caja.
A: Es el valor del desembolso inicio de la inversión.
N: Es el número de periodos considerados.
i: Tipo de interés.
A continuación, en la tabla 5.6, se presenta el flujo de caja del proyecto en el cual

para el cálculo del VAN se tomó en cuenta una tasa de interés del 15%.
Tabla 5.6: Flujo de caja del proyecto
DETALLE Año 0 Año1 Año 2 Año 3 Año 4

Ingresos 0,00 7902,98 7902,98 7902,98 7902,98
Costo de Capacitación 0,00 150,00 0,00 150,00 0,00
Costo de Soporte 0,00 200,00 200,00 200,00 200,00
Amortización Intangibles 0,00 3455,95 3455,95 3455,95 3455,95
UAI 0,00 4097,03 4247,03 4097,03 4247,03
Impuestos 25 % 0,00 1024,258 1061,758 1024,258 1061,758
UDI 0,00 3072,77 3185,27 3072,77 3185,27
Costo de Hardware 6200,00 0,00 0,00 0,00 0,00
Costo de Software 369,00 0,00 0,00 0,00 0,00
Costo de Desarrollo 6876,79 0,00 0,00 0,00 0,00
Costo de Investigación 110,00 0,00 0,00 0,00 0,00
Costos Indirectos 268,00 0,00 0,00 0,00 0,00
amortización intangibles 0,00 3455,95 3455,95 3455,95 3455,95
Flujo Neto -13823,79 6528,72 6641,22 6528,72 6641,22
Van 4.964,96
Tir 32%
198
Después de haber realizado el flujo de caja correspondiente a los costos y los
beneficios percibidos para el caso de estudio, se obtuvo un VAN de 4.964,96 $us
en una proyección a 4 años, con una tasa de interés de 32%, lo que significa una
ganancia sobre la inversión del proyecto, con lo que se puede afirmar que este es
económicamente viable.
Una vez elaborado y descrito cuales son los costos y cuales los beneficios del
proyecto, se procede a realizar el análisis de costo – beneficio mediante la
siguiente ecuación:
𝐵𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑜 𝑃𝑜𝑠𝑖𝑡𝑖𝑣𝑜 − 𝐵𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑜 𝑁𝑒𝑔𝑎𝑡𝑖𝑣𝑜

𝐴𝐵𝐶 =
𝐶𝑜𝑠𝑡𝑜𝑠
Dónde:
 Los beneficios positivos, son todos los ingresos, en este caso 14.845,21$us.
 Los beneficios negativos, serían las pérdidas del sistema que en este caso es
cero.
 Los costos son todo lo invertido en la construcción del sistema, es decir, el
costo total del proyecto que asciende a 13973,79 $us.
Reemplazando lo anterior
En la ecuación tenemos:
14845,21
𝐴𝐵𝐶 = = 1,06
13973,79
El criterio de esta evaluación indica que:
 ABC > 1 implica que los ingresos son mayores a los egresos, entonces el
proyecto es aconsejable.
 ABC = 1 implica que los ingresos son iguales a los egresos, entonces el
proyecto es indiferente.
 ABC < 1 implica que los ingresos son menores a los egresos, entonces el
proyecto no es aconsejable.
199
Como en este proyecto el resultado es de 1,06 que es mayor a 1, se concluye que
el sistema es brindara buenos resultados ya que el proyecto producirá ingresos.
200
CAPITULO VI
CONCLUSIONES Y
RECOMENDACIONES
150
Resumen
En este capítulo se realiza la conclusión en relación al presente
proyecto de grado y las respectivas recomendaciones para
futuros proyectos.
6.1. CONCLUSIONES
Para concluir con la realización del este proyecto de grado, se llegaron a las
siguientes conclusiones:
 Se pudo evidenciar que un gestor de contenidos digitales se constituye como

una herramienta de apoyo en el aprovechamiento y maximización del
aprendizaje de la materia programación orientada a objetos.
 La plataforma desarrollada brinda información demandada por los estudiantes
que al estar administrada por el docente, responde a la programación y
cumplimiento de la curricula planteada para la materia.
 Considerando que la plataforma desarrollada cuenta con un módulo de
autoevaluación y detección del conocimiento adquirido, se puede notar que el
aprovechamiento se ha maximizado.
 La plataforma cuenta con herramientas que permiten Administrar la
organización de cursos, lo que facilita la asignación de permisos y medios,
pudiéndose obtener las estadísticas necesarias y requeridas para que se
facilite la información requerida por los usuarios del sistema, lo que constituye
una herramienta que evita la saturación tanto de los usuarios como de la propia
plataforma.
 El sistema se encuentra desarrollado para la materia de programación en JAVA,
el cual tiene todas las características necesarias para instalarla en la Web y
siendo de manejo intuitivo por parte de los usuarios finales.
 El sistema de gestor de contenidos se encuentra desarrollado para sola una
materia de una carrera, sin embargo el crecimiento del proyecto está en
constante desarrollo, lo que permitiría ampliar su aplicación a otras materias.
151
 El desarrollo de este sistema con más de un programa y sus lenguajes de
programación aumento la complejidad del desarrollo del sistema, pero se logró
el cumplimiento de los objetivos planteados en el presente Trabajo de Grado.
6.2. RECOMENDACIONES
Se recomienda a los usuarios tomar en cuenta los siguientes aspectos
 Se recomienda para el uso de este sistema los usuarios tienen que tener un
conocimiento básico de la computación.
 Es aconsejable que todos los usuarios que planeen utilizar el sistema lean el
manual de usuarios.
 Los docentes que deseen subir o cargar un libro de algún autor en el presente
sistema se les advierte que el desarrollador no se hace responsable por
posibles problemas legales que se puedan tomar en cuenta por el tema de los
derechos de autor.
 Se recomienda que los docentes de la materia de JAVA diseñen sus propios
materiales y si toman en cuenta párrafos o capítulos de libros con derechos de
autor se los mencione y a los mismos como referencias bibliográficas.
152
Bibliografía
Use Case Driven Object Modeling with UML . Doug Rosenberg y Kendall Scott,
1999.
Scrum and XP from the Trenches. Henrik Kniberg, 2007.
INGENIERÍA DE SISTEMAS. ETSIN, Octubre – Noviembre 2006
Ingeniería del Software, Un Enfoque Práctico. Roger Pressman, 6ta Edición
La Educación Superior a Distancia en America Latina y el Caribe Patricia Lupion

Torres Y Claudio Rama 2004 – 2005.
Estudio de los sistemas de gestión de contenidos web. Análisis de las mejores

soluciones del mercado (2012). Creative commons By-Sa.
desarrolloweb.com Tutorial de SQL http://www.desarrolloweb.com/manuales/9/
KASMIER, Leonard J. (2000). Estadística aplicada a la administración y a la

economía. 3era edición. México, Mcgraw-Hill
Departamento de métodos cuantitativos e informáticos facultad de ciencias de la

empresa universidad politécnica de Cartagena.
153
ANEXOS
154
ÁRBOL DE PROBLEMAS
Figura 1 Árbol de problemas
Los contenidos digitales

La jefatura de carrera y los actualmente no son
docentes no pueden administrados por los docente de
identificar en forma oportuna la materia del lenguaje de
y objetiva las carencias y el Los estudiantes no cuentan
programación JAVA lo cual con herramientas que les
grado de conocimiento ocasiona que los estudiante no
adquirido por el estudiante. Al permita promover la
dispongan del material adecuado educación
no contar con un medio según el avance de la materia
(sistema) que les permita compartida/colaborativa, que
realizada por el docente, fomenten la discusión de los
hacer un seguimiento de actualmente este contenido es
aprovechamiento y temas tratados en el lenguaje
administrado por la biblioteca de de programación JAVA.
evaluación permanente. la Escuela Militar de Ingeniería.
La alta complejidad de acceso a la información por parte de los estudiante a las actuales
plataformas con las que cuenta la EMI, no proporcionan contenidos de programación lenguaje
JAVA lo que ocasiona que el estudiante no pueda realizar una autoformación (consultas, repasos,
mecanismos para el seguimiento y autoevaluación) a distancia, independientemente del lugar y
hora (OFF LINE OFF TIME) en los repositorios digitales que deberían estar catalogadas bajo
diferentes criterios (temática, curso, especialización u otro).
Conocimientos insuficientes Confusiones en aulas en más Dificultad para abordar problemas

para un desempeño laboral de una materia por problemas prácticos y teóricos
de atención en clases
155
ÁRBOL DE OBJETIVOS
Figura 2 Árbol de objetivos
Desarrollar un sistema de Proporcionar un sistema de

gestor de contenidos que apoye gestor de contenidos que sea
el proceso de aprendizaje, La plataforma permite que los una herramienta que permita
permitiendo a las jefaturas de docentes administren el promover la educación
carrera y docentes identificar en contenido digital de sus compartida/colaborativa entre
forma oportuna y objetiva las materias en el caso específico los estudiantes que ingresen
carencias y el grado de del presente trabajo de grado, a la misma, esta herramienta
conocimiento adquirido por el del contenido digital del permite realizar la evaluación
estudiante en el lenguaje de lenguaje de programación continua de los conocimientos
programación JAVA. JAVA. adquiridos.
Desarrollar un sistema gestor de contenidos digitales para formar a los estudiantes de la EMI en el
lenguaje de programación java, y que así éstos puedan realizar su autoformación/autoevaluación
independientemente del lugar o la hora que así lo prefieran.
Conocimientos suficientes Bajas confusiones en aulas Abordar problemas prácticos y

para un desempeño laboral en más de una materia teóricos sin dificultad
156

Desarrollo de Un Gestor de Contenidos Digitales para La Autoformación en Programación 2013

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Desarrollo de Un Gestor de Contenidos Digitales para La Autoformación en Programación 2013

Uploaded by

Copyright:

Available Formats

ESCUELA MILITAR DE INGENIERÍA

"MCAL. ANTONIO JOSÉ DE SUCRE"

DESARROLLO DE UN GESTOR DE CONTENIDOS DIGITALES

JORGE CRISTOBAL CORTEZ CALLE

DESARROLLO DE UN GESTOR DE CONTENIDOS DIGITALES

Postulante: JORGE CRISTOBAL CORTEZ CALLE

TUTOR: Ms. Ing. SERGIO TORO TEJADA

1.1. Introducción ................................................................................................ 2

1.2. Antecedentes ............................................................................................ 3

1.2.1. Antecedentes Institucionales .................................................................... 3

1.2.2. Antecedentes Históricos........................................................................... 4

1.2.3. Antecedentes Académicos ..................................................................... 11

1.3. Descripción del caso de estudio.............................................................. 12

1.3.1. Reseña Histórica ..................................................................................... 12

1.3.2. Marco Legal ............................................................................................. 14

1.3.3. Misión y Visión de la EMI ........................................................................ 15

1.3.3.1. Misión ....................................................................................................... 15

1.3.3.2. Visión ....................................................................................................... 15

1.3.4. Referencias de un LMS........................................................................... 15

1.3.5. Descripción del caso de estudio ............................................................. 16

1.3.6. Descripción de la Problemática .............................................................. 18

1.4. Planteamiento del Problema ...................................................................... 19

1.4.1. Problema principal................................................................................... 19

1.4.2 Problemas secundarios .............................................................................. 19

1.5. Objetivos ..................................................................................................... 20

1.5.1. Objetivo principal ..................................................................................... 20

1.5.2. Objetivos secundarios ............................................................................. 20

1.6. Hipótesis ..................................................................................................... 20

1.6.1. Determinación de variables ....................................................................... 20

1.6.1.1. Variable Independiente ............................................................................ 21

1.6.1.3. Variable interviniente ................................................................................ 21

1.6.2. Matriz de Consistencia ............................................................................ 21

1.7. Justificación ................................................................................................ 21

1.7.1. Justificación Técnica ............................................................................... 21

1.7.2. Justificación Tecnológica ........................................................................ 22

1.7.3. Justificación Operativa ............................................................................ 22

1.8. Alcances y limites ....................................................................................... 22

1.8.1. Alcance Geográfico ................................................................................. 22

1.8.2. Alcance Temporal ................................................................................... 22

1.9. Aportes ........................................................................................................ 23

CAPITULO II MARCO REFERENCIAL .................................................................... 24

2.1. ESCUELA MILITAR DE INGENIERÍA ....................................................... 25

2.1.1. Acerca de la EMI ..................................................................................... 25

2.1.1.1. Quienes somos......................................................................................... 25

2.1.1.3. Visión ........................................................................................................ 25

2.1.1.4. Objetivo Institucional ................................................................................ 26

2.1.1.5. Historia ...................................................................................................... 26

2.1.2. Palabras del Rector ................................................................................. 27

2.1.2.1. No tratamos de educar, simplemente inspiramos ................................... 27

2.1.3. Convenios interinstitucionales (Nacional e Internacional) ..................... 28

2.1.4. Bienestar universitario ............................................................................. 29

2.1.5. Unidad Académica La Paz ...................................................................... 30

2.1.5.2. Director de la Unidad Académica de La Paz .......................................... 32

2.1.6. Ingeniería en Sistemas ........................................................................... 32

2.1.6.1. Perfil profesional ....................................................................................... 32

2.1.6.2. Misión de Ingeniería de sistemas ............................................................ 32

2.1.6.3. Objetivo de Ingeniería de Sistemas ......................................................... 33

2.1.6.4. Competencias por áreas .......................................................................... 33

CAPITULO III MARCO TEÓRICO ............................................................................ 34

3.1 TEORÍA DE SISTEMAS ................................................................................ 35

3.1.2. Ámbito metamórfico de la teoría ............................................................. 36

3.1.2.1. Descripción del propósito ......................................................................... 36

3.1.2.2. Descripción del uso .................................................................................. 37