APLICACIN DE LA METODOLOGA SCRUM PARA LA OPTIMIZACIN DE

PROCESOS ACADMICOS EN LA UNIVERSIDAD DE SAN

BUENAVENTURA, CARTAGENA

ELKIN JOS TORRES MARTNEZ

EDSON CARLO ARZUZA AGUDELO
OSCAR FERNANDO BECERRA URIBE

UNIVERSIDAD DE SAN BUENAVENTURA

PROGRAMA DE INGENIERA DE SISTEMAS
FACULTAD DE INGENIERA, ARQUITECTURA, ARTE Y DISEO
CARTAGENA DE INDIAS D. T. & C.
COLOMBIA
2012
APLICACIN DE LA METODOLOGA SCRUM PARA LA OPTIMIZACIN DE
PROCESOS ACADMICOS EN LA UNIVERSIDAD DE SAN
BUENAVENTURA, CARTAGENA

ELKIN JOS TORRES MARTNEZ

EDSON CARLO ARZUZA AGUDELO
OSCAR FERNANDO BECERRA URIBE

Proyecto de grado presentado como requisito para optar al ttulo de Ingeniero

de Sistemas

Tutor
ING. DAMIAN BARRIOS CASTILLOS

UNIVERSIDAD DE SAN BUENAVENTURA

PROGRAMA DE INGENIERA DE SISTEMAS
FACULTAD DE INGENIERA, ARQUITECTURA, ARTE Y DISEO
CARTAGENA DE INDIAS D. T. & C.
COLOMBIA
2012
 CONTENIDO

RESUMEN VIII
1. PROBLEMA DE INVESTIGACION 2
1.1 PLANTEAMIENTO DEL PROBLEMA 2
1.2 FORMULACION DEL PROBLEMA 4
1.3 JUSTIFICACION 4
1.4 OBJETIVOS 6
1.4.1 Objetivo general 6
1.4.2 Objetivos especficos 6
2. MARCO DE REFERENCIA 7
2.1 MARCO HISTORICO 7
2.2 INVESTIGACIONES PREVIAS 8
2.3 MARCO TERICO 9
2.3.1 Scrum 9
2.3.2 Sistemas de informacin 14
2.3.3 Lenguajes de Programacin 15
2.3.4 Html (HyperText Markup Language) 16
2.3.5 Php (PHP HyperText Pre-processor) 17
2.3.6 Base de datos 18
2.3.7 JavaScript 19
2.3.8 Metodologa Tradicional 20
2.4 MARCO CONCEPTUAL 20
3. DISEO METODOLOGICO 22
3.1 TIPO DE INVESTIGACION 22
3.2 DISEO ADOPTADO 22
3.3 ENFOQUE DE LA METODOLOGIA 22
3.4 TECNICAS DE RECOLECCION DE LA INFORMACION 23
3.4.1 Fuentes primarias 23
3.4.2 Fuentes secundarias 24
3.5 VARIABLES 24
3.6 OPERACIONALIZACION DE VARIABLES 25
3.7 PROCESAMIENTO DE LA INFORMACION 26
3.8 RECURSOS TECNOLOGICOS 26
3.8.1 El Paradigma de Programacin 26
3.8.2 Herramienta de Desarrollo de Software 27
3.8.3 Herramientas Software 27
3.8.4 Herramientas de Diseo 28
3.8.5 Herramientas Hardware 28
4. RESULTADOS 29
4.1 API: PUNTO DE PARTIDA COMO FUENTE DE SERVICIOS 29
4.2 REQUERIMIENTOS 34
4.2.1 Product Backlog 35
4.3 ITERACIONES DE IMPLEMENTACION DE LOS PRODUCTOS 38
4.3.1 Exposicin del Product Backlog 38
4.3.2 Resolucin del Sprint Backlog 39
4.3.4 Revisin del Sprint 42
4.4 DISEO Y DESARROLLO DE INTERFACES 53
4.5 EJECUCION DE PRUEBAS 77

III
CONCLUSIONES 80
REFERENCIAS 81

IV
 LISTA DE TABLAS

Tabla 1. Operacionalizacin de Variables 25

Tabla 2. Actividad Realizar Solicitud de Grado 43
Tabla 3. Actividad Realizar Certificados 43
Tabla 4. Actividad Realizar Matricula Acadmica 43
Tabla 5. Actividad Ver Perfil del Estudiante 43
Tabla 6. Actividad Ver Informacin del Estudiante 44
Tabla 7. Actividad Mostrar Horario de Clases 44
Tabla 8. Actividad Mostrar Semforo Acadmico 44
Tabla 9. Actividad Mostrar Semforo Acadmico 44
Tabla 10. Actividad Realizar Actualizacin de Datos de Estudiantes 45
Tabla 11. Actividad Solicitar Becas y Descuentos 46
Tabla 12. Actividad Prcticas Empresariales 46
Tabla 13. Actividad Persistencia de Acaweb 47
Tabla 14. Actividad Actualizacin de Datos de Egresados 47
Tabla 15. Actividad Imprevista Sprint 2 48
Tabla 16. Actividad Prcticas Empresariales (Actividades sin Resolver) 49
Tabla 17. Actividad Matrcula en lnea 50
Tabla 18. Actividad Portal Docentes 50
Tabla 19. Actividad de Refactor 51
Tabla 20. Actividad Inscripciones en lnea (Versin Definitiva) 52
Tabla 21. Actividad Modificaciones Portal Egresados 53
Tabla 22. Actividad Portal de Elecciones Institucionales 53

V
 LISTA DE FIGURAS

Figura 1. Modelo general de la metodologa Scrum 13

Figura 2. Interaccin en arquitectura de capas 30
Figura 3. Vista de la arquitectura lgica implementada en el sistema de
informacin de la Universidad de San Buenaventura, Cartagena. 31
Figura 4. Product Backlog del Desarrollo 36
Figura 5. Sprint Backlog del Desarrollo 40
Figura 6. Avance de un Sprint 41
Figura 7. Actividades Sin Planeacin 48
Figura 8. Pgina de Inicio 54
Figura 9. Actualizar Mis Datos Datos Bsicos 55
Figura 10. Actualizar Mis Datos Datos Familiares 56
Figura 11. Actualizar Mis Datos Historial Laboral 57
Figura 12. Actualizar Mis Datos Historial Acadmico 57
Figura 13. Actualizar Mis Datos Idiomas 58
Figura 14. Ver Mis Datos Informacin Personal 59
Figura 15. Ver Mis Datos Informacin de Contacto 60
Figura 16. Prcticas Industriales- Bitcora 61
Figura 17. Prcticas Industriales Descargar Certificado 61
Figura 18. Actualizar Mis Datos Datos Bsicos 62
Figura 19. Actualizar Mis Datos Informacin Laboral 63
Figura 20. Actualizar Mis Datos Informacin Acadmica 64
Figura 21. Actualizar Mis Datos Idiomas 64
Figura 22. Actualizar Mis Datos Datos Complementarios 65
Figura 23. Mdulo Docentes Horario 66
Figura 24. Elecciones Estudiantiles Formulario de Inscripcin 67
Figura 25. Elecciones Estudiantiles Admisin 68
Figura 26. Elecciones Estudiantiles Votacin 68
Figura 27. Prcticas Industriales Subir Certificado 69
Figura 28. Prcticas Industriales Solicitudes 70
Figura 29. Prcticas Industriales listado de Amonestaciones 71
Figura 30. Prcticas Industriales Amonestaciones Respondidas 72
Figura 31. Solicitud Practicante - Identificacin de la Empresa 73
Figura 32. Solicitud Practicante - Requerimientos 74
Figura 33. Prcticas Industriales Ubicacin Estudiante 75
Figura 34. Solicitud Practicante - Ubicacin Empresa 75
Figura 35. Prcticas Industriales Ver Solicitudes 76
Figura 36. Formulario de inscripcin 77

VI
 LISTA DE ANEXOS

Anexo A. Cronograma de Actividades 83

Anexo B. Presupuesto 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.

VIII
 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.

1
 APLICACIN DE LA METODOLOGA SCRUM PARA LA OPTIMIZACIN DE
PROCESOS ACADMICOS EN LA UNIVERSIDAD DE SAN
BUENAVENTURA, CARTAGENA

1. PROBLEMA DE INVESTIGACION

1.1 PLANTEAMIENTO DEL PROBLEMA

El software evoluciona a travs de una serie de actividades de programacin

que siguen una metodologa, y que se orientan a generar una nueva versin a
partir de una versin anterior operativa, cubriendo ajustes de funcionalidades
adicionales1. La causa de ste cambio est atada a la necesidad de evolucin
del software.

Muchas de las actuales metodologas de desarrollo de software se han

enfocado en distintas dimensiones del proceso de desarrollo, colocando un
cuidadoso nfasis en el control de proceso mediante una rigurosa definicin de
roles, actividad que incluyen modelado y documentacin detallada. Este tipo de
metodologas han recibido el nombre Metodologas Tradicionales, dando
excelentes resultados en proyectos de gran tamao, pero mostrndose un poco
ineficientes en desarrollos ms pequeos y con requerimientos menos estables
que requieren flexibilidad2.

Como alternativa de desarrollo aparecen las metodologas giles,

constituyndose en una alternativa de solucin a medida, con una elevada
simplificacin en sus procesos que no renuncia a las prcticas esenciales para
asegurar la calidad del producto. Estas han sido pensadas para grupos de
desarrollo pequeos, con plazos reducidos y requisitos flexibles.

Dentro del marco de estas metodologas de desarrollo gil se encuentra Scrum.

Esta se caracteriza por brindar ventajas en entornos de trabajo con
requerimientos inestables, que requieren rapidez y flexibilidad, adaptndose
continuamente a las circunstancias de evolucin del proyecto. Estas
caractersticas coinciden en muchos de los proyectos que actualmente se
desarrollan dentro de Centro de Educacin Virtual (CEV) de la Universidad de
San Buenaventura Seccional Cartagena.

El Centro de Educacin Virtual (CEV) lleva a cabo procesos de creacin,

revisin y despliegue de desarrollos de aplicaciones, que hacen parte del
desarrollo del sistema de informacin que sirve de apoyo al modelo de
enseanza institucional. Este sistema de informacin brinda al docente y al
estudiante apoyo a su proceso de formacin, a partir del modelo de educacin

1
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.
2
Grupo ISSI. Metodologas giles en el Desarrollo de Software. Editorial Alicante. Espaa, 12 de
Noviembre de 2003. pp. 9-16.

2
que se desea implantar, ya sea presencial o virtual, teniendo como objetivo el
desarrollo de frontend de las aplicaciones que permitirn: acceso a la
informacin personal de docentes y estudiantes, administracin de notas
estudiantiles, portal para el manejo de prcticas industriales y portal de
votaciones estudiantiles (inscripcin de candidatos y votaciones). Estos
servicios que se encuentran desacoplados requieren un proceso de
optimizacin que permita el manejo digital de la informacin a travs de una
plataforma acoplada accesible desde Internet.

En la actualidad, a nivel organizacional y operativo estos servicios presentan

deficiencias en su prestacin, tales como: la falta de una plataforma amena,
intuitiva y prctica que permita presentar y recibir informacin de los usuarios;
desarrollos que brindan servicios a partir de la informacin guardada en las
bases de datos de la Universidad que son redundante e insuficientes; la lgica
de negocio an se encuentra en etapa de diseo y se ajusta a las polticas
cambiantes y poco definidas que establece la Institucin para tal fin. La poca
sinergia que se presenta entre los servicios prestados por las aplicaciones
existentes en la Institucin, conlleva a que no se logre una integracin con el
sistema en desarrollo. Teniendo en cuenta esto, la finalidad del CEV es
implementar un sistema que integre servicios como: Manejo de estudiantes, la
administracin de prcticas industriales, la gestin de notas, la conduccin de
las elecciones estudiantiles; implementacin que no se ha podido lograr debido
al uso de metodologas de desarrollo tradicionales que han causado retrasos
en los tiempos de entrega de mdulos que dan soporte al funcionamiento del
mismo.

El seguimiento de metodologas de desarrollo de software poco adaptadas a la

realidad que vive el CEV crea inconveniente como es la de priorizar las
actividades segn el grado de importancia que tienen para el buen
funcionamiento del sistema. A su vez se requiere responder a los cambios en
el diseo o requerimientos del sistema, que surgen a lo largo del proyecto, lo
cual genera un atraso constante en los desarrollos alcanzados ya que
demanda nuevas correcciones y nuevas funcionalidades al software como tal.

Teniendo en cuenta lo anterior, se requiere optimizar las diferentes

herramientas acadmicas de apoyo requeridas por el CEV, a travs de la
metodologa Scrum, desarrollando software rpidamente y respondiendo a los
diferentes requerimientos en la implementacin de los mismos (en los
requisitos, en la tecnologa).

Teniendo en cuenta estos aspectos, el proyecto ejecutado en el CEV fue

dividido en dos fases: Fase uno, elaboracin de una API (Interfaz de
programacin de aplicaciones Application Programming Interface por sus
siglas en ingles) que integra los servicios utilizados para la obtencin de datos
que la Institucin posee de los estudiantes y docentes, simplificando la manera
para consumir dichos servicios, tambin se cre un framework de desarrollo
(Underscore), que fuese capaz de integrarse con el gestor de contenidos
Joomla! y brindara un sencillo mtodo para realizar aplicaciones para el
mismo. Esta fase est a cargo en su totalidad por el equipo de trabajo del CEV.

3
Fase dos, elaboracin de frontend de las aplicaciones (desarrollo de
controladores e interfaces graficas de usuario), que tiene como finalidad
proveer a los usuarios de vista amigable para la utilizacin de la aplicacin.
Esta fase se desarroll durante el periodo de prcticas industriales y pasantas
de investigacin profesionales de los integrantes del presente proyecto,
comprendido entre Agosto de 2011 y Abril de 2012.

1.2 FORMULACION DEL PROBLEMA

Cmo implementar la metodologa Scrum para la Optimizacin de Procesos

Acadmicos: inscripcin y actualizacin de informacin de estudiantes,
administracin de prcticas industriales, gestin de notas, portal de egresados
y portal para el manejo de las elecciones estudiantiles en la Universidad de San
Buenaventura Cartagena?

1.3 JUSTIFICACION

La metodologa que se usa en el desarrollo de software integra mtodos,

herramientas y procedimientos especficos que pueden convertirse en una
pieza importante de xito para el equipo de trabajo que la utiliza haciendo
eficaz la produccin de aplicaciones. Encontrar, seguir y experimentar con
formas alternativas de trabajo, diferentes a los procesos de desarrollo de
software tradicionales, caracterizados por ser rgidos y dirigidos por la
documentacin generada en cada una de las actividades realizadas3, es una
de las principales motivaciones para la seleccin del tema.

Con este proyecto se busca hacer praxis una metodologa que sea alternativa
a los procesos de desarrollo de software tradicionales como RUP (Rational
Unified Process), logrando desarrollos rpidos y que respondan a los cambios
que puedan surgir en el mismo. La metodologa de desarrollo gil que se
utilizara para este proyecto se denomina Scrum, la cual se caracteriza por
continuas y tempranas entregas que dan parte del avance del software y rpida
respuesta a los cambios que pueda sugerir el cliente con respecto al diseo,
contenido o funcionalidad del sistema; la produccin de una aplicacin no sigue
estrictamente una planificacin inicial, siendo flexible y abierta, con reglas de
trabajo impuestas por el equipo de trabajo.

Teniendo en cuenta la cantidad de metodologas de desarrollo de software se

