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

Transcripción

1 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

2 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

3 CONTENIDO RESUMEN VIII 1. PROBLEMA DE INVESTIGACION PLANTEAMIENTO DEL PROBLEMA FORMULACION DEL PROBLEMA JUSTIFICACION OBJETIVOS Objetivo general Objetivos específicos 6 2. MARCO DE REFERENCIA MARCO HISTORICO INVESTIGACIONES PREVIAS MARCO TEÓRICO Scrum Sistemas de información Lenguajes de Programación Html (HyperText Markup Language) Php (PHP HyperText Pre-processor) Base de datos JavaScript Metodología Tradicional MARCO CONCEPTUAL DISEÑO METODOLOGICO TIPO DE INVESTIGACION DISEÑO ADOPTADO ENFOQUE DE LA METODOLOGIA TECNICAS DE RECOLECCION DE LA INFORMACION Fuentes primarias Fuentes secundarias VARIABLES OPERACIONALIZACION DE VARIABLES PROCESAMIENTO DE LA INFORMACION RECURSOS TECNOLOGICOS El Paradigma de Programación Herramienta de Desarrollo de Software Herramientas Software Herramientas de Diseño Herramientas Hardware RESULTADOS API: PUNTO DE PARTIDA COMO FUENTE DE SERVICIOS REQUERIMIENTOS Product Backlog ITERACIONES DE IMPLEMENTACION DE LOS PRODUCTOS Exposición del Product Backlog Resolución del Sprint Backlog Revisión del Sprint DISEÑO Y DESARROLLO DE INTERFACES EJECUCION DE PRUEBAS 77 III

4 CONCLUSIONES 80 REFERENCIAS 81 IV

5 LISTA DE TABLAS Tabla 1. Operacionalización de Variables 25 Tabla 2. Actividad Realizar Solicitud de Grado 43 Tabla 3. Actividad Realizar Certificados 43 Tabla 4. Actividad Realizar Matricula Académica 43 Tabla 5. Actividad Ver Perfil del Estudiante 43 Tabla 6. Actividad Ver Información del Estudiante 44 Tabla 7. Actividad Mostrar Horario de Clases 44 Tabla 8. Actividad Mostrar Semáforo Académico 44 Tabla 9. Actividad Mostrar Semáforo Académico 44 Tabla 10. Actividad Realizar Actualización de Datos de Estudiantes 45 Tabla 11. Actividad Solicitar Becas y Descuentos 46 Tabla 12. Actividad Prácticas Empresariales 46 Tabla 13. Actividad Persistencia de Acaweb 47 Tabla 14. Actividad Actualización de Datos de Egresados 47 Tabla 15. Actividad Imprevista Sprint 2 48 Tabla 16. Actividad Prácticas Empresariales (Actividades sin Resolver) 49 Tabla 17. Actividad Matrícula en línea 50 Tabla 18. Actividad Portal Docentes 50 Tabla 19. Actividad de Refactor 51 Tabla 20. Actividad Inscripciones en línea (Versión Definitiva) 52 Tabla 21. Actividad Modificaciones Portal Egresados 53 Tabla 22. Actividad Portal de Elecciones Institucionales 53 V

6 LISTA DE FIGURAS Figura 1. Modelo general de la metodología Scrum 13 Figura 2. Interacción en arquitectura de capas 30 Figura 3. Vista de la arquitectura lógica implementada en el sistema de información de la Universidad de San Buenaventura, Cartagena. 31 Figura 4. Product Backlog del Desarrollo 36 Figura 5. Sprint Backlog del Desarrollo 40 Figura 6. Avance de un Sprint 41 Figura 7. Actividades Sin Planeación 48 Figura 8. Página de Inicio 54 Figura 9. Actualizar Mis Datos Datos Básicos 55 Figura 10. Actualizar Mis Datos Datos Familiares 56 Figura 11. Actualizar Mis Datos Historial Laboral 57 Figura 12. Actualizar Mis Datos Historial Académico 57 Figura 13. Actualizar Mis Datos Idiomas 58 Figura 14. Ver Mis Datos Información Personal 59 Figura 15. Ver Mis Datos Información de Contacto 60 Figura 16. Prácticas Industriales- Bitácora 61 Figura 17. Prácticas Industriales Descargar Certificado 61 Figura 18. Actualizar Mis Datos Datos Básicos 62 Figura 19. Actualizar Mis Datos Información Laboral 63 Figura 20. Actualizar Mis Datos Información Académica 64 Figura 21. Actualizar Mis Datos Idiomas 64 Figura 22. Actualizar Mis Datos Datos Complementarios 65 Figura 23. Módulo Docentes Horario 66 Figura 24. Elecciones Estudiantiles Formulario de Inscripción 67 Figura 25. Elecciones Estudiantiles Admisión 68 Figura 26. Elecciones Estudiantiles Votación 68 Figura 27. Prácticas Industriales Subir Certificado 69 Figura 28. Prácticas Industriales Solicitudes 70 Figura 29. Prácticas Industriales listado de Amonestaciones 71 Figura 30. Prácticas Industriales Amonestaciones Respondidas 72 Figura 31. Solicitud Practicante - Identificación de la Empresa 73 Figura 32. Solicitud Practicante - Requerimientos 74 Figura 33. Prácticas Industriales Ubicación Estudiante 75 Figura 34. Solicitud Practicante - Ubicación Empresa 75 Figura 35. Prácticas Industriales Ver Solicitudes 76 Figura 36. Formulario de inscripción 77 VI

7 LISTA DE ANEXOS Anexo A. Cronograma de Actividades 83 Anexo B. Presupuesto 84 VII

8 RESUMEN El éxito del desarrollo de software no depende exactamente de las herramientas y las notaciones de modelado; tal vez tampoco sea garantía los conocimientos que manejen el grupo de desarrolladores; ni tampoco la metodología que se siga en el desarrollo de los mismos. El éxito está sin duda en la mezcla de estos tres ítems y de su adaptación continua al entorno en el que esté inmersa la aplicación. El presente proyecto muestra el desarrollo de aplicaciones, en su parte de interfaz de usuario, empleando Scrum como metodóloga de desarrollo. Para esto se describen las necesidades que se dan en un entorno particular, la Universidad de San Buenaventura Cartagena, y los requerimientos funcionales y no funcionales de la aplicación. La proliferación de metodologías ágiles despertó en el equipo de desarrolladores, el deseo de mostrar las ventajas de esta nueva forma de guiar el desarrollo de aplicaciones de forma rápida, con fácil adaptabilidad y para grupos pequeños. Scrum se presenta como una metodología que puede ser utilizada con seguridad de éxito en cuanto genera agrado del grupo de desarrollo y del cliente, siendo a satisfacción de este último la garantía de éxito de cualquier aplicación. Como profesionales en el área de ingeniería se debe, más que encontrar una solución a una dificultad, dar una serie de posibles soluciones, que dependiendo de las circunstancias y los limitantes, obtenga de forma óptima el mejor resultado a determinada situación. VIII

