Ingeniería de Sistemas

11/25/2013

PROPUESTA PARA TRABAJO DE GRADO ARQUITECTURA ORIENTADA A RECURSOS PARA APLICACIONES HIPERMEDIALES EN CONTEXTOS E-LEARNING

APLICACIÓN PRÁCTICA

CONSTRUIR UNA ARQUITECTURA ORIENTADA A RECURSOS QUE SOPORTE UN PROTOCOLO DE APLICACIÓN EN EL DOMINIO DE E-LEARNING

ESTUDIANTE(S)

Angélica María Vergara Granados __________________________________________ Documento Celular Teléfono fijo Correo Javeriano cc. 1032444177 3103094575 2229007 vergara.angelica@javeriana.edu.co

DIRECTOR

Ing. Julio Ernesto Carreño Vargas __________________________________ Documento Teléfono fijo Correo Javeriano Empresa donde trabaja y cargo cc. 13.508.444 3208320 ext 5311 carreno-j@javeriana.edu.co; Pontificia Universidad Javeriana; Profe-

sor Departamento de Sistemas

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 1

Contenido

1 OPORTUNIDAD O PROBLEMÁTICA .............................................................................3

1.1 DESCRIPCIÓN DE LA OPORTUNIDAD O PROBLEMÁTICA .............................................3 1.2 FORMULACIÓN ..........................................................................................................5 1.3 JUSTIFICACIÓN ..........................................................................................................5 1.4 IMPACTO ESPERADO DEL PROYECTO .........................................................................6

2 DESCRIPCIÓN DEL PROYECTO ...................................................................................7

2.1 OBJETIVO GENERAL ..................................................................................................7 2.2 OBJETIVOS ESPECÍFICOS ...........................................................................................7

2.3 ENTREGABLES O RESULTADOS ESPERADOS ..............................................................7

3 PROCESO .....................................................................................................................8

3.1 FASE DE CARACTERIZACIÓN .....................................................................................8 3.1.1 Metodología................................................................................................................ 8 3.1.2 Actividades ................................................................................................................. 8 3.1.3 Hitos ........................................................................................................................... 8

3.2 FASE DE DISEÑO .......................................................................................................9 3.2.1 Metodología................................................................................................................ 9 3.2.2 Actividades ................................................................................................................. 9 3.2.3 Hitos ........................................................................................................................... 9

3.3 FASE DE VALIDACIÓN ...............................................................................................9 3.3.1 Metodología................................................................................................................ 9 3.3.2 Actividades ............................................................................................................... 10 3.3.3 Hitos ......................................................................................................................... 10

4 GESTIÓN DEL PROYECTO .........................................................................................11

4.1 CALENDARIZACIÓN .................................................................................................11

4.2 PRESUPUESTO .........................................................................................................12 4.3 ANÁLISIS DE RIESGOS .............................................................................................13 4.4 DERECHOS PATRIMONIALES ....................................................................................16

5 MARCO TEÓRICO / ESTADO DEL ARTE ....................................................................17

5.1 FUNDAMENTOS Y CONCEPTOS RELEVANTES PARA EL PROYECTO. ...........................17

5.2 TRABAJOS IMPORTANTES EN EL ÁREA .....................................................................20

5.3 GLOSARIO ...............................................................................................................21

6 REFERENCIAS Y BIBLIOGRAFÍA ...............................................................................22

6.1 REFERENCIAS ..........................................................................................................22 6.2 BIBLIOGRAFÍA PROPUESTA PARA EL DESARROLLO DEL TRABAJO DE GRADO ..........23

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 2

ILUSTRACIONES

Ilustración 1. Entregables……………………………………………………………………………………………………8

Ilustración 2. Protocolo de Aplicación……………………………………………………………………………….20

TABLAS

Tabla 1. Cronograma de Trabajo……………………………………………………………………………………...12

Tabla 2. Estimación Horas Diarias…………………………………………………………………………………….12

Tabla 3. Estimación Horas Semanales………………………………………………………………………………12

Tabla 4. Estimación Horas por Fases…………………………………………………………………………………13

Tabla 5. Presupuesto de Recursos…………………………………………………………………………………….13

Tabla 6. Especificación Presupuesto de Recursos……………………………………………………………..14

Tabla 7. Clasificación del Riesgo……………………………………………………………………………………….15

Tabla 8 Riegos del Proyecto………………………………………………………………………………………………16

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 3

1 Oportunidad o Problemática

1.1 Descripción de la Oportunidad o Problemática

En contextos académicos, se requiere que el acceso a contenidos de aprendizaje sea virtual y para esto, dichos contenidos deben ser creados y almacenados en repositorios como pri-mera medida. Posteriormente se debe encontrar la forma de representarlos correctamente, los cuales se convierten en entidades de negocio que son representadas como recursos.

Con los diferentes avances tecnológicos en la web, los procesos de aprendizaje han cambia-do y hoy en día se da la posibilidad de implementar dichos procesos a través de e-learning, es decir diseñar, poner en práctica y evaluar un curso o plan informativo desarrollado, por medio de redes de computadores (Andrea M, 2009), es por esto que los sistemas de gestión de aprendizaje tienen la posibilidad de ofrecer este tipo de aprendizaje. Para que esto sea posible es necesario tener en cuenta el proceso que será utilizado para evaluar a cada con-sumidor del servicio, como por ejemplo un proceso de aprendizaje. Dicho proceso será to-mado como un protocolo de aplicación, es decir como un conjunto de interacciones legales necesarias para llegar a un objetivo (Jim Webber, 2010), en otras palabras se podría decir que será tomado como un proceso de negocio.