hace necesario dar a conocer las experiencias exitosas que se tengan con ellas
en el mbito local, permitiendo que otros puedan saber de buena tinta las
implicaciones y detalles de su implementacin. Esto permitir que otros
desarrolladores sigan esta metodologa que se muestra como exitosa.

3
Canos, J., Letelier, P. y Penads, M. Metodologas Agiles en el desarrollo de Software. Universidad
Politecnica de Valencia, Valenc
ia, 2003.

4
La elaboracin de un manual de implementacin reflejar en detalle el
desarrollo de aplicaciones utilizando la metodologa SCRUM a partir de los
casos de xito vividos por el equipo dentro del CEV. Esto permitir a futuros
desarrolladores inexpertos seleccionar metodologas que garanticen la
satisfaccin del cliente pero tambin la de ellos mismos, marcando el xito en
el desarrollo del software, y evitando dudar al escoger la metodologa
adecuada, o algo todava peor, se prescindir de estar ensayando con
metodologas adaptadas a circunstancias particulares, que pudiesen malograr
el objetivo final.

Se busca demostrar que el uso de la metodologa Scrum, proporcionar un

desarrollo rpido de aplicaciones requeridas por el sistema de informacin del
CEV de la Universidad de San Buenaventura, aportando herramientas de
apoyo de importancia para el desempeo acadmico. Las ventajas que se
podrn comparar con otras metodologas son la satisfaccin del cliente por
continuas y tempranas entregas de producto, la facilidad de responder a los
cambios en diseo, contenido o funcionalidad del sistema, la interaccin
continua con el cliente que facilita la captura de nuevos requerimientos y la
autorregulacin que surge del mismo grupo de desarrolladores.

Las herramientas acadmicas de apoyo desarrolladas a partir de la

metodologa Scrum comprendida en la Fase 2 y que son de competencias de
los desarrolladores de este proyecto, permitir ofrecer a los usuarios finales el
acceso a travs de la interfaces a los servicios proporcionados por la
Universidad de San Buenaventura, a travs del desarrollo de los frontend de
las aplicaciones obtenidos en esta fase como lo son: inscripcin y actualizacin
de informacin de estudiantes, administracin de prcticas industriales, gestin
de notas, portal de egresados y portal para el manejo de las elecciones
estudiantiles

La viabilidad tcnica del proyecto se da porque se cuenta con el capital

humano capacitado en temas de ingeniera de software y con conocimientos
avanzados en Bases de Datos, Lenguaje de programacin y metodologa del
estudio; los recursos econmicos que sern invertidos no presentan costos
elevados y son medianamente financiables por parte de los investigadores,
siendo los equipos y elementos de desarrollo facilitados por CEV de la
Universidad de San Buenaventura seccional Cartagena. La importancia que
tiene el producto garantiza el ingreso de aportes de la principal beneficiada con
el desarrollo del mismo, en este caso, el de la Universidad de San
Buenaventura Seccional Cartagena.

El desarrollo de este proyecto est enfocado bajo la perspectiva franciscana de

la Universidad de San Buenaventura, planteada en el PEB, la cual expone la
importancia de la investigacin como herramienta para el desarrollo de las
ciencias y la tecnologa informtica. Se fomenta el desarrollo de la misma a
travs actividades de formacin y de procesos que involucren cultivar aptitudes

5
y capacidades intelectuales que permitan inferir, deducir y elaborar conceptos
de carcter investigativo4.

1.4 OBJETIVOS

1.4.1 Objetivo general. Implementar la Metodologa Scrum para la

Optimizacin de Procesos Acadmicos en la Universidad de San
Buenaventura, Cartagena.

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.

4
Universidad de San Buenaventura; Proyecto Educativo Bonaventuriano PEB; Editorial bonaventuriana;
Bogot D.C. 2007; p. 66.

6
 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, auto-
organizativos 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.

7
2.2 INVESTIGACIONES PREVIAS

El desarrollo de esta investigacin servir como referencia a nuevos proyectos

de grados e investigaciones que sugieran o se encaminen en el manejo de la
metodologa SCRUM. As como las investigaciones y tesis colocadas como
referencias en este documento sirvieron de apoyo para lograr entender cmo
ha evolucionado esta metodologa en pases como Espaa, Colombia, entre
otros pases latinoamericanos. A continuacin se presenta una breve
descripcin de los proyectos similares a la investigacin.

Sergio Adrian Yazyi, Salamanca Espaa en el ao de 2011, presento en la

Universidad De Salamanca, una investigacin que lleva como ttulo Una
experiencia prctica de Scrum a travs del aprendizaje basado en proyectos
mediado por TIC en un equipo distribuido, el cual plantea dentro de su
documentacin: Scrum es un marco de trabajo para la gestin gil de
proyectos de creciente inters en distintos campos de aplicacin. Para asimilar
sus principios y prcticas no basta una formacin conceptual sino que es
necesario utilizar un enfoque prctico que permita ejercitarlo a travs del
aprender haciendo. Este estudio se convierte en punto de apoyo ya que se
estudia la implementacin de Scrum en contextos distinto al del desarrollo del
software, exponindose los logros alcanzados durante la aplicacin de esta
metodologa, corroborando la informacin obtenida durante el desarrollo del
actual proyecto.

A su vez Juan Palacios en Colombia, en Octubre de 2008, present un

proyecto o documento investigativo sobre la implementacin de Scrum llamado
Flexibilidad con Scrum Principios de diseo e implantacin de campos de
Scrum Adaptando los procesos a la empresa en el cual se hace mencin de
empresas observadas por Nonaka y Takeuchi, mostrando en stas las
caractersticas que luego pasaran a formar parte de lo hoy se conoce como
Scrum. Estas caractersticas son tratadas al detalle, terminando con consejos
prcticos que permiten llevar estas mismas cualidades a campos como el
marketing, proyectos empresariales y procesos de produccin.

De igual Juan Garbajosa Sopea y Pilar Rodrguez Gonzlez en Espaa -

Madrid, Septiembre de 2008, presentaron Tesis de Master sobre tecnologas
de la Informacin ntimamente relacionada con Scrum llamada Estudio de la
Aplicacin de Metodologas Agiles para la Evolucin de Productos Software; la
tesis presentada hace referencia a Scrum como ncleo principal y se
concentra principalmente, a nivel de las personas y equipo de desarrollo que
construye el producto. Su objetivo es que los miembros del equipo trabajen
juntos y de forma eficiente obteniendo productos complejos y sofisticados. Se
podra entender Scrum como un tipo de ingeniera social que pretende
conseguir la satisfaccin de todos los que participan en el desarrollo,
fomentando la cooperacin a travs de la auto-organizacin. De esta forma, se
favorece la franqueza entre el equipo y la visibilidad del producto. Pretende
que no haya problemas ocultos, asuntos u obstculos que puedan poner en
peligro el proyecto. Los equipos se guan por su conocimiento y experiencia
ms que por planes de proyecto formalmente definidos. La planificacin
detallada se realiza sobre cortos espacios de tiempo lo que permite una

8
constante retroalimentacin que proporciona inspecciones simples y un ciclo
de vida adaptable. As, el desarrollo de productos se produce de forma
incremental y con un control emprico del proceso que permite la mejora
continua; esto conlleva a reafirmar la utilizacin de Scrum como metodologa
de desarrollo con la consiguiente obtencin de resultados optimizados.

En el Ao de 2009 en Wasington (EE.UU.) Henrik Kniber y Mattias Skarin,

tomando un prlogo de Mary Poppendieck y David Anderson, en un
documento llamado Kamban y Scrum obteniendo lo mejor de ambos ofrece
informacin positiva de Scrum mostrando como sta divide la organizacin en
equipos pequeos, interdisciplinarios y auto-organizados, divide el trabajo en
una lista de entregables pequeos y concretos; ordena la lista por orden de
prioridad y estima el esfuerzo relativo de cada elemento; divide el tiempo en
iteraciones cortas de longitud fija (generalmente de 1 a 4 semanas), con cdigo
potencialmente entregable y demostrado, despus de cada iteracin; optimiza
el plan de entregas y actualiza las prioridades en colaboracin con el cliente,
basada en los conocimientos adquiridos mediante la inspeccin del entregable
despus de cada iteracin; optimiza el proceso teniendo una retrospectiva
despus de cada iteracin. As en lugar de un grupo numeroso pasando
mucho tiempo construyendo algo grande, se tiene un equipo menor pasando
un tiempo ms corto construyendo algo menor. Pero integrando con
regularidad para ver el conjunto completo.

2.3 MARCO TERICO

2.3.1 Scrum. En el transcurrir del tiempo las sociedades siempre han sub-
existido gracias a su habilidad de poder crear procedimientos racionales
utilizados para alcanzar una gama de objetivos que rigen en una investigacin
cientfica o tareas que requieran habilidades, conocimientos o cuidados
especficos.

Alternativamente puede definirse que una metodologa es el estudio o eleccin

de un procedimiento pertinente para alcanzar un determinado objetivo. Algunas
de estas metodologas han venido siendo iguales o han tenido sus cambios
respectivos segn la situacin lo amerite, ya que se hacen presentes diferentes
factores como el tiempo, eficacia, dinero, requerimientos, entre otros.

Existen metodologas que han venido acompaando el avance tecnolgico

desde sus inicios y ms en el desarrollo de software. Tanto as que han
proporcionado la manera de solucionar situaciones de forma prctica
obteniendo as los resultados esperados en menos tiempo. Este ha sido uno
de los objetivos principales de los programadores, para hacer que la
informacin sea utilizada en cualquier hora y lugar.

Las metodologas han sido utilizadas para la realizacin de proyectos

tecnolgicos y cientficos desde su invencin, consideradas como un proceso
de planificacin, la cual consiste en un conjunto de actividades que se
encuentran interrelacionadas y coordinadas. La razn de un proyecto es

9
alcanzar objetivos especficos dentro de los lmites que imponen un
presupuesto, calidades establecidas previamente y un lapso de tiempo
previamente definido. La gestin de proyectos es la aplicacin de
conocimientos, habilidades, herramientas y tcnicas a las actividades de un
proyecto para satisfacer los requisitos del proyecto5.

Existen metodologas orientadas a la interaccin con el cliente y el desarrollo

incremental del software, mostrando versiones parcialmente funcionales del
mismo al cliente en intervalos cortos de tiempo, para que pueda evaluar y
sugerir cambios en el producto segn se va desarrollando. Estas son llamadas
Metodologas ligeras/giles6.

El individuo y las interacciones del equipo de desarrollo sobre el proceso

y las herramientas son puntos principales en el factor de xito de un proyecto.
Es ms importante construir un buen equipo que construir el entorno, muchas
veces se comete el error de construir primero el entorno y esperar que el
equipo se adapte automticamente. Es mejor crear el equipo y que ste
configure su propio entorno de desarrollo en base a sus necesidades. Antes y
Durante la elaboracin del proyecto hay que acatar puntos clave para la
satisfaccin mxima desde el punto de vista del cliente y el desarrollador7.

Desarrollar software que funciona ms que conseguir una buena

documentacin. La regla a seguir es no producir documentos a menos que
sean necesarios de forma inmediata para tomar una decisin importante. Estos
documentos deben ser cortos y centrarse en lo fundamental. La colaboracin
con el cliente ms que la negociacin de un contrato. Se propone que exista
una interaccin constante entre el cliente y el equipo de desarrollo. Esta
colaboracin entre ambos ser la que marque la marcha del proyecto y
asegure su xito.

Responder a los cambios ms que seguir estrictamente un plan. La

habilidad de responder a los cambios que puedan surgir a los largo del
proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.)
determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no
debe ser estricta sino flexible y abierta.

Dentro de las metodologas existentes para la realizacin de proyectos a nivel

de programacin de software, se encuentre la Metodologa Scrum, la cual se
utiliz en la generacin de productos de software durante el desarrollo de la
pasanta de investigacin y la cual ser descrita a lo largo de este documento.

Scrum es un mtodo iterativo e incremental que enfatiza prcticas y valores de

Project management por sobre las dems disciplinas del desarrollo. Al principio
del proyecto se define el Product Backlog, que contiene todos los

5
Amaro C., Sarah y Jorge C. Valverde; Metodologas Agiles. Universidad Nacional de Trujillo. Trujillo,
Per, 2007.
6
Palacio, Juan. Flexibilidad con Scrum. Disponible en http://www.lulu.com, consultado el 23 de marzo
de 2012.
7
Ibd., pp. 18.

10
requerimientos funcionales y no funcionales que deber satisfacer el sistema a
construir.8

Esta es una herramienta que permite la comunicacin entre desarrolladores en

relacin uno-a-uno, que podr servir tanto para darse soporte en el proceso,
como para clarificar y valorar su contribucin individual en trabajo grupal.
Tambin permite la comunicacin el ScrumMaster (Lder del grupo) en relacin
con todos los miembros del mismo, de particular importancia para el
seguimiento del proceso de elaboracin del proyecto y culminacin del mismo9.

Esta Facilita la evaluacin formativa a travs del seguimiento de la evolucin de

los productos del proyecto, buscando modos de representar digitalmente los
mismos, para permitir de este modo analizar, valorar y ofrecer feedback a los
estudiantes, as como intervenir tempranamente en caso de dificultades

Con Scrum, el usuario se entusiasma y se compromete con el proyecto Desde

este punto de vista; Scrum es una metodologa gil de desarrollo de proyectos
de software que ha venido surgiendo en los ltimos aos. Esta toma nombre y
principios de observaciones sobre nuevas prcticas de produccin realizada
por Hirotaka y Takeuchi en los aos 8010. En muchas ocasiones, los modelos
de gestin tradicionales no cumplen con los requisitos para afrontar un reto
que hoy en da resulta muy fundamental, el cual es incorporar cambios con
rapidez y en cualquier fase del proyecto realizado o a realizar.

As mismo 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 iteracin. Esta
metodologa de trabajo promueve la innovacin, motivacin y compromiso del
equipo que forma parte del proyecto, por lo que los profesionales encuentran
un mbito propicio para desarrollar sus capacidades11.

Actualmente uno de los mtodos giles ms difundidos es Scrum, basado en

ciclos cortos de trabajo, desarrollo iterativo y adaptativo, permeabilidad a los
cambios en los requisitos, auto-organizacin del equipo de trabajo, poco en la
produccin de valor, mejora continua del proceso y orientacin a las personas.

Por qu Escoger SCRUM?

El cliente tiene la oportunidad ver los resultados desde el primer

momento.

Se ahorra tiempo que en las metodologas tradicionales se dedica en

conseguir especificaciones y documentacin exhaustivamente.

8
Amaro C., Sarah y Jorge C. Valverde; Metodologas Agiles. Universidad Nacional de Trujillo. Trujillo,
Per, 2007.
9
Ibd., pp. 26.
10
PALACIOS, Juan ; El Modelo Scrum PDF 2006; Pg.2, , Capitulo 1. Disponible en
http://www.navegapolis.net/files/s/NST-010_01.pdf. Consultado el 18 de Marzo de 2012
11
Ibd.

11
 Se hace equipo de comunicacin continua reportando seguidamente los
xitos conseguidos.

El cliente tiene la oportunidad de ser participe y opinar en el desarrollo

del proyecto.

Se reducen los riesgos por retrasos acumulados, entregas que difieren

de lo que el cliente esperaba, por lo tanto influye de manera decisiva en
el xito del proyecto.

No es dirigida del todo puede ser combinada con otras metodologas de

desarrollo

Esta forma de concebir la gestin de proyectos es radicalmente diferente al