9 INTRODUCCION Con la aparición de la computación digital, inicio el periodo de más desarrollo tecnológico jamás visto por la humanidad: viajes espaciales, telecomunicaciones, Internet, entre otros. Un elemento de importancia en este desarrollo de tecnologías lo ha constituido el software, el cual facilita el manejo del hardware. El software, definido como un conjunto de instrucciones que controlan la realización de tarea de un hardware, puede dividirse en varias categorías basadas en el tipo de trabajo que realizan. Las dos categorías primarias de software son, los Sistemas Operativos que controlan los trabajos del computador como el mantenimiento de los archivos del disco y la administración de la pantalla, y el software de aplicación que dirige las distintas tareas para las que se utilizan el computador como edición de textos, gestión de bases de datos y similares. Los desarrollos de hardware y software han sido muy dinámicos a la vez que requieren de procesos cada vez más complejos de producción. Seguir una metodología no apropiada para el desarrollo puede llevar a consumir demasiados recursos de tiempo o dinero, a la vez que se corre el riesgo de no llenar las expectativas que tenía el cliente con respecto al producto o desarrolladores insatisfechos con el mismo. Encontrar y seguir la metodología adecuada para el tipo de desarrollo, marca el éxito del software. La utilización de las llamadas metodologías tradicionales en el desarrollo de software (Cascada, RUP, entre otras), caracterizadas por la implementación de etapas secuenciales ejecutadas unas después de otras, guiadas por una planificación rígida, con lo que pretende controlar todo el proceso (planificación, diseño, implementación, evaluación), son aplicadas cada vez menos en ambientes de desarrollo de software. En contraposición, las metodologías agiles han despertado un creciente interés, que las ha llevado a campos diferentes al de la ingeniería de software. Dentro de las diferentes propuestas de mejora al desarrollo secuencial se encuentra Scrum. Éste es una técnica de desarrollo caracterizada por integrar características de las metodologías ágiles a los que se añaden la implementación de iteraciones denominadas Sprint, que deja como resultado un incremento ejecutable que se pueden mostrar al cliente y reuniones diarias de 15 minutos a los largo del ciclo del Sprint, que permite al equipo autorregularse, coordinarse e integrarse. El interés del presente proyecto gira entorno a desarrollos logrados siguiendo metodologías de desarrollo ágil: específicamente Scrum. A lo largo del trabajo se muestra la implementación y resultados logrados a partir de esta metodología de trabajo, dentro de la elaboración de frontend de las aplicaciones (desarrollo de controladores e interfaces graficas de usuario) de procesos académicos en la Universidad de San Buenaventura Cartagena. 1

10 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 adicionales 1. 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 flexibilidad 2. 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 pp Grupo ISSI. Metodologías Ágiles en el Desarrollo de Software. Editorial Alicante. España, 12 de Noviembre de pp Grupo ISSI. Metodologías Ágiles en el Desarrollo de Software. Editorial Alicante. España, 12 de Noviembre de pp

11 que se desea implantar, ya sea presencial o virtual, teniendo como objetivo el desarrollo de frontend de las aplicaciones que permitirán: acceso a la información personal de docentes y estudiantes, administración de notas estudiantiles, portal para el manejo de prácticas industriales y portal de votaciones estudiantiles (inscripción de candidatos y votaciones). Estos servicios que se encuentran desacoplados requieren un proceso de optimización que permita el manejo digital de la información a través de una plataforma acoplada accesible desde Internet. En la actualidad, a nivel organizacional y operativo estos servicios presentan deficiencias en su prestación, tales como: la falta de una plataforma amena, intuitiva y práctica que permita presentar y recibir información de los usuarios; desarrollos que brindan servicios a partir de la información guardada en las bases de datos de la Universidad que son redundante e insuficientes; la lógica de negocio aún se encuentra en etapa de diseño y se ajusta a las políticas cambiantes y poco definidas que establece la Institución para tal fin. La poca sinergia que se presenta entre los servicios prestados por las aplicaciones existentes en la Institución, conlleva a que no se logre una integración con el sistema en desarrollo. Teniendo en cuenta esto, la finalidad del CEV es implementar un sistema que integre servicios como: Manejo de estudiantes, la administración de prácticas industriales, la gestión de notas, la conducción de las elecciones estudiantiles; implementación que no se ha podido lograr debido al uso de metodologías de desarrollo tradicionales que han causado retrasos en los tiempos de entrega de módulos que dan soporte al funcionamiento del mismo. El seguimiento de metodologías de desarrollo de software poco adaptadas a la realidad que vive el CEV crea inconveniente como es la de priorizar las actividades según el grado de importancia que tienen para el buen funcionamiento del sistema. A su vez se requiere responder a los cambios en el diseño o requerimientos del sistema, que surgen a lo largo del proyecto, lo cual genera un atraso constante en los desarrollos alcanzados ya que demanda nuevas correcciones y nuevas funcionalidades al software como tal. Teniendo en cuenta lo anterior, se requiere optimizar las diferentes herramientas académicas de apoyo requeridas por el CEV, a través de la metodología Scrum, desarrollando software rápidamente y respondiendo a los diferentes requerimientos en la implementación de los mismos (en los requisitos, en la tecnología). Teniendo en cuenta estos aspectos, el proyecto ejecutado en el CEV fue dividido en dos fases: Fase uno, elaboración de una API (Interfaz de programación de aplicaciones Application Programming Interface por sus siglas en ingles) que integra los servicios utilizados para la obtención de datos que la Institución posee de los estudiantes y docentes, simplificando la manera para consumir dichos servicios, también se creó un framework de desarrollo (Underscore), que fuese capaz de integrarse con el gestor de contenidos Joomla! y brindara un sencillo método para realizar aplicaciones para el mismo. Esta fase está a cargo en su totalidad por el equipo de trabajo del CEV. 3

12 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 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 realizadas 3, 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,

13 La elaboración de un manual de implementación reflejará en detalle el desarrollo de aplicaciones utilizando la metodología SCRUM a partir de los casos de éxito vividos por el equipo dentro del CEV. Esto permitirá a futuros desarrolladores inexpertos seleccionar metodologías que garanticen la satisfacción del cliente pero también la de ellos mismos, marcando el éxito en el desarrollo del software, y evitando dudar al escoger la metodología adecuada, o algo todavía peor, se prescindirá de estar ensayando con metodologías adaptadas a circunstancias particulares, que pudiesen malograr el objetivo final. Se busca demostrar que el uso de la metodología Scrum, proporcionará un desarrollo rápido de aplicaciones requeridas por el sistema de información del CEV de la Universidad de San Buenaventura, aportando herramientas de apoyo de importancia para el desempeño académico. Las ventajas que se podrán comparar con otras metodologías son la satisfacción del cliente por continuas y tempranas entregas de producto, la facilidad de responder a los cambios en diseño, contenido o funcionalidad del sistema, la interacción continua con el cliente que facilita la captura de nuevos requerimientos y la autorregulación que surge del mismo grupo de desarrolladores. Las herramientas académicas de apoyo desarrolladas a partir de la metodología Scrum comprendida en la Fase 2 y que son de competencias de los desarrolladores de este proyecto, permitirá ofrecer a los usuarios finales el acceso a través de la interfaces a los servicios proporcionados por la Universidad de San Buenaventura, a través del desarrollo de los frontend de las aplicaciones obtenidos en esta fase como lo son: inscripción y actualización de información de estudiantes, administración de prácticas industriales, gestión de notas, portal de egresados y portal para el manejo de las elecciones estudiantiles La viabilidad técnica del proyecto se da porque se cuenta con el capital humano capacitado en temas de ingeniería de software y con conocimientos avanzados en Bases de Datos, Lenguaje de programación y metodología del estudio; los recursos económicos que serán invertidos no presentan costos elevados y son medianamente financiables por parte de los investigadores, siendo los equipos y elementos de desarrollo facilitados por CEV de la Universidad de San Buenaventura seccional Cartagena. La importancia que tiene el producto garantiza el ingreso de aportes de la principal beneficiada con el desarrollo del mismo, en este caso, el de la Universidad de San Buenaventura Seccional Cartagena. El desarrollo de este proyecto está enfocado bajo la perspectiva franciscana de la Universidad de San Buenaventura, planteada en el PEB, la cual expone la importancia de la investigación como herramienta para el desarrollo de las ciencias y la tecnología informática. Se fomenta el desarrollo de la misma a través actividades de formación y de procesos que involucren cultivar aptitudes 5

