APLICACIÓN DE LA METODOLOGÍA SCRUM PARA LA OPTIMIZACIÓN DE

PROCESOS ACADÉMICOS EN LA UNIVERSIDAD DE SAN

BUENAVENTURA, CARTAGENA

ELKIN JOSÉ TORRES MARTÍNEZ

EDSON CARLO ARZUZA AGUDELO
OSCAR FERNANDO BECERRA URIBE

UNIVERSIDAD DE SAN BUENAVENTURA

PROGRAMA DE INGENIERÍA DE SISTEMAS
FACULTAD DE INGENIERÍA, ARQUITECTURA, ARTE Y DISEÑO
CARTAGENA DE INDIAS D. T. & C.
COLOMBIA
2012
APLICACIÓN DE LA METODOLOGÍA SCRUM PARA LA OPTIMIZACIÓN DE
PROCESOS ACADÉMICOS EN LA UNIVERSIDAD DE SAN
BUENAVENTURA, CARTAGENA

ELKIN JOSÉ TORRES MARTÍNEZ

EDSON CARLO ARZUZA AGUDELO
OSCAR FERNANDO BECERRA URIBE

Proyecto de grado presentado como requisito para optar al título de Ingeniero

de Sistemas

Tutor
ING. DAMIAN BARRIOS CASTILLOS

UNIVERSIDAD DE SAN BUENAVENTURA

PROGRAMA DE INGENIERÍA DE SISTEMAS
FACULTAD DE INGENIERÍA, ARQUITECTURA, ARTE Y DISEÑO
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 específicos 6
2. MARCO DE REFERENCIA 7
2.1 MARCO HISTORICO 7
2.2 INVESTIGACIONES PREVIAS 8
2.3 MARCO TEÓRICO 9
2.3.1 Scrum 9
2.3.2 Sistemas de información 14
2.3.3 Lenguajes de Programación 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 Metodología Tradicional 20
2.4 MARCO CONCEPTUAL 20
3. DISEÑO METODOLOGICO 22
3.1 TIPO DE INVESTIGACION 22
3.2 DISEÑO 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 Programación 26
3.8.2 Herramienta de Desarrollo de Software 27
3.8.3 Herramientas Software 27
3.8.4 Herramientas de Diseño 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 Exposición del Product Backlog 38
4.3.2 Resolución del Sprint Backlog 39
4.3.4 Revisión del Sprint 42
4.4 DISEÑO Y DESARROLLO DE INTERFACES 53
4.5 EJECUCION DE PRUEBAS 77

III
CONCLUSIONES 80
REFERENCIAS 81

IV
 LISTA DE TABLAS

Tabla 1. Operacionalización de Variables 25