Construir aplicaciones basadas en e-learning es algo que se utiliza hoy en día en cualquier institución educativa, ya que es un medio que apoya el aprendizaje por parte del estudiante y que de igual manera, puede ser de apoyo para el docente. Estas aplicaciones, manejan diferentes contenidos académicos, los cuales son en su mayoría didácticos y son una forma diferente de fomentar el aprendizaje (Andrea M, 2009). Pero para construir estas aplicacio-nes, se debe tener en cuenta los requerimientos que debe satisfacer para que de esta ma-nera se logre identificar la alternativa que mejor se adapte a lo que se desea.

Por otra parte, muchas de estas aplicaciones existentes son hipermediales, es decir, mane-jan diferentes contenidos como imágenes, sonido, videos, entre otros y su conexión entre ellos (hipervínculos), pero no tienen un proceso de aprendizaje definido, es por esto que cuando se trata de aplicaciones hipermediales, la alternativa que se debe usar es REST (Ver Sección 5. Marco Teórico) ya que se acopla mejor por el manejo que proporciona a aquellos recursos que en este trabajo de grado serán mencionados como objetos virtuales de apren-dizaje (Ver Sección 5.Marco Teórico), y de igual manera permite establecer un proceso de aprendizaje, el cual en éste Trabajo de Grado será tomado como protocolo de aplicación, es aquí donde entra a jugar un papel importante las arquitecturas orientadas a recursos puesto que uno de los principios de estos dos últimos términos mencionados es la hipermedia (Savas Parastatidis, 2010), que por definición establece que es la herramienta que permite comunicar e interactuar a los usuarios mediante el uso de hipervínculos en diferentes tipos de contenido (Jim Webber, 2010). Teniendo en cuenta lo ya mencionado, se puede decir que aplicar esto es una alternativa nueva para diseñar e implementar aplicaciones hiperme-diales que estén basadas en un estilo arquitectural y que expongan protocolos de aplicación en contextos e-learning e integren la hipermedia (Savas Parastatidis, 2010).

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 4

Ahora es importante tener en cuenta que actualmente existen varios tipos de sistemas de gestión de aprendizaje que manejan contenidos de aprendizaje virtuales de diferentes ma-neras y están diseñados con diferentes estilos arquitecturales según sea la necesidad de cada uno, es aquí en donde entra una comparación entre las arquitecturas tipo SOA y REST. Una arquitectura tipo SOA (Arquitectura Orientada a Servicios) es una forma lógica de dise-ño de un sistema de software que permite proporcionar servicios a cualquiera de las aplica-ciones de usuario final o para otros servicios distribuidos en la red (Richard N. Taylor, 2010) (Ver Sección 5. Marco Teórico). Mientras que las arquitecturas tipo REST (Representational State Transfer), hacen referencia a una colección de servicios para el diseño de arquitectu-ras en red y son ideales para sistemas hipermedia distribuidos como lo es la web (Marset, 2006).

Con estas breves definiciones, se debe aclarar cuando es útil hacer diseños arquitecturales tipo SOA o REST. Si lo que se desea es establecer una descripción formal de cómo es la inter-faz del servicio, abordar requerimientos no funcionales y poco complejos (transacciones, seguridad, direccionamiento, entre otros) manteniendo información contextual y estados conversacionales, y centrado en el diseño de aplicaciones distribuidas, la solución que me-jor se acomoda es un estilo arquitectural tipo SOA; pero si por lo contrario, lo que se quiere es un servicio web que no mantenga estado, mejor rendimiento y conocimiento del conte-nido que va a ser comunicado entre consumidor y proveedor, la solución arquitectural que soporta esto debe ser tipo REST (Marset, 2006). Aun así es necesario aclarar las característi-cas correspondientes a cada uno, las arquitecturas tipo SOA generan ciertos requisitos para el intercambio de mensajes como es la implementación de SOAP (Simple Object Access Pro-tocol) que por definición es un protocolo de mensajería estándar usado en servicios web (ver Sección 5. Marco Teórico), el cual por lo general utiliza HTTP como medio de transporte para comunicar mensajes entre cliente y servidor.

Aterrizando un poco los estilos arquitecturales tipo REST, existen las arquitecturas orienta-das a recursos (ROA), que se basan en representaciones de recursos y acceso a éstos por medio de sus correspondientes URI (Universal Resource Identifier), ésta arquitectura usa el protocolo HTTP no como medio de transporte como en el caso de SOAP, sino como medio de interacción entre el cliente y el servidor, es decir que gracias a este protocolo se puede tener acceso a los recursos por medio de los métodos de éste protocolo; ROA maneja carac-terísticas específicas como lo es el direccionamiento que por definición dice que “una apli-cación es direccionable si expone sus datos o los aspectos interesantes de estos como recur-sos teniendo en cuenta la URI (Universal Resource Identifier) de cada uno de ellos” (ruby, 2007); escalabilidad se enfoca en que las peticiones realizadas al servidor sean únicas, es decir cada vez que el cliente realiza una petición ésta termina donde empezó (ruby, 2007); interoperabilidad se refiere a las formas de representación según el dispositivo para que el recurso pueda ser consumido, también depende del estado del recurso y es mostrado por el servidor en xml, página web o texto separado por comas, puesto de HTTP es un protocolo que no maneja estados, cuando se utiliza de manera adecuada permite interpretar cada mensaje sin tener conocimiento alguno de los mensajes precedentes (Marset, 2006); inter-face única ya que ROA sólo usa el protocolo HTTP, usa los 4 métodos básicos para el manejo de recursos (GET, PUT, POST, DELETE) (ruby, 2007).

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 5

