Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Aplicación de La Metodología SCRUM - Elkin José Torres Martínez - USBCTG - 2012
Aplicación de La Metodología SCRUM - Elkin José Torres Martínez - USBCTG - 2012
Tutor
ING. DAMIAN BARRIOS CASTILLOS
CONTENIDO
RESUMEN
1. PROBLEMA DE INVESTIGACION
1.1 PLANTEAMIENTO DEL PROBLEMA
1.2 FORMULACION DEL PROBLEMA
1.3 JUSTIFICACION
1.4 OBJETIVOS
1.4.1 Objetivo general
1.4.2 Objetivos especficos
2. MARCO DE REFERENCIA
2.1 MARCO HISTORICO
2.2 INVESTIGACIONES PREVIAS
2.3 MARCO TERICO
2.3.1 Scrum
2.3.2 Sistemas de informacin
2.3.3 Lenguajes de Programacin
2.3.4 Html (HyperText Markup Language)
2.3.5 Php (PHP HyperText Pre-processor)
2.3.6 Base de datos
2.3.7 JavaScript
2.3.8 Metodologa Tradicional
2.4 MARCO CONCEPTUAL
3. DISEO METODOLOGICO
3.1 TIPO DE INVESTIGACION
3.2 DISEO ADOPTADO
3.3 ENFOQUE DE LA METODOLOGIA
3.4 TECNICAS DE RECOLECCION DE LA INFORMACION
3.4.1 Fuentes primarias
3.4.2 Fuentes secundarias
3.5 VARIABLES
3.6 OPERACIONALIZACION DE VARIABLES
3.7 PROCESAMIENTO DE LA INFORMACION
3.8 RECURSOS TECNOLOGICOS
3.8.1 El Paradigma de Programacin
3.8.2 Herramienta de Desarrollo de Software
3.8.3 Herramientas Software
3.8.4 Herramientas de Diseo
3.8.5 Herramientas Hardware
4. RESULTADOS
4.1 API: PUNTO DE PARTIDA COMO FUENTE DE SERVICIOS
4.2 REQUERIMIENTOS
4.2.1 Product Backlog
4.3 ITERACIONES DE IMPLEMENTACION DE LOS PRODUCTOS
4.3.1 Exposicin del Product Backlog
4.3.2 Resolucin del Sprint Backlog
4.3.4 Revisin del Sprint
4.4 DISEO Y DESARROLLO DE INTERFACES
4.5 EJECUCION DE PRUEBAS
3
VIII
2
2
4
4
6
6
6
7
7
8
9
9
14
15
16
17
18
19
20
20
22
22
22
22
23
23
24
24
25
26
26
26
27
27
28
28
29
29
34
35
38
38
39
42
53
77
CONCLUSIONES
REFERENCIAS
80
81
LISTA DE TABLAS
25
43
43
43
43
44
44
44
44
45
46
46
47
47
48
49
50
50
51
52
53
53
LISTA DE FIGURAS
Figura 1. Modelo general de la metodologa Scrum
Figura 2. Interaccin en arquitectura de capas
Figura 3. Vista de la arquitectura lgica implementada en el sistema de
informacin de la Universidad de San Buenaventura, Cartagena.
Figura 4. Product Backlog del Desarrollo
Figura 5. Sprint Backlog del Desarrollo
Figura 6. Avance de un Sprint
Figura 7. Actividades Sin Planeacin
Figura 8. Pgina de Inicio
Figura 9. Actualizar Mis Datos Datos Bsicos
Figura 10. Actualizar Mis Datos Datos Familiares
Figura 11. Actualizar Mis Datos Historial Laboral
Figura 12. Actualizar Mis Datos Historial Acadmico
Figura 13. Actualizar Mis Datos Idiomas
Figura 14. Ver Mis Datos Informacin Personal
Figura 15. Ver Mis Datos Informacin de Contacto
Figura 16. Prcticas Industriales- Bitcora
Figura 17. Prcticas Industriales Descargar Certificado
Figura 18. Actualizar Mis Datos Datos Bsicos
Figura 19. Actualizar Mis Datos Informacin Laboral
Figura 20. Actualizar Mis Datos Informacin Acadmica
Figura 21. Actualizar Mis Datos Idiomas
Figura 22. Actualizar Mis Datos Datos Complementarios
Figura 23. Mdulo Docentes Horario
Figura 24. Elecciones Estudiantiles Formulario de Inscripcin
Figura 25. Elecciones Estudiantiles Admisin
Figura 26. Elecciones Estudiantiles Votacin
Figura 27. Prcticas Industriales Subir Certificado
Figura 28. Prcticas Industriales Solicitudes
Figura 29. Prcticas Industriales listado de Amonestaciones
Figura 30. Prcticas Industriales Amonestaciones Respondidas
Figura 31. Solicitud Practicante - Identificacin de la Empresa
Figura 32. Solicitud Practicante - Requerimientos
Figura 33. Prcticas Industriales Ubicacin Estudiante
Figura 34. Solicitud Practicante - Ubicacin Empresa
Figura 35. Prcticas Industriales Ver Solicitudes
Figura 36. Formulario de inscripcin
13
30
31
36
40
41
48
54
55
56
57
57
58
59
60
61
61
62
63
64
64
65
66
67
68
68
69
70
71
72
73
74
75
75
76
77
LISTA DE ANEXOS
Anexo A. Cronograma de Actividades
Anexo B. Presupuesto
83
84
VII
RESUMEN
El xito del desarrollo de software no depende exactamente de
las
herramientas y las notaciones de modelado; tal vez tampoco sea garanta los
conocimientos que manejen el grupo de desarrolladores; ni tampoco la
metodologa que se siga en el desarrollo de los mismos. El xito est sin duda
en la mezcla de estos tres tems y de su adaptacin continua al entorno en el
que est inmersa la aplicacin.
El presente proyecto muestra el desarrollo de aplicaciones, en su parte de
interfaz de usuario, empleando Scrum como metodloga de desarrollo. Para
esto se describen las necesidades que se dan en un entorno particular, la
Universidad de San Buenaventura Cartagena, y los requerimientos
funcionales y no funcionales de la aplicacin.
La proliferacin de metodologas giles despert en el equipo de
desarrolladores, el deseo de mostrar las ventajas de esta nueva forma de guiar
el desarrollo de aplicaciones de forma rpida, con fcil adaptabilidad y para
grupos pequeos. Scrum se presenta como una metodologa que puede ser
utilizada con seguridad de xito en cuanto genera agrado del grupo de
desarrollo y del cliente, siendo a satisfaccin de este ltimo la garanta de xito
de cualquier aplicacin.
Como profesionales en el rea de ingeniera se debe, ms que encontrar una
solucin a una dificultad, dar una serie de posibles soluciones, que
dependiendo de las circunstancias y los limitantes, obtenga de forma ptima el
mejor resultado a determinada situacin.
VII
I
INTRODUCCION
Con la aparicin de la computacin digital, inicio el periodo de ms desarrollo
tecnolgico
jams
visto
por
la
humanidad:
viajes
espaciales,
telecomunicaciones, Internet, entre otros. Un elemento de importancia en este
desarrollo de tecnologas lo ha constituido el software, el cual facilita el manejo
del hardware.
El software, definido como un conjunto de instrucciones que controlan la
realizacin de tarea de un hardware, puede dividirse en varias categoras
basadas en el tipo de trabajo que realizan. Las dos categoras primarias de
software son, los Sistemas Operativos que controlan los trabajos del
computador como el mantenimiento de los archivos del disco y la
administracin de la pantalla, y el software de aplicacin que dirige las distintas
tareas para las que se utilizan el computador como edicin de textos, gestin
de bases de datos y similares.
Los desarrollos de hardware y software han sido muy dinmicos a la vez que
requieren de procesos cada vez ms complejos de produccin. Seguir una
metodologa no apropiada para el desarrollo puede llevar a consumir
demasiados recursos de tiempo o dinero, a la vez que se corre el riesgo de no
llenar las expectativas que tena el cliente con respecto al producto o
desarrolladores insatisfechos con el mismo. Encontrar y seguir la metodologa
adecuada para el tipo de desarrollo, marca el xito del software.
La utilizacin de las llamadas metodologas tradicionales en el desarrollo de
software (Cascada, RUP, entre otras), caracterizadas por la implementacin
de etapas secuenciales ejecutadas unas despus de otras, guiadas por una
planificacin rgida, con lo que pretende controlar todo el proceso (planificacin,
diseo, implementacin, evaluacin), son aplicadas cada vez
menos en
ambientes de desarrollo de software. En contraposicin, las metodologas
agiles han despertado un creciente inters, que las ha llevado a campos
diferentes al de la ingeniera de software.
Dentro de las diferentes propuestas de mejora al desarrollo secuencial se
encuentra Scrum. ste es una tcnica de desarrollo caracterizada por integrar
caractersticas de las metodologas giles a los que se aaden la
implementacin de iteraciones denominadas Sprint, que deja como resultado
un incremento ejecutable que se pueden mostrar al cliente y reuniones diarias
de 15 minutos a los largo del ciclo del Sprint, que permite al equipo
autorregularse, coordinarse e integrarse.
El inters del presente proyecto gira entorno a desarrollos logrados siguiendo
metodologas de desarrollo gil: especficamente Scrum. A lo largo del trabajo
se muestra la implementacin y resultados logrados a partir de esta
metodologa de trabajo, dentro de la elaboracin de frontend de las
aplicaciones (desarrollo de controladores e interfaces graficas de usuario) de
procesos acadmicos en la Universidad de San Buenaventura Cartagena.
Chapin, N., Hale, J.E., Khan, K.M., Ramil, J. and Tan, W. Types of software
evolution and software maintenance. Journal of Software Maintenance and
Evolution: research and practice. 2001. pp. 3-30.
1
Grupo ISSI. Metodologas giles en el Desarrollo de Software. Editorial
Alicante. Espaa, 12 de
Noviembre de 2003. pp. 9-16.
JUSTIFICACION
1.4 OBJETIVOS
1.4.1 Objetivo general. Implementar la Metodologa Scrum
Optimizacin de Procesos Acadmicos en la Universidad
Buenaventura, Cartagena.
para la
de San
1.4.2 Objetivos especficos. Identificar los servicios que ofrece la API diseada
por el CEV, buscando a partir de esto, tener una mayor apropiacin de los
recursos que sta provee.
Identificar los requerimientos que delimitan las funcionalidades de la segunda
fase.
Describir el proceso gua que lleva la metodologa Scrum en el desarrollo de los
productos de la fase dos.
Disear y desarrollar las interfaces de usuario que siguiendo la metodologa
Scrum, respondan a los diferentes requerimientos surgidos en los procesos
propios de la fase dos, logrando que sean amenas, intuitivas y prcticas
Disear y ejecutar pruebas que permiten evaluar los prototipos funcionales
desarrollados, detectando puntos de falla que stos puedan tener.
Elaborar un manual de implementacin que refleje en detalle el desarrollo de
aplicaciones utilizando la metodologa SCRUM a partir de los casos de xito
del CEV.
2. MARCO DE REFERENCIA
2.1
MARCO HISTORICO
Scrum fue mostrada por primera vez a mediados de los ochenta como nueva
prctica de produccin alcanzado por empresas de desarrollo tecnolgico como
Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard, y que
fue estudiada por Hirotaka Takeuchi e Ikujijo Nonaka. Con el artculo titulado
The New Product Development Game, Ikujiro & Takeuchi dieron continuacin
a otro artculo escrito con Kenichi Imai, llamado Managing the New Product
Development Process: How Japanese Companies Learn and Unlearn. En
estos expusieron una nueva prctica en el desarrollo de productos tecnolgicos
desplegada en Japn, resaltando el solapamiento de las fases de desarrollo
como su principal caracterstica, en contraste con los mtodos clsicos, los
cuales emplean desarrollos secuenciales, pero que en la prctica son en
realidad secuenciales con solapamiento.
En 1991 Peter DeGrace y Leslie Stahl hacen referencia al proceso mencionado
por Takeuchi y Nonaka con el trmino Scrum en su libro Wicked Problems,
Righteous Solutions (A problemas malvados, soluciones virtuosas), vocablo
que fue tomado del juego del rugby para describir procesos adaptativos, autoorganizativos y sin elementos innecesarios, y que ya haba sido utilizado por
estos ltimos.
A partir del trabajo realizado por Hirotaka Takeuchi e Ikujijo Nonaka, Jeff
Sutherland aplicara los principios de Scrum al desarrollo de Software en 1993
en Easel Corporation (actual Ascential Software Corporation), publicando en
1996 junto con Ken Schwaber, las prcticas que empleaba como vlidas para
gestionar el desarrollo de software OOPSLA 96 (Schwaber & Sutherland,
1996).
Paralelo a este proceso, a mediados de los 90, se dio la definicin de
desarrollo gil de software como una forma de contravenir hasta ese momento
las metodologas clsicas, las cuales se consideraban excesivamente pesadas
y rgidas por su carcter normativo y dependencia fuerte de las planificaciones
detalladas. Fue as como en 2001 miembros destacados de la comunidad de
software, creadores e impulsores de las nuevas metodologas de desarrollo, de
los cuales hacan parte Schwaber y Sutherland, bautizaron la nueva corriente
de metodologas de desarrollo como Metodologas Agiles.
En el mismo ao 2001 fue constituida la Alianza agil, una organizacin sin
animo de lucro que promueve el desarrollo gil de aplicaciones y del que
Scrum hace parte como modelo para gestionar el desarrollo de software.
Es decir, tareas
YAZY ,Sergio Adrin . Una experiencia prctica de Scrum a travs del aprendizaje
basado en proyectos mediado por TIC en un equipo distribuido PDF 2010 -2011; pp.
20 . Disponible en
http://gredos.usal.es/jspui/bitstream/10366/100082/1/TFM_YazyiSergio_Master.pdf.
Consultado el 22 de Marzo de 2012.
16
17
19
22
http://www.librosweb.es/javascript/pdf/introduccion_javascript.pdf, consultado el 25
de junio de 2012.
3. DISEO METODOLOGICO
3.1
TIPO
INVESTIGACION.
DE
DE
LA
Ibd., p. 188
Ibd., p. 190
25
Ibd., p. 191
26
Aplicacin Software
Procesos acadmicos
Base de datos
Scrum
Procesos
acadmicos
Base de
Datos
Scrum
DEFINICION
DIMENSION
Es un programa diseado Anlisis
para
automatizar
una
determinada tarea. Consta
de
una
serie
de Diseo
instrucciones lgicas y en
orden con el fin de cumplir Implementacin
un objetivo.
INDICADORES
Suficiente
Insuficiente
Simple
Complejo
Suficiente
Insuficiente
Administrativos
Los procesos acadmicos
son todos aquellos trmites
relacionados con la vida Acadmicos
acadmica
de
los
estudiantes referidos a los
procesos
de
matrcula,
pagos,
evaluacin
de
docentes, consulta de notas
y horarios.
Simple
Complejo
Simple
Complejo
Almacenamiento
Es un conjunto de datos
almacenados
sistemticamente para su
uso posterior, permitiendo Consulta
operaciones
como
actualizacin, borrado y
adicin de datos, adems
de
las
operaciones
fundamentales de consulta
Satisfactorio
Insatisfactorio
Satisfactorio
Insatisfactorio
Satisfactorio
Insatisfactorio
27
28
Ibd.
Procesador de 2.8GHz.
2GB DDR2 de Memoria RAM.
250GB de espacio en disco.
Sistema operativo Microsoft Windows XP, Vista 7.
4 RESULTADOS
4.1 API: PUNTO DE PARTIDA COMO FUENTE DE SERVICIOS.
Como punto de partida se tiene la Interfaz de Programacin de Aplicaciones
(API - Application Programming Interface) desarrollado en la Universidad de
San Buenaventura Cartagena, la cual est conformada por un conjunto de
funciones y procedimientos que ofrecen una serie de interfaces que pueden ser
utilizados por otras aplicaciones. Antes de iniciar con el desarrollo del presente
proyecto se debe aclarar que existen aplicaciones que ya estn usando las
diferentes interfaces que brinda la API, siendo las aplicaciones de optimizacin
de procesos acadmicos, parte de toda esta arquitectura de funcionamiento.
Las interfaces que brinda la API son transparentes para el desarrollador y no es
necesario conocerla a fondo para su uso. Conocer el nombre del servicio, as
como los parmetros de entrada y los retornos de cada uno de estos, es
suficiente para su utilizacin. Por polticas internas del lugar donde se
desarrollaron las aplicaciones, cierta informacin de funcionamiento y
seguridad no fueron suministradas, contando para la elaboracin de este punto
informacin muy general de todo el sistema que es descrita a continuacin.
La arquitectura de la infraestructura, es decir La topologa de despliegue,
depende directamente de las restricciones impuestas por el cliente, de las
necesidades de seguridad del sistema y de la infraestructura disponible para
29
desplegar el sistema . Las aplicaciones desarrolladas para la Universidad de
San Buenaventura siguen un despliegue distribuido, lo que permite separar
capas lgicas en distintos niveles fsicos, permitiendo al sistema aumentar la
capacidad, aadir ms servidores donde se necesiten, balancear la carga para
maximizar la eficiencia y aprovechar mejor los recursos.
Las capas (Layers) implementadas dentro del desarrollo de proyectos software
en la Universidad de San Buenaventura Cartagena se ocupan de la divisin
30
lgica de componentes y funcionalidad, brindando entre otras ventajas :
29
2
9
3
0
Componentes/Aspectos Horizontales de
la Arquitectura:
Proporcionan capacidades tcnicas genricas que dan soporte a capas
superiores. En definitiva, son bloques de construccin ligados a una
tecnologa concreta para desempear sus funciones.
Existen muchas tareas implementadas en el cdigo de una aplicacin
que se deben aplicar en diferentes capas. Estas tareas o aspectos
horizontales (Transversales) implementan tipos especficos de
funcionalidad que pueden ser accedidos/utilizados desde componentes
de cualquier capa. Los diferentes tipos/aspectos horizontales ms
comunes, son: Seguridad (Autenticacin, Autorizacin y Validacin) y
tareas de gestin de operaciones (polticas, logging, trazas,
monitorizacin, configuracin, etc.).
4.2 REQUERIMIENTOS
Como ya se manifest anteriormente, la informacin pertinente para el correcto
desarrollo de ste proyecto se obtuvo a travs de la asesora continua del
Coordinador Tecnolgico del CEV Javier Garca Altamiranda, el cual actu
como gestor de la idea de implementar Scrum y su posterior orientador en el
desarrollo del mismo, buscando mejorar el ndice de desarrollo de software.
Cabe tambin aclarar que se ha seguido las caractersticas principales de
Scrum como son las iteraciones de trabajo o Sprint y las reuniones diarias de
15 minutos. A partir de esto el Ingeniero Javier Garca ha realizado cambios en
el uso de artefactos as como ha seguido el consejo de incorporar otros como
lo es el del Juego de Pker utilizado para la asignacin de horas a las
actividades y que es propio de otra metodologa gil de desarrollo, ms
concretamente, Xtreme Programing.
La informacin acerca de la lgica de negocio se consign en las historias de
usuario; la elaboracin de stas se realiz a lo largo del desarrollo del proyecto,
en reuniones que integraron al Ingeniero Javier Garca y a la ingeniera Tulia
Ziga Quintana como representante de la Universidad, siendo el primero el
Representante del Cliente (Product Owner) y el Scrum Manager, dos roles bien
definidos dentro de Scrum.
Una vez decidido el tiempo por cada actividad y el tiempo disponible para el
trabajo del Sprint, se crearon los memos en donde se colocaba el nombre de la
actividad y el tiempo dedicado a la misma, colocndose en el Sprint Backlog.
El Sprint Bagklog era una herramienta que permita de forma visual, realizar
seguimiento y control a las tareas que iban circulando por las columnas de No
empezado, pasando por En Progreso y terminando en Completado.
4.3.3 Seguimiento y control gil. Una vez terminada la planeacin, se di inicio
al desarrollo del Sprint, y con ella una de las caractersticas claves de Scrum: la
reunin diaria. Esta era una reunin corta de 15 minutos que se realiza en lugar
y hora definida anteriormente, siendo dirigida normalmente por el Team Leader
o alguno designado por el. Se realiza de pie y a ella asiste todo el equipo de
trabajo.
El encuentro diario era una forma de mantener la auto-organizacin y auto
control entre los integrantes. En ella se contestan las tres preguntas claves, y si
se encontrase algn tipo de inconveniente se le comunica al Scrum Master
para que fuese l quien tomase las medidas al respecto. Se proceda como
viene a continuacin:
4.3.4 Revisin del Sprint. Cuando termin el Sprint se hace la revisin del
mismo. El Scrum master y a la vez representante del Cliente no slo revisaba
el entregable del producto o los demos sino tambin la calidad del trabajo, de
forma que no se pudiese disimular los cdigos desordenados, sin probar y de
mala calidad.
La revisin del Sprint tambin implicaba que el equipo hablase sobre lo que
funciona y lo que no, y se acordaban que cambios se queran intentar. Se
dejaba claro qu fue bien y qu se puede mejorar, buscando causas y
previnindolas en el prximo Sprint.
Llegado este punto, se iniciaba la planeacin del siguiente Sprint, siendo
definido la fecha y lugar durante la revisin del Sprint. En este punto el Product
Owner poda actualizar la pila del Product Backlog con cambios o nuevas
actividades. El Product Owner y el equipo estaban listos para empezar otro
ciclo de Sprint, por lo cual no haba tiempo de descanso, manteniendo un ritmo
sostenible y razonable.
Con lo descrito hasta el momento se ha detallado el proceso que se sigui para
el desarrollo del primer Sprint y fue repetitivo en el desarrollo de los siguientes
Sprint hasta la obtencin de los productos finales: Portal de Docentes,
Seguimiento de Prcticas, Portal Estudiante, Portal Egresados y Portal de
Elecciones. En total se realizaron 5 Sprint o iteraciones que se detallan a
continuacin:
Sub-Actividades
Obtencin de
Requerimientos
Comentario
Ninguno
Realizar Certificados
Prioridad
Tiempo
Media
4 Horas
Sub-Actividades
Definir que
certificados se
sistematizan
Definir procesos de
certificados
Estudiar Firma
Digital
Comentario
Ninguno
Media
4 Horas
Ninguno
Baja
2 Horas
Ninguno
Sub-Actividades
Definir Proceso
Comentario
Ninguno
Sub-Actividades
Diseo de UI
Controlador de
Envo de Correo
UI envo de correo
Alta
6 Horas
Media
2 Horas
Comentario
Mostrar Cdigo,
nombre y apellido,
y agregar botn
enviar
Enviar por SMPT,
sendmail, phpmail
WYSIWYG, array,
destinatario POST
Sub-Actividades
Agregar el estado
del Estudiante
Diseo UI
Baja
4 Horas
Comentario
Creacin HBM,
entidades API,
entidades PHP
Agregar atributo
estado
Sub-Actividades
Agregar Docente
a la UI
Comentario
Ninguno
Sub-Actividades
Cambiar Nombre
al Mdulo
Agrupar
Aprobadas por
semestre
Agrupar Cursos
Pendientes por
Semestre
Agrupar Pensum
del Programa
Comentario
Ninguno
Media
3 Horas
Ninguno
Media
3 Horas
Ninguna
Media
3 Horas
Ninguna
Sub-Actividades
Sincronizar cortes
con programacin
acadmica
Obtener periodo
acadmico por
GET
2 Horas
Comentario
Tener en cuenta el
nuevo reglamento
institucional
Ninguna
Urgente
6 Horas
Ninguno
Colocar como no
editables los
campos
pertinentes
Media
4 Horas
5 Siempre
editable datos
personales
6 Cuando no
existan datos
del nombre del
padre y de la
madre, ser
editables
Implementar
formulario de
Historial Laboral
como MODAL
Implementar
formulario de
Historial
Acadmico como
MODAL
Implementar
formulario de
Estudios de
Idiomas como
MODAL
Baja
2 Horas
Ninguno
Baja
2 Horas
Ninguno
Baja
2 Horas
Ninguno
Sub-Actividades
Definicin de
Procesos
Comentario
Ninguna
Sub-Actividades
Crear Solicitud de
Practicas
Prcticas Empresariales
Prioridad
Tiempo
Medio
2 Horas
Comentario
Posterior a la
creacin de la
solicitud, se debe
enviar un Mail al
responsable
(Coordinador de
Practicas)
Crear Mdulo de
Gestin de
Empresas
Crear Mdulo de
Finalizacin de
Practicas
Crear Mdulo de
Valoracin de
Practicante
Crear Mdulo para
Responder
Practicante
Medio
2 Horas
Ninguna
Medio
5 Horas
Ninguna
Baja
4 Horas
Valoracin de Inicial
y Valoracin Final
Media
5 Horas
Media
5 Horas
Este es el mdulo
en el que el
Coordinador decide
en donde se
realizar las
prcticas de
acuerdo con las
solicitudes.
Ninguna
Persistencia de Acaweb
Prioridad
Tiempo
Urgente
11 Horas
Sub-Actividades
Realizar Active
Record Factory
Realizar
Adecuacin del
Modelo
Urgente
Comentario
Ninguna
3 Horas
Ninguna
Sub-Actividades
Agregar entidad
Reconocimientos
Agregar Encuesta
a la BD
Baja
1 Hora
Realizar UI
Actualizacin de
Datos de
Egresados
Urgente
4 Horas
Agregar
Funcionalidad al
Mdulo
Urgente
6 Horas
Comentario
Agregar en API,
Acaweb y Base de
Datos
Ninguna
Sub-Actividades
Cambios en los
script en general
Inscripciones en
lnea provisional
Imprevistas Sprint 2
Prioridad
Tiempo
Urgente
4 Horas
Urgente
8 Horas
Comentario
Revisar todos los
scripts que utiliza la
pgina y verificar
algunos errores
presentes
Realizar un portal
provisional de
Inscripciones en
lnea para los
nuevos estudiantes
Implementar un
sistema de
validaciones
gramaticales
Urgente
8 Horas
Mejorar problemas
presentados al
entrar a los
portales desde
Internet Explorer
Urgente
6 Horas
Implementar un
sistema para evitar
que los usuarios
introduzcan letras,
smbolos o nmeros
cuando no son
permitidos.
(Validacin de todos
los campos)
Garantizar un
funcionamiento
adecuado en
Internet Explorer de
todos las
aplicaciones y
servicios que se
estn desarrollando
Sub-Actividades
Realizar
Diagrama de
Actividades
Realizar UI de la
matrcula en lnea
Matrcula en lnea
Prioridad
Tiempo
Media
4 Horas
Comentario
Ninguna
Media
4 Horas
Ninguna
Obtencin de Prematrcula
Urgente
3 Horas
Agregar Auditoria
Medio
3 Horas
Calcular la pre-matrcula
del estudiante de
acuerdo al semestre, las
materias que ha perdido
y al reglamente
Ninguna
Agregar y validar
Cursos
Urgente
8 Horas
Ninguna
Revisar
Seguridad
Urgente
8 horas
Ninguna
Obtener Cursos
Habilitados
Urgente
6 Horas
Ninguna
Guardar Matricula
Urgente
7 Horas
Ninguna
Sub-Actividades
Obtener
Calendario de los
cortes (API)
Funcionalidad del
Mdulo
Portal Docentes
Prioridad
Tiempo
Urgente
3 Horas
Comentario
Ninguna
Urgente
4 Horas
Ninguna
Mis Cursos
Medio
3 Horas
Crear UI
Urgente
4 Horas
Visualizar
estudiantes y sus
respectivos
correos
electrnicos por
curso.
Ninguna
Horario
Bajo
3 Horas
Ninguna
Realizar
Actualizacin de
Datos
Medio
4 Horas
Es Similar a la de
estudiantes y
egresados, pero
con datos nicos
para los docentes
Sub-Actividades
Estandarizacin
de los widgets
Prioridad
Medio
Refactor
Tiempo
5 Horas
Realizar cambios
necesarios para
la
interoperabilidad
entre los
navegadores web
Urgente
10 Horas
Reestructurar
Tamao de los
campos de texto
Redisear las
pestaas
Bajo
3 Horas
Bajo
3 Horas
Editar formulario
de envi de
correo
Medio
5 Horas
Comentario
Pestaas,
botones, campos
de texto, entre
otros.
Debe funcionar en
Internet Explorer
(7 - ms reciente),
Firefox (3 ms
reciente) y Google
Chrome. Revisar
CSS, JS y
atributos
especiales.
Implementar
varios tamaos y
estandarizarlos.
Ninguna
Agregar la
posibilidad de
agregar ms o
eliminar usuarios
mientras se
construye el
correo.
Generador de
PDF con la cita
de la entrevista
Generador de
PDF con la cita
para la prueba
Psicotcnica
Agregar
Funcionalidad al
Mdulo
Medio
3 Horas
Ninguna
Medio
3 Horas
Medio
5 Horas
Realizar
validaciones
adicionales
Medio
3 Horas
Posibilidad
de completar
parcialmente
el proceso de
inscripcin.
6
Envo de
Correo
electrnico al
terminar la
inscripcin.
Para garantizar
an ms la
funcionalidad en
los distintos
navegadores.
Sub-Actividades
Comentario
Modificaciones
en la
actualizacin de
egresados
Medio
3 Horas
Surgieron unos
inconvenientes a la
hora de guardar los
hijos de los
egresados
A continuacin
implementacin.
se
mostrarn
las
interfaces
resultantes
de
la
56
probaba a detalle todos los aspectos que correspondan al diseo que se deba
implementar, as como los patrones y recursos que deben seguirse para el
desarrollo de las mismas, cabe aclarar que todos estos aspectos y detalles
eran discutidos en la reunin del sprint. Una vez terminada la prueba que se
efectuaba, el Scrum Master determinaba si la actividad estaba cien por ciento
terminada y se poda proseguir a colocar la actividad como finalizada.
Es relevante mencionar alguna de las pruebas que tuvieron complicaciones o
fueron destacadas durante el desarrollo de la implementacin de la
metodologa Scrum, entre las actividades que ms se destacan se encuentran
las siguientes:
Crear Mdulo de Gestin de empresas, esta actividad fue particular
debido a que la prueba fue planeada para ser realizada en el Sprint 2
pero por razones ya explicadas no se pudo realizar. La prueba que se
realiz consisti en verificar si efectivamente se cre el mdulo que
gestionara las empresas; el mdulo comprenda las acciones
CRUD (Create, Read, Update, Delete por sus siglas en ingls) bsicas
que deban ser usados al momento de gestionar las empresas, se
realiz una prueba para verificar si efectivamente se realizaban las
acciones que deba.
Crear Mdulo de Finalizacin de prcticas, igual que la anterior, esta
actividad se destaca debido a que se contempl la prueba al finalizar el
Sprint 2 y no se llev acabo. La prueba en esta actividad consista en
que efectivamente el mdulo se creara segn lo planeado, pero adems,
que segn los parmetros que exige la universidad, esta deba cumplir
con unas exigencias especficas, relacionadas con la fecha en la que se
poda efectuar la finalizacin de las prcticas y que usuario poda
realizar la finalizacin.
Otra actividad que vale la pena mencionar en esta seccin es, Realizar
cambios necesarios para la interoperabilidad entre los navegadores
web, que consisti en garantizar que en todos los navegadores web se
vieran las interfaces de usuario de la misma manera. Lgicamente, la
prueba consisti en revisar interfaz por interfaz en cada uno de los
navegadores web, cabe mencionar que esta prueba tard algo de
tiempo adicional, porque se tenan que verificar todas las interfaces en
los 4 navegadores ms usados por los usuarios de internet, los cuales
son (Safari, Internet Explorer, Mozilla Firefox y Google Chrome).
Una de las pruebas ms importantes que realizaron fue la de las
actividades que contemplan las Elecciones Estudiantiles, puesto que de
esas interfaces dependa el hecho de que no hubieran fraudes en las
CONCLUSIONES
No existe una metodologa que garantice el xito de un proyecto de desarrollo
de software, pero si metodologas que se adaptan al contexto de proyectos con
ms facilidad. Las metodologas tradicionales o clsicas requieren de un mayor
trabajo al querer ser adaptadas a proyectos pequeos y con requisitos
cambiantes, lo que ha generado un creciente inters por metodologas ms
flexibles e igual de productivas:
Scrum como metodologa gil presenta todas las caractersticas propias de
este tipo y que se pueden constatar a lo largo del presente proyecto: permite
adaptarse continuamente a las circunstancias del proyecto, entrega continua y
en plazos cortos con software funcional, trabajo integrado entre el cliente del
producto y desarrolladores, mejora continua de proceso de desarrollo lo que
permite corregir errores a tiempo, al mismo tiempo que se realizan las pruebas.
La metodologa Scrum permiti la elaboracin del frontend de las aplicaciones
(desarrollo de controladores e interfaces graficas de usuario) que apoyan los
procesos acadmicos en la Universidad de San Buenaventura Cartagena,
aportando integridad al equipo de trabajo.
La aplicacin de este tipo de metodologas tambin permite tener una visin
diferente frente al desarrollo de actividades; para Scrum las actividades no son
algo que simplemente se inician y terminan, si no que permite, a travs de las
iteraciones, volver a ellas y agregarles nuevos detalles con el fin de que estas
puedan ir en un crescendo hacindolas cada vez mejor.
Tambin es importante resaltar el enriquecimiento que se puede hacer al tomar
de otras metodologas ciertos aspectos que aportan agregados favorables para
el desarrollo de la metodologa. No ceirse a lo que marca la norma permite
que estos cambios favorables para el proceso puedan hacerse y descubrir de
esta manera una mejor manera de realizar las labores que son encomendadas.
Se demuestra que el seguimiento de metodologas giles evita fases previas de
especificacin de requisitos, anlisis y diseo, costosas en tiempo as como la
correccin de errores en estas fases, lo que generara an ms prdida de
tiempo. Se prescindi del desarrollo de documentos que haran lento el proceso
y poco entendible la globalidad del sistema.
Al finalizar la implementacin de la metodologa en el Centro de Educacin
Virtual, se pudo demostrar con hechos tangibles lo eficiente que pueden llegar
a ser las metodologas agiles para casos en los que los requerimientos son
demasiado cambiantes, en donde nunca se tiene certeza de la totalidad de
funcionalidades que tendr el aplicativo que se busca conseguir. Cabe
destacar, que en la mayora de los casos de desarrollo de software desde el
punto de vista comercial, no se puede tener el planteamiento total de
requerimientos funcionales y no funcionales que se buscan tenga el software,
haciendo de esta, una de las metodologas con mayor ventaja debido a su
flexibilidad para el desarrollo.
REFERENCIAS
ABRAHAMSSON, P. Salo, O. Ronkainen, J. Warsta, J. Agile software
develoment methods review and analysis. VTT publications. 2002. 180p.
ALARCN, Pedro P. Especificacin de un modelo de operaciones
aplicable a procesos de desarrollo y operacin de sistemas con software.
PhD thesis, Facultad de Informtica. Universidad Politcnica de Madrid.
2008. 120p.
AMARO C., Sarah y Jorge C. Valverde; Metodologas Agiles. Universidad
Nacional de Trujillo. Trujillo, Per, 2007. 155p.
ANDERSON, D. J. Stretching Agile to fit CMMI Level 3 - the story of creating
MSF for CMMI Process Improvement at Microsoft Corporation. ADC '05:
Proceedings of the Agile Development Conference, IEEE Computer Society.
2005. 65p.
BOEHM, B. Turner, R. Balancing Agility and discipline. A Guide for the
Perplexed. Addison-Wesley. 2003. 89p.
CANOS, J., Letelier, P. y Penads, M. Metodologas Agiles en el desarrollo
de Software. Universidad Politecnica de Valencia, Valencia, 2003. 346p.
CARO, F. Agile manifiesto y experiencias personales. Memorias Jornadas
de Gerencia. Acis. Bogot 2004. 69p.
COCKBUN, A. Agile Software Development. Addison-Wesley. 2001. 160p.
COCKBURN, A. Selecting a Projects Methodology,
Technology. IEEE SOFTWARE July/August 2000. 142p.
Humans
And
1 2 3 4
4 1 2 3 4
83
2012
MARZO
ABRIL
MAYO
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Anexo B. Presupuesto
RUBROS
Gastos de
personal
Equipos y
software
Materiales y
suministros
Servicios
tcnicos
Otros gastos
TOTALES
CEV
DESCRIPCIN
4 Tutores
3 Estudiantes
iMac 21
Mac Pro con Cinema
Display
Computador HP Quad Core
Papelera
Tner de impresora
Servicio de Computo 600h
5000h
Imprevistos
Especie
Efectivo
$ 2450.000.oo
$ 6335.500.oo
-
$ 7132.000.oo
$ 1835.000.oo
-
$ 200.000.oo
$ 100.000.oo
$ 8000.000.oo
$ 19417.000.oo
$ 1000.000.oo
$ 7635.500.oo
84
FUENTE
Estudiantes
$ 27052.500.oo