modo secuencial en que se afrontan tradicionalmente los mismos, dividindolos
en etapas, sucesivas y especializadas, planificadas a priori en forma detallada;
proponiendo en cambio un desarrollo en forma iterativa, como trabajo de un
equipo multidisciplinario (ScrumTeam) sobre una versin completa del
producto, centrada en el valor para el cliente o destinatario.12

Scrum es un modelo de referencia que define un conjunto de prcticas 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 equipo que incluye a los
desarrolladores.

Durante cada Sprint (un perodo entre una y cuatro semanas, cuya la magnitud
es definida por el equipo de trabajo, el equipo crea un incremento de
software potencialmente entregable (utilizable). El conjunto de caractersticas
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 reunin de planeacin.

De forma iterativa, todos los das que dure el Sprint, se realiza una reunin
operativa, informal y gil con el equipo de desarrollo, de un mximo de quince
minutos, en la que a cada integrante del equipo se le hacen tres preguntas:

Qu tareas ha hecho desde la ltima reunin? Es decir, tareas

realizadas en un da.

Qu tareas realizaras el da de hoy?

12
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.

12
 Qu ayuda necesita para poder realizar este trabajo? Es decir,
identificacin de obstculos o riesgos que impiden o pueden impedir el
normal avance.13

Durante esta reunin, el ProductOwner 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. Durante el Sprint, nadie
puede cambiar el Sprint Backlog, lo que significa que los requisitos estn
congelados durante el Sprint14.

Figura 1. Modelo general de la metodologa Scrum

La efectividad de la metodologa para la gestin de proyectos se basa en un

conjunto de valores fundamentales que deben seguir todos los integrantes del
equipo, principios sobre los que reposan el resto de prcticas: compromiso,
esmero, franqueza, respeto y valor15.

Scrum comparte los principios estructurales del desarrollo gil: a partir del
concepto o visin de la necesidad del cliente, construye el producto de forma
incremental a travs de iteraciones breves que comprenden fases de
especulacin exploracin y revisin. Estas iteraciones (en Scrum llamadas
Sprint) se repiten de forma continua hasta que el cliente da por cerrado el
producto16.

La conformacin de equipos pequeos de trabajo, es una de las caractersticas

principales de esta metodologa, formado por miembros de diferentes

13
Rodriguez Gonzalez, Pilar. Estudio De La Aplicacin De Metodologas Agiles Para La Evolucin De
Productos Software. Universidad Politecnica de Madrid. Madrid. 2008.
14
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; Pg. 22 . Disponible en
http://gredos.usal.es/jspui/bitstream/10366/100082/1/TFM_YazyiSergio_Master.pdf. Consultado el 22
de Marzo de 2012.
15
Rodriguez Gonzalez, Pilar. Estudio De La Aplicacin De Metodologas Agiles Para La Evolucin De
Productos Software. Universidad Politecnica de Madrid. Madrid. 2008.
16
PALACIOS, Juan ; El Modelo Scrum PDF 2006; pp.2, Capitulo 1. Disponible en
http://www.navegapolis.net/files/s/NST-010_01.pdf. Consultado el 18 de Marzo de 2012.

13
disciplinas consiguen mejores resultados. Es fundamental que el equipo pueda
organizarse por s mismo donde la comunicacin e intercambio de informacin
entre los implicados sea transparente. Esto hace que la manera de solucionar
los problemas que se presenten o realizar nuevos objetivos inmersos en el
proyecto se ataquen de forma paralela ahorrando hasta en 50%, en algunos
casos, el tiempo de entrega del mismo al cliente.

2.3.2 Sistemas de informacin17. Un sistema de informacin es un conjunto

formal de procesos que, operando sobre una coleccin de datos estructurada
segn las necesidades de la empresa, recopilan, elaboran y distribuyen la
informacin (o parte de ella) necesaria para las operaciones de dicha empresa
y para las actividades de direccin y control correspondientes (decisiones) para
desempear su actividad de acuerdo a su estrategia de negocio.

Un sistema de informacin realiza cuatro actividades bsicas: entrada de datos,

almacenamiento, procesamiento y salida de informacin.

Entrada de Datos: Es el proceso mediante el cual el Sistema de

Informacin toma los datos que requiere para procesar la informacin.
Las entradas pueden ser manuales o automticas. Las manuales son
aquellas que se proporcionan en forma directa por el usuario, mientras
que las automticas son datos o informacin que provienen o son
tomados de otros sistemas o mdulos. Esto ltimo se denomina
interfaces automticas. Las unidades tpicas de entrada de datos a las
computadoras son las terminales, las cintas magnticas, las unidades de
diskette, los cdigos de barras, los escner, la voz, los monitores
sensibles al tacto, el teclado y el mouse, entre otras.

Almacenamiento: El almacenamiento es una de las actividades o

capacidades ms importantes que tiene una computadora, ya que a
travs de esta propiedad el sistema puede recordar la informacin
guardada en la seccin o proceso anterior. Esta informacin suele ser
almacenada en estructuras de informacin denominadas archivos.

Procesamiento: Es la capacidad del Sistema de Informacin para

efectuar clculos de acuerdo con una secuencia de operaciones
prestablecida. Estos clculos pueden efectuarse con datos introducidos
recientemente en el sistema o bien con datos que estn almacenados.
Esta caracterstica de los sistemas permite la transformacin de datos
fuente en informacin que puede ser utilizada para la toma de
decisiones, lo que hace posible, entre otras cosas, que un tomador de
decisiones genere una proyeccin financiera a partir de los datos que
contiene un estado de resultados o un balance general de un ao base.

Salida de Informacin: La salida es la capacidad de un Sistema de

Informacin para sacar la informacin procesada o bien datos de

17
STAIR, Ralph y George W. Reynolds. Principios de Sistemas de Informacin. Mxico, 2000, Editorial
Thomson, p 4 - 5.

14
 entrada al exterior. Las unidades tpicas de salida son las impresoras,
terminales, diskettes, cintas magnticas, la voz, los graficadores y los
plotters, entre otros. Es importante aclarar que la salida de un Sistema
de Informacin puede constituir la entrada a otro Sistema de Informacin
o mdulo. En este caso, tambin existe una interface automtica de
salida. Por ejemplo, el Sistema de Control de Clientes tiene una interface
automtica de salida con el Sistema de Contabilidad, ya que genera las
plizas contables de los movimientos procesales de los clientes.

2.3.3 Lenguajes de Programacin 18 . Conocidos como el soporte lgico o

software de una computadora, de forma especfica es el conjunto de cdigos
organizados que de manera lgica da como resultado un software o programa
con una o muchas funcionalidades inmersas en l. Los lenguajes de
programacin son considerados una forma de comunicarse con la computadora
para indicar la tarea que se quiere realizar y la forma de llevarla a cabo.

Desde el comienzo de la historia de la informtica, la programacin de

computadores se ha convertido en una disciplina por derecho propio. Los
primeros sistemas de programacin, que utilizaban conexiones elctricas
realizadas con cables sobre tableros mviles, fueron rpidamente sustituidos
por otros que se apoyaban en mtodos cada vez ms sencillos y que, en
consecuencia permitieron alcanzar niveles ms altos de complejidad. Esta
evolucin afect simultneamente a los medios de introduccin de programas
en los computadores (cinta de papel, tarjetas perforadas, teletipo, mquina de
escribir, terminal provisto de pantalla, etc.) y a la forma de programar (lenguaje
mquina, lenguaje simblico, lenguajes de alto nivel, sistemas de desarrollo de
aplicaciones, entornos de generacin de sistemas de bases de conocimiento,
etc.)

Un programa completo consta siempre de dos partes: las instrucciones

ejecutables (o programa en sentido estricto) y los datos sobre los que actan
estas instrucciones. Segn la forma en que se organicen los datos y
programas, se distinguen las formas de programar: programacin lgica,
programacin orientada a objetos o programacin procedimental; en esta
ltima las instrucciones que componen los programas se ejecutan
secuencialmente en un orden prestablecido, que solo depende de los valores
de los datos a los que se aplica y que se puede deducir de estos,
inspeccionando el programa.

Los lenguajes de alto nivel se pueden clasificar de forma general en lenguajes

de propsito general y lenguajes de propsito especial. Los lenguajes de
propsito general se emplean igualmente en negocios, que aplicaciones
cientficas o en resolucin de problemas de ingeniera, como en tareas de
desarrollo de software de sistemas. Entre los lenguajes de propsito general
cabe citar al PASCAL, C y ADA.

18
Annimo. Lenguajes de Programacin Disponible en http://ocw.usal.es/ensenanzas-
tecnicas/informatica-ingeniero-tecnico-en-obras-publicas/contenidos/course_files/Temas/Tema_7_-
_Lenguajes_de_Programacion.PDF, consultado el 03 Junio de 2012.

15
Las categoras ms comunes de lenguajes de propsito especial son los
lenguajes comerciales, cientficos y educativos. En el campo comercial se
puede citar COBOL, en el campo cientfico, FORTRAN, y en el campo
educativo, aunque ya en desuso, BASIC.
Otra forma de clasificar los lenguajes es en lenguajes de procedimiento y
lenguajes declarativos:
Los lenguajes de procedimiento establecen como debe de ejecutarse
una tarea, dividindola en reas de procedimiento (procedures en ingls)
que especifican como realizar cada una de las tareas. Todos los
lenguajes de alto nivel desarrollados en las primeras pocas eran
lenguajes de procedimiento.

Los lenguajes declarativos describen estructuras de datos y las

relaciones entre ellas, siendo significativo para ejecutar una
determinada tarea, a la vez indican cual es el objetivo de esa tarea. El
proceso por el que se ejecuta la tarea no se establece de forma explcita
en el programa. Este proceso se determina por el sistema de traduccin
del lenguaje. Prolog es un ejemplo de lenguaje de programacin
declarativo.

2.3.4 Html (HyperText Markup Language)19. HTML significa HyperText Markup

Language (lenguaje de marcado de hipertexto, por sus siglas en ingles) es el
lenguaje con el que son creadas las pginas web. Las pginas web pueden ser
vistas por el usuario mediante un tipo de aplicacin llamada navegador. Se
puede decir por lo tanto que el HTML es el lenguaje usado por los navegadores
para mostrar las pginas webs al usuario, siendo hoy en da la interface ms
extendida en la red.

Este lenguaje permite adjuntar textos, sonidos e imgenes y combinarlos al

gusto del programador. Adems, y es aqu donde reside su ventaja con
respecto a libros o revistas, el HTML permite la introduccin de referencias a
otras pginas por medio de los enlaces hipertexto.

El HTML se cre en un principio con objetivos divulgativos. No se pens que la

web llegara a ser un rea de ocio con carcter multimedia, de modo que, el
HTML se cre sin dar respuesta a todos los posibles usos que se le iba a dar y
a todos los colectivos de gente que lo utilizaran en un futuro. Sin embargo,
pese a esta deficiente planificacin, s que se han ido incorporando
modificaciones con el tiempo, estos son los estndares del HTML. Numerosos
estndares se han presentado ya.

Esta evolucin tan anrquica del HTML ha supuesto toda una seria de
inconvenientes y deficiencias que han debido ser superados con la introduccin
de otras tecnologas accesorias capaces de organizar, optimizar y automatizar
el funcionamiento de las webs. Ejemplos son las CSS, JavaScript entre otros.

19
Annimo, Manual HTML. Disponible en http://profesores.fi-b.unam.mx/cintia/Manualhtml.pdf,
Consultado el 03 de Junio de 2012

16
Otros de los problemas que han acompaado al HTML es la diversidad de
navegadores presentes en el mercado los cuales no son capaces de interpretar
un mismo cdigo de una manera unificada. Esto obliga al Webmaster a, una
vez creada su pgina, comprobar que esta puede ser leda satisfactoriamente
por todos los navegadores, o al menos, los ms utilizados.

Adems del navegador necesario para ver los resultados de nuestro trabajo, se
necesita evidentemente otra herramienta capaz de crear la pgina en s. Un
archivo HTML (una pgina) no es ms que un texto. Es por ello que para
programar en HTML se necesita un editor de textos.

Es recomendable usar el Bloc de notas que viene con Windows, u otro editor
de textos sencillo. Hay que tener cuidado con algunos editores ms complejos
como WORDPAD o Microsoft Word, pues colocan su propio cdigo especial al
guardar las pginas y HTML es nicamente texto plano, con lo que no se
tendr problemas.

Existen otro tipo de editores especficos para la creacin de pginas web los
cuales ofrecen muchas facilidades que permiten aumentar la productividad. No
obstante, es aconsejable en un principio utilizar una herramienta lo ms sencilla
posible para poder prestar la mxima atencin a nuestro cdigo y familiarizarse
lo antes posible con l. Siempre se tendr tiempo ms delante de pasarse a
editores ms verstiles con la consiguiente ganancia de tiempo.

2.3.5 Php (PHP HyperText Pre-processor)20. PHP significa PHP HyperText

Pre-processor, Es un lenguaje de programacin pensado en el web, el ideal
para la creacin de pginas dinmicas. E la versin libre del sistema
equivalente de Microsoft ASP. Es un lenguaje encapsulado dentro de los
documentos HTML, de forma que se pueden introducir instrucciones PHP
dentro de las pginas.

Gracias a esto el diseador grfico del web puede trabajar de forma

independiente al programador. Es interpretado por el servidor (apache)
generando un HTML con el resultado de substituir las secuencias de
instrucciones PHP por su salida.

Es un lenguaje de desarrollo de aplicaciones web de cdigo abierto (open

source) muy verstil utilizado frecuentemente en forma conjunta con el servidor
de aplicaciones Apache y el sistema operativo Linux, PHP est entre las
tecnologas de cdigo abierto ms desarrolladas y usadas, permite la conexin
e interaccin a numerosas bases de datos de forma nativa como MySQL,
Postgres, Oracle, ODBC, IBM DB2, Microsoft SQL Server y SQLite, lo cual
permite la creacin de aplicaciones robustas y altamente confiables.

Tiene la capacidad de ser ejecutado en la mayora de los sistemas operativos

como UNIX, Linux, Windows y Mac OS X, e interacta con los servidores ms

20
Annimo. PHP. Disponible en http://www.sinemed.com/recursos/docs/PHP.pdf, Consultado el 03 de
Junio de 2012.

17
populares del mercado. La interpretacin y ejecucin del cdigo de la
aplicacin se da en el servidor donde se encuentra almacenada la informacin,
el usuario solo recibe el resultado de la ejecucin que puede ser desde una
imagen hasta una aplicacin completa.

PHP ha sobrepasado a Microsoft ASP, convirtindose en el lenguaje de

desarrollo web ms popular, siendo utilizado en ms de 19 millones de sitios.

Fuente: NetCraft PHP es fcil de integrar con ambientes y sistemas

heterogneos y completamente operativo con otros lenguajes, protocolos,
systemas, bases de datos, incluyendo C/C++, Java, Perl, COM/.NET,
XML/Web services, LDAP, ODBC, Oracle y MySQL.

PHP es estable y seguro y suficientemente robusto para soportar aplicaciones

de misin crtica de los negocios que requieren estar constantemente
disponibles y muy seguras. Adicionalmente PHP ofrece las siguientes ventajas:

Plataforma robusta, estable y segura

Alto desempeo
Interfaces con distintos sistemas de bases de datos
Diseado para trabajar con libreras que permiten la interaccin con
distintas aplicaciones web o en su defecto otros lenguajes
Facilidad de uso y aprendizaje del mismo
Facilidad de migracin
Bajo costo
Disponibilidad del cdigo fuente PHP est diseado para soportar
aplicaciones web que son escalables a un gran nmero de usuarios.

2.3.6 Base de datos21. El objetivo principal de las bases de datos es el de

unificar los datos que se manejan y los programas o aplicaciones que los
manejan. Anteriormente los programas se codificaban junto con los datos, es
decir, se diseaban para la aplicacin concreta que los iba a manejar, lo que
desembocaba en una dependencia de los programas respecto a los datos, ya
que la estructura de los ficheros va incluida dentro del programa, y cualquier
cambio en la estructura del fichero provocaba modificar y recompilar
programas. Adems, cada aplicacin utiliza ficheros que pueden ser comunes
a otras de la misma organizacin, por lo que se produce una REDUNDANCIA
de la informacin, que provoca mayor ocupacin de memoria, laboriosos
programas de actualizacin (unificar datos recogidos por las aplicaciones de los
diferentes departamentos), e inconsistencia de datos (no son correctos) si los
datos no fueron bien actualizados en todos los programas.

Con las bases de datos, se busca independizar los datos y las aplicaciones, es
decir, mantenerlos en espacios diferentes. Los datos residen en memoria y los
programas mediante un sistema gestor de bases de datos, manipulan la
informacin. El sistema gestor de bases de datos recibe la peticin por parte

21
Annimo. Teora de base de datos. Disponible en
http://si.ua.es/es/documentos/documentacion/office/access/teoria-de-bases-de-datos.pdf, consultado
el 30 de abril de 2012.

18
del programa para manipular los datos y es el encargado de recuperar la
informacin de la base de datos y devolvrsela al programa que la solicit.
Cada programa requerir de una cierta informacin de la base de datos, y
podr haber otros que utilicen los mismos datos, pero realmente residirn en el
mismo espacio de almacenamiento y los programas no duplicarn esos datos,
si no que trabajarn directamente sobre ellos concurrentemente. Aunque la
estructura de la base de datos cambiara, si los datos modificados no afectan a
un programa especfico, ste no tendr por qu ser alterado. Mediante estas
tcnicas de base de datos se pretende conseguir a travs del Sistema Gestor
de Bases de Datos (SGBD):

INDEPENDENCIA de los Datos: Cambios en la estructura de la Base

de Datos no modifican las aplicaciones.

INTEGRIDAD de los Datos: Los datos han de ser siempre correctos.

Se establecen una serie de restricciones (reglas de validacin) sobre los
datos.

SEGURIDAD de los Datos: Control de acceso a los datos para evitar

manipulaciones de estos no deseadas.

Como tal, una base de datos es un conjunto exhaustivo (en su modelizacin del
mundo real) de datos estructurados, fiables y homogneos, organizados
independientemente de su utilizacin y de su implementacin en mquina,
accesibles en tiempo real, compartibles por usuarios concurrentes que tienen
necesidades de informacin diferentes y no predecibles en el tiempo. Esa
informacin est bajo el control de un conjunto de programas que constituyen
el Manejador del Sistema de Base de Datos (DBMS por sus siglas en ingls) el
cual gestiona el manejo del conjunto de archivos que dan soporte fsico a la
informacin.

2.3.7 JavaScript22. JavaScript es un lenguaje de programacin que se utiliza

principalmente para crear pginas web dinmicas.

Una pgina web dinmica es aquella que incorpora efectos como texto que
aparece y desaparece, animaciones, acciones que se activan al pulsar botones
y ventanas con mensajes de aviso al usuario.

Tcnicamente, JavaScript es un lenguaje de programacin interpretado, por lo

que no es necesario compilar los programas para ejecutarlos. En otras
palabras, los programas escritos con JavaScript se pueden probar
directamente en cualquier navegador sin necesidad de procesos intermedios.

A pesar de su nombre, JavaScript no guarda ninguna relacin directa con el

lenguaje de programacin Java. Legalmente, JavaScript es una marca

22
EGULUZ PREZ, Javier. Introduccin a JavaScript. Disponible en:
http://www.librosweb.es/javascript/pdf/introduccion_javascript.pdf, consultado el 25 de junio de 2012.

19
registrada de la empresa Sun Microsystems, como se puede ver en
http://www.sun.com/suntrademarks/.

Especificaciones Oficiales: ECMA ha publicado varios estndares relacionados

con ECMAScript. En Junio de 1997 se public la primera edicin del estndar
ECMA-262. Un ao despus, en Junio de 1998 se realizaron pequeas
modificaciones para adaptarlo al estandar ISO/IEC-16262 y se cre la segunda
edicin.

Actualmente se encuentra en desarrollo la cuarta versin de ECMA-262, que

podra incluir novedades como paquetes, namespaces, definicin explcita de
clases, etc.

2.3.8 Metodologa Tradicional. Aquellas metodologas de desarrollo con mayor

nfasis en la planificacin y control del proyecto, en especificacin precisa de
requisitos y modelado. Para ello, se hace nfasis en la planificacin total de
todo el trabajo a realizar y una vez que est todo detallado, comienza el ciclo
de desarrollo del producto software. Se centran especialmente en el control del
proceso, mediante una rigurosa definicin de roles, actividades, artefactos,
herramientas y notaciones para el modelado y documentacin detallada.
Adems, las metodologas tradicionales no se adaptan adecuadamente a los
cambios, por lo que no son mtodos adecuados cuando se trabaja en un
entorno, donde los requisitos no pueden predecirse o bien pueden variar.

2.4 MARCO CONCEPTUAL

PRODUCT BACKLOG: en la estructura organizacional que se define al

principio del proyecto y contiene todos los requerimientos funcionales y no
funcionales que deber satisfacer el sistema a construir. Los mismos estarn
especificados de acuerdo a las convenciones de la organizacin ya sea
mediante: features (caractersticas), casos de uso, diagramas de flujo de datos,
incidentes, tareas, etc. El Product Backlog ser definido durante reuniones de
planeamiento con los stakeholders.

FEEDBACK: es un proceso utilizado para la comparacin y afirmacin de los

conocimientos adquiridos durante una actividad.

STAKEHOLDERS: son las otras personas interesadas en el proyecto y que

pueden realizar aportes significativos para el mismo.

SPRINT: A partir del Product Backlog se definirn las iteraciones, conocidas

como Sprint en la juerga de Scrum, en las que se ir evolucionando la
aplicacin evolutivamente. Cada Sprint tendr su propio Sprint Backlog que
ser un subconjunto del Product Backlog con los requerimientos a ser
construidos en el Sprint correspondiente. La duracin recomendada del Sprint
es de un mes.

20
PROTOTIPO: es el resultado que produce un sprint y se generan con el fin de
ir evolucionando el software a medida en que el proyecto avanza, para de ese
modo, poder ver constantemente que el trabajo que se va realizando est
generando frutos.

PRODUCT OWNER: representa la voz del cliente. Se asegura de que el

equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio.

SPRINT PLANNING: es el momento de planificacin de actividades a realizar o

concluir durante el Sprint.

SCRUM MASTER: tambien conocido como facilitador, cuyo trabajo primario es

eliminar los obstculos que impiden que el equipo alcance el objetivo del sprint.
El ScrumMaster no es el lder del equipo (porque ellos se auto-organizan), sino
que acta como una proteccin entre el equipo y cualquier influencia que le
distraiga. Es quien hace que las reglas se cumplan.

TEAM: conocido tambin como Equipo, tiene la responsabilidad de entregar el

producto. Un pequeo equipo de 5 a 9 personas con las habilidades
transversales necesarias para realizar el trabajo.

ITERACION: es la repeticin de una serie de instrucciones en un programa de

computador. Puede usarse tanto como un trmino genrico (como sinnimo de
repeticin) as como para describir una forma especfica de repeticin con un
estado mutable

APLICACION SOFTWARE: es un programa diseado para automatizar una

determinada tarea. Consta de una serie de instrucciones lgicas y en orden,
con el fin de cumplir un objetivo.

21
 3. DISEO METODOLOGICO

3.1 TIPO DE INVESTIGACION.

El tipo de investigacin se enmarca dentro de los estudios descriptivos, definida

por Roberto Hernndez Sampieri y otros autores en su libro Metodologa De La
Investigacin como aquella que describe situaciones y eventos, es decir, cmo
es y se manifiesta determinado fenmeno. En el presente estudio se describir
la implementacin de la metodologa Scrum buscando aumentar el grado de
familiaridad con este nuevo integrante de las nuevas alternativas de desarrollo
gil. El propsito de la investigacin ser el de mostrar cmo es y se aplica la
metodologa Scrum en un contexto particular: el Centro de Educacin Virtual
(CEV) de la Universidad San Buenaventura, Cartagena.

3.2 DISEO ADOPTADO.

El diseo adoptado para este estudio es el no experimental porque se indagar

la ocurrencia en que se manifiesta varias variables, proporcionando su
descripcin y estableciendo hiptesis descriptivas. Los diseos no
experimentales son definido por Roberto Hernndez Sampieri y otros autores
en su libro Metodologa De La Investigacin como aquella que se realiza sin
manipular deliberadamente variable, siendo su grado de control mnimo23. Su
estudio de caso se realizar con una sola medicin y consistir en administrar
la metodologa Scrum a casos particulares de desarrollo dentro del CEV y
despus aplicar mediciones a una serie de variables (tiempo, productividad,
rendimiento) para observar cul es el comportamiento de las variables en este
escenario particular24.

Los diseos no experimentales no son adecuados para el establecimiento de

relaciones entre la variable independiente y la variable dependiente, siendo
tiles como pruebas pilotos que permitirn, ms adelante, llevar experimentos
con mayor control que arrojen mediciones sobre variables, y que permita sacar
conclusiones ms slidas25.

Dentro de los diseos de estudio no experimental, se adopta el diseo

transaccional descriptivo, el cual indaga la incidencia y los valores en que se
manifiesta una o ms variables. El procedimiento que se seguir ser el de
medir las variables seleccionadas, proporcionando su descripcin,
estableciendo hiptesis descriptivas.

3.3 ENFOQUE DE LA METODOLOGIA.

Como paradigma metodolgico se ha elegido el enfoque cualitativo porque

permitir describir el desarrollo de procesos acadmicos requeridos en el
23
Ibd., p. 188
24
Ibd., p. 190
25
Ibd., p. 191

22
Centro de Educacin Virtual, mediante el seguimiento de la metodologa
Scrum, llevndola a estudio mediante el planteamiento de varios objetivos; esto
llevar a evaluar situaciones no provocadas intencionalmente, realizando
inferencias sobre las relaciones entre las variables tal y como se han dado en
su contexto natural y sin intervencin o influencia directa.

El enfoque cualitativo es definido por Roberto Hernndez Sampieri y otros

autores en su libro Metodologa De La Investigacin como aquella que utiliza
preferente o exclusivamente informacin de tipo descriptivo y cuyo anlisis se
dirige a lograr descripciones detalladas de los fenmenos estudiados. El
enfoque cualitativo describe la realidad en el que se desarrolla un
acontecimiento dado, es decir la metodologa cualitativa se basa en una
rigurosa descripcin contextual de un hecho o situacin que garantice la
mxima intersubjetividad en la captacin de una realidad compleja mediante
una recogida sistemtica de datos que posibilite un anlisis e interpretacin del
fenmeno en cuestin.

3.4 TECNICAS DE RECOLECCION DE LA INFORMACION

3.4.1 Fuentes primarias. Las fuentes primarias aportan datos a la investigacin,

buscando recopilar informacin acerca del tema que se est analizando. En la
presente investigacin la principal fuente de informacin sern los artculos de
revistas que hagan referencia a la metodologa Scrum, as como apartados
periodsticos, entrevistas realizadas a expertos, tesis y disertaciones que
toquen temas relacionados con este tipo de metodologa.

Tambin se contar con la colaboracin del Ingeniero Javier Garca

Altamiranda, Coordinador Tecnolgico del CEV, as como de los
desarrolladores vinculados al CEV. La informacin pertinente para el correcto
desarrollo de este proyecto se obtuvo a travs de la asesora continua del
Coordinador Tecnolgico como gestor de la idea de implementar Scrum y su
posterior orientacin en el desarrollo del mismo buscando mejorar el ndice de
desarrollo de software. La informacin acerca de la lgica de negocio se
consignar en las historias de usuario; la elaboracin de stas se realizar en
reuniones que integrarn al equipo desarrollador y el Ingeniero Javier Garca a
lo largo de todo el desarrollo del proyecto, desempeando dos roles bien
definidos: como representante del cliente y como Scrum Manager.

El papel que da ser representante del cliente permite obtener la visin general
del producto, creando a partir de stas el Product Backlog o lista de tareas que
se van a realizar, determinndose los requisitos que el software debe realizar
para dar respuesta a las funcionalidades esperadas por el cliente. El Product
Backlog representa todo aquello que esperan los clientes y usuarios que tenga
el software.

La elaboracin del Product Backlog se da como resultado de una reunin

cruzada entre el representante del cliente y el equipo desarrollador antes de
iniciar la planeacin de los Sprint. Pero no es un producto terminado sino que
estar en continua evolucin y crecimiento mientras el producto est en

23
desarrollo, por lo cual, se permitir agregar, quitar o cambiar especificaciones
requeridas al producto final. Esto se har durante las reuniones de planeacin
de futuros Sprint, en los cuales debern estar presentes el representante del
cliente y el equipo desarrollador en pleno.

3.4.2 Fuentes secundarias. Como fuentes secundarias de la investigacin se

tienen libros relacionados con la metodologa Scrum; los libros relacionados
con la gua de desarrollos giles y los sistemas metodolgicos similares
desarrollados en el mercado, as mismo, el componente del sistema de
informacin que se ha venido desarrollando en el CEV de la Universidad
requiere de documentos de referencias que permitan conocer el alcance del
mismo. Se constituye as un extenso campo bibliogrfico que puede ser
utilizado para el desarrollo de la presente investigacin.

3.5 VARIABLES

En la metodologa cualitativa, los datos recogidos necesitan ser traducidos en

categoras con el fin de poder realizar comparaciones y posibles contrastes, de
manera que se pueda organizar conceptualmente los datos y presentar la
informacin siguiendo algn tipo de patrn o regularidad emergente. La
categorizacin (es decir, cerrar o establecer las categoras) facilita la
clasificacin de los datos registrados, y por consiguiente, propicia una
importante simplificacin26. Teniendo en cuenta lo anterior se determinan las
siguientes variables:

Aplicacin Software

Procesos acadmicos

Base de datos

Scrum

26
AUSTIN MILLN, Toms. Investigacin cualitativa. Disponible en
http://metodoinvestigacion.wordpress.com /2008/02/29/investigacion-cualitativa/. Consultado el 26 de
marzo de 2012.

24
3.6 OPERACIONALIZACION DE VARIABLES

VARIABLE DEFINICION DIMENSION INDICADORES

Aplicacin Es un programa diseado Anlisis Suficiente
Software para automatizar una Insuficiente
determinada tarea. Consta
de una serie de Diseo Simple
instrucciones lgicas y en Complejo
orden con el fin de cumplir Implementacin Suficiente
un objetivo. Insuficiente

Procesos Administrativos
acadmicos Los procesos acadmicos Simple
son todos aquellos trmites Complejo
relacionados con la vida Acadmicos Simple
acadmica de los Complejo
estudiantes referidos a los
procesos de matrcula,
pagos, evaluacin de
docentes, consulta de notas
y horarios.

Base de Almacenamiento
Datos Es un conjunto de datos Satisfactorio
almacenados Insatisfactorio
sistemticamente para su
uso posterior, permitiendo Consulta Satisfactorio
operaciones como Insatisfactorio
actualizacin, borrado y
adicin de datos, adems
de las operaciones
fundamentales de consulta

Scrum Es una metodologa de Aplicativo Satisfactorio

desarrollo de software gil Insatisfactorio
que permite obtener
aplicaciones utilizando
avances iterativos e
incrementales.

Tabla 1. Operacionalizacin de Variables

25
3.7 PROCESAMIENTO DE LA INFORMACION

Despus de observar y evaluar la realidad que vive el Centro de Educacin

Virtual (CEV), se propondr un plan de trabajo que entregue sistemas amenos,
intuitivos y prcticos que optimicen procesos acadmicos como son el acceso a
la informacin personal, administracin de notas estudiantiles, portal para el
manejo de prcticas industriales, inscripcin a votaciones estudiantiles y portal
de votaciones estudiantiles.

Siguiendo la Metodologa Scrum se definirn un planeamiento inicial con el

propsito es establecer la visin y definir expectativas. Esto se concreta al
definir Product Backlog, que contiene todos los requerimientos funcionales y no
funcionales que deber satisfacer los sistemas a construir. Se realizar el
registro de acumulacin (Product Backlog) del producto inicial y los tems
estimados, as como la arquitectura de alto nivel, el diseo exploratorio y los
prototipos a alcanzar.

Luego se pasara a la etapa de desarrollo cuyo propsito ser el de

implementar un sistema listo para entregar a lo largo de una serie de
iteraciones de quince das llamadas sprints. En los sprints son planeadas las
actividades para cada iteracin, y que se constituyen en estimados, que dan la
temtica a los encuentros diarios de Scrum. Finalmente se realizar el
despliegue operacional que pondr en funcionamiento los sistemas
construidos. Cuando esta etapa finalice se formalizaron los documentos
respectivos para su entrega oficial.

3.8 RECURSOS TECNOLOGICOS

3.8.1 El Paradigma de Programacin.

POO: El Paradigma Orientado a Objetos expresa un programa como un

conjunto objetos, que colaboran entre ellos para realizar tareas. Esto
permite hacer los programas y mdulos ms fciles de escribir,
mantener y reutilizar. Un objeto es aqul que posee Atributos,
Comportamiento e Identidad. Los atributos o propiedades de un objeto
definen los datos que el mismo objeto manipula para realizar sus
funciones. El comportamiento de un objeto define la funcionalidad del
mismo; es a travs de mtodos o funciones que se puede manipular sus
propiedades o las de otros objetos. Estos (los objetos) son elementos
abstractos que referencia una serie de propiedades y funciones. Estas
son definidas en las llamadas Clases. Una clase es una definicin de un
objeto en donde se declaran sus propiedades y el comportamiento.27

27
ORTEGA MONTALVO, Nohora y otro. Desarrollo de un aplicativo web para apoyar el anlisis
estructural del proceso prospectivo en las organizaciones. Universidad de San Buenaventura Cartagena,
Colombia.

26
 El paradigma de programacin orientado a objetos posee las siguientes
caractersticas:28

Herencia: Las clases pueden heredar el comportamiento y

las propiedades de otras clases, relacionndolas entre s
formando una jerarqua de clasificacin. Esto permite construir
componentes de software ms flexibles y reutilizables.

Polimorfismo: Dentro de una clase se pueden definir

comportamientos con el mismo nombre, pero que realizan una
funcin diferente segn el parmetro o la condicin en que se
reciban.

Abstraccin: Se emplea en las clases cuando se definen sus

propiedades y mtodos por nombre ms no lo que estos
realmente hacen. Las clases abstractas definen o agrupan a
clases hijas que heredan estas propiedades y es en estas
donde se deben definir su comportamiento.

Modularidad: Refiere al poder descomponer el cdigo en

piezas de cdigo mejores (mdulos) a fin de ganar en
legibilidad y facilidad de revisin. As en lugar de slo un
mtodo impresin en una clase informe, usted podra dividirlo
en ttulo, cuerpo, y mtodos pie de pgina. Igualmente, el
mtodo cuerpo podra dividirse en los ttulos de la columnas,
lnea de tems, y mtodo pie de pgina de columna.

Estas caractersticas ofrecen una mayor ventaja ante las

dems filosofas de programacin. Del paradigma orientado a
objetos se puede obtener un sistema de informacin completo,
reutilizable y flexible.

3.8.2 Herramienta de Desarrollo de Software. A continuacin se define la

herramienta.

PHP: La herramienta para desarrollar este proyecto fue PHP (HyperText

Preprocessor), por muchas razones. Es una herramienta que permite
crear interfaces con ambiente web, es potente, eficiente, fcil de
aprender, Open Source (Cdigo fuente abierto), lo cual implica que sea
de libre distribucin, permite el acceso a bases de datos, portable,
multiplataforma y porque dispone de abundante soporte en la Web.

3.8.3 Herramientas Software. A continuacin se describen las herramientas

que se utilizaron en el proceso.

28
Ibd.

27
 NetBeans: Para el desarrollo del sistema de informacin se utilizar el
lenguaje de programacin orientado a objetos PHP, el cual crea objetos
mediante instrucciones secuenciales, y que son manipulables mediante
la utilizacin de mtodos que son interfaces que dejan entrever su
funcionalidad. Los mtodos permiten a los objetos comunicarse entre
ellos a travs del paso de mensajes. PHP es un lenguaje de
programacin joven pero muy robusto y potente, que mediante la
utilizacin de herramientas de edicin como Netbeans versin 7.0.1, que
permite crear interfaces o ventanas de interaccin agradables al usuario.

3.8.4 Herramientas de Diseo. Como herramienta de diseo se utiliz.

HTML: acrnimo de HyperText Markup Language o lenguaje de marcas

de hipertexto. Se utilizar esta herramienta de desarrollo de software
porque es el formato estndar de los documentos que circularan en la
Word Wide Web (WWW), y porque adems HTML es un lenguaje muy
sencillo que permite describir hipertexto, es decir, texto presentado de
forma estructurada y agradable, con enlaces (hyperlinks) que conducen
a otros documentos o fuentes de informacin relacionadas, y con
inserciones multimedia (grficos, sonido.). HTML realiza una
descripcin de pgina independiente del dispositivo, lo que permite
adaptar la visin del documento al tamao de la pantalla en la que se
muestra.

3.8.5 Herramientas Hardware. Las herramientas hardware fueron las descritas

a continuacin.

Para la construccin del sistema de informacin se utilizaran las

siguientes configuraciones mnimas en cuanto al rendimiento que deber
tener el equipo utilizado para el desarrollo del software:

Procesador de 3 GHz, doble ncleo.

3GB DDR2 de Memoria RAM.
250GB de espacio en disco.
Tarjeta Aceleradora de Video de 512MB DDR2.
Sistema operativo Microsoft Windows 7.

Para que el usuario use el sistema con buenas respuestas en cuanto a

la fluidez del mismo, se calcula que ser menor el requerimiento que
necesitara, a continuacin se muestra las configuraciones mnimas
necesarias para que el sistema funcione en recomendables condiciones.

Procesador de 2.8GHz.
2GB DDR2 de Memoria RAM.
250GB de espacio en disco.
Sistema operativo Microsoft Windows XP, Vista 7.

28
 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
desplegar el sistema29. 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
lgica de componentes y funcionalidad, brindando entre otras ventajas30:

Localizar los cambios de un tipo en una parte de la solucin minimiza el

impacto en otras partes, reduce el trabajo requerido en arreglar defectos,
facilita el mantenimiento de la aplicacin y mejora la flexibilidad general
de la aplicacin.

La separacin de responsabilidades entre componentes (por ejemplo,

separar la interfaz de usuario de la lgica de negocio, y la lgica de
negocio del acceso a la base de datos) aumenta la flexibilidad, la
mantenibilidad y la escalabilidad.

29
Gua Arquitectura N-Capas Orientada al Dominio - Microsoft Architecture (1a Edicin Noviembre
2010)
30
Ibd.

29
 La reutilizacin de ciertos componentes entre diferentes mdulos de una
aplicacin o incluso entre diferentes aplicaciones.

Equipos diferentes deben poder trabajar en partes de la solucin con

mnimas dependencias entre los diferentes equipos de desarrollo y para
ello, deben desarrollar contra interfaces bien definidas.

El sistema de informacin desarrollado en la Universidad de San Buenaventura

Cartagena sigui un diseo bsico de capas: Los componentes de la solucin
han sido divididos en capas presentando una interaccin que se ilustra en la
figura 1. Las capas son agrupaciones horizontales lgicas de componentes de
software que forman la aplicacin o el servicio. Ayudan a diferenciar entre los
diferentes tipos de tareas a ser realizadas por los componentes, ofreciendo un
diseo que maximiza la reutilizacin y, especialmente, la mantenibilidad. En
definitiva, se trata de aplicar el principio de Separacin de Responsabilidades
(SoC - Separation of Concerns principle) dentro de una Arquitectura31.

Figura 2. Interaccin en arquitectura de capas

La gestin de dependencias escogido para el diseo de las aplicaciones es

laxo en tanto que permite que los componentes de una capa pueden
interactuar con cualquier otra capa de nivel inferior. Esto mejora el rendimiento
porque el sistema no tiene que realizar redundancia de llamadas de unas
capas a otras.

31
Ibd.

30
Figura 3. Vista de la arquitectura lgica implementada en el sistema de
informacin de la Universidad de San Buenaventura, Cartagena.

31
A continuacin se describen las diferentes capas en que encuentra dividida la
arquitectura lgica del sistema de informacin de la Universidad de San
Buenaventura (ver figura 3), la cual da una visin global y permite comprender
mejor todo el sistema:

Capa de Presentacin: Esta capa es responsable de los componentes

visuales que se muestran al usuario. Los componentes han sido
divididos en mdulos, los cuales implementan las funcionalidades
requeridas para que los usuarios interacten con la aplicacin. Los
componentes de esta capa han sido divididos en:

Componentes Visuales (vistas): Estos componentes proporcionan

el mecanismo base para que el usuario utilice la aplicacin. Son
componentes formados por los datos guardados en base de datos
y suministrados a travs de los controladores; otra parte de los
componentes est constituida por los recibidos por el usuario.

Controlador: Es un subcapa encargada de sincronizar y orquestar

las interacciones del usuario, siendo til para conducir el proceso
separando los componentes propiamente grficos de la lgica de
negocio, impidiendo que el flujo de proceso y lgica de gestin
est programada dentro de los propios controles y formularios
visuales, permitiendo reutilizar dicha lgica desde otra interfaces
o vistas.

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.).