Tabla 2. Actividad Realizar Solicitud de Grado 43
Tabla 3. Actividad Realizar Certificados 43
Tabla 4. Actividad Realizar Matricula Académica 43
Tabla 5. Actividad Ver Perfil del Estudiante 43
Tabla 6. Actividad Ver Información del Estudiante 44
Tabla 7. Actividad Mostrar Horario de Clases 44
Tabla 8. Actividad Mostrar Semáforo Académico 44
Tabla 9. Actividad Mostrar Semáforo Académico 44
Tabla 10. Actividad Realizar Actualización de Datos de Estudiantes 45
Tabla 11. Actividad Solicitar Becas y Descuentos 46
Tabla 12. Actividad Prácticas Empresariales 46
Tabla 13. Actividad Persistencia de Acaweb 47
Tabla 14. Actividad Actualización de Datos de Egresados 47
Tabla 15. Actividad Imprevista Sprint 2 48
Tabla 16. Actividad Prácticas Empresariales (Actividades sin Resolver) 49
Tabla 17. Actividad Matrícula en línea 50
Tabla 18. Actividad Portal Docentes 50
Tabla 19. Actividad de Refactor 51
Tabla 20. Actividad Inscripciones en línea (Versión 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 metodología Scrum 13

Figura 2. Interacción en arquitectura de capas 30
Figura 3. Vista de la arquitectura lógica implementada en el sistema de
información 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 Planeación 48
Figura 8. Página de Inicio 54
Figura 9. Actualizar Mis Datos – Datos Básicos 55
Figura 10. Actualizar Mis Datos – Datos Familiares 56
Figura 11. Actualizar Mis Datos – Historial Laboral 57
Figura 12. Actualizar Mis Datos – Historial Académico 57
Figura 13. Actualizar Mis Datos – Idiomas 58
Figura 14. Ver Mis Datos – Información Personal 59
Figura 15. Ver Mis Datos – Información de Contacto 60
Figura 16. Prácticas Industriales- Bitácora 61
Figura 17. Prácticas Industriales – Descargar Certificado 61
Figura 18. Actualizar Mis Datos – Datos Básicos 62
Figura 19. Actualizar Mis Datos – Información Laboral 63
Figura 20. Actualizar Mis Datos – Información Académica 64
Figura 21. Actualizar Mis Datos – Idiomas 64
Figura 22. Actualizar Mis Datos – Datos Complementarios 65
Figura 23. Módulo Docentes – Horario 66
Figura 24. Elecciones Estudiantiles – Formulario de Inscripción 67
Figura 25. Elecciones Estudiantiles – Admisión 68
Figura 26. Elecciones Estudiantiles Votación 68
Figura 27. Prácticas Industriales – Subir Certificado 69
Figura 28. Prácticas Industriales – Solicitudes 70
Figura 29. Prácticas Industriales listado de Amonestaciones 71
Figura 30. Prácticas Industriales Amonestaciones Respondidas 72
Figura 31. Solicitud Practicante - Identificación de la Empresa 73
Figura 32. Solicitud Practicante - Requerimientos 74
Figura 33. Prácticas Industriales –Ubicación Estudiante 75
Figura 34. Solicitud Practicante - Ubicación Empresa 75
Figura 35. Prácticas Industriales – Ver Solicitudes 76
Figura 36. Formulario de inscripción 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 garantía los
conocimientos que manejen el grupo de desarrolladores; ni tampoco la
metodología que se siga en el desarrollo de los mismos. El éxito está sin duda
en la mezcla de estos tres ítems y de su adaptación continua al entorno en el
que esté inmersa la aplicación.

El presente proyecto muestra el desarrollo de aplicaciones, en su parte de

interfaz de usuario, empleando Scrum como metodóloga 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 aplicación.

La proliferación de metodologías á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 rápida, con fácil adaptabilidad y para
grupos pequeños. Scrum se presenta como una metodología que puede ser
utilizada con seguridad de éxito en cuanto genera agrado del grupo de
desarrollo y del cliente, siendo a satisfacción de este último la garantía de éxito
de cualquier aplicación.

Como profesionales en el área de ingeniería se debe, más que encontrar una

solución 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 situación.

VIII
 INTRODUCCION

Con la aparición de la computación digital, inicio el periodo de más desarrollo

tecnológico jamás visto por la humanidad: viajes espaciales,
telecomunicaciones, Internet, entre otros. Un elemento de importancia en este
desarrollo de tecnologías lo ha constituido el software, el cual facilita el manejo
del hardware.

El software, definido como un conjunto de instrucciones que controlan la

realización de tarea de un hardware, puede dividirse en varias categorías
basadas en el tipo de trabajo que realizan. Las dos categorías primarias de
software son, los Sistemas Operativos que controlan los trabajos del
computador como el mantenimiento de los archivos del disco y la
administración de la pantalla, y el software de aplicación que dirige las distintas
tareas para las que se utilizan el computador como edición de textos, gestión
de bases de datos y similares.

Los desarrollos de hardware y software han sido muy dinámicos a la vez que
requieren de procesos cada vez más complejos de producción. Seguir una
metodología 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 tenía el cliente con respecto al producto o
desarrolladores insatisfechos con el mismo. Encontrar y seguir la metodología
adecuada para el tipo de desarrollo, marca el éxito del software.

La utilización de las llamadas metodologías tradicionales en el desarrollo de

software (Cascada, RUP, entre otras), caracterizadas por la implementación
de etapas secuenciales ejecutadas unas después de otras, guiadas por una
planificación rígida, con lo que pretende controlar todo el proceso (planificación,
diseño, implementación, evaluación), son aplicadas cada vez menos en
ambientes de desarrollo de software. En contraposición, las metodologías
agiles han despertado un creciente interés, que las ha llevado a campos
diferentes al de la ingeniería de software.

Dentro de las diferentes propuestas de mejora al desarrollo secuencial se

encuentra Scrum. Éste es una técnica de desarrollo caracterizada por integrar
características de las metodologías ágiles a los que se añaden la
implementación 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 interés del presente proyecto gira entorno a desarrollos logrados siguiendo

metodologías de desarrollo ágil: específicamente Scrum. A lo largo del trabajo
se muestra la implementación y resultados logrados a partir de esta
metodología de trabajo, dentro de la elaboración de “frontend” de las
aplicaciones (desarrollo de controladores e interfaces graficas de usuario) de
procesos académicos en la Universidad de San Buenaventura – Cartagena.

1
 APLICACIÓN DE LA METODOLOGÍA SCRUM PARA LA OPTIMIZACIÓN DE
PROCESOS ACADÉMICOS EN LA UNIVERSIDAD DE SAN
BUENAVENTURA, CARTAGENA

1. PROBLEMA DE INVESTIGACION

1.1 PLANTEAMIENTO DEL PROBLEMA

El software evoluciona a través de una serie de actividades de programación

que siguen una metodología, y que se orientan a generar una nueva versión a
partir de una versión anterior operativa, cubriendo ajustes de funcionalidades
adicionales1. La causa de éste cambio está atada a la necesidad de evolución
del software.

Muchas de las actuales metodologías 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 definición de
roles, actividad que incluyen modelado y documentación detallada. Este tipo de
metodologías han recibido el nombre “Metodologías Tradicionales”, dando
excelentes resultados en proyectos de gran tamaño, pero mostrándose un poco
ineficientes en desarrollos más pequeños y con requerimientos menos estables
que requieren flexibilidad2.

Como alternativa de desarrollo aparecen las metodologías ágiles,

constituyéndose en una alternativa de solución a medida, con una elevada
simplificación en sus procesos que no renuncia a las prácticas esenciales para
asegurar la calidad del producto. Estas han sido pensadas para grupos de
desarrollo pequeños, con plazos reducidos y requisitos flexibles.

Dentro del marco de estas metodologías de desarrollo ágil se encuentra Scrum.

Esta se caracteriza por brindar ventajas en entornos de trabajo con
requerimientos inestables, que requieren rapidez y flexibilidad, adaptándose
continuamente a las circunstancias de evolución del proyecto. Estas
características coinciden en muchos de los proyectos que actualmente se
desarrollan dentro de Centro de Educación Virtual (CEV) de la Universidad de
San Buenaventura Seccional Cartagena.

El Centro de Educación Virtual (CEV) lleva a cabo procesos de creación,

revisión y despliegue de desarrollos de aplicaciones, que hacen parte del
desarrollo del sistema de información que sirve de apoyo al modelo de
enseñanza institucional. Este sistema de información brinda al docente y al
estudiante apoyo a su proceso de formación, a partir del modelo de educación

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. Metodologías Ágiles en el Desarrollo de Software. Editorial Alicante. España, 12 de
Noviembre de 2003. pp. 9-16.
2
Grupo ISSI. Metodologías Ágiles en el Desarrollo de Software. Editorial Alicante. España, 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 permitirán: acceso a la
información personal de docentes y estudiantes, administración de notas
estudiantiles, portal para el manejo de prácticas industriales y portal de
votaciones estudiantiles (inscripción de candidatos y votaciones). Estos
servicios que se encuentran desacoplados requieren un proceso de
optimización que permita el manejo digital de la información a través de una
plataforma acoplada accesible desde Internet.

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

deficiencias en su prestación, tales como: la falta de una plataforma amena,
intuitiva y práctica que permita presentar y recibir información de los usuarios;
desarrollos que brindan servicios a partir de la información guardada en las
bases de datos de la Universidad que son redundante e insuficientes; la lógica
de negocio aún se encuentra en etapa de diseño y se ajusta a las políticas
cambiantes y poco definidas que establece la Institución para tal fin. La poca
sinergia que se presenta entre los servicios prestados por las aplicaciones
existentes en la Institución, conlleva a que no se logre una integración 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
administración de prácticas industriales, la gestión de notas, la conducción de
las elecciones estudiantiles; implementación que no se ha podido lograr debido
al uso de metodologías de desarrollo tradicionales que han causado retrasos
en los tiempos de entrega de módulos que dan soporte al funcionamiento del
mismo.

El seguimiento de metodologías de desarrollo de software poco adaptadas a la

realidad que vive el CEV crea inconveniente como es la de priorizar las
actividades según el grado de importancia que tienen para el buen
funcionamiento del sistema. A su vez se requiere responder a los cambios en
el diseño 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 académicas de apoyo requeridas por el CEV, a través de la
metodología Scrum, desarrollando software rápidamente y respondiendo a los
diferentes requerimientos en la implementación de los mismos (en los
requisitos, en la tecnología).

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

dividido en dos fases: Fase uno, elaboración de una “API” (Interfaz de
programación de aplicaciones – Application Programming Interface por sus
siglas en ingles) que integra los servicios utilizados para la obtención de datos
que la Institución posee de los estudiantes y docentes, simplificando la manera
para consumir dichos servicios, también se creó un “framework” de desarrollo
(Underscore), que fuese capaz de integrarse con el gestor de contenidos
“Joomla!” y brindara un sencillo método para realizar aplicaciones para el
mismo. Esta fase está a cargo en su totalidad por el equipo de trabajo del CEV.

3
Fase dos, elaboración 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 utilización de la aplicación.
Esta fase se desarrolló durante el periodo de prácticas industriales y pasantías
de investigación profesionales de los integrantes del presente proyecto,
comprendido entre Agosto de 2011 y Abril de 2012.

1.2 FORMULACION DEL PROBLEMA

¿Cómo implementar la metodología Scrum para la Optimización de Procesos

Académicos: inscripción y actualización de información de estudiantes,
administración de prácticas industriales, gestión 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 metodología que se usa en el desarrollo de software integra métodos,

herramientas y procedimientos específicos que pueden convertirse en una
pieza importante de éxito para el equipo de trabajo que la utiliza haciendo
eficaz la producción de aplicaciones. Encontrar, seguir y experimentar con
formas alternativas de trabajo, diferentes a los procesos de desarrollo de
software tradicionales, caracterizados por ser rígidos y dirigidos por la
documentación generada en cada una de las actividades realizadas3, es una
de las principales motivaciones para la selección del tema.

Con este proyecto se busca hacer praxis una metodología que sea alternativa
a los procesos de desarrollo de software tradicionales como RUP (Rational
Unified Process), logrando desarrollos rápidos y que respondan a los cambios
que puedan surgir en el mismo. La metodología 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 rápida
respuesta a los cambios que pueda sugerir el cliente con respecto al diseño,
contenido o funcionalidad del sistema; la producción de una aplicación no sigue
estrictamente una planificación inicial, siendo flexible y abierta, con reglas de
trabajo impuestas por el equipo de trabajo.

Teniendo en cuenta la cantidad de metodologías 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 implementación. Esto permitirá que otros
desarrolladores sigan esta metodología que se muestra como exitosa.

3
Canos, J., Letelier, P. y Penadés, M. Metodologías Agiles en el desarrollo de Software. Universidad
Politecnica de Valencia, Valenc
ia, 2003.

4
La elaboración de un manual de implementación reflejará en detalle el
desarrollo de aplicaciones utilizando la metodología “SCRUM” a partir de los
casos de éxito vividos por el equipo dentro del CEV. Esto permitirá a futuros
desarrolladores inexpertos seleccionar metodologías que garanticen la
satisfacción del cliente pero también la de ellos mismos, marcando el éxito en
el desarrollo del software, y evitando dudar al escoger la metodología
adecuada, o algo todavía peor, se prescindirá de estar ensayando con
metodologías adaptadas a circunstancias particulares, que pudiesen malograr
el objetivo final.

Se busca demostrar que el uso de la metodología “Scrum”, proporcionará un

desarrollo rápido de aplicaciones requeridas por el sistema de información del
CEV de la Universidad de San Buenaventura, aportando herramientas de
apoyo de importancia para el desempeño académico. Las ventajas que se
podrán comparar con otras metodologías son la satisfacción del cliente por
continuas y tempranas entregas de producto, la facilidad de responder a los
cambios en diseño, contenido o funcionalidad del sistema, la interacción
continua con el cliente que facilita la captura de nuevos requerimientos y la
autorregulación que surge del mismo grupo de desarrolladores.

Las herramientas académicas de apoyo desarrolladas a partir de la

metodología “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 través de la interfaces a los servicios proporcionados por la
Universidad de San Buenaventura, a través del desarrollo de los “frontend” de
las aplicaciones obtenidos en esta fase como lo son: inscripción y actualización
de información de estudiantes, administración de prácticas industriales, gestión
de notas, portal de egresados y portal para el manejo de las elecciones
estudiantiles

La viabilidad técnica del proyecto se da porque se cuenta con el capital

humano capacitado en temas de ingeniería de software y con conocimientos
avanzados en Bases de Datos, Lenguaje de programación y metodología del
estudio; los recursos económicos que serán 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 investigación como herramienta para el desarrollo de las
ciencias y la tecnología informática. Se fomenta el desarrollo de la misma a
través actividades de formación y de procesos que involucren cultivar aptitudes

5
y capacidades intelectuales que permitan inferir, deducir y elaborar conceptos
de carácter investigativo4.

1.4 OBJETIVOS

1.4.1 Objetivo general. Implementar la Metodología Scrum para la

Optimización de Procesos Académicos en la Universidad de San
Buenaventura, Cartagena.

1.4.2 Objetivos específicos. Identificar los servicios que ofrece la API diseñada
por el CEV, buscando a partir de esto, tener una mayor apropiación de los
recursos que ésta provee.

Identificar los requerimientos que delimitan las funcionalidades de la segunda

fase.

Describir el proceso guía que lleva la metodología Scrum en el desarrollo de los

productos de la fase dos.

Diseñar y desarrollar las interfaces de usuario que siguiendo la metodología

Scrum, respondan a los diferentes requerimientos surgidos en los procesos
propios de la fase dos, logrando que sean amenas, intuitivas y prácticas

Diseñar y ejecutar pruebas que permiten evaluar los prototipos funcionales

desarrollados, detectando puntos de falla que éstos puedan tener.

Elaborar un manual de implementación que refleje en detalle el desarrollo de

aplicaciones utilizando la metodología “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
práctica de producción alcanzado por empresas de desarrollo tecnológico como
Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard, y que
fue estudiada por Hirotaka Takeuchi e Ikujijo Nonaka. Con el artículo titulado
“The New Product Development Game”, Ikujiro & Takeuchi dieron continuación
a otro artículo escrito con Kenichi Imai, llamado “Managing the New Product
Development Process: How Japanese Companies Learn and Unlearn”. En
estos expusieron una nueva práctica en el desarrollo de productos tecnológicos
desplegada en Japón, resaltando el solapamiento de las fases de desarrollo
como su principal característica, en contraste con los métodos clásicos, los
cuales emplean desarrollos “secuenciales”, pero que en la práctica son en
realidad “secuenciales con solapamiento”.

En 1991 Peter DeGrace y Leslie Stahl hacen referencia al proceso mencionado

por Takeuchi y Nonaka con el término “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 había sido utilizado por
estos últimos.

A partir del trabajo realizado por Hirotaka Takeuchi e Ikujijo Nonaka, Jeff
Sutherland aplicaría 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 prácticas que empleaba como válidas para
gestionar el desarrollo de software OOPSLA 96 (Schwaber & Sutherland,
1996).

Paralelo a este proceso, a mediados de los 90’, se dio la definición de

desarrollo ágil de software como una forma de contravenir hasta ese momento
las metodologías clásicas, las cuales se consideraban excesivamente pesadas
y rígidas por su carácter 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 metodologías de desarrollo, de
los cuales hacían parte Schwaber y Sutherland, bautizaron la nueva corriente
de metodologías de desarrollo como “Metodologías Agiles”.

En el mismo año 2001 fue constituida la “Alianza agil”, una organización 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 investigación servirá como referencia a nuevos proyectos

de grados e investigaciones que sugieran o se encaminen en el manejo de la
metodología SCRUM. Así como las investigaciones y tesis colocadas como
referencias en este documento sirvieron de apoyo para lograr entender cómo
ha evolucionado esta metodología en países como España, Colombia, entre
otros países latinoamericanos. A continuación se presenta una breve
descripción de los proyectos similares a la investigación.

Sergio Adrian Yazyi, Salamanca – España en el año de 2011, presento en la

Universidad De Salamanca, una investigación que lleva como título “Una
experiencia práctica de Scrum a través del aprendizaje basado en proyectos
mediado por TIC en un equipo distribuido”, el cual plantea dentro de su
documentación: “Scrum es un marco de trabajo para la gestión ágil de
proyectos de creciente interés en distintos campos de aplicación. Para asimilar
sus principios y prácticas no basta una formación conceptual sino que es
necesario utilizar un enfoque práctico que permita ejercitarlo a través del
aprender haciendo”. Este estudio se convierte en punto de apoyo ya que se
estudia la implementación de Scrum en contextos distinto al del desarrollo del
software, exponiéndose los logros alcanzados durante la aplicación de esta
metodología, corroborando la información 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 implementación de Scrum llamado
“Flexibilidad con Scrum – Principios de diseño e implantación de campos de
Scrum –Adaptando los procesos a la empresa” en el cual se hace mención de
“empresas observadas por Nonaka y Takeuchi, mostrando en éstas las
características que luego pasarían a formar parte de lo hoy se conoce como
Scrum. Estas características son tratadas al detalle, terminando con consejos
prácticos que permiten llevar estas mismas cualidades a campos como el
marketing, proyectos empresariales y procesos de producción.

De igual Juan Garbajosa Sopeña y Pilar Rodríguez González en España -

Madrid, Septiembre de 2008, presentaron Tesis de Master sobre tecnologías
de la Información íntimamente relacionada con Scrum llamada “Estudio de la
Aplicación de Metodologías Agiles para la Evolución de Productos Software”; la
tesis presentada hace referencia a Scrum como núcleo 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
podría entender Scrum como un tipo de ingeniería social que pretende
conseguir la satisfacción de todos los que participan en el desarrollo,
fomentando la cooperación a través de la auto-organización. De esta forma, se
favorece la franqueza entre el equipo y la visibilidad del producto. Pretende
que no haya problemas ocultos, asuntos u obstáculos que puedan poner en
peligro el proyecto. Los equipos se guían por su conocimiento y experiencia
más que por planes de proyecto formalmente definidos. La planificación
detallada se realiza sobre cortos espacios de tiempo lo que permite una

8
constante retroalimentación que proporciona inspecciones simples y un ciclo
de vida adaptable. Así, el desarrollo de productos se produce de forma
incremental y con un control empírico del proceso que permite la mejora
continua”; esto conlleva a reafirmar la utilización de Scrum como metodología
de desarrollo con la consiguiente obtención de resultados optimizados.

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

tomando un prólogo de Mary Poppendieck y David Anderson, en un
documento llamado “ Kamban y Scrum obteniendo lo mejor de ambos” ofrece
información positiva de Scrum mostrando como ésta “divide la organización en
equipos pequeños, interdisciplinarios y auto-organizados, divide el trabajo en
una lista de entregables pequeños 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 código
potencialmente entregable y demostrado, después de cada iteración; optimiza
el plan de entregas y actualiza las prioridades en colaboración con el cliente,
basada en los conocimientos adquiridos mediante la inspección del entregable
después de cada iteración; optimiza el proceso teniendo una retrospectiva
después de cada iteración. Así en lugar de un grupo numeroso pasando
mucho tiempo construyendo algo grande, se tiene un equipo menor pasando
un tiempo más corto construyendo algo menor. Pero integrando con
regularidad para ver el conjunto completo.”

2.3 MARCO TEÓRICO

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 investigación
científica o tareas que requieran habilidades, conocimientos o cuidados
específicos.

Alternativamente puede definirse que una metodología es el estudio o elección

de un procedimiento pertinente para alcanzar un determinado objetivo. Algunas
de estas metodologías han venido siendo iguales o han tenido sus cambios
respectivos según la situación lo amerite, ya que se hacen presentes diferentes
factores como el tiempo, eficacia, dinero, requerimientos, entre otros.

Existen metodologías que han venido acompañando el avance tecnológico

desde sus inicios y más en el desarrollo de software. Tanto así que han
proporcionado la manera de solucionar situaciones de forma práctica
obteniendo así los resultados esperados en menos tiempo. Este ha sido uno
de los objetivos principales de los programadores, para hacer que la
información sea utilizada en cualquier hora y lugar.

Las metodologías han sido utilizadas para la realización de proyectos

tecnológicos y científicos desde su invención, consideradas como un proceso
de planificación, la cual consiste en un conjunto de actividades que se
encuentran interrelacionadas y coordinadas. La razón de un proyecto es

9
alcanzar objetivos específicos dentro de los límites que imponen un
presupuesto, calidades establecidas previamente y un lapso de tiempo
previamente definido. La gestión de proyectos es la aplicación de
conocimientos, habilidades, herramientas y técnicas a las actividades de un
proyecto para satisfacer los requisitos del proyecto5.

Existen metodologías orientadas a la interacción 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 según se va desarrollando. Estas son llamadas
Metodologías 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 más 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 automáticamente. Es mejor crear el equipo y que éste
configure su propio entorno de desarrollo en base a sus necesidades. Antes y
Durante la elaboración del proyecto hay que acatar puntos clave para la
satisfacción máxima desde el punto de vista del cliente y el desarrollador7.

Desarrollar software que funciona más que conseguir una buena

documentación. La regla a seguir es “no producir documentos a menos que
sean necesarios de forma inmediata para tomar una decisión importante. Estos
documentos deben ser cortos y centrarse en lo fundamental. La colaboración
con el cliente más que la negociación de un contrato. Se propone que exista
una interacción constante entre el cliente y el equipo de desarrollo. Esta
colaboración entre ambos será la que marque la marcha del proyecto y
asegure su éxito.

Responder a los cambios más 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 tecnología, en el equipo, etc.)
determina también el éxito o fracaso del mismo. Por lo tanto, la planificación no
debe ser estricta sino flexible y abierta.