Con esto, se puede decir que los objetos virtuales de aprendizaje pueden ser tratados como recursos en un sistema de gestión de aprendizaje (requieren tener tus propias URI’s para poder ser representados y trabajar con dicha representación) (Marset, 2006), posteriormen-te se pueden crear aplicaciones hipermediales teniendo en cuenta un protocolo de aplica-ción y así mismo tener en cuenta la novedad de contextos e-learning que permiten que los procesos de aprendizaje sean diferentes. Se puede decir que es una alternativa diferente para crear aplicaciones basadas en recursos (Jim Webber, 2010).

1.2 Formulación

¿Cómo construir sistemas distribuidos hipermediales que expongan protocolos de aplicación para contextos e-learning basados en una arquitectura orientada a recursos?

1.3 Justificación

Manejar objetos virtuales de aprendizaje como recursos en una arquitectura orientada a recursos, permite que el acceso a las representaciones de éstos sea más ágil gracias al uso del protocolo HTTP y de sus métodos. Pero el acceso a estos recursos debe estar definido en un orden según reglas establecidas, por esto la idea de un protocolo de aplicación basado en procesos de aprendizaje permite que esto sea posible, ya que al establecer un conjunto de interacciones entre los recursos (Jim Webber, 2010) hace que sea posible modificar el esta-do de la aplicación. Para que esto sea posible, es necesario escoger un diseño arquitectural que se acomode a lo que se quiere lograr, teniendo en cuenta lo mencionado anteriormente (Ver Sección 1.1Descripción de la Oportunidad o Problemática) el estilo más adecuado es una arquitectura orientada a recursos, puesto que sus ventajas permiten una facilidad en el diseño (interoperabilidad, rendimiento e interfaz única).

Cabe aclarar que SOA permite también desempeñar esta labor mencionada anteriormente, pero es un estilo arquitectural que se acomoda de mejor manera en otro tipo de contextos y aplicaciones, y de igual manera el intercambio de objetos virtuales de aprendizaje por medio de SOAP implica empaquetar el mensaje en un documento XML teniendo en cuenta la es-tructura de los sobres (envelope), encabezados (header) y cuerpo del mensaje (body) (Papazoglou, 2008), y enviar todo esto a través de HTTP. Ya que este Trabajo de Grado se centra en la idea del uso de una arquitectura orientada a recursos para construir aplicacio-nes distribuidas, es importante aclarar las ventajas de este estilo arquitecturas, que en otras palabras vienen siendo las misma que REST, por esto se aclara que dicho estilo se enfoca en escalabilidad y rendimiento para este tipo de sistemas y tiene como ventaja que maneja muchos recursos por medio de pocas operaciones ya definidas por el protocolo HTTP, mien-tras que SOA se centra en el diseño de dichas aplicaciones y maneja muchas operaciones pero con escasez de recursos (Marset, 2006).

Es importante aclarar que crear una aplicación que exponga protocolos de aplicación y que además, se base en procesos de aprendizaje permite al cliente extender y facilitar el acceso a la información no sólo a una persona sino de manera colectiva de tal forma que sea de

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 6

gran ayuda para aquellos que no pueden estar de manera presencial adquiriendo conoci-mientos en alguna asignatura o tema, dicha persona(s) que utilicen el servicio incrementará la autonomía y responsabilidad teniendo en cuenta el proceso de aprendizaje establecido y permite que las limitaciones de espacio/tiempo se hagan a un lado (Andrea M, 2009). De igual manera, permite que el aprendizaje logrado por el estudiante en una clase presencial, sea complementado por medio de aplicaciones hipermediales.

1.4 Impacto Esperado del Proyecto

El diseño arquitectural que se genere en este proyecto tiene como fin a corto, mediano y largo plazo, ser una base para la creación de plataformas que se encuentren en contextos e-learning de manera que aprovechen el uso de la hipermedia junto con objetos virtuales de aprendizaje. A corto plazo, se pretende que se use en el desarrollo de aplicaciones que se basen en procesos de aprendizaje en contextos de e-learning, teniendo en cuenta la crea-ción de objetos virtuales de aprendizaje y el correcto uso de estos en una arquitectura orientada a recursos.

A mediano plazo y a largo plazo, se pretende que la arquitectura propuesta sea parte de una plataforma de aprendizaje que haga parte del departamento de departamento de ingeniería de sistemas, de manera que se convierta en un apoyo para estudiantes en las aulas de clase y por fuera de estas.

Se tiene como meta principal, que el diseño arquitectural sea un apoyo para desarrolladores de aplicaciones y/o plataformas en contextos e-learning, manejando un protocolo de aplica-ción establecido junto con objetos virtuales de aprendizaje de modo que se generen dife-rentes alternativas, que apoyen el aprendizaje hacia los estudiantes.

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 7

2 Descripción del Proyecto

2.1 Objetivo general

Construir una arquitectura orientada a recursos que soporte un protocolo de aplicación en el dominio de e-learning.

2.2 Objetivos Específicos

Caracterizar el estilo arquitectural orientado a recursos en contextos de aprendiza-je.

Diseñar un protocolo basado en recursos hipermediales para una aplicación e-learning.

Diseñar una arquitectura dirigida por recursos que soporte el protocolo diseñado.

Validar la arquitectura mediante la implementación de un prototipo en el dominio de e-learning

2.3 Entregables o Resultados Esperados

Ilustración 1. Entregables.

Objetivo Específico 1

•Documento de investigación pertinente a una arquitectura orientada a recursos (Componentes, relaciones, restricciones, etc).

•Documento de investigación con especificación de objetos virtuales de aprendizaje en contextos e-learning.