14 y capacidades intelectuales que permitan inferir, deducir y elaborar conceptos de carácter investigativo OBJETIVOS Objetivo general. Implementar la Metodología Scrum para la Optimización de Procesos Académicos en la Universidad de San Buenaventura, Cartagena 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

15 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, autoorganizativos y sin elementos innecesarios, y que ya había sido utilizado por estos últimos. A partir del trabajo realizado por Hirotaka Takeuchi e Ikujijo Nonaka, Jeff Sutherland aplicaría los principios de Scrum al desarrollo de Software en 1993 en Easel Corporation (actual Ascential Software Corporation), publicando en 1996 junto con Ken Schwaber, las prácticas que empleaba como válidas para gestionar el desarrollo de software OOPSLA 96 (Schwaber & Sutherland, 1996). Paralelo a este proceso, a mediados de los 90, se dio la definición de desarrollo ágil de software como una forma de contravenir hasta ese momento las metodologías clásicas, las cuales se consideraban excesivamente pesadas y rígidas por su carácter normativo y dependencia fuerte de las planificaciones detalladas. Fue así como en 2001 miembros destacados de la comunidad de software, creadores e impulsores de las nuevas metodologías de desarrollo, de los cuales hacían parte Schwaber y Sutherland, bautizaron la nueva corriente de metodologías de desarrollo como Metodologías Agiles. En el mismo año 2001 fue constituida la Alianza agil, una organización sin animo de lucro que promueve el desarrollo ágil de aplicaciones y del que Scrum hace parte como modelo para gestionar el desarrollo de software. 7

16 2.2 INVESTIGACIONES PREVIAS El desarrollo de esta investigación servirá como referencia a nuevos proyectos de grados e investigaciones que sugieran o se encaminen en el manejo de la metodología SCRUM. Así como las investigaciones y tesis colocadas como referencias en este documento sirvieron de apoyo para lograr entender cómo ha evolucionado esta metodología en países como España, Colombia, entre otros países latinoamericanos. A continuación se presenta una breve descripción de los proyectos similares a la investigación. Sergio Adrian Yazyi, Salamanca España en el año de 2011, presento en la Universidad De Salamanca, una investigación que lleva como título Una experiencia práctica de Scrum a través del aprendizaje basado en proyectos mediado por TIC en un equipo distribuido, el cual plantea dentro de su documentación: Scrum es un marco de trabajo para la gestión ágil de proyectos de creciente interés en distintos campos de aplicación. Para asimilar sus principios y prácticas no basta una formación conceptual sino que es necesario utilizar un enfoque práctico que permita ejercitarlo a través del aprender haciendo. Este estudio se convierte en punto de apoyo ya que se estudia la implementación de Scrum en contextos distinto al del desarrollo del software, exponiéndose los logros alcanzados durante la aplicación de esta metodología, corroborando la información obtenida durante el desarrollo del actual proyecto. A su vez Juan Palacios en Colombia, en Octubre de 2008, presentó un proyecto o documento investigativo sobre la implementación de Scrum llamado Flexibilidad con Scrum Principios de diseño e implantación de campos de Scrum Adaptando los procesos a la empresa en el cual se hace mención de empresas observadas por Nonaka y Takeuchi, mostrando en éstas las características que luego pasarían a formar parte de lo hoy se conoce como Scrum. Estas características son tratadas al detalle, terminando con consejos prácticos que permiten llevar estas mismas cualidades a campos como el marketing, proyectos empresariales y procesos de producción. De igual Juan Garbajosa Sopeña y Pilar Rodríguez González en España - Madrid, Septiembre de 2008, presentaron Tesis de Master sobre tecnologías de la Información íntimamente relacionada con Scrum llamada Estudio de la Aplicación de Metodologías Agiles para la Evolución de Productos Software ; la tesis presentada hace referencia a Scrum como núcleo principal y se concentra principalmente, a nivel de las personas y equipo de desarrollo que construye el producto. Su objetivo es que los miembros del equipo trabajen juntos y de forma eficiente obteniendo productos complejos y sofisticados. Se podría entender Scrum como un tipo de ingeniería social que pretende conseguir la satisfacción de todos los que participan en el desarrollo, fomentando la cooperación a través de la auto-organización. De esta forma, se favorece la franqueza entre el equipo y la visibilidad del producto. Pretende que no haya problemas ocultos, asuntos u obstáculos que puedan poner en peligro el proyecto. Los equipos se guían por su conocimiento y experiencia más que por planes de proyecto formalmente definidos. La planificación detallada se realiza sobre cortos espacios de tiempo lo que permite una 8

17 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 Scrum. En el transcurrir del tiempo las sociedades siempre han subexistido gracias a su habilidad de poder crear procedimientos racionales utilizados para alcanzar una gama de objetivos que rigen en una investigación científica o tareas que requieran habilidades, conocimientos o cuidados específicos. Alternativamente puede definirse que una metodología es el estudio o elección de un procedimiento pertinente para alcanzar un determinado objetivo. Algunas de estas metodologías han venido siendo iguales o han tenido sus cambios respectivos según la situación lo amerite, ya que se hacen presentes diferentes factores como el tiempo, eficacia, dinero, requerimientos, entre otros. Existen metodologías que han venido acompañando el avance tecnológico desde sus inicios y más en el desarrollo de software. Tanto así que han proporcionado la manera de solucionar situaciones de forma práctica obteniendo así los resultados esperados en menos tiempo. Este ha sido uno de los objetivos principales de los programadores, para hacer que la información sea utilizada en cualquier hora y lugar. Las metodologías han sido utilizadas para la realización de proyectos tecnológicos y científicos desde su invención, consideradas como un proceso de planificación, la cual consiste en un conjunto de actividades que se encuentran interrelacionadas y coordinadas. La razón de un proyecto es 9

18 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 proyecto 5. 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/ágiles 6. 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 desarrollador 7. 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ú, Palacio, Juan. Flexibilidad con Scrum. Disponible en consultado el 23 de marzo de Ibíd., pp

19 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 mismo 9. 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 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 capacidades 11. 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ú, Ibíd., pp PALACIOS, Juan ; El Modelo Scrum PDF 2006; Pg.2,, Capitulo 1. Disponible en Consultado el 18 de Marzo de Ibíd. 11

20 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? realizadas en un día. Es decir, tareas 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 ; pp. 20. Disponible en Consultado el 22 de Marzo de

21 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 Sprint 14. 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 valor 15. 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 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 ; Pg. 22. Disponible en Consultado el 22 de Marzo de Rodriguez Gonzalez, Pilar. Estudio De La Aplicación De Metodologías Agiles Para La Evolución De Productos Software. Universidad Politecnica de Madrid. Madrid PALACIOS, Juan ; El Modelo Scrum PDF 2006; pp.2, Capitulo 1. Disponible en Consultado el 18 de Marzo de

22 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 Sistemas de información 17. 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

23 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 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 tecnicas/informatica-ingeniero-tecnico-en-obras-publicas/contenidos/course_files/temas/tema_7_- _Lenguajes_de_Programacion.PDF, consultado el 03 Junio de

24 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 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 Consultado el 03 de Junio de

25 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 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 Consultado el 03 de Junio de

26 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 Base de datos 21. 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 consultado el 30 de abril de

27 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 JavaScript 22. 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: consultado el 25 de junio de