Capa Service (Aplicacin): Esta capa no contiene reglas del dominio o

conocimiento de la lgica de negocio, simplemente debe realizar tareas
de coordinacin de aspectos tecnolgicos de la aplicacin que nunca se
explicaran al propietario del producto. Es una capa que brinda servicios
que coordinan otros llamadas a otros servicios, siendo su principal
beneficiario la capa de presentacin. Un ejemplo lo constituira un
servicio ofrecido a la capa de aplicacin, ste coordinar las llamadas a
la los servicios que brinda la capa de Dominio y posteriormente las
realizadas a Repositorios para realizar la persistencia.

32
 La capa Service se convierte en una Capa Fachada, sin la cual no se
pueden utilizar los servicios que brindan otras capas de la aplicacin.
Por esto, en esta misma capa, pero solapada se encuentra la capa de
Seguridad: nada puede se consumido y nada podr acceder a la
aplicacin sin haber hecho uso de esta capa.

Capa Component (Modelo de Dominio): Esta capa es responsable de

representar conceptos de negocio, informacin sobre la situacin de los
procesos de negocio e implementacin de las reglas del dominio.
Tambin debe contener los estados que reflejan la situacin de los
procesos de negocio. Esta capa, Dominio, es el corazn del software.

As pues, estos componentes implementan la funcionalidad principal del

