APLICACIÓN DE LA METODOLOGÍA SCRUM PARA LA …³n de... · Dentro del marco de estas metodologías de desarrollo ágil se encuentra Scrum. Esta se caracteriza por brindar ventajas

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

III

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

IV

CONCLUSIONES 80 REFERENCIAS 81

V

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

VI

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

VII

LISTA DE ANEXOS

Anexo A. Cronograma de Actividades 83 Anexo B. Presupuesto 84

VIII

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.

1

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.

2

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.

3

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.

4

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.

5

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

6

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.

7

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.

8

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

9

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

10

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.

11

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.

12

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.

13

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

14

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.

15

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.

16

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

17

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.

18

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.

19

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.

20

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.

21

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.

22

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

23

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

24

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.

25

3.6 OPERACIONALIZACION DE VARIABLES

VARIABLE DEFINICION DIMENSION INDICADORES

Aplicación 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.

Análisis Suficiente Insuficiente

Diseño Simple Complejo

Implementación Suficiente Insuficiente

Procesos académicos

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

Administrativos Simple Complejo

Académicos Simple Complejo

Base de Datos

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

Almacenamiento Satisfactorio Insatisfactorio

Consulta Satisfactorio Insatisfactorio

Scrum Es una metodología de desarrollo de software ágil que permite obtener aplicaciones utilizando avances iterativos e incrementales.

Aplicativo Satisfactorio Insatisfactorio

Tabla 1. Operacionalización de Variables

26

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.

27

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.

28

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

29

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.

30

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.

31

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

32

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.

33

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

34

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.

35

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

36

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

37

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

38

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.

39

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

40

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-

41

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.

42

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:

43

Realizar Solicitud de Grado

Sub-Actividades Prioridad Tiempo Comentario

Obtención de Requerimientos

Media 4 Horas Ninguno

Tabla 2. Actividad Realizar Solicitud de Grado

Realizar Certificados

Sub-Actividades Prioridad Tiempo Comentario

Definir que certificados se sistematizan

Media 4 Horas Ninguno

Definir procesos de certificados

Media 4 Horas Ninguno

Estudiar Firma Digital

Baja 2 Horas Ninguno

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 Envío de Correo

Alta 6 Horas Enviar por SMPT, sendmail, phpmail

UI envío de correo Media 2 Horas WYSIWYG, array, destinatario POST

Tabla 5. Actividad Ver Perfil del Estudiante

44

Ver Información del Estudiante

Sub-Actividades Prioridad Tiempo Comentario

Agregar el estado del Estudiante

Media 3 Horas Creación HBM, 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 a la UI

Baja 1 Horas Ninguno

Tabla 7. Actividad Mostrar Horario de Clases

Mostrar Semáforo Académico

Sub-Actividades Prioridad Tiempo Comentario

Cambiar Nombre al Módulo

Baja 10 Minutos Ninguno

Agrupar Aprobadas por

semestre

Media 3 Horas Ninguno

Agrupar Cursos Pendientes por

Semestre

Media 3 Horas Ninguna

Agrupar Pensum del Programa

Media 3 Horas Ninguna

Tabla 8. Actividad Mostrar Semáforo Académico

Mostrar Historial de Notas

Sub-Actividades Prioridad Tiempo Comentario

Sincronizar cortes con programación

académica

Urgente 5 Horas Tener en cuenta el nuevo reglamento

institucional

Obtener periodo académico por

GET

Media 2 Horas Ninguna

Tabla 9. Actividad Mostrar Semáforo Académico

45

Realizar Actualización de Datos de Estudiantes

Sub-Actividades Prioridad Tiempo Comentario

Reparar Código JS (jQuery/Ajax)

Urgente 9 Horas Ninguno

Revisar/Reparar que todo guarde

Urgente 6 Horas Ninguno

Colocar como no editables los

campos pertinentes

Media 4 Horas 5 Siempre editable datos personales

6 Cuando no existan datos del nombre del padre y de la madre, será editables

Implementar formulario de

Historial Laboral como MODAL

Baja 2 Horas Ninguno

Implementar formulario de

Historial Académico como

MODAL

Baja 2 Horas Ninguno

Implementar formulario de Estudios de

Idiomas como MODAL

Baja 2 Horas Ninguno

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ó

46

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 Procesos

Baja 4 Horas Ninguna

Tabla 11. Actividad Solicitar Becas y Descuentos

Prácticas Empresariales

Sub-Actividades Prioridad Tiempo Comentario

Crear Solicitud de Practicas

Medio 2 Horas Posterior a la creación de la

solicitud, se debe enviar un Mail al

responsable (Coordinador de

Practicas)

Crear Módulo de Gestión de Empresas

Medio 2 Horas Ninguna

Crear Módulo de Finalización de

Practicas

Medio 5 Horas Ninguna

Crear Módulo de Valoración de

Practicante

Baja 4 Horas Valoración de Inicial y Valoración Final

Crear Módulo para Responder Practicante

Media 5 Horas Este es el módulo en el que el

Coordinador decide en donde se realizará las prácticas de

acuerdo con las solicitudes.

Crear Módulo para Diligenciar Bitácora

por parte del Practicante

Media 5 Horas Ninguna

Tabla 12. Actividad Prácticas Empresariales

47

Persistencia de Acaweb

Sub-Actividades Prioridad Tiempo Comentario

Realizar Active Record Factory

Urgente 11 Horas Ninguna

Realizar Adecuación del

Modelo

Urgente 3 Horas Ninguna

Tabla 13. Actividad Persistencia de Acaweb

Actualización de Datos de Egresados

Sub-Actividades Prioridad Tiempo Comentario

Agregar entidad Reconocimientos

Media 3 Horas Agregar en API, Acaweb y Base de

Datos