28 registrada de la empresa Sun Microsystems, como se puede ver en 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 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 Metodología Tradicional. Aquellas metodologías de desarrollo con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado. Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada. Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar. 2.4 MARCO CONCEPTUAL PRODUCT BACKLOG: en la estructura organizacional que se define al principio del proyecto y contiene todos los requerimientos funcionales y no funcionales que deberá satisfacer el sistema a construir. Los mismos estarán especificados de acuerdo a las convenciones de la organización ya sea mediante: features (características), casos de uso, diagramas de flujo de datos, incidentes, tareas, etc. El Product Backlog será definido durante reuniones de planeamiento con los stakeholders. FEEDBACK: es un proceso utilizado para la comparación y afirmación de los conocimientos adquiridos durante una actividad. STAKEHOLDERS: son las otras personas interesadas en el proyecto y que pueden realizar aportes significativos para el mismo. SPRINT: A partir del Product Backlog se definirán las iteraciones, conocidas como Sprint en la juerga de Scrum, en las que se irá evolucionando la aplicación evolutivamente. Cada Sprint tendrá su propio Sprint Backlog que será un subconjunto del Product Backlog con los requerimientos a ser construidos en el Sprint correspondiente. La duración recomendada del Sprint es de un mes. 20

29 PROTOTIPO: es el resultado que produce un sprint y se generan con el fin de ir evolucionando el software a medida en que el proyecto avanza, para de ese modo, poder ver constantemente que el trabajo que se va realizando está generando frutos. PRODUCT OWNER: representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. SPRINT PLANNING: es el momento de planificación de actividades a realizar o concluir durante el Sprint. SCRUM MASTER: tambien conocido como facilitador, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. Es quien hace que las reglas se cumplan. TEAM: conocido también como Equipo, tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo. ITERACION: es la repetición de una serie de instrucciones en un programa de computador. Puede usarse tanto como un término genérico (como sinónimo de repetición) así como para describir una forma específica de repetición con un estado mutable APLICACION SOFTWARE: es un programa diseñado para automatizar una determinada tarea. Consta de una serie de instrucciones lógicas y en orden, con el fin de cumplir un objetivo. 21

30 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ínimo 23. 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 particular 24. 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ólidas 25. 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 Ibíd., p Ibíd., p

31 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 Fuentes primarias. Las fuentes primarias aportan datos a la investigación, buscando recopilar información acerca del tema que se está analizando. En la presente investigación la principal fuente de información serán los artículos de revistas que hagan referencia a la metodología Scrum, así como apartados periodísticos, entrevistas realizadas a expertos, tesis y disertaciones que toquen temas relacionados con este tipo de metodología. También se contará con la colaboración del Ingeniero Javier García Altamiranda, Coordinador Tecnológico del CEV, así como de los desarrolladores vinculados al CEV. La información pertinente para el correcto desarrollo de este proyecto se obtuvo a través de la asesoría continua del Coordinador Tecnológico como gestor de la idea de implementar Scrum y su posterior orientación en el desarrollo del mismo buscando mejorar el índice de desarrollo de software. La información acerca de la lógica de negocio se consignará en las historias de usuario; la elaboración de éstas se realizará en reuniones que integrarán al equipo desarrollador y el Ingeniero Javier García a lo largo de todo el desarrollo del proyecto, desempeñando dos roles bien definidos: como representante del cliente y como Scrum Manager. El papel que da ser representante del cliente permite obtener la visión general del producto, creando a partir de éstas el Product Backlog o lista de tareas que se van a realizar, determinándose los requisitos que el software debe realizar para dar respuesta a las funcionalidades esperadas por el cliente. El Product Backlog representa todo aquello que esperan los clientes y usuarios que tenga el software. La elaboración del Product Backlog se da como resultado de una reunión cruzada entre el representante del cliente y el equipo desarrollador antes de iniciar la planeación de los Sprint. Pero no es un producto terminado sino que estará en continua evolución y crecimiento mientras el producto esté en 23

32 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 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ón 26. 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 /2008/02/29/investigacion-cualitativa/. Consultado el 26 de marzo de

33 3.6 OPERACIONALIZACION DE VARIABLES VARIABLE DEFINICION DIMENSION INDICADORES Aplicación Análisis Suficiente Software Insuficiente 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. Diseño Implementación Simple Complejo 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 Académicos Simple Complejo 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 Consulta Satisfactorio Insatisfactorio 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 25

34 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 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 ORTEGA MONTALVO, Nohora y otro. Desarrollo de un aplicativo web para apoyar el análisis estructural del proceso prospectivo en las organizaciones. Universidad de San Buenaventura Cartagena, Colombia. 26

35 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 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 Herramientas Software. A continuación se describen las herramientas que se utilizaron en el proceso. 28 Ibíd. 27

36 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 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 Herramientas Hardware. Las herramientas hardware fueron las descritas a continuación. Para la construcción del sistema de información se utilizaran las siguientes configuraciones mínimas en cuanto al rendimiento que deberá tener el equipo utilizado para el desarrollo del software: Procesador de 3 GHz, doble núcleo. 3GB DDR2 de Memoria RAM. 250GB de espacio en disco. Tarjeta Aceleradora de Video de 512MB DDR2. Sistema operativo Microsoft Windows 7. Para que el usuario use el sistema con buenas respuestas en cuanto a la fluidez del mismo, se calcula que será menor el requerimiento que necesitara, a continuación se muestra las configuraciones mínimas necesarias para que el sistema funcione en recomendables condiciones. Procesador de 2.8GHz. 2GB DDR2 de Memoria RAM. 250GB de espacio en disco. Sistema operativo Microsoft Windows XP, Vista ó 7. 28

37 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 sistema 29. 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 ventajas 30 : Localizar los cambios de un tipo en una parte de la solución minimiza el impacto en otras partes, reduce el trabajo requerido en arreglar defectos, facilita el mantenimiento de la aplicación y mejora la flexibilidad general de la aplicación. La separación de responsabilidades entre componentes (por ejemplo, separar la interfaz de usuario de la lógica de negocio, y la lógica de negocio del acceso a la base de datos) aumenta la flexibilidad, la mantenibilidad y la escalabilidad. 29 Guía Arquitectura N-Capas Orientada al Dominio - Microsoft Architecture (1a Edición Noviembre 2010) 30 Ibíd. 29

38 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 Arquitectura 31. Figura 2. Interacción en arquitectura de capas La gestión de dependencias escogido para el diseño de las aplicaciones es laxo en tanto que permite que los componentes de una capa pueden interactuar con cualquier otra capa de nivel inferior. Esto mejora el rendimiento porque el sistema no tiene que realizar redundancia de llamadas de unas capas a otras. 31 Ibíd. 30

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