•Documento de investigación con lista de objetos virtuales de aprendizaje adecuados para ser representados como recursos en una arquitectura orientada a recursos, y su respectiva representación.

Objetivo Específico 2

•Documento con la especificación del proceso de aprendizaje escogido.

Objetivo Específico 3

•Documento de arquitectura de software (S.A.D.)

Objetivo Específico 4

•Documentación de los objetos virtuales de aprendizaje creados y sus correspondientes especificaciones.

•Documentación del prototipo a implementar.

•Prototipo implementado con su respectivo código fuente.

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 8

3 Proceso

Para la realización de éste de trabajo de grado, se implementará una metodología SCRUM (Gallego), en donde como primera medida se generará un Product Backlog con los artefac-tos más relevantes que deben generarse, posteriormente se definirán los correspondientes Sprint Backlog que serán desarrollados en cada una de las fases metodológicas (estas serán tomadas como sprints en el desarrollo de éste proyecto). Se estimará una duración de 1 a 4 semanas por Sprint, en donde por cada una se realizará la ejecución del correspondiente Sprint Backlog y BurnDown chart (avance en horas del Product Backlog y/o Sprint Backlog). Cabe aclarar que las primeras fases de ése proyecto serán genéricas, con el fin de que el resultado de estas aplique para cualquier aplicación que se base en el proceso realizado.

3.1 Fase De Caracterización

Esta fase será tomada como Sprint 1 en donde se pretende desarrollar el objetivo específico 1 (Ver Sección 2.2 Objetivos Específicos), para realizar esto se implementará una metodolo-gía de investigación especulativa que permitirá desarrollar el primer Sprint Backlog.

3.1.1 Metodología

Para el desarrollo de éste Sprint se utilizará una investigación especulativa o deductiva, la cual permite que a través de conceptos se genere una estructuración teórica, que permita adaptar los elementos identificados en el contexto de una arquitectura orientada a recur-sos, teniendo en cuenta e-learning como el área en la que se trabajará.

3.1.2 Actividades

Identificar componentes, relaciones, restricciones, y otros elementos de una arqui-tectura orientada a recursos.

Identificar objetos virtuales de aprendizaje relevantes en el contexto de e-learning.

Identificar procesos de aprendizaje en e-learning.

Identificar tipos de objetos virtuales de aprendizaje adecuados para ser representa-dos como recursos en una arquitectura orientada a recursos.

3.1.3 Hitos

Documento con investigación pertinente a una arquitectura orientada a recursos (componentes, relaciones, restricciones, etc).

Documento con especificación de objetos virtuales de aprendizaje en contextos de e-learning.

Documento con diagrama de proceso de aprendizaje, que incluye de igual manera una especificación de cada una de las fases del mismo.

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 9

Documento con listado de objetos virtuales de aprendizaje adecuados para ser re-presentados como recursos en una arquitectura orientada a recursos, y su respecti-va representación.

3.2 Fase De Diseño

Esta fase será tomada como Sprint 2, en donde se desea dar solución a los objetivos especí-ficos 2 y 3 (Ver Sección 2.2 Objetivos Específicos) generando un diseño arquitectural que soporte los elementos identificados en el Sprint anterior y que adicionalmente tenga en cuenta el uso de objetos virtuales de aprendizaje.

3.2.1 Metodología

Para el desarrollo de éste Sprint, se usará una metodología de investigación inductiva, en donde por medio de los resultado adquiridos en el Sprint anterior, se pretende diseñar un protocolo de aplicación en base a un proceso de aprendizaje adecuado para contextos e-learning, y de igual manera se diseñará una arquitectura orientada a recursos que soporte tanto objetos virtuales de aprendizaje como el protocolo de aplicación diseñado.

3.2.2 Actividades

Determinar requerimientos arquitecturalmente significantes del dominio de proce-sos de enseñanza para e-learning.

Diseñar un protocolo de aplicación para contextos de e-learning basados en proce-sos de enseñanza.

Realizar el diseño de una arquitectura orientada a recursos focalizada en un proto-colo de aplicación diseñado.

3.2.3 Hitos

Documento con la especificación del proceso de aprendizaje escogido.

Documento S.A.D. (Documento de arquitectura de software).

3.3 Fase De Validación

Esta fase será tomada como Sprint 3, en donde se pretende dar solución al objetivo específi-co 4 (Ver Sección 2.2 Objetivos Específicos) generando un prototipo que permita verificar la implementación del Sprint anterior, se tomará un caso base para este Sprint puesto que la idea fundamental de éste proyecto se centra en el Sprint 2, dicho caso será un tema especí-fico de una asignatura del departamento de ingeniería de sistemas.

3.3.1 Metodología

Para el desarrollo de éste Sprint, se utilizará una metodología SCRUM (Larman, 2003), la cual permitirá por medio de iteraciones cortas, crear el prototipo correspondiente que permita

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 10

validar los resultados obtenidos en los Sprints anteriores. Se Establecerán 2 Sprints principa-les (construcción de objetos virtuales de aprendizaje y construcción de la aplicación), ya que se tendrán cuenta los resultados finales de los Sprints anteriores para poder desarrollar las etapas correspondientes a ésta última fase.

3.3.2 Actividades

Planeación (Product Backlog).

Puesta en escena (Identificación de requerimientos y priorización de los mismos).

Desarrollo (Elaborar Sprint Backlog para cada iteración, estas iteraciones desarrolla-rán el prototipo que pruebe la arquitectura planteada y de igual manera incluyen la creación de objetos virtuales de aprendizaje correspondientes).

Publicación (Documentación del prototipo).

3.3.3 Hitos