sistema y encapsulan toda la lgica de negocio relevante. Bsicamente
suelen ser clases en el lenguaje seleccionado que implementan la lgica
del dominio dentro de sus mtodos. Para conseguir la mxima
independencia de los objetos del Dominio, las entidades del dominio se
han implementado como clases POCO. Estas dan ventajas como
independencia de las entidades con respecto a tecnologas concretas
siendo clases relativamente ligeras con buen rendimiento y adecuadas
en implementaciones N-Capas.

Esta capa ignora completamente los detalles de persistencia, siendo

stas realizadas por la capa de infraestructura. El consumo de datos se
realiza mediante contratos o interfaces que ofrece los objetos del
repositorio.

Capa de Data y Model (Infraestructura de Persistencia de Datos): La

capa de infraestructura contiene todo lo ligado a la tecnologa e
infraestructura sobre la cual se construye la aplicacin. Esta capa
proporciona la capacidad de persistir datos as como lgicamente
acceder a ellos. Pueden ser datos propios del sistema o incluso acceder
a datos expuestos por sistemas externos (Base de datos alternas). As
pues, esta capa de persistencia de datos expone el acceso a datos a las
capas superiores, normalmente las capas del dominio. Esta exposicin
deber realizarse de una forma desacoplada.

Un componente importante dentro de la capa de persistencia y acceso a

datos est compuesto por los repositorios. Estos son clases/objetos que
encapsulan la lgica necesaria para acceder a los datos, es decir, de
mtodos para consultar, aadir, modificar y eliminar objetos. Permite
adems seleccionar objetos basndose en criterios de seleccin,
devolviendo objeto o colecciones de objetos instanciados con los
valores del criterio.

La tecnologa de persistencia utilizada en los repositorios es un O/RM

llamado N/Hibernat. Junto a esta tecnologa utilizada internamente se
aadieron operaciones de Base de datos. Cabe aadir que se logrado

33
 desacoplar la capa de persistencia mediante el uso de
interfaces/contratos. Este contrato ser lo que la capa de Dominio
requiera de un repositorio para que pueda funcionar.

Capa Common: Se debe asegurar la implementacin de mecanismos de

desacoplamiento entre los objetos de las capas. Por esto se hace
necesario el desacoplamiento entre capas mediante contratos e
interfaces que utilicen Inyeccin de Dependencia e Inversin de Control.
Esta mantenibilidad del sistema es dada por esta capa en donde se
realizan las instancias necesarias para tal fin. Esto facilita la sustitucin
de capas o mdulos sin ningn tipo de dificultad. La IoC describe
tcnicas para soportar una arquitectura tipo plug-in donde los objetos
pueden buscar instancias de otros objetos que requieren y de los cuales
dependen. DI Es un patrn en el que se suplen objetos/dependencias a
una clase en lugar de ser la propia clase quien cree los
objetos/dependencias que necesita.

La elaboracin del frontend de las aplicaciones que administran los procesos

acadmicos en la Universidad de San Buenaventura Cartagena, implic el
manejo principlamente de la capa de presentacin principalmente, junto a un
conocimiento superficial de las dems capas (esto segn la utilizacin dentro
de los trabajos que se desarrollaban).

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.

34
El resto de roles definidos por Scrum fueron designados de la siguiente
manera: Elkin Torres Martnez, Edson Arzuza Agudelo, Oscar Fernando
Becerra Uribe, Manlio Ferreira y Jeisson Guevara como equipo desarrollador.
Dentro equipo desarrollador se design a Manlio Ferreira como Team Leader,
miembro del equipo que conduce y garantiza el protocolo, formato y tiempos de
la reunin.

El proceso iniciado con la definicin sencilla y clara de las caractersticas que

debe tener el producto que iba a ser desarrollado, permiti definir las historias
de usuario que iban guiar el proceso. Esta etapa recibe el nombre de
"fertilizacin cruzada" o brainstorming.