40 A continuación se describen las diferentes capas en que encuentra dividida la arquitectura lógica del sistema de información de la Universidad de San Buenaventura (ver figura 3), la cual da una visión global y permite comprender mejor todo el sistema: Capa de Presentación: Esta capa es responsable de los componentes visuales que se muestran al usuario. Los componentes han sido divididos en módulos, los cuales implementan las funcionalidades requeridas para que los usuarios interactúen con la aplicación. Los componentes de esta capa han sido divididos en: Componentes Visuales (vistas): Estos componentes proporcionan el mecanismo base para que el usuario utilice la aplicación. Son componentes formados por los datos guardados en base de datos y suministrados a través de los controladores; otra parte de los componentes está constituida por los recibidos por el usuario. Controlador: Es un subcapa encargada de sincronizar y orquestar las interacciones del usuario, siendo útil para conducir el proceso separando los componentes propiamente gráficos de la lógica de negocio, impidiendo que el flujo de proceso y lógica de gestión esté programada dentro de los propios controles y formularios visuales, permitiendo reutilizar dicha lógica desde otra interfaces o vistas. Componentes/Aspectos Horizontales de la Arquitectura: Proporcionan capacidades técnicas genéricas que dan soporte a capas superiores. En definitiva, son bloques de construcción ligados a una tecnología concreta para desempeñar sus funciones. Existen muchas tareas implementadas en el código de una aplicación que se deben aplicar en diferentes capas. Estas tareas o aspectos horizontales (Transversales) implementan tipos específicos de funcionalidad que pueden ser accedidos/utilizados desde componentes de cualquier capa. Los diferentes tipos/aspectos horizontales más comunes, son: Seguridad (Autenticación, Autorización y Validación) y tareas de gestión de operaciones (políticas, logging, trazas, monitorización, configuración, etc.). Capa Service (Aplicación): Esta capa no contiene reglas del dominio o conocimiento de la lógica de negocio, simplemente debe realizar tareas de coordinación de aspectos tecnológicos de la aplicación que nunca se explicarían al propietario del producto. Es una capa que brinda servicios que coordinan otros llamadas a otros servicios, siendo su principal beneficiario la capa de presentación. Un ejemplo lo constituiría un servicio ofrecido a la capa de aplicación, éste coordinará las llamadas a la los servicios que brinda la capa de Dominio y posteriormente las realizadas a Repositorios para realizar la persistencia. 32

41 La capa Service se convierte en una Capa Fachada, sin la cual no se pueden utilizar los servicios que brindan otras capas de la aplicación. Por esto, en esta misma capa, pero solapada se encuentra la capa de Seguridad: nada puede se consumido y nada podrá acceder a la aplicación sin haber hecho uso de esta capa. Capa Component (Modelo de Dominio): Esta capa es responsable de representar conceptos de negocio, información sobre la situación de los procesos de negocio e implementación de las reglas del dominio. También debe contener los estados que reflejan la situación de los procesos de negocio. Esta capa, Dominio, es el corazón del software. Así pues, estos componentes implementan la funcionalidad principal del sistema y encapsulan toda la lógica de negocio relevante. Básicamente suelen ser clases en el lenguaje seleccionado que implementan la lógica del dominio dentro de sus métodos. Para conseguir la máxima independencia de los objetos del Dominio, las entidades del dominio se han implementado como clases POCO. Estas dan ventajas como independencia de las entidades con respecto a tecnologías concretas siendo clases relativamente ligeras con buen rendimiento y adecuadas en implementaciones N-Capas. Esta capa ignora completamente los detalles de persistencia, siendo éstas realizadas por la capa de infraestructura. El consumo de datos se realiza mediante contratos o interfaces que ofrece los objetos del repositorio. Capa de Data y Model (Infraestructura de Persistencia de Datos): La capa de infraestructura contiene todo lo ligado a la tecnología e infraestructura sobre la cual se construye la aplicación. Esta capa proporciona la capacidad de persistir datos así como lógicamente acceder a ellos. Pueden ser datos propios del sistema o incluso acceder a datos expuestos por sistemas externos (Base de datos alternas). Así pues, esta capa de persistencia de datos expone el acceso a datos a las capas superiores, normalmente las capas del dominio. Esta exposición deberá realizarse de una forma desacoplada. Un componente importante dentro de la capa de persistencia y acceso a datos está compuesto por los repositorios. Estos son clases/objetos que encapsulan la lógica necesaria para acceder a los datos, es decir, de métodos para consultar, añadir, modificar y eliminar objetos. Permite además seleccionar objetos basándose en criterios de selección, devolviendo objeto o colecciones de objetos instanciados con los valores del criterio. La tecnología de persistencia utilizada en los repositorios es un O/RM llamado N/Hibernat. Junto a esta tecnología utilizada internamente se añadieron operaciones de Base de datos. Cabe añadir que se logrado 33

42 desacoplar la capa de persistencia mediante el uso de interfaces/contratos. Este contrato será lo que la capa de Dominio requiera de un repositorio para que pueda funcionar. Capa Common: Se debe asegurar la implementación de mecanismos de desacoplamiento entre los objetos de las capas. Por esto se hace necesario el desacoplamiento entre capas mediante contratos e interfaces que utilicen Inyección de Dependencia e Inversión de Control. Esta mantenibilidad del sistema es dada por esta capa en donde se realizan las instancias necesarias para tal fin. Esto facilita la sustitución de capas o módulos sin ningún tipo de dificultad. La IoC describe técnicas para soportar una arquitectura tipo plug-in donde los objetos pueden buscar instancias de otros objetos que requieren y de los cuales dependen. DI Es un patrón en el que se suplen objetos/dependencias a una clase en lugar de ser la propia clase quien cree los objetos/dependencias que necesita. La elaboración del frontend de las aplicaciones que administran los procesos académicos en la Universidad de San Buenaventura Cartagena, implicó el manejo principlamente de la capa de presentación principalmente, junto a un conocimiento superficial de las demás capas (esto según la utilización dentro de los trabajos que se desarrollaban). 4.2 REQUERIMIENTOS Como ya se manifestó anteriormente, la información pertinente para el correcto desarrollo de éste proyecto se obtuvo a través de la asesoría continua del Coordinador Tecnológico del CEV Javier García Altamiranda, el cual actuó como gestor de la idea de implementar Scrum y su posterior orientador en el desarrollo del mismo, buscando mejorar el índice de desarrollo de software. Cabe también aclarar que se ha seguido las características principales de Scrum como son las iteraciones de trabajo o Sprint y las reuniones diarias de 15 minutos. A partir de esto el Ingeniero Javier García ha realizado cambios en el uso de artefactos así como ha seguido el consejo de incorporar otros como lo es el del Juego de Póker utilizado para la asignación de horas a las actividades y que es propio de otra metodología ágil de desarrollo, más concretamente, Xtreme Programing. La información acerca de la lógica de negocio se consignó en las historias de usuario; la elaboración de éstas se realizó a lo largo del desarrollo del proyecto, en reuniones que integraron al Ingeniero Javier García y a la ingeniera Tulia Zúñiga Quintana como representante de la Universidad, siendo el primero el Representante del Cliente (Product Owner) y el Scrum Manager, dos roles bien definidos dentro de Scrum. 34

43 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 Product Backlog. Teniendo en cuenta lo anterior se define a continuación este elemento de Scrum. Se tienen cinco secciones de trabajo, los cuales presentan requerimientos que han sido transmitidas al grupo de desarrolladores en la reunión de planificación del primer Sprint. Estos módulos se especifican a continuación: Portal de Docentes, Seguimiento de Prácticas, Portal Estudiante, Portal Egresados y Portal de Elecciones. Portal de Docentes: Esta sección permite visualizar información personal del docente, actualizar sus datos, publicar y corregir notas. Se halla dividido en los siguientes módulos: Módulo Actualización de Datos: Actualiza la Información de Contacto y Datos aún no diligenciados. Módulo Ficha de Docente: Muestra la Información Básica del Docente y Permite el Envío de Correo Electrónico Módulo Publicación de Notas: Permite el Registro de Calificaciones Módulo Corrección de Notas: Permite la Corrección de Calificaciones Seguimiento de Prácticas: Esta sección permite realizar un seguimiento virtual a las prácticas que realiza el estudiante. En ella interactúan 35