• Documento con Product Backlog del caso de estudio.

• Documento con requerimientos priorizados y especificados.

• Documento con Sprint Backlog correspondiente al caso de estudio.

• Documentación de los objetos virtuales de aprendizaje creados y sus correspondien-tes especificaciones.

• Documentación del prototipo a implementar.

• Prototipo implementado con su respectivo código fuente.

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 11

4 Gestión del Proyecto

4.1 Calendarización

Para realizar la estimación de duración de éste proyecto, se organizaron las actividades planteadas en la sección anterior (Ver Sección 3.Proceso), en sus correspondientes metodo-logías, del mismo modo se incluyeron fechas de inicio y de finalización para cada actividad, la estimación en horas a la semana, la persona responsable de realizar cada ítem allí esta-blecido, y el entregable que se debe generar para esa actividad (Ver Cronograma.xlsx). La siguiente tabla muestra una aproximación de lo que se acaba de explicar.

Cronograma de Trabajo

Tarea Fecha Inicio Fecha Finali-zación

Responsable Entregables Tiempo (ho-ras)

Metodología

Tabla 1. Cronograma de Trabajo

Para la asignación de horas por actividad, se tuvo en cuenta lo siguiente:

Estimación de horas diarias:

Día Lunes Martes Miércoles Jueves Viernes

Horas de Trabajo 8 8 8 8 8

Tabla 2. Estimación Horas Diarias

Estimación de horas semanales:

Horas por Semana Cantidad de Semanas Total

Horas de Trabajo 8 17 136

Tabla 3. Estimación Horas Semanales

Estimación de horas por fases:

Fases Horas Estimadas

1 32

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 12

2 40

3

Total

64

136

Tabla 4. Estimación Horas por Fases

Para una información más completa acerca del desarrollo de las actividades y su correspon-diente camino crítico, puede dirigirse al Diagrama de Gantt.pdf.

4.2 Presupuesto

Para el desarrollo de las actividades mencionadas en la sección anterior (Ver Sección 3.Proceso), se cuenta con los siguientes recursos:

Hardware

Computador $1.500.000.00

USB $20.000.00

Servicios

Internet $46.000.00

Energía $68.000.00

Transporte $62.000.00

Agua $100.000.00

Licencias $490.000.00

Otros

Conocimientos Previos $6.000.000.00

Costo Total $8.286.000.00

Tabla 5. Presupuesto de Recursos

Recursos Especificación

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 13

Computador Valor: $1.500.000.00

Propietario: Angélica Vergara

Marca: HP Pavilion dv4

SO: Windows 8 y Linux Mint.

Disco Duro: 250GB

RAM: 3GB

USB Valor: $20.000.00

Capacidad: 4GB

Internet Valor por mes: 46.000.00

6MB ETB

Energía Valor por mes: 68.000.00

Transporte Valor por semana: $15.550.00

Bus

Agua Valor por mes: $100.000.00

Licencias Valor: $90.000.00

Licencia Microsoft Office 2013

Valor $400.000.00

Enterprise Architec

Conocimientos Previos $6.000.000.00

Tabla 6. Especificación Presupuesto de Recursos

Algunos de los costos presentados anteriormente son fijos, es decir en el caso de Compu-tadores, medios de almacenamiento externo (USB), y licencias, son precios fijos, mientras que en el caso de los servicios se debe tener en cuenta que dicho valor es mensual y puede variar según sea el caso.

4.3 Análisis de Riesgos

Esta sección abarca aquellas situaciones que se pueden presentar y que de igual manera pueden ser inesperadas, generando dificultades durante el desarrollo de éste proyecto. Para comenzar, se manejará una tabla de Clasificación de Riesgo, que permitirá clasificar los ries-gos principales de éste Trabajo de Grado.

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 14

Cada riesgo será clasificado dentro de un porcentaje correspondiente a un rango. El siguien-te paso permitirá visualizar qué tan probable es que ocurra el riesgo y cuál sería su efecto.

Rango Probabilidad Efecto Prioridad

<10% MB Insignificante 1

10%-25% B Marginal 2

25%-50% MOD Serio 3

50%-75% A Crítico 4

>75% MA Catastrófico 5

Tabla 7. Clasificación del Riesgo

La columna de probabilidad se encuentra denotada de la siguiente forma: MB (muy bajo), B (bajo), MOD (moderado), A (alto), MA (muy alto).

En la siguiente tabla se enuncian los posibles riesgos para cada fase y su correspondiente análisis.

Riesgos del Proyecto

Fase Riego Rango Probabilidad Efecto Prioridad

Categorización

Retraso en el desa-rrollo de alguna actividad

50% A Crítico 4

Falta de evidencia bibliográfica para el desarrollo de cada actividad

45% MOD Serio 3

Retraso en la ela-boración de entre-gables para cada actividad

30% MOD Serio 3

Diseño

Retraso en el desa-rrollo de alguna actividad

50% A Crítico 4

Identificación inco-rrecta de requeri-mientos arquitec-

20% B Marginal 2

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 15

turalmente signifi-cantes

Diseño no adecua-do del protocolo de aplicación

15% B Marginal 2

Diseño arquitectu-ral no adecuado

10% B Marginal 2

Falla en la correc-ción de actividades anteriores.

35% MOD Serio 3

Retraso en la ela-boración de entre-gables para cada actividad

30% MOD Serio 3

Validación

Retraso en el desa-rrollo de alguna actividad

50% A Crítico 4

Falla en la correc-ción de actividades anteriores.

35% MOD Serio 3

Retraso en la ela-boración de entre-gables para cada actividad

30% MOD Serio 3

Falla en el levan-tamiento de re-querimientos del caso de estudio