Posteriormente, el Representante del Cliente tom cada historia de usuario y

la desglos de forma que permiti identificar de forma ms fcil, las tareas a
llevar a cabo. El resultado de este desglose fue el Product Backlog, que
contiene todas las historias de usuario junto al nivel de prioridad que tienen
para el cliente, siendo toda una gua de desarrollo.

El Product Backlog es propio del Dueo del Producto o como en este caso, del
Representante del Cliente y servir para registrar el estado y las modificaciones
de la pila del producto. Este inventario de funcionalidades y tecnologas que el
sistema debe incorporar a travs de iteraciones de desarrollo, no constituye un
documento inicial y definitivo, sino en un instrumento que permite incorporar
modificaciones, correcciones e incorporacin de nuevas funcionalidades.

4.2.1 Product Backlog. Teniendo en cuenta lo anterior se define a continuacin

este elemento de Scrum. Se tienen cinco secciones de trabajo, los cuales
presentan requerimientos que han sido transmitidas al grupo de
desarrolladores en la reunin de planificacin del primer Sprint. Estos mdulos
se especifican a continuacin: Portal de Docentes, Seguimiento de Prcticas,
Portal Estudiante, Portal Egresados y Portal de Elecciones.

Portal de Docentes: Esta seccin permite visualizar informacin personal

del docente, actualizar sus datos, publicar y corregir notas. Se halla
dividido en los siguientes mdulos:

Mdulo Actualizacin de Datos: Actualiza la Informacin de Contacto

y Datos an no diligenciados.

Mdulo Ficha de Docente: Muestra la Informacin Bsica del

Docente y Permite el Envo de Correo Electrnico

Mdulo Publicacin de Notas: Permite el Registro de Calificaciones

Mdulo Correccin de Notas: Permite la Correccin de Calificaciones

Seguimiento de Prcticas: Esta seccin permite realizar un seguimiento

virtual a las prcticas que realiza el estudiante. En ella interactan

35
empresa, docente encargado y estudiante. Se halla dividido en los
siguientes mdulos:

Mdulo Creacin de Solicitud: Creacin de Solicitud de Practicante

por parte de una Empresa

Mdulo Responder Solicitud: Respuesta de una Solicitud de

Practicante por parte de un Coordinador de Prcticas

Figura 4. Product Backlog del Desarrollo

Mdulo Gestin de Empresas: Crear, Actualizar, Eliminar y Editar

Empresas

36
 Mdulo Diligenciar Bitcora: Permite tramitar el llenado de las
bitcoras de trabajo que se han realizado por parte del estudiante.

Mdulo Valorar Practicante: Le permite al empresario dar una

calificacin a cada practicante evaluando la labor realizada.

Mdulo Finalizar Prctica: Le permite al empresario dar por

terminado el periodo de prcticas, siempre y cuando no existan
labores pendientes por parte del practicante.

Mdulo Reportar Amonestacin: Le permite al empresario realizar

amonestaciones al practicante, informando a ste y al tutor de
prcticas la situacin presentada.

Mdulo Ver Amonestaciones: Le permite al tutor de prcticas ver las

amonestaciones que realiza el empresario.

Mdulo Responder Amonestaciones: Le permite dar respuesta a

cada amonestacin que el empresario haga de un practicante.

Mdulo Practicantes Asignados a Empresa: Les permite a los tutores

de prctica asignar practicantes de acuerdo a las solicitudes
existentes de empresas.

Mdulo: Cargar Certificado: Una vez que el empresario a dado por

finalizada una prctica, se debe cargar un certificado que informe de
tal hecho.

Portal Estudiante: Esta seccin permite visualizar, de forma general,

informacin de inters para el estudiante, sus datos personales y su
histrico de notas. Se halla dividido en los siguientes mdulos:

Mdulo Actualizacin de Datos: Actualiza la Informacin Personal,

Familiar, Acadmica, Laboral y Estudios de Idiomas que este
presenta.

Mdulo Historial de Notas: Muestra las Calificaciones Obtenidas por

el Estudiante en las Materias Cursadas en su carrera universitaria.

Mdulo Semforo Acadmico: Muestra los Cursos Aprobados y

Pendientes del Plan de Estudio relacionado con cada estudiante.

Mdulo Informacin de Estudiante: Muestra la informacin Personal

Mdulo Perfil del Estudiante: Muestra una Ficha con la Informacin

Bsica y la Posibilidad de Envo de Correo Electrnico

37
 Portal Egresados: Esta seccin permite visualizar, de forma general,
informacin de inters para los egresados, como sus datos personales y
su histrico de notas. Se halla dividido en el siguiente mdulo:

Mdulo Actualizacin de Datos: Actualiza la Informacin Personal,

Familiar, Acadmica, Laboral y Estudios de Idiomas

Portal de Elecciones: Esta seccin permite realizar de forma sistematiza

todo el proceso de elecciones: inscripcin, aprobacin de candidatos y
la respectiva eleccin de los mismos. Se halla dividido en los siguientes
mdulos:

Mdulo Inscripcin: Permite a un estudiante activo inscribirse como

candidato para el consejo acadmico o representante de facultad.

Mdulo Aprobacin candidatos: Permite a una persona encargada

aprobar la candidatura de estudiantes al consejo acadmico o
representante de facultad.

Mdulo Votacin: Permite a estudiantes que se encuentren activos

realizar la votacin por sus candidatos favoritos.

4.3 ITERACIONES DE IMPLEMENTACION DE LOS PRODUCTOS.

Scrum permite trabajar en productos diferentes simultneamente, es decir, un

Sprint no representa el desarrollo de un producto o aplicacin, sino que
constituye el avance en las actividades prioritarias definidas al inicio del Sprint
y que constituyen entregables, que van incrementndose hasta convertirse en
los productos exigidos por el Product Owner.

Como ya se mencion, al comienzo del proyecto se reuni el Scrum Master y a

la vez Representante del Producto (Product Owner) con un representante de la
Universidad San Buenaventura, lo cual permiti intercambiar ideas y
establecer las historias de usuario que sern necesarias para la creacin del
Product Backlog.

4.3.1 Exposicin del Product Backlog. Una vez establecido el Product Backlog,
se realiz la primera reunin con todos los integrantes del proyecto (Product
Owner, Scrum Master y Scrum Team); su duracin de 8 horas en promedio fue
dividid en dos partes: en la primera de 4 horas, el Product Owner describi
todas las funcionalidades del producto o tambin llamadas Historia de Usuario.
Durante la primera parte de la reunin se definieron por parte del Product
Owner, los elementos de alta prioridad.

38
4.3.2 Resolucin del Sprint Backlog. En la segunda parte de la reunin se
seleccionaron, de las tareas que han sido colocadas en la Product Backlog,
aquellas que iban a ser desarrolladas durante el primer Sprint. Estas tareas
seleccionadas fueron escritas en memos con los que se cre el Sprint Backlog,
llevando el orden de importancia para el Dueo del Producto.

El equipo garantiza tener listos los elementos de la pila que hayan sido
elegidos, siendo esto una clave de Scrum, ya que son ellos mismos quienes,
basndose en su propio anlisis y planificacin se comprometen a terminar la
parte del producto escogida. El dueo del Producto aunque no tiene control
sobre la cantidad de trabajo realizado, goza de elementos prioritarios para el
proyecto.

Luego de esto, el equipo estim la cantidad de tiempo que empleara en cada

actividad, emplendose para esto el juego del Pker. Cada miembro daba su
estimacin con una tarjeta que contena un nmero que simbolizaba el nmero
de horas que tardara en realizar la actividad, siendo luego comparadas con las
del resto del equipo y escogindose, a partir de estas, la media del tiempo que
cada miembro del equipo haya manifestado. El significado de los nmeros y
smbolos utilizados en el pker se muestran a continuacin:

0: La tarea no tomar tiempo pues ya est realizada.

: Tarea que tomar media hora para su realizacin.
? : El significado que representa esta tarjeta en la reunin es que no se
tiene conocimiento de cmo se realizar la actividad o no sabe de qu
se est hablando ya que no se maneja el tema.
: El significado que representa esta tarjeta en la reunin es que la
actividad que se est evaluando tomara un tiempo indefinido, es decir,
es incalculable.
1, 2, 3, 5, 8, 13, 20, 40, 100: Cada nmero representa una tarjeta, y
representa el nmero de horas que la actividad tomar en realizarse.

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

39
para que fuese l quien tomase las medidas al respecto. Se proceda como
viene a continuacin:

Cada integrante del equipo responda estas tres interrogantes:

1. En qu tarea trabaj ayer?
2. En qu tarea trabajar hoy?
3. Si van a necesitar algo especial o prevn algn
impedimento para realizar su trabajo.

Se actualizaba en el Sprint Backlog el tiempo de trabajo que queda

pendiente a su vez que se marcaban las tareas que hubiesen sido
terminadas (slo las que ya hayan sido probadas).

Figura 5. Sprint Backlog del Desarrollo

Con la informacin del encuentro diario se actualizan las columnas No

empezado, En Progreso y Completado del Sprint Backlog y la Grfica de
trabajo (Diagrama de Burn-Down), aadiendo en sta las horas de trabajo de
las tareas realizadas. La grfica de no queda nada de esfuerzo o de Burn-

40
Down mostraba el progreso del equipo hacia su objetivo y el trabajo restante
para alcanzar tal fin.

Figura 6. Avance de un Sprint

Una vez que el equipo iniciaba el desarrollo del Scrum, no se permitan

cambios en actividades o adicin de actividades, debiendo esperar al siguiente
Sprint. En cambio se permiti que uno o dos integrantes trabajasen en estas
actividades imprevistas con prioridad alta, y dejar por sentado en el Sprint
Backlog estos imprevistos; los dems integrantes del equipo deban suplir en la
medida que lo requiera, las actividades que se dejaban de desarrollar por este
cambio de planes, no afectando fuertemente el avance del Sprint.

El equipo de trabajo, a medida que avanza el desarrollo de las actividades,

deba ir detallando nuevos requisitos, separar elementos grandes en otros ms
pequeos, estimar actividades imprevistas y restimando elementos ya
existentes. Para esto se dejaba un espacio dentro del Sprint Backlog dedicado
a Actividades Futuras, con lo cual se dejaban actividades claras y estimadas
para el siguiente Sprint.

La duracin de los Sprint nunca se prolongaron ms haya del tiempo

establecido para los mismos, es decir, se terminaron en la fecha asignada
aunque el equipo no hubiese terminado con todas las actividades con las que
se haba comprometido.
41
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:

Sprint 1: Por ser el primer sprint de la implementacin de la metodologa,

todos los participantes estaban sumamente ansiosos por ver como
evolucionaba; este Sprint en particular fue el caso de una
implementacin ideal, debido a que, a pesar que era la primera
experiencia con respecto a la implementacin de la metodologa, se
logr una ejecucin casi perfecta, a razn de que los tiempos se
cumplieron tal como se planearon y las tareas se realizaron como se
discutieron en la reunin de planeacin del sprint das atrs. Cabe
mencionar, que los comentarios de muchos autores con respecto al
primer sprint, no son muy agradables, puesto que, ellos mencionan que
por ser la primera experiencia con la metodologa, casi siempre se
produce una psima ejecucin, arrojando como resultado actividades sin
completar, apata de los participantes a la nueva metodologa, entre
otras cosas, pero ese no fue el caso de esta implementacin.

Las actividades y sub-actividades que se tuvieron en cuenta en este

sprint fueron las siguientes:

42
 Realizar Solicitud de Grado
Sub-Actividades Prioridad Tiempo Comentario
Obtencin de Media 4 Horas Ninguno
Requerimientos

Tabla 2. Actividad Realizar Solicitud de Grado

Realizar Certificados
Sub-Actividades Prioridad Tiempo Comentario
Definir que Media 4 Horas Ninguno
certificados se
sistematizan
Definir procesos de Media 4 Horas Ninguno
certificados
Estudiar Firma Baja 2 Horas Ninguno
Digital

Tabla 3. Actividad Realizar Certificados

Realizar Matricula Acadmica

Sub-Actividades Prioridad Tiempo Comentario
Definir Proceso Urgente 8 Horas Ninguno

Tabla 4. Actividad Realizar Matricula Acadmica

Ver Perfil del Estudiante

Sub-Actividades Prioridad Tiempo Comentario
Diseo de UI Media 1 Horas Mostrar Cdigo,
nombre y apellido,
y agregar botn
enviar
Controlador de Alta 6 Horas Enviar por SMPT,
Envo de Correo sendmail, phpmail
UI envo de correo Media 2 Horas WYSIWYG, array,
destinatario POST

Tabla 5. Actividad Ver Perfil del Estudiante

43
 Ver Informacin del Estudiante
Sub-Actividades Prioridad Tiempo Comentario
Agregar el estado Media 3 Horas Creacin HBM,
del Estudiante entidades API,
entidades PHP
Diseo UI Baja 4 Horas Agregar atributo
estado

Tabla 6. Actividad Ver Informacin del Estudiante

Mostrar Horario de Clases

Sub-Actividades Prioridad Tiempo Comentario
Agregar Docente Baja 1 Horas Ninguno
a la UI

Tabla 7. Actividad Mostrar Horario de Clases

Mostrar Semforo Acadmico

Sub-Actividades Prioridad Tiempo Comentario
Cambiar Nombre Baja 10 Minutos Ninguno
al Mdulo

Agrupar Media 3 Horas Ninguno

Aprobadas por
semestre
Agrupar Cursos Media 3 Horas Ninguna
Pendientes por
Semestre
Agrupar Pensum Media 3 Horas Ninguna
del Programa

Tabla 8. Actividad Mostrar Semforo Acadmico

Mostrar Historial de Notas

Sub-Actividades Prioridad Tiempo Comentario
Sincronizar cortes Urgente 5 Horas Tener en cuenta el
con programacin nuevo reglamento
acadmica institucional
Obtener periodo Media 2 Horas Ninguna
acadmico por
GET

Tabla 9. Actividad Mostrar Semforo Acadmico

44
 Realizar Actualizacin de Datos de Estudiantes
Sub-Actividades Prioridad Tiempo Comentario
Reparar Cdigo Urgente 9 Horas Ninguno
JS (jQuery/Ajax)

Revisar/Reparar Urgente 6 Horas Ninguno

que todo guarde

Colocar como no Media 4 Horas 5 Siempre

editables los editable datos
campos personales
pertinentes 6 Cuando no
existan datos
del nombre del
padre y de la
madre, ser
editables
Implementar Baja 2 Horas Ninguno
formulario de
Historial Laboral
como MODAL
Implementar Baja 2 Horas Ninguno
formulario de
Historial
Acadmico como
MODAL
Implementar Baja 2 Horas Ninguno
formulario de
Estudios de
Idiomas como
MODAL

Tabla 10. Actividad Realizar Actualizacin de Datos de Estudiantes

Sprint 2: Debido a que en el Sprint anterior se realizaron las actividades

tal cual se planearon no quedaron actividades pendientes, y por ese
motivo, este sprint se plane con la totalidad de las actividades nuevas
al igual que el anterior. Al transcurrir el tiempo, y debido a la confianza
que gan el equipo por el xito de la ejecucin y planeacin del sprint
anterior, surgieron unos inconvenientes a la hora de ejecutar esta
iteracin, ya que las actividades se planearon un poco mal en lo que al
tiempo de desarrollo por actividad se refiere. Las actividades que ste
sprint contempl, adems de que fueron mal estimadas, presentaron
cambios muy inesperados, ya que por rdenes de los directivos de la
universidad y clientes de los desarrollos que se realizaban en el CEV, se
tuvieron adelantar algunas de las actividades y esto produjo que se
demoraran an ms. Llegado el da final del sprint, el equipo de trabajo
no haba terminado todas las actividades, otras se demoraron ms de lo
planeado, unas quedaron sin resolver; todo esto afect
45
 significativamente el resultado final de la iteracin, arrojando un balance