44 empresa, docente encargado y estudiante. Se halla dividido en los siguientes módulos: Módulo Creación de Solicitud: Creación de Solicitud de Practicante por parte de una Empresa Módulo Responder Solicitud: Respuesta de una Solicitud de Practicante por parte de un Coordinador de Prácticas Figura 4. Product Backlog del Desarrollo Módulo Gestión de Empresas: Crear, Actualizar, Eliminar y Editar Empresas 36

45 Módulo Diligenciar Bitácora: Permite tramitar el llenado de las bitácoras de trabajo que se han realizado por parte del estudiante. Módulo Valorar Practicante: Le permite al empresario dar una calificación a cada practicante evaluando la labor realizada. Módulo Finalizar Práctica: Le permite al empresario dar por terminado el periodo de prácticas, siempre y cuando no existan labores pendientes por parte del practicante. Módulo Reportar Amonestación: Le permite al empresario realizar amonestaciones al practicante, informando a éste y al tutor de prácticas la situación presentada. Módulo Ver Amonestaciones: Le permite al tutor de prácticas ver las amonestaciones que realiza el empresario. Módulo Responder Amonestaciones: Le permite dar respuesta a cada amonestación que el empresario haga de un practicante. Módulo Practicantes Asignados a Empresa: Les permite a los tutores de práctica asignar practicantes de acuerdo a las solicitudes existentes de empresas. Módulo: Cargar Certificado: Una vez que el empresario a dado por finalizada una práctica, se debe cargar un certificado que informe de tal hecho. Portal Estudiante: Esta sección permite visualizar, de forma general, información de interés para el estudiante, sus datos personales y su histórico de notas. Se halla dividido en los siguientes módulos: Módulo Actualización de Datos: Actualiza la Información Personal, Familiar, Académica, Laboral y Estudios de Idiomas que este presenta. Módulo Historial de Notas: Muestra las Calificaciones Obtenidas por el Estudiante en las Materias Cursadas en su carrera universitaria. Módulo Semáforo Académico: Muestra los Cursos Aprobados y Pendientes del Plan de Estudio relacionado con cada estudiante. Módulo Información de Estudiante: Muestra la información Personal Módulo Perfil del Estudiante: Muestra una Ficha con la Información Básica y la Posibilidad de Envío de Correo Electrónico 37

46 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 Exposición del Product Backlog. Una vez establecido el Product Backlog, se realizó la primera reunión con todos los integrantes del proyecto (Product Owner, Scrum Master y Scrum Team); su duración de 8 horas en promedio fue divididá en dos partes: en la primera de 4 horas, el Product Owner describió todas las funcionalidades del producto o también llamadas Historia de Usuario. Durante la primera parte de la reunión se definieron por parte del Product Owner, los elementos de alta prioridad. 38

47 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 Seguimiento y control ágil. Una vez terminada la planeación, se dió inicio al desarrollo del Sprint, y con ella una de las características claves de Scrum: la reunión diaria. Esta era una reunión corta de 15 minutos que se realiza en lugar y hora definida anteriormente, siendo dirigida normalmente por el Team Leader o alguno designado por el. Se realiza de pie y a ella asiste todo el equipo de trabajo. El encuentro diario era una forma de mantener la auto-organización y auto control entre los integrantes. En ella se contestan las tres preguntas claves, y si se encontrase algún tipo de inconveniente se le comunica al Scrum Master 39

48 para que fuese él quien tomase las medidas al respecto. Se procedía como viene a continuación: Cada integrante del equipo respondía estas tres interrogantes: 1. En qué tarea trabajó ayer? 2. En qué tarea trabajará hoy? 3. Si van a necesitar algo especial o prevén algún impedimento para realizar su trabajo. Se actualizaba en el Sprint Backlog el tiempo de trabajo que queda pendiente a su vez que se marcaban las tareas que hubiesen sido terminadas (sólo las que ya hayan sido probadas). Figura 5. Sprint Backlog del Desarrollo Con la información del encuentro diario se actualizan las columnas No empezado, En Progreso y Completado del Sprint Backlog y la Gráfica de trabajo (Diagrama de Burn-Down), añadiendo en ésta las horas de trabajo de las tareas realizadas. La gráfica de no queda nada de esfuerzo o de Burn- 40

49 Down mostraba el progreso del equipo hacia su objetivo y el trabajo restante para alcanzar tal fin. Figura 6. Avance de un Sprint Una vez que el equipo iniciaba el desarrollo del Scrum, no se permitían cambios en actividades o adición de actividades, debiendo esperar al siguiente Sprint. En cambio se permitió que uno o dos integrantes trabajasen en estas actividades imprevistas con prioridad alta, y dejar por sentado en el Sprint Backlog estos imprevistos; los demás integrantes del equipo debían suplir en la medida que lo requiera, las actividades que se dejaban de desarrollar por este cambio de planes, no afectando fuertemente el avance del Sprint. El equipo de trabajo, a medida que avanza el desarrollo de las actividades, debía ir detallando nuevos requisitos, separar elementos grandes en otros más pequeños, estimar actividades imprevistas y restimando elementos ya existentes. Para esto se dejaba un espacio dentro del Sprint Backlog dedicado a Actividades Futuras, con lo cual se dejaban actividades claras y estimadas para el siguiente Sprint. La duración de los Sprint nunca se prolongaron más haya del tiempo establecido para los mismos, es decir, se terminaron en la fecha asignada aunque el equipo no hubiese terminado con todas las actividades con las que se había comprometido. 41

50 4.3.4 Revisión del Sprint. Cuando terminó el Sprint se hace la revisión del mismo. El Scrum master y a la vez representante del Cliente no sólo revisaba el entregable del producto o los demos sino también la calidad del trabajo, de forma que no se pudiese disimular los códigos desordenados, sin probar y de mala calidad. La revisión del Sprint también implicaba que el equipo hablase sobre lo que funciona y lo que no, y se acordaban que cambios se querían intentar. Se dejaba claro qué fue bien y qué se puede mejorar, buscando causas y previniéndolas en el próximo Sprint. Llegado este punto, se iniciaba la planeación del siguiente Sprint, siendo definido la fecha y lugar durante la revisión del Sprint. En este punto el Product Owner podía actualizar la pila del Product Backlog con cambios o nuevas actividades. El Product Owner y el equipo estaban listos para empezar otro ciclo de Sprint, por lo cual no había tiempo de descanso, manteniendo un ritmo sostenible y razonable. Con lo descrito hasta el momento se ha detallado el proceso que se siguió para el desarrollo del primer Sprint y fue repetitivo en el desarrollo de los siguientes Sprint hasta la obtención de los productos finales: Portal de Docentes, Seguimiento de Prácticas, Portal Estudiante, Portal Egresados y Portal de Elecciones. En total se realizaron 5 Sprint o iteraciones que se detallan a continuación: Sprint 1: Por ser el primer sprint de la implementación de la metodología, todos los participantes estaban sumamente ansiosos por ver como evolucionaba; este Sprint en particular fue el caso de una implementación ideal, debido a que, a pesar que era la primera experiencia con respecto a la implementación de la metodología, se logró una ejecución casi perfecta, a razón de que los tiempos se cumplieron tal como se planearon y las tareas se realizaron como se discutieron en la reunión de planeación del sprint días atrás. Cabe mencionar, que los comentarios de muchos autores con respecto al primer sprint, no son muy agradables, puesto que, ellos mencionan que por ser la primera experiencia con la metodología, casi siempre se produce una pésima ejecución, arrojando como resultado actividades sin completar, apatía de los participantes a la nueva metodología, entre otras cosas, pero ese no fue el caso de esta implementación. Las actividades y sub-actividades que se tuvieron en cuenta en este sprint fueron las siguientes: 42