35% MOD Serio 3

Tabla 8 Riegos del Proyecto

La mitigación de los riesgos identificados en la tabla anterior se basará en las revisiones dia-rias de cada Sprint, verificando qué se ha hecho, qué se está haciendo, qué se va a hacer, y qué problemas se han generado con respecto a la actividad. De igual modo se realizarán controles de avance, se establecerán recordatorios para cada actividad especificando qué se debe hacer, cómo debería hacerse y para cuándo debería estar listo en entregable corres-pondiente. Solo si se ve la necesidad, se asignará tiempo extra para completar la actividad o resolver el problema que se presente respecto a ésta.

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 16

4.4 Derechos Patrimoniales

El presente Trabajo de Grado se llevará a cabo dentro del marco del grupo de investigación ISTAR de la Pontificia Universidad Javeriana de Bogotá y su resultado estará a disposición del grupo ISTAR para futuros trabajos en el área. Así mismo, el resultado del proyecto aportará al marco global del desarrollo del grupo ISTAR, servirá como base para futuros trabajos y proyectos del grupo, y estará a disposición del grupo, sin ninguna restricción de uso, ya sea éste de carácter académico o empresarial. El software producto de este trabajo de grado se licenciará bajo el modelo de software libre con licencia GPL.

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 17

5 Marco Teórico / Estado del Arte

5.1 Fundamentos y conceptos relevantes para el proyecto.

Para tener mayor claridad de lo que se quiere obtener con éste proyecto, se enunciarán con más profundidad aquellos conceptos fundamentales que juntos, lograrán dar una visión más amplia al lector.

Servicio web: Son sistemas que están especialmente diseñados para mantener una comunicación interoperable entre maquinas que se encuentren sobre una red. Por lo general, los servicios web “suelen ser APIs web que pueden ser accedidas dentro de una red (principalmente internet) y son ejecutados en el sistema que los aloja.” (Marset, 2006). Es común que los servicios web se comuniquen entre sí por medio del estándar SOAP (Simple Object Access Protocol) ya que la comunicación entre es-tos por lo general se da por medio de mensajes tipo XML.

Servicios web tipo REST: Este tipo de servicios intentan imitar el protocolo HTTP es-tableciendo una interfaz uniforme, por medio de un conjunto de operaciones están-dar y que son conocidas, en otras palabras métodos HTTP (GET, POST, PUT…), y por esta razón este tipo de servicios se encuentran enfocados en la interacción con re-cursos que posean estado. Por otra parte, es importante aclara que REST (Represen-tational State Transfer) es un estilo de arquitectura de software que se acomoda perfectamente a aplicaciones hipermediales como lo es la web. Trabaja estricta-mente con una colección de recursos para el buen diseño de arquitecturas en red (Marset, 2006).

SOAP: (Simple Object Access Protocol) es un protocolo de mensajería estándar que es utilizado en servicios web, que permite la invocación remota de métodos entre aplicaciones que pasan mensajes y datos de la forma request/response. Su objetivo principal es la comunicación entre aplicaciones. Cubre cuatro áreas específicas como lo es el formato del mensaje (puede ser empaquetado en un documento XML), la descripción (como el mensaje debería ser transportado usando HTTP si se trata de una interacción basada en la web, o SMTP si la interacción está basada en e-mail), un grupo de reglas (deben ser seguidas cuando se procesa un mensaje SOAP), y un grupo de convenciones (conversión de llamados RPC en mensajes SOAP y al contra-rio) (Papazoglou, 2008).

Arquitectura Orientada a Recursos (ROA): una arquitectura orientada a recursos es un estilo arquitectural tipo REST, que utiliza las ventajas de este como lo es el uso de información y representación de ésta a través de recursos (trabaja con representa-ciones de estos) por medio de métodos HTTP (GET, POST, PUT…), gracias a esto y a la identificación de recursos por medio de URI’s, este estilo arquitectural se basa en dos características fundamentales, accesibilidad y “statelessness”. Se puede decir que cuando se habla de accesibilidad se hace referencia a exponer un conjunto de datos como recursos, una vez realizado esto los recursos son expuestos a través de sus URI’s; cuando una aplicación es accesible da a conocer dichas URI’s de cada pie-za de información que podría servir. Esta justificación es uno de los aspectos más

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 18

importantes en cualquier sitio o aplicación web, ya que cuando es accesible, sim-plemente basta con una URI que permita mostrar el recuso sobre el cual se está tra-bajando sin tener la necesidad de descargar el sitio o aplicación web y enviarla como archivo adjunto a través de HTTP. Para concretar y ser más precisos acerca del prin-cipio de accesibilidad, se puede decir que para que esto ocurra, cada sitio o aplica-ción web debe tener su propia dirección, la cual debe ser única, en otras palabras su propia URI al igual que los recursos que allí se representen; Por otra parte, la segun-da característica de una arquitectura orientada a recursos es que es “statelessness”, es decir que no conserva estado conversacional, para que este término sea más cla-ro y fácil de entender se explicará de la siguiente manera, cada petición que se reali-ce debe incluir toda la información necesaria para que el servidor pueda cumplirla, puesto que éste no conserva la información de peticiones anteriores (Richard N. Taylor, 2010).

