ASISTENTE DE ENSEANZA

Antes de comenzar con el desarrollo del software mediante la metodologa

SCRUM se deben definir los roles propios de SCRUM. Estos roles se explican a
continuacin:
ROLES
SCRUM MASTER

GESTOR DE EQUIPO

PRODUCT OWNER

EQUIPO

DESCRIPCION
Es quien facilita las reuniones, protege
al equipo de distracciones y vela
porque se cumpla el proceso de
SCRUM como es debido.
Impulsa la comunicacin, busca
mejorar el proceso sin buscar
culpables, tolerando errores y
promoviendo la confianza entre cliente
y el equipo.
Define los objetivos del proyecto, dirige
los resultados y posee la autoridad para
la toma de decisiones.
Desarrolla el producto/proyecto, debe
ser organizado y posee miembros con
distintas especialidades y disciplinas.
Tabla 1. Roles en SCRUM

Objetivos

Establecer estrategias que

permitan asistir al profesor
en el diseo de diferentes
Escenarios de Aprendizaje
Colaborativo.

Actividades

Indagar mtodos pedaggicos de

aprendizaje colaborativo y las tcnicas
asociadas a estos mtodos para el diseo
de escenarios de aprendizaje colaborativo.
Seleccionar el mtodo pedaggico y las
tcnicas que sern implementadas en el
Asistente de Enseanza.

N
Semanas
Fecha de
Inicio:
01/07/2012
Fecha
Final:
01/12/2013

Especificar la arquitectura
base del Asistente de
Enseanza.

Desarrollar un prototipo
del Asistente de
Enseanza propuesto.

Integrar el Asistente de
Enseanza al sistema
Moodle.

Realizar experiencias BL
en asignaturas de la UPBMontera y en la
Universidad del ValleUNIVALLE-Cali apoyadas
por ambos sistemas: El
Asistente de Enseanza y
Moodle.

Definir criterios de evaluacin para el

proceso de actividades de aprendizaje
colaborativo
Determinacin de requerimientos
funcionales del Asistente de Enseanza.
Definicin de objetivos de diseo del
Asistente de Enseanza.
Realizacin de documento de diseo.
Diseo de interfaces grficas del Asistente
de Enseanza.
Diseo de los mdulos que permitirn la
implementacin de las funcionalidades
bsicas del Asistente de Enseanza
Realizacin de pruebas del prototipo
desarrollado
Definir mecanismos de integracin del
Asistente de Enseanza con el LMS
Moodle.
Determinar los niveles de interoperabilidad
e integracin del Asistente de Enseanza
desarrollado
Disear el modelo de datos que permitir la
integracin con la base de datos de Moodle.
Disear el plug-in tipo block que permitir
realizar la integracin del Asistente de
Enseanza propuesto y el Sistema Moodle.
Realizar pruebas de integracin del modelo
de datos y del plug-in tipo block y el sistema
Moodle.
Estudiar principios y modelos de BL que
permitan definir elementos de interaccin
tales como: usuarios, enfoque pedaggico y
tecnologas asociadas.
Indagar metodologas de BL y las
estrategias utilizadas para la realizacin de
experiencias BL.
Disear las experiencias BL en la UPBMontera.
Desarrollar las experiencias BL en la UPBMontera.
Disear las experiencias BL en la
UNIVALLE-Cali.

Desarrollar las experiencias BL en la

UNIVALLE-Cali.
Tabla 2. Objetivos y actividades.

Miembro del
Equipo SCRUM

Das
disponibles
durante el
objetivo

Horas
disponibles
por da

Total horas
disponible
s

Universidad
Pontificia
Bolivariana,
Montera
Leovy Echeverra
5
4
20
Rodrguez
Sergio Andres
5
4
20
Buendia Lopez
Ruth Cobos Prez
5
2
10
Tabla 3 Horas disponibles de cada miembro del grupo

Objetivo
Establecer estrategias que permitan asistir al
profesor en el diseo de diferentes
Escenarios de Aprendizaje Colaborativo.
Especificar la arquitectura base del Asistente
de Enseanza.
Desarrollar un prototipo del Asistente de
Enseanza propuesto.
Integrar el Asistente de Enseanza al sistema
Moodle.
Realizar experiencias BL en asignaturas de la
UPB-Montera y en la Universidad del ValleUNIVALLE-Cali apoyadas por ambos
sistemas: El Asistente de Enseanza y
Moodle.
Tabla 4. Prioridad de objetivos

Roles

Product
Owner

ScrumMaste
r
Scrum Team
Scrum Team

Priorida
d
5

4
3
2
1

GESTOR DE NOTIFICACIONES

1. METODOLOGA
Con el transcurrir de los aos los sistemas de software o sistemas de
cmputo nos han permitido optimizar la eficiencia laboral y
productiva de una empresa, pero en la actualidad el desarrollo de
estos sistemas ha aumentado su complejidad en tiempo, costo y
calidad. Las metodologas tradicionales empleadas para el
desarrollo de software no se estn adaptando a la velocidad de
cambio del mercado, la complejidad de los sistemas y el cambio
tecnolgico. Por esto se estn empleando metodologas agiles las
cuales surgen como alternativas a esas metodologas tradicionales
las cuales son muy rgidas, donde es necesario conocer desde el
inicio que producto necesita el cliente, los cambios no son
permitidos una vez iniciado el proyecto no se puede realizar
modificacin despus de terminar o revisar por completo el
proyecto, esto constituye una prdida de tiempo por falta de
agilidad flexibilidad de la metodologa.

La metodologa gil SCRUM propone colaboracin directa con el cliente,