en cuanto a tiempo decepcionante.

Las actividades y sub-actividades que se tuvieron en cuenta en este

sprint fueron las siguientes:

Solicitar Becas y Descuentos

Sub-Actividades Prioridad Tiempo Comentario
Definicin de Baja 4 Horas Ninguna
Procesos

Tabla 11. Actividad Solicitar Becas y Descuentos

Prcticas Empresariales
Sub-Actividades Prioridad Tiempo Comentario
Crear Solicitud de Medio 2 Horas Posterior a la
Practicas creacin de la
solicitud, se debe
enviar un Mail al
responsable
(Coordinador de
Practicas)
Crear Mdulo de Medio 2 Horas Ninguna
Gestin de
Empresas
Crear Mdulo de Medio 5 Horas Ninguna
Finalizacin de
Practicas
Crear Mdulo de Baja 4 Horas Valoracin de Inicial
Valoracin de y Valoracin Final
Practicante
Crear Mdulo para Media 5 Horas Este es el mdulo
Responder en el que el
Practicante Coordinador decide
en donde se
realizar las
prcticas de
acuerdo con las
solicitudes.
Crear Mdulo para Media 5 Horas Ninguna
Diligenciar Bitcora
por parte del
Practicante

Tabla 12. Actividad Prcticas Empresariales

46
 Persistencia de Acaweb
Sub-Actividades Prioridad Tiempo Comentario
Realizar Active Urgente 11 Horas Ninguna
Record Factory

Realizar Urgente 3 Horas Ninguna

Adecuacin del
Modelo

Tabla 13. Actividad Persistencia de Acaweb

Actualizacin de Datos de Egresados

Sub-Actividades Prioridad Tiempo Comentario
Agregar entidad Media 3 Horas Agregar en API,
Reconocimientos Acaweb y Base de
Datos
Agregar Encuesta Baja 1 Hora Ninguna
a la BD

Realizar UI Urgente 4 Horas Esta vista es muy

Actualizacin de parecida a la de
Datos de Actualizacin de
Egresados Datos de
Estudiantes, pero
con unos datos
adicionales
especficos de los
egresados
Agregar Urgente 6 Horas Hacer que todo
Funcionalidad al funciones
Mdulo perfectamente bien

Tabla 14. Actividad Actualizacin de Datos de Egresados

Imprevistas Sprint 2
Sub-Actividades Prioridad Tiempo Comentario
Cambios en los Urgente 4 Horas Revisar todos los
script en general scripts que utiliza la
pgina y verificar
algunos errores
presentes
Inscripciones en Urgente 8 Horas Realizar un portal
lnea provisional provisional de
Inscripciones en
lnea para los
nuevos estudiantes

47
 Implementar un Urgente 8 Horas Implementar un
sistema de sistema para evitar
validaciones que los usuarios
gramaticales introduzcan letras,
smbolos o nmeros
cuando no son
permitidos.
(Validacin de todos
los campos)
Mejorar problemas Urgente 6 Horas Garantizar un
presentados al funcionamiento
entrar a los adecuado en
portales desde Internet Explorer de
Internet Explorer todos las
aplicaciones y
servicios que se
estn desarrollando

Tabla 15. Actividad Imprevista Sprint 2

Figura 7. Actividades Sin Planeacin

48
 Sprint 3: A razn de que el sprint 2 no tuvo el xito que tuvo el primero,
este dej actividades que debieron haberse resuelto en el mismo; por tal
motivo, dichas actividades pasaron a ser prioritarias para ste sprint,
generando en los participantes del desarrollo muchas ms de cautela y
precaucin a la hora de asignar tiempo a las actividades de la iteracin.
La ejecucin del Sprint se llev a cabo sin muchos altercados,
nuevamente se presentaron actividades y cambios a las actividades
planeadas en tiempo de ejecucin por los directivos de la universidad,
pero por la experticia que ganaron los integrantes del equipo, se
lograron resolver sin que generaran muchos inconvenientes para el
resultado final de la iteracin y como resultado se produjo una buena
ejecucin del sprint.

Las actividades y sub-actividades que se tuvieron en cuenta en este

sprint fueron las siguientes:

Prcticas Empresariales (Actividades sin Resolver)

Sub-Actividades Prioridad Tiempo Comentario
Crear Mdulo de Urgente 2 Horas Ninguna
Gestin de
Empresas
Crear Mdulo de Urgente 5 Horas Ninguna
Finalizacin de
Practicas
Crear Mdulo de Urgente 4 Horas Valoracin de
Valoracin de Inicial y Valoracin
Practicante Final

Tabla 16. Actividad Prcticas Empresariales (Actividades sin Resolver)

Matrcula en lnea
Sub-Actividades Prioridad Tiempo Comentario
Realizar Media 4 Horas Ninguna
Diagrama de
Actividades
Realizar UI de la Media 4 Horas Ninguna
matrcula en lnea

Obtencin de Pre- Urgente 3 Horas Calcular la pre-matrcula

matrcula del estudiante de
acuerdo al semestre, las
materias que ha perdido
y al reglamente
Agregar Auditoria Medio 3 Horas Ninguna

49
Agregar y validar Urgente 8 Horas Ninguna
Cursos

Revisar Urgente 8 horas Ninguna

Seguridad

Obtener Cursos Urgente 6 Horas Ninguna

Habilitados

Guardar Matricula Urgente 7 Horas Ninguna

Tabla 17. Actividad Matrcula en lnea

Portal Docentes
Sub-Actividades Prioridad Tiempo Comentario
Obtener Urgente 3 Horas Ninguna
Calendario de los
cortes (API)
Funcionalidad del Urgente 4 Horas Ninguna
Mdulo

Mis Cursos Medio 3 Horas Visualizar

estudiantes y sus
respectivos
correos
electrnicos por
curso.
Crear UI Urgente 4 Horas Ninguna

Horario Bajo 3 Horas Ninguna

Realizar Medio 4 Horas Es Similar a la de

Actualizacin de estudiantes y
Datos egresados, pero
con datos nicos
para los docentes

Tabla 18. Actividad Portal Docentes

Sprint de Refactory: Al finalizar los tres sprint planeados, se pudo

realizar una revisin general o sprint de refactory, con el fin de evaluar
todas y cada una de las actividades que se ejecutaron en el transcurrir

50
 de las tres iteraciones. Se pudo concluir, que la metodologa tuvo un
xito retundo en cuanto a los tiempos de entrega se refiere, debido a
que estos se cumplieron en un 80% contando el impase que se present
en la segunda iteracin a causas de modificaciones imprevistas.

Las actividades y sub-actividades que se tuvieron en cuenta en este

sprint fueron las siguientes:

Refactor
Sub-Actividades Prioridad Tiempo Comentario
Estandarizacin Medio 5 Horas Pestaas,
de los widgets botones, campos
de texto, entre
otros.
Realizar cambios Urgente 10 Horas Debe funcionar en
necesarios para Internet Explorer
la (7 - ms reciente),
interoperabilidad Firefox (3 ms
entre los reciente) y Google
navegadores web Chrome. Revisar
CSS, JS y
atributos
especiales.
Reestructurar Bajo 3 Horas Implementar
Tamao de los varios tamaos y
campos de texto estandarizarlos.
Redisear las Bajo 3 Horas Ninguna
pestaas

Editar formulario Medio 5 Horas Agregar la

de envi de posibilidad de
correo agregar ms o
eliminar usuarios
mientras se
construye el
correo.

Tabla 19. Actividad de Refactor

Posterior a todas las iteraciones que se presentaron incluyendo el sprint

de refactory y tras concluir que la metodologa fue un xito, surgi la
necesidad de realizar varias actividades fuera de lo planeado, dichas
actividades fueron: Inscripcin en Lnea (Versin Definitiva),
Modificaciones en el portal de egresados y Elecciones estudiantiles.

Sprint Final: Para realizar las actividades que surgieron posteriormente a

las iteraciones planteadas, se plane un sprint con el que se pudo
51
 finalizar las actividades restantes, esta iteracin se llev a cabo sin
mayor imprevisto ya que se tena una experiencia previa con las
anteriores iteraciones. Todo surgi segn lo planeado en la reunin
previa y como resultado surgi el portal de inscripciones en lnea que
actualmente est utilizando la universidad para los posibles estudiantes
nuevos, al igual que el portal de egresados que se usa en la actualidad
por la comunidad de egresados de la Universidad de San Buenaventura;
el portal para las elecciones de representante a concejo acadmico de la
Universidad tambin fue terminado satisfactoriamente, con algunos
detalles que fueron mejorados con su puesta en marcha.

Las actividades y sub-actividades que se tuvieron en cuenta en este

sprint fueron las siguientes:

Inscripciones en lnea (Versin Definitiva)

Sub-Actividades Prioridad Tiempo Comentario
Diseo de la UI Medio 6 Horas Ninguna

Generador de Medio 3 Horas Ninguna

PDF con la cita
de la entrevista
Generador de Medio 3 Horas Solo para los
PDF con la cita estudiantes de
para la prueba Psicologa
Psicotcnica
Agregar Medio 5 Horas 5 Posibilidad
Funcionalidad al de completar
Mdulo parcialmente
el proceso de
inscripcin.
6 Envo de
Correo
electrnico al
terminar la
inscripcin.
Realizar Medio 3 Horas Para garantizar
validaciones an ms la
adicionales funcionalidad en
los distintos
navegadores.

Tabla 20. Actividad Inscripciones en lnea (Versin Definitiva)

Modificaciones Portal Egresados

Sub-Actividades Prioridad Tiempo Comentario

52
 Modificaciones Medio 3 Horas Surgieron unos
en la inconvenientes a la
actualizacin de hora de guardar los
egresados hijos de los
egresados

Tabla 21. Actividad Modificaciones Portal Egresados

Portal de Elecciones Institucionales

Sub-Actividades Prioridad Tiempo Comentario
Diseo de la UI Medio 4 Horas Diseo de Interfaces
de usuario para,
inscripcin de
representantes,
aprobacin de
inscritos y
elecciones.
Agregar Medio 4 Horas Garantizar la
Funcionalidad al funcionalidad en
Mdulo todos los
navegadores,
implementar un
sistema de
auditoras que
almacene la
direccin IP de
donde se realiz el
voto.

Tabla 22. Actividad Portal de Elecciones Institucionales

Scrum permiti a travs de iteraciones, un desarrollo contnuo de varias

aplicaciones o productos, permitiendo trabajar simultneamente en actividades
con fines diferentes; para esto se cont con un equipo de trabajo auto-
gestionado que trabaj en una serie de tareas, desarrolladas en series de
Sprint de 1 a 4 semanas, hasta que se entreg los productos o aplicaciones
completas.

4.4 DISEO Y DESARROLLO DE INTERFACES.

En este punto es preciso mencionar algunas de las herramientas de software

que se usaron especficamente para este aspecto. Entre las herramientas
usadas se encuentran:
Netbeans como editor de cdigo fuente
Navicat como gestor de base de datos
PhotoShop como herramienta para edicin de imgenes
Navegadores web, entre estos se encuentra Google Chrome, Mozilla
Firefox, Safari e Internet Explorer.

53
A continuacin se mostrarn las interfaces resultantes de la implementacin.

Interfaz principal donde podemos apreciar los diferentes mdulos

realizados durante nuestras pasantas, podemos observar Mis datos el
cual es el lugar donde podremos observar y actualizar toda la informacin
correspondiente a los, Mis Cursos es otro modulo donde se encuentra
toda la informacin referente a Horario, Notas y Cursos Matriculados.
Practicas Industriales, modulo relacionado con toda la vida de prcticas
Industriales. Consultas este mdulo nos da la oportunidad de observar la
informacin correspondiente al volante de pago y al Semforo Acadmico.
(Ver la siguiente Figura)

Figura 8. Pgina de Inicio

Actualizacin de Datos Estudiantes: Interfaz donde se puede apreciar

Mis datos en el cual se pueden observar los datos del estudiante y
actualizar toda la informacin correspondiente del mismo; Mis Cursos
es otro mdulo donde se encuentra toda la informacin referente a
Horario, Notas y Cursos Matriculados; Prcticas Industriales, mdulo
relacionado con toda la vida de prcticas Industriales en caso de tener
vigente alguna; Consultas este mdulo da la oportunidad de observar la
informacin correspondiente al volante de pago y a toda el pensum y
notas del estudiante.

La primera seccin de este mdulo es Actualizar Mis Datos y en l se tiene

acceso a diferentes interfaces donde se puede modificar ciertos atributos que
se inmersos en la ficha el estudiante, estos son:

Actualizar Mis Datos Datos Bsicos: Dentro del mdulo de Mis

Datos se puede Actualizar informacin sobre la ficha de estudiante,
teniendo la opcin de variar toda aquella que al transcurrir el tiempo

54
 haya presentado modificaciones como el lugar de residencia,
telfono, correo electrnico y celular. (Ver la siguiente Figura)

Figura 9. Actualizar Mis Datos Datos Bsicos

Actualizar Mis Datos Datos Familiares: En esta Interfaz se tiene

acceso a la informacin que puede variar con el tiempo en referencia
a acudiente o en referencia a datos relacionados con los padres. (Ver
la siguiente Figura)

55
Figura 10. Actualizar Mis Datos Datos Familiares

56
 Actualizar Mis Datos Historial Laboral: Espacio que Posee un
Estudiante para agregar a la ficha estudiantil lo relacionado con la
vida laboral que este ha generado o en su defecto esta generando.
(Ver la siguiente Figura)

Figura 11. Actualizar Mis Datos Historial Laboral

Actualizar Mis Datos Historial Acadmico: Esta interfaz permite

agregar informacin sobre estudios realizados con anterioridad por
el estudiante. (Ver la siguiente Figura)

Figura 12. Actualizar Mis Datos Historial Acadmico

57
 Actualizar Mis Datos Idiomas: En esta pestaa se puede aadir
informacin sobre los idiomas que el estudiante maneje desde un nivel
bajo, pasando por medio, hasta llegar a un nivel alto. (Ver la siguiente
Figura)

Figura 13. Actualizar Mis Datos Idiomas

Actualizar Mis Datos - Finalizar: Interfaz Final donde se muestran los

trminos y condiciones para poder confirmar el cambio de informacin
realizado sobre la ficha correspondiente.

La segunda seccin de ste mdulo es Ver mis Datos y permite a los

estudiantes visualizar la informacin relacionada con su ficha estudiantil; est
compuesta por las siguientes interfaces:

Ver Mis Datos Informacin Personal: En Mis Datos se da la opcin de

observar la informacin presente en la Base de Datos de la universidad.
(Ver la siguiente Figura)

58
 Figura 14. Ver Mis Datos Informacin Personal

Ver Mis Datos Informacin de Contacto: Ficha de Estudiante con datos

exactos y que permiten datos de residencia, telfono, email entre otros.
(Ver la siguiente Figura)

59
 Figura 15. Ver Mis Datos Informacin de Contacto

La tercera seccin de ste mdulo es Mis Cursos en el que el estudiante puede

observar los cursos en los que actualmente se encuentra matriculados,
permitindole ver compaeros de curso, enviarles correos, detallar el horario de
clases, entre otras actividades.

La cuarta seccin de ste mdulo es Prcticas Industriales en el que el