Dentro de las metodologías existentes para la realización de proyectos a nivel

de programación de software, se encuentre la Metodología Scrum, la cual se
utilizó en la generación de productos de software durante el desarrollo de la
pasantía de investigación y la cual será descrita a lo largo de este documento.

Scrum es un método iterativo e incremental que enfatiza prácticas y valores de

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

5
Amaro C., Sarah y Jorge C. Valverde; Metodologías 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
Ibíd., pp. 18.

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

Esta es una herramienta que permite la comunicación entre desarrolladores en

relación uno-a-uno, que podrá servir tanto para darse soporte en el proceso,
como para clarificar y valorar su contribución individual en trabajo grupal.
También permite la comunicación el ScrumMaster (Líder del grupo) en relación
con todos los miembros del mismo, de particular importancia para el
seguimiento del proceso de elaboración del proyecto y culminación del mismo9.

Esta Facilita la evaluación formativa a través del seguimiento de la evolución 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 metodología ágil de desarrollo de proyectos
de software que ha venido surgiendo en los últimos años. Esta toma nombre y
principios de observaciones sobre nuevas prácticas de producción realizada
por Hirotaka y Takeuchi en los años 80´10. En muchas ocasiones, los modelos
de gestión tradicionales no cumplen con los requisitos para afrontar un reto
que hoy en día 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 iteración. Esta
metodología de trabajo promueve la innovación, motivación y compromiso del
equipo que forma parte del proyecto, por lo que los profesionales encuentran
un ámbito propicio para desarrollar sus capacidades11.

Actualmente uno de los métodos ágiles más difundidos es Scrum, basado en

ciclos cortos de trabajo, desarrollo iterativo y adaptativo, permeabilidad a los
cambios en los requisitos, auto-organización del equipo de trabajo, poco en la
producción de valor, mejora continua del proceso y orientación 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 metodologías tradicionales se dedica en

conseguir especificaciones y documentación exhaustivamente.

8
Amaro C., Sarah y Jorge C. Valverde; Metodologías Agiles. Universidad Nacional de Trujillo. Trujillo,
Perú, 2007.
9
Ibíd., 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
Ibíd.

11
  Se hace equipo de comunicación 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 metodologías de

desarrollo

“Esta forma de concebir la gestión de proyectos es radicalmente diferente al

modo secuencial en que se afrontan tradicionalmente los mismos, dividiéndolos
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 versión completa del
producto, centrada en el valor para el cliente o destinatario.”12

Scrum es un modelo de referencia que define un conjunto de prácticas y roles,

y que puede tomarse como punto de partida para definir el proceso de
desarrollo que se ejecutará durante un proyecto. Los roles principales en
Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma
similar al director de proyecto, el ProductOwner, que representa a
los stakeholders (interesados externos o internos), y el equipo que incluye a los
desarrolladores.