Protocolo de Aplicación: En hipermedia, se define protocolo de aplicación como aquel conjunto de interacciones legales necesarias para entender el comportamien-to de una aplicación, es decir su estado el cual se podría decir que es como se en-cuentra ésta en determinado estado del tiempo. Este protocolo define las reglas de interacción que lideran la interacción entre los integrantes de un sistema. Al mane-jar un protocolo de aplicación, el estado de la aplicación cambia constantemente gracias a un flujo de trabajo o la ejecución de un proceso de negocio, lo que implica que es posible construir aplicaciones que enuncien un flujo de trabajo usando hi-permedia (Savas Parastatidis, 2010). Al implementar un protocolo de aplicación usando hipermedia, ésta facilita la el uso de un proceso de negocio reduciendo el acoplamiento entre los servidores y consumidores. En pocas palabras, el uso de un protocolo de aplicación en aplicaciones hipermediales, permite quitar la dependen-cia de un WADL (Web Application Description Language) ya que el al definir el pro-ceso de negocio se está conociendo lo que la aplicación hace con exactitud. La si-guiente ilustración muestra un ejemplo de un protocolo de aplicación.

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 19

Ilustración 2. Protocolo de Aplicación. Tomado de (Jim Webber, 2010)

Aplicación Hipermedia: cuando se habla de hipermedia, se puede decir que es una tecnología que permite realizar una estructuración de la información (sonido, imá-genes, texto), a través de nodos interconectados por enlaces o links, dichos nodos contienen la información ya mencionada antes (Rolando, 2011). Por lo tanto se puede afirmar que una aplicación que maneje la hipermedia, se caracteriza por la transferencia de representaciones de recursos (en este caso el tipo de información mencionada anteriormente), los cuales contienen links que se encuentran ordena-dos según un protocolo de aplicación. Dichos links, pertenecen a otras representa-ciones de recursos que hacen parte de la aplicación. Por otra parte también se puede afirmar que el uso de la hipermedia permite captu-rar el estado actual de la aplicación por medio de documentos hipertexto, los cuales deben estar tanto del lado del servidor (quien sólo conoce el estado de sus recursos) como del lado del cliente (conoce el estado de la sesión). Esta función es realizada por el navegador, quien se encarga de recopilar aquella información necesaria o que simplemente debe cambiar el estado de algún recurso, navegando entre estos (Marset, 2006).

E-learning: Es una modalidad de enseñanza-aprendizaje que consiste en diseñar, poner en práctica y evaluar un curso, desarrollado en redes de computador y que a su vez, se puede definir como un tipo de educación ofrecida a personas que se en-cuentran geográficamente separadas o que actúan en tiempos diferentes al docen-te, empleando recursos informáticos (Andrea M, 2009). Se caracteriza por el desa-rrollo de un proceso formativo en aulas o entornos virtuales en donde hay una in-teracción estudiante-profesor de manera virtual, y en donde el estudiante de igual

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 20

manera mantiene una relación con las actividades y el material de aprendizaje. Cabe aclarar que e-learning también permite ser un apoyo de enseñanza-aprendizaje, ya que ofrece material didáctico que puede ser utilizado durante clases presenciales o para reforzar lo visto y estudiado en estas (Cabero, 2006).

Objetos Virtuales de Aprendizaje: Material digital de aprendizaje que se encuentra fundamentado en el uso de recursos tecnológicos y que sirven para adquirir cono-cimiento en un área específica (Díaz & Castel, 2010). “Es cualquier entidad digital que puede ser usada, re-usada o referenciada para el aprendizaje soportado en tec-nología” (IEEE). Son utilizados como recursos didácticos en aprendizaje en línea. Es-tán compuestos por título, palabras claves, objetivos o competencias, contenidos temáticos multimediales, ejemplos, actividades de repaso, evaluación, retroalimen-tación, y elementos de contextualización. Pueden ser modificados en cualquier momento con el fin de dar vigencia a los contenidos dependiendo de las necesida-des, y de igual manera pueden ser reutilizados diferentes veces en diferentes temá-ticas, pueden ser llevados a cualquier plataforma o entorno tecnológico educativo.

5.2 Trabajos Importantes en el área

Para este trabajo de grado se abarca el tema de e-learning junto con hipermedia, los cuales han sido manejados en diferentes tipos de estudios que son de gran importancia para justi-ficar la implementación de estos en ambientes académicos.

Uno de los estudios que se relaciona con este Trabajo de Grado se titula “Successful imple-mentation of e-learning: Pedagogical considerations” (Traxmedia Sdn Berhad, 2001), en donde se centra en identificar principios pedagógicos de las actividades de enseñanza-aprendizaje que son adecuadas para e-learning. Este tipo de trabajos e investigaciones, permite identificar cuáles son aquellos procesos de aprendizaje más adecuados para aplica-ciones que se enfocan en e-learning, de modo que muchas instituciones educativas hoy en día manejan e incorporan éste concepto como apoyo para el estudiante y/o el docente.

Otro estudio relacionado se titula “ReST-Based Web Access to Learning Design Services” (Dodero & Ghiglione, 2008), el cual relaciona recursos específicos utilizados en sistemas LMS (Learning Management System) y servicios relacionados con el área, del mismo modo afirma que el diseño de aprendizaje proporciona en este tipo de sistemas elementos fundamenta-les como lo son objetos de aprendizaje y los servicios que pueden ser utilizados para realizar un diseño correcto del aprendizaje. Este trabajo en particular permite aclarar el manejo de objetos de aprendizaje basados en el diseño de un proceso de aprendizaje, por lo cual apor-ta un conocimiento más amplio en cuanto a lo que se desea realizar para éste Trabajo de Grado.

En el estudio titulado “Learning objects as a uniform foundation for e-learning plattaforms” (Vossen & Jaeschke, 2003), establece una discusión sobre el uso de objetos de aprendizaje en contextos e-learning, en donde afirma que son unidades reutilizables de contenido de aprendizaje y que son generalmente utilizados en clases o cursos. Por esta razón se propone

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 21