estudiante puede ir aadiendo actividades a su bitcora siempre que lo desee.
Esta seccin estar activada si y slo si el estudiante es asignado a una
empresa que haya expresado su intencin de contar con los servicios de un
practicante. Sus interfaces son:

Prcticas Industriales - Bitacoras: Se da la opcin para que el

estudiante genere actividades con un porcentaje de cumplimiento o
realizacion, aadiendo los objetivos o competencias relacionadascon la
actividad desarrollada. (Ver la siguiente Figura)

60
 Figura 16. Prcticas Industriales- Bitcora

Prcticas Industriales Descargar Certificado: En este espacio el

estudiante tiene la opcin de descargar el certificado que prueba que
este ha cumplido con todos los requisitos presentados durante sus
Prcticas industriales, teniendo presente que este debe ser aprobado y
subido por el director de las mismas. (Ver la siguiente Figura)

Figura 17. Prcticas Industriales Descargar Certificado

61
 Actualizacin de Datos Egresados. Espacio de los Egresados donde
pueden modificar la informacin relacionada con la que fue en algn
momento su ficha estudiantil.

Actualizar Mis Datos Datos Bsicos: El Portal Egresados y El

Portal Estudiantes con respecto a las actualizaciones son muy
similares donde solo algunos tems hacen la diferencia entre ellos
la opcin de poder agregar hijos .(Ver la siguiente Figura)

Figura 18. Actualizar Mis Datos Datos Bsicos

62
 Actualizar Mis Datos Informacin Laboral: En esta interfaz permite
apreciar los campos donde se debe colocar todo lo referente a la
informacin laboral del grupo Egresados as como reconocimientos
dentro de la empresa, entre otros. (Ver la siguiente Figura)

Figura 19. Actualizar Mis Datos Informacin Laboral

Actualizar Mis Datos Informacin Acadmica: La Informacin

acadmica de un egresado se encuentra en esta interfaz, donde podr
aadir nuevos ttulos obtenidos en cualquier entidad educativa (Ver la
siguiente Figura).

63
 Figura 20. Actualizar Mis Datos Informacin Acadmica

Actualizar Mis Datos Idiomas: Los egresados tienen la oportunidad de

poder anexar los lenguajes que manejen, teniendo presente el nivel de
escritura, lectura y fluides. (Ver la siguiente Figura)

Figura 21. Actualizar Mis Datos Idiomas

64
Actualizar Mis Datos Datos Complementarios: En esta ltima interfaz se hace
presente informacin complementaria que es de protocolo para la universidad.
(Ver la siguiente Figura).

Figura 22. Actualizar Mis Datos Datos Complementarios

Interfaces Mdulo de Docentes. Campo relacionado con los docentes

donde podrn visualizar informacin que estos poseen, estas interfaces son:

Mdulo de Docentes Horario: Los Docentes tienen la oportunidad de

poder ver el horario de clases generado segn las asignaturas que
fueron otorgadas para ser dictadas. (Ver la siguiente Figura)

65
 Figura 23. Mdulo Docentes Horario

Mdulo de Docentes - Cursos: En esta ventana aparecern todos los

cursos asignados al docente con informacin detallada sobre el mismo.

Mdulo de Docentes Notas: Es esta interfaz se permite al docente

asignar las notas acadmicas a cada estudiante, as como corregirlas
segn el lmite de tiempo que para ste efecto se le asigne.

Elecciones Estudiantiles. Espacio donde los estudiantes pueden tomar

eleccin de aquellos que se hayan postulado a Consejo Acadmico o
Representante de Facultad, estas interfaces son:

Elecciones Estudiantiles - Formulario de Inscripcin: En el mdulo de

Elecciones, se permite realizar la inscripcin a la candidatura al Consejo
Academico o a Representante de Facultad; en este formulario tambien
se cuenta con la opcion de colocar todo lo referente al plan de campaa
del postulado. (Ver la siguiente Figura)

66
 Figura 24. Elecciones Estudiantiles Formulario de Inscripcin

Elecciones Estudiantiles Admisiones: Esta Interfaz slo se encuentra

disponible para el Jefe de Unidad de Registro Acadmico quien tendr la
opcin de admitir o denegar la inscripcin de los candidatos postulados.
(Ver la siguiente Figura)

67
 Figura 25. Elecciones Estudiantiles Admisin

Elecciones Estudiantiles - Votacion: En esta interfaz se puede apreciar

los diferentes aspirantes al consejo acadmico o representante de
facultad que se encuentren admitidos para su eleccin por el cuerpo
estudiantil; adems, tambin se podr sufragar por el candidato de
eleccin (Ver la siguiente Figura)

Figura 26. Elecciones Estudiantiles Votacin

68
 Mdulo de Prcticas Industriales. El control y seguimieento de las
prcticas se realiza mediante estas interfaces. En esta oportunidad se
tendran presentes varios usuarios como lo son el Coordiandor de
Prcticas y la Empresa. Las vistas correspondientes al estudiante ya han
sido descritas en la seccin correspondiente a l.

Las interfaces de prcticas industriales que puede visualizar el

Coordinador de Prcticas permiten ver las empresas registradas en la
base de datos, peticiones de stas hagan, asignarles practicante, entre
otras funciones. Sus interfaces son:

Prcticas Industriales Subir Certificado: En este espacio el

Coordinador de Prcticas Industriales tiene la opcin de subir el
certificado que avala el cumplimiento total de las horas asignadas al
estudiante. Este certificado se entrega tras la aprobacin de la
empresa donde se realizan las prcticas, la cual certifica que se han
cumplido todas las actividades planeadas. (Ver la siguiente Figura)

Figura 27. Prcticas Industriales Subir Certificado

Prcticas Industriales Solicitudes: Esta interfaz permite apreciar las

solicitudes de practicantes enviadas por las empresas que tengan
convenio con la Universidad De San Buenaventura Cartagena; el
coordinador tiene la oportunidad de revisarlas, aprobar y asignar el
practicante o sencillamente rechazarlas. (Ver la siguiente Figura)

69
 Figura 28. Prcticas Industriales Solicitudes

Prcticas Industriales - Amonestaciones: La empresa tiene la

oportunidad de enviar amonestaciones al Coordinador de prcticas
dndole a conocer a ste el tipo de inconvenientes que se estn
presentando con el practicante asignado. As mismo da la opcin al
Coordinador de responder cada amonestacin. (Ver la siguiente Figura)

70
 Figura 29. Prcticas Industriales listado de Amonestaciones

Prcticas Industriales - Amonestaciones Respondidas: El director de

Prcticas podr ver la informacin enviada como respuesta a las
diferentes amonestaciones que hayan realizado las empresas con
practicantes asignados. (Ver la siguiente Figura)

71
 Figura 30. Prcticas Industriales Amonestaciones Respondidas

Las interfaces de prcticas industriales que puede visualizar una empresa

registrada ante la Universidad le permiten ver su registro, realizar solicitudes de
practicantes, amonestar un practicante, entre otras funciones. Su principal
seccion se centra en la solicitud de practicante, la cual presenta los siguientes
vistas

Solicitud Practicante - Identificacin de la Empresa: Presenta todo lo

correspondiente al registro de la empresa ante la Universidad,
permitindosele cambiar cierta informacin. (Ver la siguiente Figura)

72
 Figura 31. Solicitud Practicante - Identificacin de la Empresa

Solicitud Practicante - Requerimientos: En esta interfaz se describen

los requerimientos que debe tener el practicante solicitado, como rama
profesional, perfil y fechas de inicio y fin de la prctica. (Ver la siguiente
Figura)

73
 Figura 32. Solicitud Practicante - Requerimientos

Solicitud Practicante - Ubicacin Estudiante Solicitado: En esta interfaz

se precisa informacin acerca de ubicacin del estudiante dentro de la
entidad o empresa, el cargo, tutor, entre otros datos. (Ver la siguiente
Figura)

74
 Figura 33. Prcticas Industriales Ubicacin Estudiante

Solicitud Practicante - Ubicacin Empresa: La empresa dar informacin

acerca de ubicacin geogrfica del sitio de prcticas; esto facilita
distinguir establecimientos dentro de empresas multinacionales o con
diferentes sedes dentro del pas. (Ver la siguiente Figura)

Figura 34. Solicitud Practicante - Ubicacin Empresa

75
 Ver Solicitudes: Las Empresas pueden realizar acciones sobre las
solicitudes que se hayan enviado; segn el estado de una solicitud esta
permite verla, enviar amonestacin, finalizarla, entre otras opciones.
(Ver la siguiente Figura)

Figura 35. Prcticas Industriales Ver Solicitudes

Las interfaces del portal de inscripciones en linea las cuales son utilizadas en la
actualidad para efectuar el proceso de insripcion de los estudiantes que van a
ingresar a la universidad, en este portal se pueden observar las siguiente
vistas:

Formulario de inscripcin. (Ver la siguiente Figura)

76
 Figura 36. Formulario de inscripcin

Este mdulo tiene una funcionalidad en particular que consiste en que cuando
se termina de diligenciar el formulario en su totalidad, se enva un correo
electrnico al estudiante y varias personas en la universidad las cuales exigen
que se les notifique cada vez que se inscribe alguien nuevo, adems, el
formulario permite que la persona que lo est diligenciando pueda guardar el
proceso que lleva del mismo, de ese modo puede continuar posteriormente con
el proceso de inscripcin. Cabe resaltar que una vez finalizado el formulario
como tal, no se puede volver a editar, solo permite descargar la citacin a la
entrevista presencial en la universidad.

4.5 EJECUCION DE PRUEBAS

Las pruebas que se desarrollaron durante el desarrollo de los frontend, se

hicieron al finalizar cada uno de los sprints, el procedimiento que se sigui para
la realizacin de la prueba fue repetido en todas las pruebas que se realizaron,
as que a continuacin se describir el proceso que se sigui.

Una vez terminado el sprint, las actividades que se contemplaron en el mismo

eran sometidas a unas pruebas que eran ejecutadas por el Ingeniero Javier
Garca quien ejerca el rol de Scrum Master, bsicamente la prueba consista
en verificar rigurosamente cada detalle que se deba contemplar en la
actividad, por ejemplo, si la actividad era el desarrollo de una interfaz, se
77
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.

Crear Mdulo de Valoracin de Practicante, esta actividad consisti

en examen que debe diligenciar cada practicante al inicio de las
prcticas y al finalizar las mismas. Se verific que el mdulo cumpliera
con las exigencias que se tenan planteadas respecto a las fechas en las
cuales se deban realizar estas valoraciones.

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

78
 elecciones que se realizaran posteriormente. Esta prueba consisti
incluso en invitar a personas ajenas al CEV para que probaran las
interfaces, adems, se solicit a personas expertas en seguridad que
revisaran tediosamente si la aplicacin tena alguna falla que pudiera
ocasionar un fraude en las elecciones. Debido a esta prueba de
seguridad se implement la funcionalidad que capturaba la direccin IP
del equipo que votaba para as controlar que IP intentaban realizar
fraudes, y tener una auditora de las elecciones, cabe aclarar que las
direcciones IP no se relacionaban con los votantes, es decir, la direccin
IP se registraba con la hora y fecha, incluso el navegador que uso pero
solo a manera de informacin, esta no se encontraba ligada a la persona
que realizo el voto.

Otra prueba que fue muy importante, fue la de las inscripciones en lnea
que posteriormente se utiliz por la universidad para los nuevos
estudiantes. Esta prueba consisti en generar muchas inscripciones y en
diferentes navegadores para verificar que efectivamente las
inscripciones se generaban con todos los parmetros, uno de los
aspectos que ms se prob fue el de envo de correo electrnico por
parte del portal al estudiante y a los directivos de la universidad
notificando la inscripcin de nuevos interesados, y el de la generacin de
citas para entrevistas personalmente en la universidad, es decir, que el
portal adems que inscriba, enviaba correo notificando y generaba una
cita para la entrevista entre el programa que selecciono el interesado y
el interesado.

Y de ese modo se evaluaban las actividades, probando aspecto por aspecto.

Una vez aprobada la actividad se daba por terminaba y se prosegua a
desarrollar la siguiente que estuviera pendiente en el sprint.

79
 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.

80
 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, Humans And

Technology. IEEE SOFTWARE July/August 2000. 142p.

RUBIO, D. N. Andriano, A. Ruiz de Mendarozqueta, C. Bart. An integrated

improvement framework for sharing assessment lessons learned. La Rioja:
Proceedings del XIV Congreso Argentino de Ciencias de la Computacin,
2008. 269p.

GUTIERREZ, Jaoquin. Metodologas giles. Universidad Pablo de Olavide.

2007. 192p.

PALACIO, Juan. Flexibilidad con Scrum. Disponible en http://www.lulu.com,

consultado el 23 de marzo de 2012. 145p.

PICHLER, ROMAN. Agile Product Management Whit Scrum. Creating

Products That Customers Love. Roman Pichler. 2010. 132p.

PRIES, KIM H. y Quigley, Jon M. Scrum Project Management. Taylor &

Francis Group. 2011. 163p.

81
POPPENDIECK M., Poppendieck T. Lean Software Development: An Agile
Toolkit for Software Develoment Managers. Addison Wesley. 2003. 98p.

SCHWABER, KEN y Belle, Mike. Agile Software Development with Scrum.

Prentice Hall. 2008. 156p.

SCHWADER, KEN. The Enterprice and Scrum. Prentice Hall. 2007.

SCHUWABER, K. Agile Project Management with Scrum (Microsoft

Professional). Mar 10, 2004. 346p.

TEASLEY, Covi, Krishnan, & Olson (2000). How Does Radical Collocation
Help a Team Succeed? Proceedings of the 2000 ACM Conference on
Computer Supported Cooperative Work (pp. 339 - 346). New York: ACM.
149p

WELLINGTON, A., Briggs, T., y Girard, C.D., Comparison of Student

Experiences with Plan-Driven and Agile Methodologies, Proceedings of the
35th ASEE/IEEE Frontiers in Education Conference, 2005. 163p.

82
 Anexo A. Cronograma de Actividades

2011 2012
AGOSTO SEPTIEMBRE OCTUBRE NOVIEMBRE FEBRERO MARZO ABRIL MAYO
TIEMPO
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
ACTIVIDADES
Capacitacin Inicial de los
Prcticantes
Lineamientos e indicaciones
del software
Distribucin de actividades
Ejecucin de actividades
Revisin
Ejecucin de actividades
Revisin Final de Prcticas
Investigacin de factibilidad y
riesgo para la elaboracin del
libro planteado sobre SCRUM
como metodologa de
desarrollo ideal
Investigacin general de la
temtica a tratar en los
documentos que se
presentarn
Elaboracin de los
documentos
Presentacin previa para
revisin
Correccin
Entrega final y sustentacin

83
Anexo B. Presupuesto

FUENTE
RUBROS DESCRIPCIN CEV Estudiantes
Especie Efectivo
Gastos de 4 Tutores - -
personal 3 Estudiantes - $ 6335.500.oo
iMac 21 $ 2450.000.oo -
Equipos y Mac Pro con Cinema
$ 7132.000.oo -
software Display
Computador HP Quad Core $ 1835.000.oo -
Materiales y Papelera - $ 200.000.oo
suministros Tner de impresora - $ 100.000.oo
Servicios Servicio de Computo 600h
$ 8000.000.oo -
tcnicos 5000h
Otros gastos Imprevistos - $ 1000.000.oo
TOTALES $ 19417.000.oo $ 7635.500.oo

TOTAL DEL PRESUPUESTO $ 27052.500.oo

84