Agregar Encuesta a la BD

Baja 1 Hora Ninguna

Realizar UI Actualización de

Datos de Egresados

Urgente 4 Horas Esta vista es muy parecida a la de Actualización de

Datos de Estudiantes, pero con unos datos

adicionales específicos de los

egresados

Agregar Funcionalidad al

Módulo

Urgente 6 Horas Hacer que todo funciones

perfectamente bien

Tabla 14. Actividad Actualización de Datos de Egresados

Imprevistas Sprint 2

Sub-Actividades Prioridad Tiempo Comentario

Cambios en los script en general

Urgente 4 Horas Revisar todos los scripts que utiliza la

página y verificar algunos errores

presentes

Inscripciones en línea provisional

Urgente 8 Horas Realizar un portal provisional de

Inscripciones en línea para los

nuevos estudiantes

48

Implementar un sistema de

validaciones gramaticales

Urgente 8 Horas Implementar un sistema para evitar

que los usuarios introduzcan letras,

símbolos o números cuando no son

permitidos. (Validación de todos

los campos)

Mejorar problemas presentados al

entrar a los portales desde

Internet Explorer

Urgente 6 Horas Garantizar un funcionamiento adecuado en

Internet Explorer de todos las

aplicaciones y servicios que se

están desarrollando

Tabla 15. Actividad Imprevista Sprint 2

Figura 7. Actividades Sin Planeación

49

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 Gestión de Empresas

Urgente 2 Horas Ninguna

Crear Módulo de Finalización de

Practicas

Urgente 5 Horas Ninguna

Crear Módulo de Valoración de

Practicante

Urgente 4 Horas Valoración de Inicial y Valoración

Final

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

Matrícula en línea

Sub-Actividades Prioridad Tiempo Comentario

Realizar Diagrama de Actividades

Media 4 Horas Ninguna

Realizar UI de la matrícula en línea

Media 4 Horas Ninguna

Obtención de Pre-matrícula

Urgente 3 Horas Calcular la pre-matrícula del estudiante de

acuerdo al semestre, las materias que ha perdido

y al reglamente

Agregar Auditoria Medio 3 Horas Ninguna

50

Agregar y validar Cursos

Urgente 8 Horas Ninguna

Revisar Seguridad

Urgente 8 horas Ninguna

Obtener Cursos Habilitados

Urgente 6 Horas Ninguna

Guardar Matricula Urgente 7 Horas Ninguna

Tabla 17. Actividad Matrícula en línea

Portal Docentes

Sub-Actividades Prioridad Tiempo Comentario

Obtener Calendario de los

cortes (API)

Urgente 3 Horas Ninguna

Funcionalidad del Módulo

Urgente 4 Horas Ninguna

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

Datos

Medio 4 Horas Es Similar a la de estudiantes y

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

51

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 de los widgets

Medio 5 Horas Pestañas, botones, campos

de texto, entre otros.

Realizar cambios necesarios para

la interoperabilidad

entre los navegadores web

Urgente 10 Horas Debe funcionar en Internet Explorer

(7 - más reciente), Firefox (3 – más

reciente) y Google Chrome. Revisar

CSS, JS y atributos

especiales.

Reestructurar Tamaño de los

campos de texto

Bajo 3 Horas Implementar varios tamaños y estandarizarlos.

Rediseñar las pestañas

Bajo 3 Horas Ninguna

Editar formulario de envió de

correo

Medio 5 Horas Agregar la posibilidad de 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

52

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 PDF con la cita de la entrevista

Medio 3 Horas Ninguna

Generador de PDF con la cita para la prueba Psicotécnica

Medio 3 Horas Solo para los estudiantes de

Psicología

Agregar Funcionalidad al

Módulo

Medio 5 Horas 5 Posibilidad de completar parcialmente el proceso de inscripción.

6 Envío de Correo electrónico al terminar la inscripción.

Realizar validaciones adicionales

Medio 3 Horas Para garantizar aún más la

funcionalidad en los distintos

navegadores.

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

Modificaciones Portal Egresados

Sub-Actividades Prioridad Tiempo Comentario

53

Modificaciones en la

actualización de egresados

Medio 3 Horas Surgieron unos inconvenientes a la hora de guardar los

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 Funcionalidad al

Módulo

Medio 4 Horas Garantizar la funcionalidad en

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.

54

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

55

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)

56

Figura 10. Actualizar Mis Datos – Datos Familiares

57

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

58

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)

59

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)

60

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)

61

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

62

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

63

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

64

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

65

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)

66

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)

67

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)

68

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

69

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)

70

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)

71

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)

72

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)

73

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)

74

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)

75

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

76

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)

77

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

78

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

79

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.

80

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.

81

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.

82

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.

83

Anexo A. Cronograma de Actividades

2011 2012

TIEMPO

ACTIVIDADES

AGOSTO SEPTIEMBRE OCTUBRE NOVIEMBRE FEBRERO MARZO ABRIL MAYO

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

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

84

Anexo B. Presupuesto

RUBROS DESCRIPCIÓN

FUENTE

CEV Estudiantes

Especie Efectivo

Gastos de personal

4 Tutores - -

3 Estudiantes - $ 6’335.500.oo

Equipos y software

iMac 21” $ 2’450.000.oo -

Mac Pro con Cinema Display

$ 7’132.000.oo -

Computador HP Quad Core $ 1’835.000.oo -

Materiales y suministros

Papelería - $ 200.000.oo

Tóner de impresora - $ 100.000.oo

Servicios técnicos

Servicio de Computo 600h – 5000h

$ 8’000.000.oo -

Otros gastos Imprevistos - $ 1’000.000.oo

TOTALES

$ 19’417.000.oo $ 7’635.500.oo

TOTAL DEL PRESUPUESTO $ 27’052.500.oo