Durante cada Sprint (un período 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 características
que forma parte de cada Sprint viene del Product Backlog, que es un conjunto
de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los
elementos del Product Backlog que forman parte del Sprint se determinan
durante la reunión de planeación.

De forma iterativa, todos los días que dure el Sprint, se realiza una reunión
operativa, informal y ágil con el equipo de desarrollo, de un máximo de quince
minutos, en la que a cada integrante del equipo se le hacen tres preguntas:

 ¿Qué tareas ha hecho desde la última reunión? Es decir, tareas

realizadas en un día.

 ¿Qué tareas realizaras el día de hoy?

12
YAZY ,Sergio Adrián . Una experiencia práctica de Scrum a través 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,
identificación de obstáculos o riesgos que impiden o pueden impedir el
normal avance.13

Durante esta reunión, 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 están
congelados durante el Sprint14.

Figura 1. Modelo general de la metodología Scrum

“La efectividad de la metodología para la gestión 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 prácticas: compromiso,
esmero, franqueza, respeto y valor15.”

“Scrum comparte los principios estructurales del desarrollo ágil: a partir del
concepto o visión de la necesidad del cliente, construye el producto de forma
incremental a través de iteraciones breves que comprenden fases de
especulación – exploración y revisión. Estas iteraciones (en Scrum llamadas
Sprint) se repiten de forma continua hasta que el cliente da por cerrado el
producto”16.

La conformación de equipos pequeños de trabajo, es una de las características

principales de esta metodología, formado por miembros de diferentes

13
Rodriguez Gonzalez, Pilar. Estudio De La Aplicación De Metodologías Agiles Para La Evolución De
Productos Software. Universidad Politecnica de Madrid. Madrid. 2008.
14
YAZY ,Sergio Adrián . Una experiencia práctica de Scrum a través 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 Aplicación De Metodologías Agiles Para La Evolución 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 comunicación e intercambio de información
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 información17. Un sistema de información es un conjunto

formal de procesos que, operando sobre una colección de datos estructurada
según las necesidades de la empresa, recopilan, elaboran y distribuyen la
información (o parte de ella) necesaria para las operaciones de dicha empresa
y para las actividades de dirección y control correspondientes (decisiones) para
desempeñar su actividad de acuerdo a su estrategia de negocio.

Un sistema de información realiza cuatro actividades básicas: entrada de datos,

almacenamiento, procesamiento y salida de información.

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

Información toma los datos que requiere para procesar la información.
Las entradas pueden ser manuales o automáticas. Las manuales son
aquellas que se proporcionan en forma directa por el usuario, mientras
que las automáticas son datos o información que provienen o son
tomados de otros sistemas o módulos. Esto último se denomina
interfaces automáticas. Las unidades típicas de entrada de datos a las
computadoras son las terminales, las cintas magnéticas, las unidades de
diskette, los códigos de barras, los escáner, la voz, los monitores
sensibles al tacto, el teclado y el mouse, entre otras.

 Almacenamiento: El almacenamiento es una de las actividades o

capacidades más importantes que tiene una computadora, ya que a
través de esta propiedad el sistema puede recordar la información
guardada en la sección o proceso anterior. Esta información suele ser
almacenada en estructuras de información denominadas archivos.

 Procesamiento: Es la capacidad del Sistema de Información para

efectuar cálculos de acuerdo con una secuencia de operaciones
prestablecida. Estos cálculos pueden efectuarse con datos introducidos
recientemente en el sistema o bien con datos que están almacenados.
Esta característica de los sistemas permite la transformación de datos
fuente en información que puede ser utilizada para la toma de
decisiones, lo que hace posible, entre otras cosas, que un tomador de
decisiones genere una proyección financiera a partir de los datos que
contiene un estado de resultados o un balance general de un año base.

 Salida de Información: La salida es la capacidad de un Sistema de

Información para sacar la información procesada o bien datos de

17
STAIR, Ralph y George W. Reynolds. Principios de Sistemas de Información. México, 2000, Editorial
Thomson, p 4 - 5.

14
 entrada al exterior. Las unidades típicas de salida son las impresoras,
terminales, diskettes, cintas magnéticas, la voz, los graficadores y los
plotters, entre otros. Es importante aclarar que la salida de un Sistema
de Información puede constituir la entrada a otro Sistema de Información
o módulo. En este caso, también existe una interface automática de
salida. Por ejemplo, el Sistema de Control de Clientes tiene una interface
automática de salida con el Sistema de Contabilidad, ya que genera las
pólizas contables de los movimientos procesales de los clientes.

2.3.3 Lenguajes de Programación 18 . Conocidos como el soporte lógico o

software de una computadora, de forma específica es el conjunto de códigos
organizados que de manera lógica da como resultado un software o programa
con una o muchas funcionalidades inmersas en él. Los lenguajes de
programación 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 informática, la programación de

computadores se ha convertido en una disciplina por derecho propio. Los
primeros sistemas de programación, que utilizaban conexiones eléctricas
realizadas con cables sobre tableros móviles, fueron rápidamente sustituidos
por otros que se apoyaban en métodos cada vez más sencillos y que, en
consecuencia permitieron alcanzar niveles más altos de complejidad. Esta
evolución afectó simultáneamente a los medios de introducción de programas
en los computadores (cinta de papel, tarjetas perforadas, teletipo, máquina de
escribir, terminal provisto de pantalla, etc.) y a la forma de programar (lenguaje
máquina, lenguaje simbólico, lenguajes de alto nivel, sistemas de desarrollo de
aplicaciones, entornos de generación 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 actúan
estas instrucciones. Según la forma en que se organicen los datos y
programas, se distinguen las formas de programar: programación lógica,
programación orientada a objetos o programación 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 propósito general y lenguajes de propósito especial. Los lenguajes de
propósito general se emplean igualmente en negocios, que aplicaciones
científicas o en resolución de problemas de ingeniería, como en tareas de
desarrollo de software de sistemas. Entre los lenguajes de propósito general
cabe citar al PASCAL, C y ADA.

18
Anónimo. Lenguajes de Programación 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 categorías más comunes de lenguajes de propósito especial son los
lenguajes comerciales, científicos y educativos. En el campo comercial se
puede citar COBOL, en el campo científico, 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, dividiéndola en áreas de procedimiento (procedures en inglés)
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 explícita
en el programa. Este proceso se determina por el sistema de traducción
del lenguaje. Prolog es un ejemplo de lenguaje de programación
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 páginas web. Las páginas web pueden ser
vistas por el usuario mediante un tipo de aplicación llamada navegador. Se
puede decir por lo tanto que el HTML es el lenguaje usado por los navegadores
para mostrar las páginas webs al usuario, siendo hoy en día la interface más
extendida en la red.

Este lenguaje permite adjuntar textos, sonidos e imágenes y combinarlos al

gusto del programador. Además, y es aquí donde reside su ventaja con
respecto a libros o revistas, el HTML permite la introducción de referencias a
otras páginas 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 carácter 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 utilizarían en un futuro. Sin embargo,
pese a esta deficiente planificación, sí que se han ido incorporando
modificaciones con el tiempo, estos son los estándares del HTML. Numerosos
estándares se han presentado ya.

Esta evolución tan anárquica del HTML ha supuesto toda una seria de
inconvenientes y deficiencias que han debido ser superados con la introducción
de otras tecnologías accesorias capaces de organizar, optimizar y automatizar
el funcionamiento de las webs. Ejemplos son las CSS, JavaScript entre otros.

19
Anónimo, 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 acompañado al HTML es la diversidad de
navegadores presentes en el mercado los cuales no son capaces de interpretar
un mismo código de una manera unificada. Esto obliga al Webmaster a, una
vez creada su página, comprobar que esta puede ser leída satisfactoriamente
por todos los navegadores, o al menos, los más utilizados.

Además del navegador necesario para ver los resultados de nuestro trabajo, se
necesita evidentemente otra herramienta capaz de crear la página en sí. Un
archivo HTML (una página) no es más 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 más complejos
como WORDPAD o Microsoft Word, pues colocan su propio código especial al
guardar las páginas y HTML es únicamente texto plano, con lo que no se
tendrá problemas.

Existen otro tipo de editores específicos para la creación de páginas web los
cuales ofrecen muchas facilidades que permiten aumentar la productividad. No
obstante, es aconsejable en un principio utilizar una herramienta lo más sencilla
posible para poder prestar la máxima atención a nuestro código y familiarizarse
lo antes posible con él. Siempre se tendrá tiempo más delante de pasarse a
editores más versátiles 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 programación pensado en el web, el ideal
para la creación de páginas dinámicas. E la versión 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 páginas.

Gracias a esto el diseñador gráfico 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 código abierto (open

source) muy versátil utilizado frecuentemente en forma conjunta con el servidor
de aplicaciones Apache y el sistema operativo Linux, PHP está entre las
tecnologías de código abierto más desarrolladas y usadas, permite la conexión
e interacción a numerosas bases de datos de forma nativa como MySQL,
Postgres, Oracle, ODBC, IBM DB2, Microsoft SQL Server y SQLite, lo cual
permite la creación de aplicaciones robustas y altamente confiables.

Tiene la capacidad de ser ejecutado en la mayoría de los sistemas operativos

como UNIX, Linux, Windows y Mac OS X, e interactúa con los servidores más

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

17
populares del mercado. La interpretación y ejecución del código de la
aplicación se da en el servidor donde se encuentra almacenada la información,
el usuario solo recibe el resultado de la ejecución que puede ser desde una
imagen hasta una aplicación completa.

PHP ha sobrepasado a Microsoft ASP, convirtiéndose en el lenguaje de

desarrollo web más popular, siendo utilizado en más de 19 millones de sitios.

Fuente: NetCraft PHP es fácil de integrar con ambientes y sistemas

heterogéneos 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 misión crítica de los negocios que requieren estar constantemente
disponibles y muy seguras. Adicionalmente PHP ofrece las siguientes ventajas:

 Plataforma robusta, estable y segura

 Alto desempeño
 Interfaces con distintos sistemas de bases de datos
 Diseñado para trabajar con librerías que permiten la interacción con
distintas aplicaciones web o en su defecto otros lenguajes
 Facilidad de uso y aprendizaje del mismo
 Facilidad de migración
 Bajo costo
 Disponibilidad del código fuente PHP está diseñado para soportar
aplicaciones web que son escalables a un gran número 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 diseñaban para la aplicación 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. Además, cada aplicación utiliza ficheros que pueden ser comunes
a otras de la misma organización, por lo que se produce una REDUNDANCIA
de la información, que provoca mayor ocupación de memoria, laboriosos
programas de actualización (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
información. El sistema gestor de bases de datos recibe la petición por parte

21
Anónimo. Teoría 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
información de la base de datos y devolvérsela al programa que la solicitó.
Cada programa requerirá de una cierta información de la base de datos, y
podrá haber otros que utilicen los mismos datos, pero realmente residirán en el
mismo espacio de almacenamiento y los programas no duplicarán esos datos,
si no que trabajarán directamente sobre ellos concurrentemente. Aunque la
estructura de la base de datos cambiara, si los datos modificados no afectan a
un programa específico, éste no tendrá por qué ser alterado. Mediante estas
técnicas de base de datos se pretende conseguir a través 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 validación) 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 modelización del
mundo real) de datos estructurados, fiables y homogéneos, organizados
independientemente de su utilización y de su implementación en máquina,
accesibles en tiempo real, compartibles por usuarios concurrentes que tienen
necesidades de información diferentes y no predecibles en el tiempo. Esa
información está bajo el control de un conjunto de programas que constituyen
el Manejador del Sistema de Base de Datos (DBMS por sus siglas en inglés) el
cual gestiona el manejo del conjunto de archivos que dan soporte físico a la
información.

2.3.7 JavaScript22. JavaScript es un lenguaje de programación que se utiliza

principalmente para crear páginas web dinámicas.

Una página web dinámica 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.

Técnicamente, JavaScript es un lenguaje de programación 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 relación directa con el

lenguaje de programación Java. Legalmente, JavaScript es una marca

22
EGUÍLUZ PÉREZ, Javier. Introducción 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 estándares relacionados

con ECMAScript. En Junio de 1997 se publicó la primera edición del estándar
ECMA-262. Un año después, en Junio de 1998 se realizaron pequeñas
modificaciones para adaptarlo al estandar ISO/IEC-16262 y se creó la segunda
edición.

Actualmente se encuentra en desarrollo la cuarta versión de ECMA-262, que

podría incluir novedades como paquetes, namespaces, definición explícita de
clases, etc.

2.3.8 Metodología Tradicional. Aquellas metodologías de desarrollo con mayor

énfasis en la planificación y control del proyecto, en especificación precisa de
requisitos y modelado. Para ello, se hace énfasis en la planificación 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 definición de roles, actividades, artefactos,
herramientas y notaciones para el modelado y documentación detallada.
Además, las metodologías tradicionales no se adaptan adecuadamente a los
cambios, por lo que no son métodos 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 estarán
especificados de acuerdo a las convenciones de la organización ya sea
mediante: features (características), 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 comparación y afirmación 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 definirán las iteraciones, conocidas

como Sprint en la juerga de Scrum, en las que se irá evolucionando la
aplicación 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 duración 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 planificación de actividades a realizar o

concluir durante el Sprint.

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

eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint.
El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino
que actúa como una protección entre el equipo y cualquier influencia que le
distraiga. Es quien hace que las reglas se cumplan.

TEAM: conocido también como Equipo, tiene la responsabilidad de entregar el

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

ITERACION: es la repetición de una serie de instrucciones en un programa de

computador. Puede usarse tanto como un término genérico (como sinónimo de
repetición) así como para describir una forma específica de repetición con un
estado mutable

APLICACION SOFTWARE: es un programa diseñado para automatizar una

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

21
 3. DISEÑO METODOLOGICO

3.1 TIPO DE INVESTIGACION.

El tipo de investigación se enmarca dentro de los estudios descriptivos, definida

por Roberto Hernández Sampieri y otros autores en su libro Metodología De La
Investigación como aquella que describe situaciones y eventos, es decir, cómo
es y se manifiesta determinado fenómeno. En el presente estudio se describirá
la implementación de la metodología Scrum buscando aumentar el grado de
familiaridad con este nuevo integrante de las nuevas alternativas de desarrollo
ágil. El propósito de la investigación será el de mostrar cómo es y se aplica la
metodología Scrum en un contexto particular: el Centro de Educación Virtual
(CEV) de la Universidad San Buenaventura, Cartagena.

3.2 DISEÑO ADOPTADO.

El diseño adoptado para este estudio es el no experimental porque se indagará

la ocurrencia en que se manifiesta varias variables, proporcionando su
descripción y estableciendo hipótesis descriptivas. Los diseños no
experimentales son definido por Roberto Hernández Sampieri y otros autores
en su libro Metodología De La Investigación como aquella que se realiza sin
manipular deliberadamente variable, siendo su grado de control mínimo23. Su
estudio de caso se realizará con una sola medición y consistirá en administrar
la metodología Scrum a casos particulares de desarrollo dentro del CEV y
después aplicar mediciones a una serie de variables (tiempo, productividad,
rendimiento) para observar cuál es el comportamiento de las variables en este
escenario particular24.

Los diseños no experimentales no son adecuados para el establecimiento de

relaciones entre la variable independiente y la variable dependiente, siendo
útiles como pruebas pilotos que permitirán, más adelante, llevar experimentos
con mayor control que arrojen mediciones sobre variables, y que permita sacar
conclusiones más sólidas25.

Dentro de los diseños de estudio no experimental, se adopta el diseño

transaccional descriptivo, el cual indaga la incidencia y los valores en que se
manifiesta una o más variables. El procedimiento que se seguirá será el de
medir las variables seleccionadas, proporcionando su descripción,
estableciendo hipótesis descriptivas.

3.3 ENFOQUE DE LA METODOLOGIA.

Como paradigma metodológico se ha elegido el enfoque cualitativo porque

permitirá describir el desarrollo de procesos académicos requeridos en el
23
Ibíd., p. 188
24
Ibíd., p. 190
25
Ibíd., p. 191

22
Centro de Educación Virtual, mediante el seguimiento de la metodología
Scrum, llevándola 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 intervención o influencia directa.

El enfoque cualitativo es definido por Roberto Hernández Sampieri y otros

autores en su libro Metodología De La Investigación como aquella que utiliza
preferente o exclusivamente información de tipo descriptivo y cuyo análisis se
dirige a lograr descripciones detalladas de los fenómenos estudiados. El
enfoque cualitativo describe la realidad en el que se desarrolla un
acontecimiento dado, es decir la metodología cualitativa se basa en una
rigurosa descripción contextual de un hecho o situación que garantice la
máxima intersubjetividad en la captación de una realidad compleja mediante
una recogida sistemática de datos que posibilite un análisis e interpretación del
fenómeno en cuestión.

3.4 TECNICAS DE RECOLECCION DE LA INFORMACION

3.4.1 Fuentes primarias. Las fuentes primarias aportan datos a la investigación,

buscando recopilar información acerca del tema que se está analizando. En la
presente investigación la principal fuente de información serán los artículos de
revistas que hagan referencia a la metodología Scrum, así como apartados
periodísticos, entrevistas realizadas a expertos, tesis y disertaciones que
toquen temas relacionados con este tipo de metodología.

También se contará con la colaboración del Ingeniero Javier García

Altamiranda, Coordinador Tecnológico del CEV, así como de los
desarrolladores vinculados al CEV. La información pertinente para el correcto
desarrollo de este proyecto se obtuvo a través de la asesoría continua del
Coordinador Tecnológico como gestor de la idea de implementar Scrum y su
posterior orientación en el desarrollo del mismo buscando mejorar el índice de
desarrollo de software. La información acerca de la lógica de negocio se
consignará en las historias de usuario; la elaboración de éstas se realizará en
reuniones que integrarán al equipo desarrollador y el Ingeniero Javier García a
lo largo de todo el desarrollo del proyecto, desempeñando dos roles bien
definidos: como representante del cliente y como Scrum Manager.

El papel que da ser representante del cliente permite obtener la visión general
del producto, creando a partir de éstas el Product Backlog o lista de tareas que
se van a realizar, determinándose 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 elaboración del Product Backlog se da como resultado de una reunión

cruzada entre el representante del cliente y el equipo desarrollador antes de
iniciar la planeación de los Sprint. Pero no es un producto terminado sino que
estará en continua evolución 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 planeación
de futuros Sprint, en los cuales deberán estar presentes el representante del
cliente y el equipo desarrollador en pleno.

3.4.2 Fuentes secundarias. Como fuentes secundarias de la investigación se

tienen libros relacionados con la metodología Scrum; los libros relacionados
con la guía de desarrollos ágiles y los sistemas metodológicos similares
desarrollados en el mercado, así mismo, el componente del sistema de
información 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 bibliográfico que puede ser
utilizado para el desarrollo de la presente investigación.

3.5 VARIABLES

En la metodología cualitativa, los datos recogidos necesitan ser traducidos en

categorías con el fin de poder realizar comparaciones y posibles contrastes, de
manera que se pueda organizar conceptualmente los datos y presentar la
información siguiendo algún tipo de patrón o regularidad emergente. La
categorización (es decir, cerrar o establecer las categorías) facilita la
clasificación de los datos registrados, y por consiguiente, propicia una
importante simplificación26. Teniendo en cuenta lo anterior se determinan las
siguientes variables:

 Aplicación Software

 Procesos académicos

 Base de datos

 Scrum

26
AUSTIN MILLÁN, Tomás. Investigación 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

Aplicación Es un programa diseñado Análisis Suficiente
Software para automatizar una Insuficiente
determinada tarea. Consta
de una serie de Diseño Simple
instrucciones lógicas y en Complejo
orden con el fin de cumplir Implementación Suficiente
un objetivo. Insuficiente

Procesos Administrativos
académicos Los procesos académicos Simple
son todos aquellos trámites Complejo
relacionados con la vida Académicos Simple
académica de los Complejo
estudiantes referidos a los
procesos de matrícula,
pagos, evaluación de
docentes, consulta de notas
y horarios.

Base de Almacenamiento
Datos Es un conjunto de datos Satisfactorio
almacenados Insatisfactorio
sistemáticamente para su
uso posterior, permitiendo Consulta Satisfactorio
operaciones como Insatisfactorio
actualización, borrado y
adición de datos, además
de las operaciones
fundamentales de consulta

Scrum Es una metodología de Aplicativo Satisfactorio

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

Tabla 1. Operacionalización de Variables

25
3.7 PROCESAMIENTO DE LA INFORMACION

Después de observar y evaluar la realidad que vive el Centro de Educación

Virtual (CEV), se propondrá un plan de trabajo que entregue sistemas amenos,
intuitivos y prácticos que optimicen procesos académicos como son el acceso a
la información personal, administración de notas estudiantiles, portal para el
manejo de prácticas industriales, inscripción a votaciones estudiantiles y portal
de votaciones estudiantiles.

Siguiendo la Metodología Scrum se definirán un planeamiento inicial con el

propósito es establecer la visión 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 acumulación (Product Backlog) del producto inicial y los ítems
estimados, así como la arquitectura de alto nivel, el diseño exploratorio y los
prototipos a alcanzar.

Luego se pasara a la etapa de desarrollo cuyo propósito será el de

implementar un sistema listo para entregar a lo largo de una serie de
iteraciones de quince días llamadas sprints. En los sprints son planeadas las
actividades para cada iteración, y que se constituyen en estimados, que dan la
temática 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 Programación.

 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 módulos más fáciles de escribir,
mantener y reutilizar. Un objeto es aquél 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 través de métodos 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 definición 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 análisis
estructural del proceso prospectivo en las organizaciones. Universidad de San Buenaventura Cartagena,
Colombia.

26
 El paradigma de programación orientado a objetos posee las siguientes
características:28

 Herencia: Las clases pueden “heredar” el comportamiento y

las propiedades de otras clases, relacionándolas entre sí
formando una jerarquía de clasificación. Esto permite construir
componentes de software más flexibles y reutilizables.

 Polimorfismo: Dentro de una clase se pueden definir

comportamientos con el mismo nombre, pero que realizan una
función diferente según el parámetro o la condición en que se
reciban.

 Abstracción: Se emplea en las clases cuando se definen sus

propiedades y métodos por nombre más 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 código en

piezas de código mejores (módulos) a fin de ganar en
legibilidad y facilidad de revisión. Así en lugar de sólo un
método impresión en una clase informe, usted podría dividirlo
en título, cuerpo, y métodos pie de página. Igualmente, el
método cuerpo podría dividirse en los títulos de la columnas,
línea de ítems, y método pie de página de columna”.

 Estas características ofrecen una mayor ventaja ante las

demás filosofías de programación. Del paradigma orientado a
objetos se puede obtener un sistema de información completo,
reutilizable y flexible.

3.8.2 Herramienta de Desarrollo de Software. A continuación 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, fácil de
aprender, Open Source (Código fuente abierto), lo cual implica que sea
de libre distribución, permite el acceso a bases de datos, portable,
multiplataforma y porque dispone de abundante soporte en la Web.

3.8.3 Herramientas Software. A continuación se describen las herramientas

que se utilizaron en el proceso.

28
Ibíd.

27
  NetBeans: Para el desarrollo del sistema de información se utilizará el
lenguaje de programación orientado a objetos PHP, el cual crea objetos
mediante instrucciones secuenciales, y que son manipulables mediante
la utilización de métodos que son interfaces que dejan entrever su
funcionalidad. Los métodos permiten a los objetos comunicarse entre
ellos a través del paso de mensajes. PHP es un lenguaje de
programación joven pero muy robusto y potente, que mediante la
utilización de herramientas de edición como Netbeans versión 7.0.1, que
permite crear interfaces o ventanas de interacción agradables al usuario.

3.8.4 Herramientas de Diseño. Como herramienta de diseño se utilizó.

 HTML: acrónimo de HyperText Markup Language o lenguaje de marcas

de hipertexto. Se utilizará esta herramienta de desarrollo de software
porque es el formato estándar de los documentos que circularan en la
Word Wide Web (WWW), y porque además 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 información relacionadas, y con
inserciones multimedia (gráficos, sonido.). HTML realiza una
descripción de página independiente del dispositivo, lo que permite
adaptar la visión del documento al tamaño de la pantalla en la que se
muestra.

3.8.5 Herramientas Hardware. Las herramientas hardware fueron las descritas

a continuación.

 Para la construcción del sistema de información se utilizaran las

siguientes configuraciones mínimas en cuanto al rendimiento que deberá
tener el equipo utilizado para el desarrollo del software:

 Procesador de 3 GHz, doble núcleo.

 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 continuación se muestra las configuraciones mínimas
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 Programación 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 están usando las
diferentes interfaces que brinda la API, siendo las aplicaciones de optimización
de procesos académicos, 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 parámetros de entrada y los retornos de cada uno de estos, es
suficiente para su utilización. Por políticas internas del lugar donde se
desarrollaron las aplicaciones, cierta información de funcionamiento y
seguridad no fueron suministradas, contando para la elaboración de este punto
información muy general de todo el sistema que es descrita a continuación.

La arquitectura de la infraestructura, es decir La topología 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 lógicas en distintos niveles físicos, permitiendo al sistema aumentar la
capacidad, añadir más 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 división
lógica de componentes y funcionalidad, brindando entre otras ventajas30:

 Localizar los cambios de un tipo en una parte de la solución minimiza el

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

 La separación de responsabilidades entre componentes (por ejemplo,

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

29
Guía Arquitectura N-Capas Orientada al Dominio - Microsoft Architecture (1a Edición Noviembre
2010)
30
Ibíd.

29
  La reutilización de ciertos componentes entre diferentes módulos de una
aplicación o incluso entre diferentes aplicaciones.

 Equipos diferentes deben poder trabajar en partes de la solución con

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

El sistema de información desarrollado en la Universidad de San Buenaventura

Cartagena siguió un diseño básico de capas: Los componentes de la solución
han sido divididos en capas presentando una interacción que se ilustra en la
figura 1. Las capas son agrupaciones horizontales lógicas de componentes de
software que forman la aplicación o el servicio. Ayudan a diferenciar entre los
diferentes tipos de tareas a ser realizadas por los componentes, ofreciendo un
diseño que maximiza la reutilización y, especialmente, la mantenibilidad. En
definitiva, se trata de aplicar el principio de „Separación de Responsabilidades‟
(SoC - Separation of Concerns principle) dentro de una Arquitectura31.

Figura 2. Interacción en arquitectura de capas

La gestión de dependencias escogido para el diseño 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
Ibíd.

30
Figura 3. Vista de la arquitectura lógica implementada en el sistema de
información de la Universidad de San Buenaventura, Cartagena.

31
A continuación se describen las diferentes capas en que encuentra dividida la
arquitectura lógica del sistema de información de la Universidad de San
Buenaventura (ver figura 3), la cual da una visión global y permite comprender
mejor todo el sistema:

 Capa de Presentación: Esta capa es responsable de los componentes

visuales que se muestran al usuario. Los componentes han sido
divididos en módulos, los cuales implementan las funcionalidades
requeridas para que los usuarios interactúen con la aplicación. Los
componentes de esta capa han sido divididos en:

 Componentes Visuales (vistas): Estos componentes proporcionan

el mecanismo base para que el usuario utilice la aplicación. Son
componentes formados por los datos guardados en base de datos
y suministrados a través 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 gráficos de la lógica de
negocio, impidiendo que el flujo de proceso y lógica de gestión
esté programada dentro de los propios controles y formularios
visuales, permitiendo reutilizar dicha lógica desde otra interfaces
o vistas.

 Componentes/Aspectos Horizontales de la Arquitectura: Proporcionan

capacidades técnicas genéricas que dan soporte a capas superiores. En
definitiva, son „bloques de construcción‟ ligados a una tecnología
concreta para desempeñar sus funciones.

Existen muchas tareas implementadas en el código de una aplicación

que se deben aplicar en diferentes capas. Estas tareas o aspectos
horizontales (Transversales) implementan tipos específicos de
funcionalidad que pueden ser accedidos/utilizados desde componentes
de cualquier capa. Los diferentes tipos/aspectos horizontales más
comunes, son: Seguridad (Autenticación, Autorización y Validación) y
tareas de gestión de operaciones (políticas, logging, trazas,
monitorización, configuración, etc.).

 Capa Service (Aplicación): Esta capa no contiene reglas del dominio o

conocimiento de la lógica de negocio, simplemente debe realizar tareas
de coordinación de aspectos tecnológicos de la aplicación que nunca se
explicarían al propietario del producto. Es una capa que brinda servicios
que coordinan otros llamadas a otros servicios, siendo su principal
beneficiario la capa de presentación. Un ejemplo lo constituiría un
servicio ofrecido a la capa de aplicación, é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 aplicación.
Por esto, en esta misma capa, pero solapada se encuentra la capa de
Seguridad: nada puede se consumido y nada podrá acceder a la
aplicación sin haber hecho uso de esta capa.

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

representar conceptos de negocio, información sobre la situación de los
procesos de negocio e implementación de las reglas del dominio.
También debe contener los estados que reflejan la situación de los
procesos de negocio. Esta capa, “Dominio”, es el corazón del software.

Así pues, estos componentes implementan la funcionalidad principal del

sistema y encapsulan toda la lógica de negocio relevante. Básicamente
suelen ser clases en el lenguaje seleccionado que implementan la lógica
del dominio dentro de sus métodos. Para conseguir la máxima
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 tecnologías 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 tecnología e
infraestructura sobre la cual se construye la aplicación. Esta capa
proporciona la capacidad de persistir datos así como lógicamente
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 exposición
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 lógica necesaria para acceder a los datos, es decir, de
métodos para consultar, añadir, modificar y eliminar objetos. Permite
además seleccionar objetos basándose en criterios de selección,
devolviendo objeto o colecciones de objetos instanciados con los
valores del criterio.

La tecnología de persistencia utilizada en los repositorios es un O/RM

llamado N/Hibernat. Junto a esta tecnología utilizada internamente se
añadieron operaciones de Base de datos. Cabe añadir 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 implementación 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 Inyección de Dependencia e Inversión de Control.
Esta mantenibilidad del sistema es dada por esta capa en donde se
realizan las instancias necesarias para tal fin. Esto facilita la sustitución
de capas o módulos sin ningún tipo de dificultad. La IoC describe
técnicas 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 patrón 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 elaboración del “frontend” de las aplicaciones que administran los procesos

académicos en la Universidad de San Buenaventura – Cartagena, implicó el
manejo principlamente de la capa de presentación principalmente, junto a un
conocimiento superficial de las demás capas (esto según la utilización dentro
de los trabajos que se desarrollaban).

4.2 REQUERIMIENTOS

Como ya se manifestó anteriormente, la información pertinente para el correcto

desarrollo de éste proyecto se obtuvo a través de la asesoría continua del
Coordinador Tecnológico del CEV Javier García 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 también aclarar que se ha seguido las características 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 García ha realizado cambios en
el uso de artefactos así como ha seguido el consejo de incorporar otros como
lo es el del Juego de Póker utilizado para la asignación de horas a las
actividades y que es propio de otra metodología ágil de desarrollo, más
concretamente, Xtreme Programing.

La información acerca de la lógica de negocio se consignó en las historias de

usuario; la elaboración de éstas se realizó a lo largo del desarrollo del proyecto,
en reuniones que integraron al Ingeniero Javier García y a la ingeniera Tulia
Zúñiga 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 Martínez, 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 reunión.

El proceso iniciado con la definición sencilla y clara de las características 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
"fertilización cruzada" o brainstorming.

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

la desglosó de forma que permitió identificar de forma más fácil, 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 guía de desarrollo.

El Product Backlog es propio del Dueño 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 tecnologías que el
sistema debe incorporar a través de iteraciones de desarrollo, no constituye un
documento inicial y definitivo, sino en un instrumento que permite incorporar
modificaciones, correcciones e incorporación de nuevas funcionalidades.

4.2.1 Product Backlog. Teniendo en cuenta lo anterior se define a continuación

este elemento de Scrum. Se tienen cinco secciones de trabajo, los cuales
presentan requerimientos que han sido transmitidas al grupo de
desarrolladores en la reunión de planificación del primer Sprint. Estos módulos
se especifican a continuación: Portal de Docentes, Seguimiento de Prácticas,
Portal Estudiante, Portal Egresados y Portal de Elecciones.

 Portal de Docentes: Esta sección permite visualizar información personal

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

 Módulo Actualización de Datos: Actualiza la Información de Contacto

y Datos aún no diligenciados.

 Módulo Ficha de Docente: Muestra la Información Básica del

Docente y Permite el Envío de Correo Electrónico

 Módulo Publicación de Notas: Permite el Registro de Calificaciones

 Módulo Corrección de Notas: Permite la Corrección de Calificaciones

 Seguimiento de Prácticas: Esta sección permite realizar un seguimiento

virtual a las prácticas que realiza el estudiante. En ella interactúan

35
empresa, docente encargado y estudiante. Se halla dividido en los
siguientes módulos:

 Módulo Creación de Solicitud: Creación de Solicitud de Practicante

por parte de una Empresa

 Módulo Responder Solicitud: Respuesta de una Solicitud de

Practicante por parte de un Coordinador de Prácticas

Figura 4. Product Backlog del Desarrollo

 Módulo Gestión de Empresas: Crear, Actualizar, Eliminar y Editar

Empresas

36
  Módulo Diligenciar Bitácora: Permite tramitar el llenado de las
bitácoras de trabajo que se han realizado por parte del estudiante.

 Módulo Valorar Practicante: Le permite al empresario dar una

calificación a cada practicante evaluando la labor realizada.

 Módulo Finalizar Práctica: Le permite al empresario dar por

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

 Módulo Reportar Amonestación: Le permite al empresario realizar

amonestaciones al practicante, informando a éste y al tutor de
prácticas la situación presentada.

 Módulo Ver Amonestaciones: Le permite al tutor de prácticas ver las

amonestaciones que realiza el empresario.

 Módulo Responder Amonestaciones: Le permite dar respuesta a

cada amonestación que el empresario haga de un practicante.

 Módulo Practicantes Asignados a Empresa: Les permite a los tutores

de práctica asignar practicantes de acuerdo a las solicitudes
existentes de empresas.

 Módulo: Cargar Certificado: Una vez que el empresario a dado por

finalizada una práctica, se debe cargar un certificado que informe de
tal hecho.

 Portal Estudiante: Esta sección permite visualizar, de forma general,

información de interés para el estudiante, sus datos personales y su
histórico de notas. Se halla dividido en los siguientes módulos:

 Módulo Actualización de Datos: Actualiza la Información Personal,

Familiar, Académica, Laboral y Estudios de Idiomas que este
presenta.

 Módulo Historial de Notas: Muestra las Calificaciones Obtenidas por

el Estudiante en las Materias Cursadas en su carrera universitaria.

 Módulo Semáforo Académico: Muestra los Cursos Aprobados y

Pendientes del Plan de Estudio relacionado con cada estudiante.

 Módulo Información de Estudiante: Muestra la información Personal

 Módulo Perfil del Estudiante: Muestra una Ficha con la Información

Básica y la Posibilidad de Envío de Correo Electrónico

37
  Portal Egresados: Esta sección permite visualizar, de forma general,
información de interés para los egresados, como sus datos personales y
su histórico de notas. Se halla dividido en el siguiente módulo:

 Módulo Actualización de Datos: Actualiza la Información Personal,

Familiar, Académica, Laboral y Estudios de Idiomas

 Portal de Elecciones: Esta sección permite realizar de forma sistematiza

todo el proceso de elecciones: inscripción, aprobación de candidatos y
la respectiva elección de los mismos. Se halla dividido en los siguientes
módulos:

 Módulo Inscripción: Permite a un estudiante activo inscribirse como

candidato para el consejo académico o representante de facultad.

 Módulo Aprobación candidatos: Permite a una persona encargada

aprobar la candidatura de estudiantes al consejo académico o
representante de facultad.

 Módulo Votación: Permite a estudiantes que se encuentren activos

realizar la votación por sus candidatos favoritos.

4.3 ITERACIONES DE IMPLEMENTACION DE LOS PRODUCTOS.

Scrum permite trabajar en productos diferentes simultáneamente, es decir, un

Sprint no representa el desarrollo de un producto o aplicación, sino que
constituye el avance en las actividades prioritarias definidas al inicio del Sprint
y que constituyen entregables, que van incrementándose 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 serán necesarias para la creación del
Product Backlog.

4.3.1 Exposición del Product Backlog. Una vez establecido el Product Backlog,
se realizó la primera reunión con todos los integrantes del proyecto (Product
Owner, Scrum Master y Scrum Team); su duración 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 también llamadas Historia de Usuario.
Durante la primera parte de la reunión se definieron por parte del Product
Owner, los elementos de alta prioridad.

38
4.3.2 Resolución del Sprint Backlog. En la segunda parte de la reunión 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 Dueño 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,
basándose en su propio análisis y planificación se comprometen a terminar la
parte del producto escogida. El dueño 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 emplearía en cada

actividad, empleándose para esto el juego del Póker. Cada miembro daba su
estimación con una tarjeta que contenía un número que simbolizaba el número
de horas que tardaría en realizar la actividad, siendo luego comparadas con las
del resto del equipo y escogiéndose, a partir de estas, la media del tiempo que
cada miembro del equipo haya manifestado. El significado de los números y
símbolos utilizados en el póker se muestran a continuación:

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

 ½: Tarea que tomará media hora para su realización.
 ? : El significado que representa esta tarjeta en la reunión es que no se
tiene conocimiento de cómo 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 reunión 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 número representa una tarjeta, y
representa el número 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, colocándose en el Sprint Backlog.
El Sprint Bagklog era una herramienta que permitía 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 planeación, se dió inicio
al desarrollo del Sprint, y con ella una de las características claves de Scrum: la
reunión diaria. Esta era una reunión 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-organización y auto–

control entre los integrantes. En ella se contestan las tres preguntas claves, y si
se encontrase algún tipo de inconveniente se le comunica al Scrum Master

39
para que fuese él quien tomase las medidas al respecto. Se procedía como
viene a continuación:

 Cada integrante del equipo respondía estas tres interrogantes:

1. ¿En qué tarea trabajó ayer?
2. ¿En qué tarea trabajará hoy?
3. Si van a necesitar algo especial o prevén algún
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 (sólo las que ya hayan sido probadas).

Figura 5. Sprint Backlog del Desarrollo

Con la información del encuentro diario se actualizan las columnas “No

empezado”, “En Progreso” y “Completado” del Sprint Backlog y la Gráfica de
trabajo (Diagrama de Burn-Down), añadiendo en ésta las horas de trabajo de
las tareas realizadas. La gráfica 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 permitían

cambios en actividades o adición 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 demás integrantes del equipo debían 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,

debía ir detallando nuevos requisitos, separar elementos grandes en otros más
pequeños, 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 duración de los Sprint nunca se prolongaron más 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 había comprometido.
41
4.3.4 Revisión del Sprint. Cuando terminó el Sprint se hace la revisión del
mismo. El Scrum master y a la vez representante del Cliente no sólo revisaba
el entregable del producto o los demos sino también la calidad del trabajo, de
forma que no se pudiese disimular los códigos desordenados, sin probar y de
mala calidad.

La revisión del Sprint también implicaba que el equipo hablase sobre lo que
funciona y lo que no, y se acordaban que cambios se querían intentar. Se
dejaba claro “qué fue bien” y “qué se puede mejorar”, buscando causas y
previniéndolas en el próximo Sprint.

Llegado este punto, se iniciaba la planeación del siguiente Sprint, siendo

definido la fecha y lugar durante la revisión del Sprint. En este punto el Product
Owner podía 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 había 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 obtención de los productos finales: Portal de Docentes,
Seguimiento de Prácticas, Portal Estudiante, Portal Egresados y Portal de
Elecciones. En total se realizaron 5 Sprint o iteraciones que se detallan a
continuación:

 Sprint 1: Por ser el primer sprint de la implementación de la metodología,

todos los participantes estaban sumamente ansiosos por ver como
evolucionaba; este Sprint en particular fue el caso de una
implementación ideal, debido a que, a pesar que era la primera
experiencia con respecto a la implementación de la metodología, se
logró una ejecución casi perfecta, a razón de que los tiempos se
cumplieron tal como se planearon y las tareas se realizaron como se
discutieron en la reunión de planeación del sprint días atrás. 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 metodología, casi siempre se
produce una pésima ejecución, arrojando como resultado actividades sin
completar, apatía de los participantes a la nueva metodología, entre
otras cosas, pero ese no fue el caso de esta implementación.

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
Obtención 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 Académica

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

Tabla 4. Actividad Realizar Matricula Académica

Ver Perfil del Estudiante

Sub-Actividades Prioridad Tiempo Comentario
Diseño de UI Media 1 Horas Mostrar Código,
nombre y apellido,
y agregar botón
enviar
Controlador de Alta 6 Horas Enviar por SMPT,
Envío de Correo sendmail, phpmail
UI envío de correo Media 2 Horas WYSIWYG, array,
destinatario POST

Tabla 5. Actividad Ver Perfil del Estudiante

43
 Ver Información del Estudiante
Sub-Actividades Prioridad Tiempo Comentario
Agregar el estado Media 3 Horas Creación HBM,
del Estudiante entidades API,
entidades PHP
Diseño UI Baja 4 Horas Agregar atributo
estado

Tabla 6. Actividad Ver Información 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 Semáforo Académico

Sub-Actividades Prioridad Tiempo Comentario
Cambiar Nombre Baja 10 Minutos Ninguno
al Módulo

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 Semáforo Académico

Mostrar Historial de Notas

Sub-Actividades Prioridad Tiempo Comentario
Sincronizar cortes Urgente 5 Horas Tener en cuenta el
con programación nuevo reglamento
académica institucional
Obtener periodo Media 2 Horas Ninguna
académico por
GET

Tabla 9. Actividad Mostrar Semáforo Académico

44
 Realizar Actualización de Datos de Estudiantes
Sub-Actividades Prioridad Tiempo Comentario
Reparar Código 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
Académico como
MODAL
Implementar Baja 2 Horas Ninguno
formulario de
Estudios de
Idiomas como
MODAL

Tabla 10. Actividad Realizar Actualización 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 ejecución y planeación del sprint
anterior, surgieron unos inconvenientes a la hora de ejecutar esta
iteración, 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ó, además 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 aún más. Llegado el día final del sprint, el equipo de trabajo
no había terminado todas las actividades, otras se demoraron más de lo
planeado, unas quedaron sin resolver; todo esto afectó
45
 significativamente el resultado final de la iteración, 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
Definición de Baja 4 Horas Ninguna
Procesos

Tabla 11. Actividad Solicitar Becas y Descuentos

Prácticas Empresariales
Sub-Actividades Prioridad Tiempo Comentario
Crear Solicitud de Medio 2 Horas Posterior a la
Practicas creación de la
solicitud, se debe
enviar un Mail al
responsable
(Coordinador de
Practicas)
Crear Módulo de Medio 2 Horas Ninguna
Gestión de
Empresas
Crear Módulo de Medio 5 Horas Ninguna
Finalización de
Practicas
Crear Módulo de Baja 4 Horas Valoración de Inicial
Valoración de y Valoración Final
Practicante
Crear Módulo para Media 5 Horas Este es el módulo
Responder en el que el
Practicante Coordinador decide
en donde se
realizará las
prácticas de
acuerdo con las
solicitudes.
Crear Módulo para Media 5 Horas Ninguna
Diligenciar Bitácora
por parte del
Practicante

Tabla 12. Actividad Prácticas Empresariales

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

Realizar Urgente 3 Horas Ninguna

Adecuación del
Modelo

Tabla 13. Actividad Persistencia de Acaweb

Actualización 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

Actualización de parecida a la de
Datos de Actualización de
Egresados Datos de
Estudiantes, pero
con unos datos
adicionales
específicos de los
egresados
Agregar Urgente 6 Horas Hacer que todo
Funcionalidad al funciones
Módulo perfectamente bien

Tabla 14. Actividad Actualización 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
página y verificar
algunos errores
presentes
Inscripciones en Urgente 8 Horas Realizar un portal
línea provisional provisional de
Inscripciones en
línea para los
nuevos estudiantes

47
 Implementar un Urgente 8 Horas Implementar un
sistema de sistema para evitar
validaciones que los usuarios
gramaticales introduzcan letras,
símbolos o números
cuando no son
permitidos.
(Validación 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
están desarrollando

Tabla 15. Actividad Imprevista Sprint 2

Figura 7. Actividades Sin Planeación

48
 Sprint 3: A razón 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 más de cautela y
precaución a la hora de asignar tiempo a las actividades de la iteración.
La ejecución del Sprint se llevó a cabo sin muchos altercados,
nuevamente se presentaron actividades y cambios a las actividades
planeadas en tiempo de ejecución 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 iteración y como resultado se produjo una buena
ejecución del sprint.

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

sprint fueron las siguientes:

Prácticas Empresariales (Actividades sin Resolver)

Sub-Actividades Prioridad Tiempo Comentario
Crear Módulo de Urgente 2 Horas Ninguna
Gestión de
Empresas
Crear Módulo de Urgente 5 Horas Ninguna
Finalización de
Practicas
Crear Módulo de Urgente 4 Horas Valoración de
Valoración de Inicial y Valoración
Practicante Final

Tabla 16. Actividad Prácticas Empresariales (Actividades sin Resolver)

Matrícula en línea
Sub-Actividades Prioridad Tiempo Comentario
Realizar Media 4 Horas Ninguna
Diagrama de
Actividades
Realizar UI de la Media 4 Horas Ninguna
matrícula en línea

Obtención de Pre- Urgente 3 Horas Calcular la pre-matrícula

matrícula 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 Matrícula en línea

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

Mis Cursos Medio 3 Horas Visualizar

estudiantes y sus
respectivos
correos
electrónicos por
curso.
Crear UI Urgente 4 Horas Ninguna

Horario Bajo 3 Horas Ninguna

Realizar Medio 4 Horas Es Similar a la de

Actualización 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 revisión 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 metodología 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 iteración 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
Estandarización Medio 5 Horas Pestañas,
de los widgets botones, campos
de texto, entre
otros.
Realizar cambios Urgente 10 Horas Debe funcionar en
necesarios para Internet Explorer
la (7 - más reciente),
interoperabilidad Firefox (3 – más
entre los reciente) y Google
navegadores web Chrome. Revisar
CSS, JS y
atributos
especiales.
Reestructurar Bajo 3 Horas Implementar
Tamaño de los varios tamaños y
campos de texto estandarizarlos.
Rediseñar las Bajo 3 Horas Ninguna
pestañas

Editar formulario Medio 5 Horas Agregar la

de envió de posibilidad de
correo agregar más 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 metodología fue un éxito, surgió la
necesidad de realizar varias actividades fuera de lo planeado, dichas
actividades fueron: Inscripción en Línea (Versión 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 iteración se llevó a cabo sin
mayor imprevisto ya que se tenía una experiencia previa con las
anteriores iteraciones. Todo surgió según lo planeado en la reunión
previa y como resultado surgió el portal de inscripciones en línea 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 académico de la
Universidad también 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 línea (Versión Definitiva)

Sub-Actividades Prioridad Tiempo Comentario
Diseño 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 Psicología
Psicotécnica
Agregar Medio 5 Horas 5 Posibilidad
Funcionalidad al de completar
Módulo parcialmente
el proceso de
inscripción.
6 Envío de
Correo
electrónico al
terminar la
inscripción.
Realizar Medio 3 Horas Para garantizar
validaciones aún más la
adicionales funcionalidad en
los distintos
navegadores.

Tabla 20. Actividad Inscripciones en línea (Versión Definitiva)

Modificaciones Portal Egresados

Sub-Actividades Prioridad Tiempo Comentario

52
 Modificaciones Medio 3 Horas Surgieron unos
en la inconvenientes a la
actualización 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
Diseño de la UI Medio 4 Horas Diseño de Interfaces
de usuario para,
inscripción de
representantes,
aprobación de
inscritos y
elecciones.
Agregar Medio 4 Horas Garantizar la
Funcionalidad al funcionalidad en
Módulo todos los
navegadores,
implementar un
sistema de
auditorías que
almacene la
dirección IP de
donde se realizó el
voto.

Tabla 22. Actividad Portal de Elecciones Institucionales

Scrum permitió a través de iteraciones, un desarrollo contínuo de varias

aplicaciones o productos, permitiendo trabajar simultáneamente 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 DISEÑO Y DESARROLLO DE INTERFACES.

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

que se usaron específicamente para este aspecto. Entre las herramientas
usadas se encuentran:
 Netbeans como editor de código fuente
 Navicat como gestor de base de datos
 PhotoShop como herramienta para edición de imágenes
 Navegadores web, entre estos se encuentra Google Chrome, Mozilla
Firefox, Safari e Internet Explorer.

53
A continuación se mostrarán las interfaces resultantes de la implementación.

 Interfaz principal donde podemos apreciar los diferentes módulos

realizados durante nuestras pasantías, podemos observar Mis datos el
cual es el lugar donde podremos observar y actualizar toda la información
correspondiente a los, Mis Cursos es otro modulo donde se encuentra
toda la información referente a Horario, Notas y Cursos Matriculados.
Practicas Industriales, modulo relacionado con toda la vida de prácticas
Industriales. Consultas este módulo nos da la oportunidad de observar la
información correspondiente al volante de pago y al Semáforo Académico.
(Ver la siguiente Figura)

Figura 8. Página de Inicio

 Actualización de Datos Estudiantes: Interfaz donde se puede apreciar

Mis datos en el cual se pueden observar los datos del estudiante y
actualizar toda la información correspondiente del mismo; Mis Cursos
es otro módulo donde se encuentra toda la información referente a
Horario, Notas y Cursos Matriculados; Prácticas Industriales, módulo
relacionado con toda la vida de prácticas Industriales en caso de tener
vigente alguna; Consultas este módulo da la oportunidad de observar la
información correspondiente al volante de pago y a toda el pensum y
notas del estudiante.

La primera sección de este módulo 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 Básicos: Dentro del módulo de “Mis

Datos” se puede Actualizar información sobre la ficha de estudiante,
teniendo la opción de variar toda aquella que al transcurrir el tiempo

54
 haya presentado modificaciones como el lugar de residencia,
teléfono, correo electrónico y celular. (Ver la siguiente Figura)

Figura 9. Actualizar Mis Datos – Datos Básicos

 Actualizar Mis Datos – Datos Familiares: En esta Interfaz se tiene

acceso a la información 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 Académico: Esta interfaz permite

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

Figura 12. Actualizar Mis Datos – Historial Académico

57
  Actualizar Mis Datos – Idiomas: En esta pestaña se puede añadir
información 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

términos y condiciones para poder confirmar el cambio de información
realizado sobre la ficha correspondiente.

La segunda sección de éste módulo es Ver mis Datos y permite a los

estudiantes visualizar la información relacionada con su ficha estudiantil; está
compuesta por las siguientes interfaces:

 Ver Mis Datos – Información Personal: En Mis Datos se da la opción de

observar la información presente en la Base de Datos de la universidad.
(Ver la siguiente Figura)

58
 Figura 14. Ver Mis Datos – Información Personal

 Ver Mis Datos – Información de Contacto: Ficha de Estudiante con datos

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

59
 Figura 15. Ver Mis Datos – Información de Contacto

La tercera sección de éste módulo es Mis Cursos en el que el estudiante puede

observar los cursos en los que actualmente se encuentra matriculados,
permitiéndole ver compañeros de curso, enviarles correos, detallar el horario de
clases, entre otras actividades.

La cuarta sección de éste módulo es Prácticas Industriales en el que el

estudiante puede ir añadiendo actividades a su bitácora siempre que lo desee.
Esta sección estará activada si y sólo si el estudiante es asignado a una
empresa que haya expresado su intención de contar con los servicios de un
practicante. Sus interfaces son:

 Prácticas Industriales - Bitacoras: Se da la opción para que el

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

60
 Figura 16. Prácticas Industriales- Bitácora

 Prácticas Industriales – Descargar Certificado: En este espacio el

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

Figura 17. Prácticas Industriales – Descargar Certificado

61
 Actualización de Datos Egresados. Espacio de los Egresados donde
pueden modificar la información relacionada con la que fue en algún
momento su ficha estudiantil.

 Actualizar Mis Datos – Datos Básicos: 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 opción de poder agregar hijos .(Ver la siguiente Figura)

Figura 18. Actualizar Mis Datos – Datos Básicos

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

Figura 19. Actualizar Mis Datos – Información Laboral

 Actualizar Mis Datos – Información Académica: La Información

académica de un egresado se encuentra en esta interfaz, donde podrá
añadir nuevos títulos obtenidos en cualquier entidad educativa (Ver la
siguiente Figura).

63
 Figura 20. Actualizar Mis Datos – Información Académica

 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 información complementaria que es de protocolo para la universidad.
(Ver la siguiente Figura).

Figura 22. Actualizar Mis Datos – Datos Complementarios

 Interfaces Módulo de Docentes. Campo relacionado con los docentes

donde podrán visualizar información que estos poseen, estas interfaces son:

 Módulo de Docentes – Horario: Los Docentes tienen la oportunidad de

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

65
 Figura 23. Módulo Docentes – Horario

 Módulo de Docentes - Cursos: En esta ventana aparecerán todos los

cursos asignados al docente con información detallada sobre el mismo.

 Módulo de Docentes – Notas: Es esta interfaz se permite al docente

asignar las notas académicas a cada estudiante, así como corregirlas
según el límite de tiempo que para éste efecto se le asigne.

 Elecciones Estudiantiles. Espacio donde los estudiantes pueden tomar

elección de aquellos que se hayan postulado a Consejo Académico o
Representante de Facultad, estas interfaces son:

 Elecciones Estudiantiles - Formulario de Inscripción: En el módulo de

Elecciones, se permite realizar la inscripción 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 campaña
del postulado. (Ver la siguiente Figura)

66
 Figura 24. Elecciones Estudiantiles – Formulario de Inscripción

 Elecciones Estudiantiles – Admisiones: Esta Interfaz sólo se encuentra

disponible para el Jefe de Unidad de Registro Académico quien tendrá la
opción de admitir o denegar la inscripción de los candidatos postulados.
(Ver la siguiente Figura)

67
 Figura 25. Elecciones Estudiantiles – Admisión

 Elecciones Estudiantiles - Votacion: En esta interfaz se puede apreciar

los diferentes aspirantes al consejo académico o representante de
facultad que se encuentren admitidos para su elección por el cuerpo
estudiantil; además, también se podrá sufragar por el candidato de
elección (Ver la siguiente Figura)

Figura 26. Elecciones Estudiantiles Votación

68
 Módulo de Prácticas Industriales. El control y seguimieento de las
prácticas se realiza mediante estas interfaces. En esta oportunidad se
tendran presentes varios usuarios como lo son el Coordiandor de
Prácticas y la Empresa. Las vistas correspondientes al estudiante ya han
sido descritas en la sección correspondiente a él.

Las interfaces de prácticas industriales que puede visualizar el

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

 Prácticas Industriales – Subir Certificado: En este espacio el

Coordinador de Prácticas Industriales tiene la opción de subir el
certificado que avala el cumplimiento total de las horas asignadas al
estudiante. Este certificado se entrega tras la aprobación de la
empresa donde se realizan las prácticas, la cual certifica que se han
cumplido todas las actividades planeadas. (Ver la siguiente Figura)

Figura 27. Prácticas Industriales – Subir Certificado

 Prácticas 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. Prácticas Industriales – Solicitudes

 Prácticas Industriales - Amonestaciones: La empresa tiene la

oportunidad de enviar amonestaciones al Coordinador de prácticas
dándole a conocer a éste el tipo de inconvenientes que se están
presentando con el practicante asignado. Así mismo da la opción al
Coordinador de responder cada amonestación. (Ver la siguiente Figura)

70
 Figura 29. Prácticas Industriales listado de Amonestaciones

 Prácticas Industriales - Amonestaciones Respondidas: El director de

Prácticas podrá ver la información enviada como respuesta a las
diferentes amonestaciones que hayan realizado las empresas con
practicantes asignados. (Ver la siguiente Figura)

71
 Figura 30. Prácticas Industriales Amonestaciones Respondidas

Las interfaces de prácticas 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 - Identificación de la Empresa: Presenta todo lo

correspondiente al registro de la empresa ante la Universidad,
permitiéndosele cambiar cierta información. (Ver la siguiente Figura)

72
 Figura 31. Solicitud Practicante - Identificación 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 práctica. (Ver la siguiente
Figura)

73
 Figura 32. Solicitud Practicante - Requerimientos

 Solicitud Practicante - Ubicación Estudiante Solicitado: En esta interfaz

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

74
 Figura 33. Prácticas Industriales –Ubicación Estudiante

 Solicitud Practicante - Ubicación Empresa: La empresa dará información

acerca de ubicación geográfica del sitio de prácticas; esto facilita
distinguir establecimientos dentro de empresas multinacionales o con
diferentes sedes dentro del país. (Ver la siguiente Figura)

Figura 34. Solicitud Practicante - Ubicación Empresa

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

Figura 35. Prácticas 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 inscripción. (Ver la siguiente Figura)

76
 Figura 36. Formulario de inscripción

Este módulo tiene una funcionalidad en particular que consiste en que cuando
se termina de diligenciar el formulario en su totalidad, se envía un correo
electrónico al estudiante y varias personas en la universidad las cuales exigen
que se les notifique cada vez que se inscribe alguien nuevo, además, 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 inscripción. Cabe resaltar que una vez finalizado el formulario
como tal, no se puede volver a editar, solo permite descargar la citación 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 realización de la prueba fue repetido en todas las pruebas que se realizaron,
así que a continuación 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
García quien ejercía el rol de Scrum Master, básicamente la prueba consistía
en verificar rigurosamente cada detalle que se debía contemplar en la
actividad, por ejemplo, si la actividad era el desarrollo de una interfaz, se
77
probaba a detalle todos los aspectos que correspondían al diseño que se debía
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 reunión del sprint. Una vez terminada la prueba que se
efectuaba, el Scrum Master determinaba si la actividad estaba cien por ciento
terminada y se podía 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 implementación de la
metodología Scrum, entre las actividades que más se destacan se encuentran
las siguientes:

 Crear Módulo de Gestión 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 módulo que
gestionara las empresas; el módulo comprendía las acciones CRUD
(Create, Read, Update, Delete por sus siglas en inglés) básicas que
debían ser usados al momento de gestionar las empresas, se realizó
una prueba para verificar si efectivamente se realizaban las acciones
que debía.

 Crear Módulo de Finalización de prácticas, 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 consistía en
que efectivamente el módulo se creara según lo planeado, pero además,
que según los parámetros que exige la universidad, esta debía cumplir
con unas exigencias específicas, relacionadas con la fecha en la que se
podía efectuar la finalización de las prácticas y que usuario podía
realizar la finalización.

 Crear Módulo de Valoración de Practicante, esta actividad consistió

en examen que debe diligenciar cada practicante al inicio de las
prácticas y al finalizar las mismas. Se verificó que el módulo cumpliera
con las exigencias que se tenían planteadas respecto a las fechas en las
cuales se debían realizar estas valoraciones.

 Otra actividad que vale la pena mencionar en esta sección 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. Lógicamente, 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 tenían que verificar todas las interfaces en
los 4 navegadores más usados por los usuarios de internet, los cuales
son (Safari, Internet Explorer, Mozilla Firefox y Google Chrome).

 Una de las pruebas más importantes que realizaron fue la de las

actividades que contemplan las Elecciones Estudiantiles, puesto que de
esas interfaces dependía el hecho de que no hubieran fraudes en las

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

 Otra prueba que fue muy importante, fue la de las inscripciones en línea
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 parámetros, uno de los
aspectos que más se probó fue el de envío de correo electrónico por
parte del portal al estudiante y a los directivos de la universidad
notificando la inscripción de nuevos interesados, y el de la generación de
citas para entrevistas personalmente en la universidad, es decir, que el
portal además que inscribía, 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 proseguía a
desarrollar la siguiente que estuviera pendiente en el sprint.

79
 CONCLUSIONES

No existe una metodología que garantice el éxito de un proyecto de desarrollo

de software, pero si metodologías que se adaptan al contexto de proyectos con
más facilidad. Las metodologías tradicionales o clásicas requieren de un mayor
trabajo al querer ser adaptadas a proyectos pequeños y con requisitos
cambiantes, lo que ha generado un creciente interés por metodologías más
flexibles e igual de productivas:

Scrum como metodología ágil presenta todas las características 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 metodología Scrum permitió la elaboración del “frontend” de las aplicaciones
(desarrollo de controladores e interfaces graficas de usuario) que apoyan los
procesos académicos en la Universidad de San Buenaventura – Cartagena,
aportando integridad al equipo de trabajo.

La aplicación de este tipo de metodologías también permite tener una visión

diferente frente al desarrollo de actividades; para Scrum las actividades no son
algo que simplemente se inician y terminan, si no que permite, a través de las
iteraciones, volver a ellas y agregarles nuevos detalles con el fin de que estas
puedan ir en un crescendo haciéndolas cada vez mejor.

También es importante resaltar el enriquecimiento que se puede hacer al tomar

de otras metodologías ciertos aspectos que aportan agregados favorables para
el desarrollo de la metodología. No ceñirse 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 metodologías ágiles evita fases previas de

especificación de requisitos, análisis y diseño, costosas en tiempo así como la
corrección de errores en estas fases, lo que generaría aún más pérdida de
tiempo. Se prescindió del desarrollo de documentos que harían lento el proceso
y poco entendible la globalidad del sistema.

Al finalizar la implementación de la metodología en el Centro de Educación

Virtual, se pudo demostrar con hechos tangibles lo eficiente que pueden llegar
a ser las metodologías 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 mayoría 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 metodologías 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.

ALARCÓN, Pedro P. “Especificación de un modelo de operaciones

aplicable a procesos de desarrollo y operación de sistemas con software”.
PhD thesis, Facultad de Informática. Universidad Politécnica de Madrid.
2008. 120p.

AMARO C., Sarah y Jorge C. Valverde; Metodologías 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 Penadés, M. Metodologías 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 Project’s 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 Computación,
2008. 269p.

GUTIERREZ, Jaoquin. Metodologías á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
Capacitación Inicial de los
Prácticantes
Lineamientos e indicaciones
del software
Distribución de actividades
Ejecución de actividades
Revisión
Ejecución de actividades
Revisión Final de Prácticas
Investigación de factibilidad y
riesgo para la elaboración del
libro planteado sobre SCRUM
como metodología de
desarrollo ideal
Investigación general de la
temática a tratar en los
documentos que se
presentarán
Elaboración de los
documentos
Presentación previa para
revisión
Corrección
Entrega final y sustentación

83
Anexo B. Presupuesto

FUENTE
RUBROS DESCRIPCIÓN CEV Estudiantes
Especie Efectivo
Gastos de 4 Tutores - -
personal 3 Estudiantes - $ 6’335.500.oo
iMac 21” $ 2’450.000.oo -
Equipos y Mac Pro con Cinema
$ 7’132.000.oo -
software Display
Computador HP Quad Core $ 1’835.000.oo -
Materiales y Papelería - $ 200.000.oo
suministros Tóner de impresora - $ 100.000.oo
Servicios Servicio de Computo 600h
$ 8’000.000.oo -
técnicos – 5000h
Otros gastos Imprevistos - $ 1’000.000.oo
TOTALES $ 19’417.000.oo $ 7’635.500.oo

TOTAL DEL PRESUPUESTO $ 27’052.500.oo

84