predisposicin y respuesta a los cambios del proyecto, esta metodologa
tiene la particularidad de comunicacin verbal directa y simplicidad para
incrementar entregas frecuentes del desarrollo por lo tanto los Product
Owner o clientes pueden visualizar constantemente los avances del
proyecto. Scrum funciona de la siguiente forma:

1. Se determinan los roles del equipo de trabajo, los cuales son tres:
a) Product Owner: Es el cliente o dueo del producto, b)
ScrumMaster: Es el directo responsable del proceso Scrum y
asegura el cumplimiento de los roles y responsabilidades dentro
del proyecto, c) Scrum Team: Son los desarrolladores de las
funcionalidades del proyecto.

2. Determinar los Backlog que son los productos o los objetivos a

alcanzar, Sprint Backlog son las pequeas tareas que determinan
el cumplimiento de un objetivo y la grfica de progreso esperado
del proyecto segn Scrum.
3. Antes de iniciar cada iteracin, el equipo revisa las tareas
pendientes y selecciona la parte que entregar como un
incremento de funcionalidad al finalizar la iteracin (Sprint).
4. El equipo debe revisar los requisitos, considerar la tecnologa a
utilizar, evaluar su conocimiento y en forma colectiva determinar
la forma en la que implementara la funcionalidad.
5. Los Sprints Backlog es el tiempo en el cual se desarrolla un
incremento en la funcionalidad, la duracin mxima son 4
semanas y durante el Sprint no puede modificar el contenido de
los Sprint Backlog. Solo el Scrum Master puede cancelar un sprint
y debe ser por tres razones las cuales son:
a. La tecnologa seleccionada no funciona.
b. Han cambiado las circunstancias del negocio
c. El Scrum Team ha tenido interferencias.

Figura 1. Flujo de Scrum en el Gestor de Notificaciones.

Por lo anterior se decidi que la metodologa a utilizar para la ejecucin

del proyecto es la metodologa Scrum. A travs de esta metodologa se
pueden organizar los objetivos en una lista que define las prioridades de
cada objetivo que son los Product BackLog, en la Tablas 5 se presenta
esta informacin. Adems en la Tabla 6 se muestra el equipo de trabajo
con el nmero de das disponibles para trabajar en el proyecto, el
nmero de horas disponible por das a trabajar y los roles que
desempean dentro del proyecto con la finalidad de poder cumplir los
objetivos.

Objetivo

Priori
dad

Definir un sistema de historial de notificaciones para los

estudiantes y profesores.

Definir mecanismos de integracin del servicio con el LMS

Moodle.
Disear el servicio de conciencia de grupo.

Integrar el servicio de conciencia de grupo al sistema

Moodle mediante el desarrollo de interfaces Web Services.

Realizar experiencias BL en asignaturas de la UPBMontera.

Tabla 5. Lista de Objetivos

HORAS MINIMAS DE TRABAJO

Das laborales durante el objetivo

Miembro del
Equipo

Das
disponible
s durante
el
objetivo*

Horas
disponibles
por da

Total horas
disponibles

Carlos
Snchez
Alarcn

20

Leovy
Echeverra
Rodrguez

Ruth Cobos
Prez

Roles

Scrum Team
4

20
ScrumMaster

Universidad
Pontificia
Bolivariana,
Monteria

10

Scrum Team

Product
Owner
Tabla 6. Miembros del Equipo

El cronograma de actividades asociado al proyecto est organizado por

una lista de Product BackLog. Seguido tenemos una lista de actividades
por objetivos que son los Sprint Backlog los cuales se estar revisando
peridicamente cada semana para ver los avances del desarrollo y
determinar la grfica de progreso segn las estimaciones de tiempo
dadas por el equipo de trabajo.

Objetivos del
proyecto

Actividades

N Semanas
Fecha
Inicio:18/01/2012
Fecha Final:
31/01/2013

Definir un sistema
de
notificaciones
para los estudiantes.

Definir mecanismos
de integracin del
servicio con el LMS
Moodle.

Disear el servicio
de
conciencia
de
grupo.

Integrar el servicio

Determinar
la
estructura
de
notificaciones
que
recibirn
estudiantes.

las
los

Determinar
el
contenido
de
notificaciones
que
recibirn
profesores.

las
los

Determinar
comunicacin.

de

Determinar el tipo de mecanismo de

integracin

Definir los estndares para la integracin

y comunicacin

Determinar los niveles de flexibilidad e

interoperabilidad

Disear BD (Base de Datos), diagramas

UML que el servicio de conciencia de
grupo
requiera
para
su
ptimo
funcionamiento.

Disear
la
interfaz
donde
se
proporcionara la informacin al usuario
del servicio de conciencia de grupo WILy
Service.

Determinar los niveles de integracin del

la

estructura

de
conciencia
de
grupo
al
sistema
Moodle mediante el
desarrollo
de
interfaces
Web
Services.

Realizar
experiencias BL
asignaturas de
UPB-Montera.

en
la

servicio de conciencia
sistema MLS Moodle.

de

grupo

al

Determinar el tipo de integracin del

servicio de conciencia de grupo al
sistema Moodle.

Definir los protocolos de integracin del

servicio de conciencia de grupo al
sistema Moodle.

Capacitar un profesor que tenga un curso

asignado en la Universidad Pontificia
Bolivariana Seccional Montera

Crear un curso en la plataforma Moodle

Realizar experiencias BL para recoleccin

de datos y resultados de este proyecto.
Elaboracin de informe final
Tabla 7. Cronograma de actividades en Scrum.

18
5