51 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 Media 4 Horas Ninguno certificados se sistematizan Definir procesos de Media 4 Horas Ninguno certificados 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 43

52 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 Agrupar Cursos Pendientes por Semestre Agrupar Pensum del Programa Media 3 Horas Ninguno Media 3 Horas Ninguna 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 44

53 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 Colocar como no editables los campos pertinentes Implementar formulario de Historial Laboral como MODAL Implementar formulario de Historial Académico como MODAL Implementar formulario de Estudios de Idiomas como MODAL Urgente 6 Horas Ninguno Media 4 Horas 5 Siempre editable datos personales 6 Cuando no existan datos del nombre del padre y de la madre, será editables Baja 2 Horas Ninguno Baja 2 Horas Ninguno 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ó 45

54 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 Crear Módulo de Gestión de Empresas Crear Módulo de Finalización de Practicas Crear Módulo de Valoración de Practicante Crear Módulo para Responder Practicante Crear Módulo para Diligenciar Bitácora por parte del Practicante Practicas) Medio 2 Horas Ninguna Medio 5 Horas Ninguna Baja 4 Horas Valoración de Inicial y Valoración Final 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. Media 5 Horas Ninguna Tabla 12. Actividad Prácticas Empresariales 46

55 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 Agregar Funcionalidad al Módulo 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 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 Inscripciones en línea provisional presentes Urgente 8 Horas Realizar un portal provisional de Inscripciones en línea para los nuevos estudiantes 47

56 Implementar un sistema de validaciones gramaticales Mejorar problemas presentados al entrar a los portales desde Internet Explorer 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) 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 48

57 Sprint 3: A razón de que el sprint 2 no tuvo el éxito que tuvo el primero, este dejó actividades que debieron haberse resuelto en el mismo; por tal motivo, dichas actividades pasaron a ser prioritarias para éste sprint, generando en los participantes del desarrollo muchas más de cautela y precaución a la hora de asignar tiempo a las actividades de la iteración. La ejecución del Sprint se llevó a cabo sin muchos altercados, nuevamente se presentaron actividades y cambios a las actividades planeadas en tiempo de ejecución por los directivos de la universidad, pero por la experticia que ganaron los integrantes del equipo, se lograron resolver sin que generaran muchos inconvenientes para el resultado final de la iteración y como resultado se produjo una buena ejecución del sprint. Las actividades y sub-actividades que se tuvieron en cuenta en este sprint fueron las siguientes: Prácticas Empresariales (Actividades sin Resolver) Sub-Actividades Prioridad Tiempo Comentario Crear Módulo de Urgente 2 Horas Ninguna Gestión de Empresas Crear Módulo de Urgente 5 Horas Ninguna Finalización de Practicas Crear Módulo de 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 Media 4 Horas Ninguna Diagrama de Actividades Realizar UI de la matrícula en línea Media 4 Horas Ninguna Obtención de Prematrí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 49

58 Agregar y validar Cursos Revisar Seguridad Obtener Cursos Habilitados Urgente 8 Horas Ninguna Urgente 8 horas Ninguna 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 Urgente 3 Horas Ninguna Calendario de los cortes (API) 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 50

59 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 Realizar cambios necesarios para la interoperabilidad entre los navegadores web Reestructurar Tamaño de los campos de texto Rediseñar las pestañas otros. 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. Bajo 3 Horas Implementar varios tamaños y estandarizarlos. 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 51

60 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 Generador de PDF con la cita para la prueba Psicotécnica Agregar Funcionalidad al Módulo Realizar validaciones adicionales Medio 3 Horas Ninguna Medio 3 Horas Solo para los estudiantes de Psicología 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. 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 52

61 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 autogestionado que trabajó en una serie de tareas, desarrolladas en series de Sprint de 1 a 4 semanas, hasta que se entregó los productos o aplicaciones completas. 4.4 DISEÑO Y DESARROLLO DE INTERFACES. En este punto es preciso mencionar algunas de las herramientas de software que se usaron específicamente para este aspecto. Entre las herramientas usadas se encuentran: Netbeans como editor de código fuente Navicat como gestor de base de datos PhotoShop como herramienta para edición de imágenes Navegadores web, entre estos se encuentra Google Chrome, Mozilla Firefox, Safari e Internet Explorer. 53

62 A continuación se mostrarán las interfaces resultantes de la implementación. Interfaz principal donde podemos apreciar los diferentes módulos realizados durante nuestras pasantías, podemos observar Mis datos el cual es el lugar donde podremos observar y actualizar toda la información correspondiente a los, Mis Cursos es otro modulo donde se encuentra toda la información referente a Horario, Notas y Cursos Matriculados. Practicas Industriales, modulo relacionado con toda la vida de prácticas Industriales. Consultas este módulo nos da la oportunidad de observar la información correspondiente al volante de pago y al Semáforo Académico. (Ver la siguiente Figura) Figura 8. Página de Inicio Actualización de Datos Estudiantes: Interfaz donde se puede apreciar Mis datos en el cual se pueden observar los datos del estudiante y actualizar toda la información correspondiente del mismo; Mis Cursos es otro módulo donde se encuentra toda la información referente a Horario, Notas y Cursos Matriculados; Prácticas Industriales, módulo relacionado con toda la vida de prácticas Industriales en caso de tener vigente alguna; Consultas este módulo da la oportunidad de observar la información correspondiente al volante de pago y a toda el pensum y notas del estudiante. La primera sección de este módulo es Actualizar Mis Datos y en él se tiene acceso a diferentes interfaces donde se puede modificar ciertos atributos que se inmersos en la ficha el estudiante, estos son: Actualizar Mis Datos Datos Básicos: Dentro del módulo de Mis Datos se puede Actualizar información sobre la ficha de estudiante, teniendo la opción de variar toda aquella que al transcurrir el tiempo 54

63 haya presentado modificaciones como el lugar de residencia, teléfono, correo electrónico y celular. (Ver la siguiente Figura) Figura 9. Actualizar Mis Datos Datos Básicos Actualizar Mis Datos Datos Familiares: En esta Interfaz se tiene acceso a la información que puede variar con el tiempo en referencia a acudiente o en referencia a datos relacionados con los padres. (Ver la siguiente Figura) 55

64 Figura 10. Actualizar Mis Datos Datos Familiares 56

65 Actualizar Mis Datos Historial Laboral: Espacio que Posee un Estudiante para agregar a la ficha estudiantil lo relacionado con la vida laboral que este ha generado o en su defecto esta generando. (Ver la siguiente Figura) Figura 11. Actualizar Mis Datos Historial Laboral Actualizar Mis Datos Historial Académico: Esta interfaz permite agregar información sobre estudios realizados con anterioridad por el estudiante. (Ver la siguiente Figura) Figura 12. Actualizar Mis Datos Historial Académico 57

66 Actualizar Mis Datos Idiomas: En esta pestaña se puede añadir información sobre los idiomas que el estudiante maneje desde un nivel bajo, pasando por medio, hasta llegar a un nivel alto. (Ver la siguiente Figura) Figura 13. Actualizar Mis Datos Idiomas Actualizar Mis Datos - Finalizar: Interfaz Final donde se muestran los términos y condiciones para poder confirmar el cambio de información realizado sobre la ficha correspondiente. La segunda sección de éste módulo es Ver mis Datos y permite a los estudiantes visualizar la información relacionada con su ficha estudiantil; está compuesta por las siguientes interfaces: Ver Mis Datos Información Personal: En Mis Datos se da la opción de observar la información presente en la Base de Datos de la universidad. (Ver la siguiente Figura) 58