en este estudio, que dichos objetos de aprendizaje sean almacenados en una base de datos en donde sean susceptibles a una asistencia técnica, ya que a partir de esto pueden ser utili-zados como base central en una plataforma de e-learning, que permita realizar un segui-miento del uso de estos objetos de aprendizaje por parte de los usuarios. Este estudio apor-ta un enfoque técnico sobre el manejo de objetos de aprendizaje en plataformas e-learning, por lo cual puede mostrar una idea diferente de cómo deben ser empleados para su correc-to uso.

5.3 Glosario

HTTP: Hypertex Transfer Protocol.

ROA: Resource Oriented Architecture.

SOA: Service Oriented Architecture.

REST: Representational State Transfer.

SOAP: Simple Object Access Protocol.

LMS: Learning Management System.

OVA: Objetos Virtuales de Aprendizaje

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 22

6 Referencias y Bibliografía

6.1 Referencias

Andrea M, A. J. (2009). Tecedu.

Cabero, J. (2006). Bases Pedagógicas del e-learning. Revista de Universidad y Sociedad del Conocimiento.

Díaz, G. A., & Castel, P. A. (2010). SlideShare. Obtenido de http://www.slideshare.net/pablocastell/objetos-virtuales-de-aprendizaje-ova

Dodero, J. M., & Ghiglione, E. (Julio de 2008). IEEExplore. Obtenido de http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4721288

Fähnrich, K.-P. F. (2009). REST and Resource-Oriented Architecture. Proceedings First International Symposium, 11.

Gallego, M. T. (s.f.). Metodología SCRUM. Catalunya, España.

IEEE. (s.f.). IEEE Revista Iberoamericana de Tecnologias del Aprendizaje.

Jim Webber, S. P. (2010). Rest in Practice. Sebastopol: O'Reilly.

Larman, C. (2003). Agile & Iterative Development.

Marset, R. N. (Julio de 2006). Universidad Politécnica de Valencia. Obtenido de http://users.dsic.upv.es/~rnavarro/NewWeb/docs/RestVsWebServices.pdf

Papazoglou, M. P. (2008). SOAP: Simple Object Access Protocol. Tilburg, Holanda.

Richard N. Taylor, N. M. (2010). Service-Oriented Architectures and Web Services. En N. M. Richard N. Taylor, Software Architecture: Foundations, Theory and Practice. Wiley.

Rolando, F. L. (Agosto de 2011). Universidad de Palermo. Obtenido de http://fido.palermo.edu/servicios_dyc/publicacionesdc/vista/detalle_articulo.php?id_articulo=6478&id_libro=270

ruby, L. R. (2007). RESTful Web Services. En L. R. ruby, RESTful Web Services.

Savas Parastatidis, J. W. (2010). researchgate. Obtenido de www.researchgate.net/...The_role_of_hypermedia_in_distributed_system_development

Traxmedia Sdn Berhad, 1.-1. J. (2001). The internet and higher education . L. Dringus.

Vossen, G., & Jaeschke, P. (2003). Learning objects as a uniform foundation for e-learning platforms. Database Engineering and Applications Symposium, 2003. Proceedings. Seventh International, 278 - 287.

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 23

6.2 Bibliografía Propuesta para el desarrollo del Trabajo de Grado

6.3

ACHICANOY MIRANDA, J. J. (2008). OBJETOS VIRTUALES DE APRENDIZAJE - OVAS. 3.

Allamaraju, S. (2010). Restful Web Services Cookbook. O'reilly.

Castillo Cortés, J. (2009). Universidad de la Rioja. Obtenido de http://dialnet.unirioja.es/servlet/articulo?codigo=3019056

Castillo, J. (2008). Universidad del Valle. Obtenido de http://redes-univalle.blogspot.com/2008/06/objetos-virtuales-de-aprendizaje.html

Dominique Guinard, V. T. (2010). The College of Information Sciences and Technology. Obtenido de http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.173.3354

Dominique Guinard, V. T. (2011). From the Internet of Things to the Web of Things: Resource-oriented. Springer.

Duggan, D. (2012). Resource-Oriented Architecture. Stevens Institute of Technology, USA.

Enrique Chavarriaga Bautista, F. D. (2011). Sistema para la generación automática de contenido y evaluación para. 6.

Erazo, G. E. (2010). Objetvos Virtuales de aprendizaje. Revista Criterios, 10.

Erik Sundvall, M. N. (2013). Applying representational state transfer (REST) architecture to archetype-based. BMC Medical Informatics and Decision Making, 25.

F. Belqasmi, R. G. (2011). Restful Web Services for service provisioning in next- generation. Communications Magazine, IEEE.

Fähnrich, K.-P. F. (2009). REST and Resource-Oriented Architecture. Proceedings First International Symposium, 11.

Granada, C. d. (2005). Guía para la generación de contenidos educativos en entornos virtuales. 40.

Guinard, D., SAP Res., E. Z., & Trifa. (2010). A resource oriented architecture for the Web of Things. Internet of Things (IOT).

López Gúzman, C. (2005). Los Repositorios de Objetos de Aprendizaje como soporte a un entorno.

Sanchez, L. F., Pabón, G. A., & Bohórquez, L. F. (s.f.). Universidad Francisco de Paula Santander. Obtenido de http://ova.ufps.edu.co/drupal/files/Objeto%20ROA/index.html

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Aplicación Práctica

Página 24

Soriano, D. J. (s.f.). Universidad Politécnica de Madrid. Obtenido de http://pegaso.ls.fi.upm.es/sos/images/documentacion/material_aux_t2/tema4_RestfulWS.pdf