67 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, entre otros. (Ver la siguiente Figura) 59

68 Figura 15. Ver Mis Datos Información de Contacto La tercera sección de éste módulo es Mis Cursos en el que el estudiante puede observar los cursos en los que actualmente se encuentra matriculados, permitiéndole ver compañeros de curso, enviarles correos, detallar el horario de clases, entre otras actividades. La cuarta sección de éste módulo es Prácticas Industriales en el que el estudiante puede ir añadiendo actividades a su bitácora siempre que lo desee. Esta sección estará activada si y sólo si el estudiante es asignado a una empresa que haya expresado su intención de contar con los servicios de un practicante. Sus interfaces son: Prácticas Industriales - Bitacoras: Se da la opción para que el estudiante genere actividades con un porcentaje de cumplimiento o realizacion, añadiendo los objetivos o competencias relacionadascon la actividad desarrollada. (Ver la siguiente Figura) 60

69 Figura 16. Prácticas Industriales- Bitácora Prácticas Industriales Descargar Certificado: En este espacio el estudiante tiene la opción de descargar el certificado que prueba que este ha cumplido con todos los requisitos presentados durante sus Prácticas industriales, teniendo presente que este debe ser aprobado y subido por el director de las mismas. (Ver la siguiente Figura) Figura 17. Prácticas Industriales Descargar Certificado 61

70 Actualización de Datos Egresados. Espacio de los Egresados donde pueden modificar la información relacionada con la que fue en algún momento su ficha estudiantil. Actualizar Mis Datos Datos Básicos: El Portal Egresados y El Portal Estudiantes con respecto a las actualizaciones son muy similares donde solo algunos ítems hacen la diferencia entre ellos la opción de poder agregar hijos.(ver la siguiente Figura) Figura 18. Actualizar Mis Datos Datos Básicos 62

71 Actualizar Mis Datos Información Laboral: En esta interfaz permite apreciar los campos donde se debe colocar todo lo referente a la información laboral del grupo Egresados así como reconocimientos dentro de la empresa, entre otros. (Ver la siguiente Figura) Figura 19. Actualizar Mis Datos Información Laboral Actualizar Mis Datos Información Académica: La Información académica de un egresado se encuentra en esta interfaz, donde podrá añadir nuevos títulos obtenidos en cualquier entidad educativa (Ver la siguiente Figura). 63

72 Figura 20. Actualizar Mis Datos Información Académica Actualizar Mis Datos Idiomas: Los egresados tienen la oportunidad de poder anexar los lenguajes que manejen, teniendo presente el nivel de escritura, lectura y fluides. (Ver la siguiente Figura) Figura 21. Actualizar Mis Datos Idiomas 64

73 Actualizar Mis Datos Datos Complementarios: En esta última interfaz se hace presente información complementaria que es de protocolo para la universidad. (Ver la siguiente Figura). Figura 22. Actualizar Mis Datos Datos Complementarios Interfaces Módulo de Docentes. Campo relacionado con los docentes donde podrán visualizar información que estos poseen, estas interfaces son: Módulo de Docentes Horario: Los Docentes tienen la oportunidad de poder ver el horario de clases generado según las asignaturas que fueron otorgadas para ser dictadas. (Ver la siguiente Figura) 65

74 Figura 23. Módulo Docentes Horario Módulo de Docentes - Cursos: En esta ventana aparecerán todos los cursos asignados al docente con información detallada sobre el mismo. Módulo de Docentes Notas: Es esta interfaz se permite al docente asignar las notas académicas a cada estudiante, así como corregirlas según el límite de tiempo que para éste efecto se le asigne. Elecciones Estudiantiles. Espacio donde los estudiantes pueden tomar elección de aquellos que se hayan postulado a Consejo Académico o Representante de Facultad, estas interfaces son: Elecciones Estudiantiles - Formulario de Inscripción: En el módulo de Elecciones, se permite realizar la inscripción a la candidatura al Consejo Academico o a Representante de Facultad; en este formulario tambien se cuenta con la opcion de colocar todo lo referente al plan de campaña del postulado. (Ver la siguiente Figura) 66

75 Figura 24. Elecciones Estudiantiles Formulario de Inscripción Elecciones Estudiantiles Admisiones: Esta Interfaz sólo se encuentra disponible para el Jefe de Unidad de Registro Académico quien tendrá la opción de admitir o denegar la inscripción de los candidatos postulados. (Ver la siguiente Figura) 67

76 Figura 25. Elecciones Estudiantiles Admisión Elecciones Estudiantiles - Votacion: En esta interfaz se puede apreciar los diferentes aspirantes al consejo académico o representante de facultad que se encuentren admitidos para su elección por el cuerpo estudiantil; además, también se podrá sufragar por el candidato de elección (Ver la siguiente Figura) Figura 26. Elecciones Estudiantiles Votación 68

77 Módulo de Prácticas Industriales. El control y seguimieento de las prácticas se realiza mediante estas interfaces. En esta oportunidad se tendran presentes varios usuarios como lo son el Coordiandor de Prácticas y la Empresa. Las vistas correspondientes al estudiante ya han sido descritas en la sección correspondiente a él. Las interfaces de prácticas industriales que puede visualizar el Coordinador de Prácticas permiten ver las empresas registradas en la base de datos, peticiones de éstas hagan, asignarles practicante, entre otras funciones. Sus interfaces son: Prácticas Industriales Subir Certificado: En este espacio el Coordinador de Prácticas Industriales tiene la opción de subir el certificado que avala el cumplimiento total de las horas asignadas al estudiante. Este certificado se entrega tras la aprobación de la empresa donde se realizan las prácticas, la cual certifica que se han cumplido todas las actividades planeadas. (Ver la siguiente Figura) Figura 27. Prácticas Industriales Subir Certificado Prácticas Industriales Solicitudes: Esta interfaz permite apreciar las solicitudes de practicantes enviadas por las empresas que tengan convenio con la Universidad De San Buenaventura Cartagena; el coordinador tiene la oportunidad de revisarlas, aprobar y asignar el practicante o sencillamente rechazarlas. (Ver la siguiente Figura) 69

78 Figura 28. Prácticas Industriales Solicitudes Prácticas Industriales - Amonestaciones: La empresa tiene la oportunidad de enviar amonestaciones al Coordinador de prácticas dándole a conocer a éste el tipo de inconvenientes que se están presentando con el practicante asignado. Así mismo da la opción al Coordinador de responder cada amonestación. (Ver la siguiente Figura) 70

79 Figura 29. Prácticas Industriales listado de Amonestaciones Prácticas Industriales - Amonestaciones Respondidas: El director de Prácticas podrá ver la información enviada como respuesta a las diferentes amonestaciones que hayan realizado las empresas con practicantes asignados. (Ver la siguiente Figura) 71

80 Figura 30. Prácticas Industriales Amonestaciones Respondidas Las interfaces de prácticas industriales que puede visualizar una empresa registrada ante la Universidad le permiten ver su registro, realizar solicitudes de practicantes, amonestar un practicante, entre otras funciones. Su principal seccion se centra en la solicitud de practicante, la cual presenta los siguientes vistas Solicitud Practicante - Identificación de la Empresa: Presenta todo lo correspondiente al registro de la empresa ante la Universidad, permitiéndosele cambiar cierta información. (Ver la siguiente Figura) 72

81 Figura 31. Solicitud Practicante - Identificación de la Empresa Solicitud Practicante - Requerimientos: En esta interfaz se describen los requerimientos que debe tener el practicante solicitado, como rama profesional, perfil y fechas de inicio y fin de la práctica. (Ver la siguiente Figura) 73