Versión del sistema informático para la gestión de los procesos de la Dirección de Relaciones Internacionales en la UCLV Autor: José A Herrera Delgado Tutor: Dr. Daniel Gálvez Lio Departamento de Ciencias de la Computación , Septiembre 2019 Title: Version of computer system for the management of the processes of the International Relations Directorate in the UCLV Author: José A Herrera Delgado Thesis Director: Dr. Daniel Gálvez Lio Academic Departament Computer’s Science , September 2019 Este documento es Propiedad Patrimonial de la Universidad Central “Marta Abreu” de Las Villas, y se encuentra depositado en los fondos de la Biblioteca Universitaria “Chiqui Gómez Lubian” subordinada a la Dirección de Información Científico Técnica de la mencionada casa de altos estudios. Se autoriza su utilización bajo la licencia siguiente: Atribución- No Comercial- Compartir Igual Para cualquier información contacte con: Dirección de Información Científico Técnica. Universidad Central “Marta Abreu” de Las Villas. Carretera a Camajuaní. Km 5½. Santa Clara. Villa Clara. Cuba. CP. 54 830 Teléfonos.: +53 01 42281503-1419 Hago constar que el presente trabajo fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de los estudios de la especialidad de Ingeniería Informática, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad. _____________ Firma del autor Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada. _____________ _____________ ____________________ Firma del tutor Firma del tutor Firma del jefe del Dpto Dedicatoria A mis padres por ser el motor impulsor en cada uno de estos años de mi carrera. A mis abuelos, por ser una de las fuentes fundamentales de mi vida. A mi familia, por brindarme siempre su apoyo incondicional. A mi novia, por estar ahí cuando lo necesité. Agradecimientos Le doy gracias a Dios por permitirme llegar hasta el final de esta carrera y en los momentos más difíciles supo ponerme a las personas indicadas en mi camino para superar el desafío. A mis padres, Nuvia, Cesar y José Patricio que, a su manera, supieron guiarme y alentarme a terminar. A mis abuelos los que ya no están presente, sé que ellos hubiesen disfrutado de este momento tanto como yo. Ojalá y hubiesen estado aquí. A mi abuela, siempre preocupada por todos sus nietos. Gracias a Dios por estar siempre presente. A mi familia, la de sangre y la que la vida nos hace familia. Muchas gracias por su apoyo siempre, unos desde la distancia otros desde bien cerca pero nunca me sentí solo en esta trayectoria. Gracias a Dios por todos ustedes. A mi tutor, el Dr. Daniel Gálvez Lio por tenerme paciencia y apoyarme en este proceso. A mi novia, Elizet Pérez Parra, porque Dios la puso en un momento de mi vida donde el estrés, el desánimo y las malas noches hacían estrago por donde quiera que pasara, y ella supo cómo ayudarme y alentarme en cada instante. Resumen La presente investigación se realiza en la Dirección de Relaciones Internacionales de la Universidad Central ¨Marta Abreu¨ de las Villas (DRI-UCLV) con el objetivo de implementar una nueva versión de sistema informático para la gestión de los procesos en dicho departamento, refactorizando el código de la versión anterior y actualizando los cambios en los procesos que desarrolla esta Dirección. Dicha versión será implementada haciendo uso del framework Symfony y como sistema gestor de base de datos MySQL. Abstract This research is carried out at the International Relations Directorate of the Central University ¨Marta Abreu¨ de las Villas (DRI-UCLV) with the objective of implementing a new version of the computer system for the management of the processes in said department, refactoring the code of the previous version and updating the changes in the processes that this Directorate develops. This version will be implemented using the Symfony framework and as a MySQL database management system. Tabla de Contenidos TABLA DE CONTENIDOS INTRODUCCIÓN ....................................................................................................................... 1 1. FUNDAMENTACIÓN TEÓRICA ..................................................................................... 7 1.1 Dirección de Relaciones Internacionales de la UCLV .................................................. 7 1.1.1 Objeto de estudio ........................................................................................................ 7 1.1.2 Procesos de Gestión de la DRI.................................................................................... 9 1.2 Refactorización. Proceso de la Ingeniería Informática ............................................... 11 1.2.1 Concepto y características.................................................................................... 12 1.2.2 Ventajas y desventajas ......................................................................................... 13 1.2.3 Tipos de código que necesitan una refactorización ............................................. 15 1.3 Tendencias y tecnologías actuales empleadas en la implementación ......................... 16 1.3.1 Framework Symfony ................................................................................................ 16 1.3.2 Lenguaje PHP ........................................................................................................... 18 1.3.3 Sistema Gestor de Base de Datos MySQL ............................................................... 19 2. MODELO DEL NEGOCIO Y DISEÑO UML ................................................................. 22 2.1 Reglas del Negocio...................................................................................................... 22 2.1.1 Reglas del negocio a considerar ................................................................................ 22 2.1.2 Actores del Negocio .................................................................................................. 23 2.1.3 Diagrama de Casos de Uso ....................................................................................... 23 2.1.3 Descripción de los casos de usos del Sistema ........................................................... 24 2.1.4 Los diagramas de paquetes ....................................................................................... 26 2.2 Pasos para la refactorización ....................................................................................... 26 3. Descripción de la propuesta de solución ............................................................................ 30 3.1 Arquitectura del sistema .................................................................................................. 30 3.2 Diagrama de clases del diseño .................................................................................... 30 3.3 Diagrama de secuencia ................................................................................................ 31 3.4 Tratamiento de errores ................................................................................................ 32 3.5 Diseño de la base de datos........................................................................................... 33 3.6 Modelo de componentes.............................................................................................. 34 3.7 Diagrama de despliegue .............................................................................................. 35 3.8 Conclusiones Parciales ................................................ ¡Error! Marcador no definido. 4. PRUEBAS Y ANÁLISIS DE FACTIBILIDAD ............................................................... 39 Tabla de Contenidos 4.1 Planificación basada en uno de los métodos de estimación ............................................. 39 4.1.1 Estimación basada en Casos de Uso ......................................................................... 39 4.1.2 Conclusiones del Análisis de Factibilidad ................................................................ 46 4.2 Casos de Pruebas (caja negra).......................................................................................... 46 4.3 Conclusiones parciales ..................................................................................................... 47 5. CONCLUSIONES ............................................................................................................. 48 6. REFERENCIAS BIBLIOGRÁFICAS............................................................................... 49 Lista de Tablas Introducción 1 INTRODUCCIÓN La Dirección de Relaciones Internacionales de la Universidad Central “Marta Abreu” de Las Villas (DRI-UCLV) tiene como misión fundamental el diseño, seguimiento y evaluación de políticas y estrategias para jel proceso de internacionalización institucional y la prestación de asesoría metodológica y servicios de tramitación y gestión efectivos para la consecución de acciones internacionales y el manejo del proceso de la Estrategia de Internacionalización Institucional de la Universidad (UCLV, 2019). La DRI-UCLV tiene varias funciones fundamentales, entre ellas se pueden destacar el diseño consensuado con las estructuras universitarias de estrategias y políticas, la asesoría metodológica para el desarrollo de los procesos de internacionalización, la puesta en práctica de instrumentos para la inserción de la dimensión internacional en los procesos sustantivos de la institución, el seguimiento de las acciones, convenios y planes específicos, el control y evaluación del cumplimiento de la estrategia y en base a los resultados proyectar su futura consecución, la prestación de servicios de gestión y tramitación efectivos (UCLV, 2019). Dicha Dirección está integrada por cuatro departamentos que se encargan de realizar las tareas y funciones dentro de las encomendadas por la DRI. El Departamento de Trámites (DT) se encarga de gestionar las propuestas de viajes de todas las personas de la UCLV y de la confección pasaportes. El Departamento de Atención a Estudiantes Extranjeros (DAEE) se encarga de atender a todos los estudiantes extranjeros del centro. La Oficina Coordinadora de Servicios Académicos (OCSA) se encarga de la contratación de los estudiantes extranjeros financiados por el gobierno y autofinanciados y de atender los profesores con misiones aprobadas de asistencia técnica, esta actividad es conocida por profesor invitado (PI). El Departamento de Colaboración Internacional (DCI) es el encargado de la atención de visitas, de la recepción de estudiantes de intercambio (becarios) y maneja las redes y asociaciones a las que pertenece la UCLV. Antecedentes Desde sus inicios en la DRI-UCLV se maneja la información mediante ficheros de datos creados en Excel. Cada departamento lleva un registro independiente de la información. En Introducción 2 ocasiones no se registra toda la información relevante y pueden existir errores al recopilarla, lo que dificulta la búsqueda, la entrega de información rápida y confiable, así como la toma de decisiones por parte de los directivos. Para mejorar el trabajo de la DRI y lograr la socialización de la información en sus procesos surgió la idea de confeccionar una herramienta capaz de gestionar la información de dicha Dirección que respondiera a las necesidades del área. En el año 2016 se creó el software “Sistema informático para la gestión de los procesos de la Dirección de Relaciones Internacionales en la Universidad Central "Marta Abreu" de Las Villas (SIRI-UCLV)” (Abreu, 2016a) como resultado de una tesis de pregrado realizada por los estudiantes Alejandro Bermúdez Espinosa y Raúl A. Alfonso Camacho de la carrera de Ingeniería Informática del Centro de Investigaciones de la Informática (CII). Este sistema se realizó con el fin de automatizar los procesos llevados a cabo en la DRI. Se logró implementar varios procesos de los que se realiza en la DRI y aunque se dejó en funcionamiento en esta Dirección al cabo de poco tiempo se perdió el mismo por rotura de la computadora donde se encontraba instalado quedando solo disponible la información entregada como parte del trabajo de diploma. Es necesario actualizar ese software y facilitar su migración a los servidores centrales de la UCLV para ser atendido por la Dirección de Informatización y Comunicaciones (DIC). Esa actualización incluye un proceso de refactorización, de adición y cambio de algunos procesos que se han modificado desde el desarrollo del software precedente. En ingeniería de software, el término refactorización se usa a menudo para describir la modificación del código fuente sin cambiar su comportamiento, lo que se conoce informalmente por limpiar el código. La refactorización se realiza a menudo como parte del proceso de desarrollo del software: los desarrolladores alternan la inserción de nuevas funcionalidades y casos de prueba con la refactorización del código para mejorar su consistencia interna y su claridad. Los tests aseguran que la refactorización no cambia el comportamiento del código. La refactorización es la parte del mantenimiento del código que no arregla errores ni añade funcionalidad. El objetivo, por el contrario, es mejorar la facilidad de comprensión del código o cambiar su estructura y diseño y eliminar código muerto, para facilitar el mantenimiento en el futuro. Añadir nuevo comportamiento a un programa puede ser difícil con la estructura Introducción 3 dada del programa, así que un desarrollador puede refactorizarlo primero para facilitar esta tarea y luego añadir el nuevo comportamiento (Fowler, 1999). Planteamiento del Problema Actualmente la DRI-UCLV no cuenta con el software SIRI-UCLV debido a factores ajenos a la institución, sin embargo, se mantiene el interés y la necesidad del mismo como parte del proceso de informatización de esta Dirección. Además, esta Dirección mantiene una adecuación constante de sus funciones por lo que existen procesos que han cambiado para dar un mejor cumplimiento de las mismas. Entonces resulta necesario actualizar ese sistema y facilitar su migración a los servidores centrales de la UCLV para ser atendido por la DIC y garantizar la seguridad. La actualización incluye una etapa de refactorización, así como la adición y cambio de algunos procesos que se han transformado desde el desarrollo del software precedente. Objetivo general Desarrollar una nueva implementación del “Sistema informático para la gestión de los procesos de la Dirección de Relaciones Internacionales en la Universidad Central "Marta Abreu" de Las Villas (SIRI-UCLV versión 2.0)” refactorizando el código y actualizando los cambios en los procesos que desarrolla esta Dirección. Objetivos específicos 1. Seleccionar los elementos de la versión anterior de la herramienta que deben ser refactorizados. 2. Determinar de las funciones que desarrolla la DRI aquellas cuyos procesos de negocio han cambiado y necesitan actualización en la nueva versión del sistema. 3. Desarrollar el proceso de refactorización y de actualización sobre el Sistema informático para la gestión de los procesos de la DRI. 4. Validar la nueva versión obtenida. Introducción 4 Justificación Existe la necesidad de actualizar el Sistema informático para la Dirección de Relaciones Internacionales debido a que el software que fue creado hace varios años ya no está disponible y esta dirección ha cambiado parte de su funcionamiento modificando e introduciendo nuevos procesos para la gestión de la información. Es importante para dicha dirección recuperar el sistema pues por razones ajenas a ellos no conservan el software en estos momentos. Para los departamentos asociados a la dirección resulta de vital utilidad el sitio pues son los que llevan a cabo las tareas principales de la DIR-UCLV. Con el Sistema Informático restaurado y actualizado se pueden agilizar los procesos de gestión de dicha dirección. La información puede quedar registrada de forma segura y ser socializada entre todos los departamentos. Además, se pueden eliminar los errores existentes al recopilarla. Así también, se les facilitaría la búsqueda y la toma de decisiones por parte de los directivos. La estructura de esta investigación en este trabajo de diploma se organiza en introducción, cuatro capítulos, conclusiones, recomendaciones, referencias bibliográficas y los anexos. En el Capítulo 1 se describen los fundamentos teóricos y metodológicos sobre los elementos determinantes en el desarrollo del trabajo. Se exponen la misión, objeto de estudio y procesos de gestión de la DRI-UCLV. Se describen las características fundamentales del proceso de refactorización. También se desglosan las tendencias y tecnologías actuales empleadas en la implementación. En el Capítulo 2 se reelaboran las reglas del negocio de la DIR-UCLV teniendo en cuenta las modificaciones y actualizaciones de sus tareas y procesos. Además, se detallan a profundidad los tipos de refactorización utilizados para la recuperación y actualización del software para la DIR-UCLV. En el Capítulo 3 se muestra la arquitectura del sistema informático, el diagrama de clases del diseño, el diagrama de secuencia, el diseño de la base de datos, el modelo de componentes y el diagrama de despliegue. Introducción 5 En el Capítulo 4 se realizan las pruebas de validación al sistema para asegurar que la refactorización no cambia el comportamiento del código y se verifica el nuevo comportamiento incorporado al sistema. CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA 1. FUNDAMENTACIÓN TEÓRICA En este capítulo se describen la misión, objeto de estudio y procesos de gestión de la DRI-UCLV. Asimismo, se detallan las peculiaridades teóricas del proceso de refactorización, los tipos existentes importantes a tener en cuenta en el sistema informático. Se exponen las tecnologías y tendencias actuales útiles en la mejora y refactorización al sitio. 1.1 Dirección de Relaciones Internacionales de la UCLV La DRI-UCLV tiene como misión fundamental el diseño, seguimiento y evaluación de políticas y estrategias para el proceso de internacionalización institucional y la prestación de asesoría metodológica y servicios de tramitación y gestión efectivos para la consecución de acciones internacionales. 1.1.1 Objeto de estudio La DRI-UCLV presenta un conjunto de funciones fundamentales como el diseño consensuado con las estructuras universitarias de estrategias y políticas, la asesoría metodológica para el desarrollo de los procesos de internacionalización, la puesta en práctica de instrumentos para la inserción de la dimensión internacional en los procesos sustantivos de la institución, el seguimiento de las acciones, convenios y planes específicos, el control y evaluación del cumplimiento de la estrategia y en base a los resultados proyectar su futura consecución, la prestación de servicios de gestión y tramitación efectivos. Cada departamento de esta Dirección tiene asociado tareas específicas. El Departamento de Trámites (DT) se encarga de gestionar las propuestas de salida de todas las personas con intención de realizar un viaje oficial mediante la UCLV. Esta propuesta se almacena en un documento denominado diáspora, donde se recogen los datos entregados por la persona: nombre y apellidos, carné de identidad, foto, país e institución a la que pretende viajar. Si es profesor categoría científica, facultad y departamento al cual pertenece. En caso de ser trabajador, el área al cual pertenece. Si es estudiante, la carrera. Además, el tipo de misión que puede ser misión oficial, profesor invitado, evento, beca pre doctoral y postdoctoral, entre otros; la fecha de inicio y fecha de fin. Dependiendo del país al cual pretende viajar la persona, es necesario entregar una Ficha de Salida, en el caso de viajar hacia Nicaragua y Bolivia se necesita entregar la Ficha de Salida del ALBA, si es hacia Colombia se necesita entregar la Ficha de Salida de Colombia. En el caso de que los que vayan a viajar ocupen los cargos de decano de facultad, vicerrector o el de rector de la universidad tienen que entregar la Ficha de Salida RT. También se necesita el número del pasaporte de la persona de tenerlo confeccionado, además de la fecha de emisión, fecha de vencimiento del mismo y la persona que ha actualizado la diáspora. Se agrega un campo estado, este estado se refiere al estado en que se encuentra la solicitud de salida que puede ser: pendiente, aprobado o no aprobado. Al pasar el campo estado al valor aprobado, se añade la fecha de aprobación en rectoría, la fecha real de salida y fecha real de regreso (estos dos campos de fecha dependen de que exista una fecha de aprobación en rectoría). Otra de las funcionalidades del DT consiste en la confección de nuevo pasaporte, este puede ser por concepto de nueva confección. Para la confección de dicho pasaporte es necesario que la persona llene una Solicitud de Pasaporte en la cual plasme todos sus datos personales, ya sea nombre y apellidos, color de piel, foto, fecha de nacimiento, padre, madre, sexo, estatura, color de ojos, color de cabello, ciudadanía, dirección particular, entre otras. El Departamento de Atención a Estudiantes Extranjeros (DAEE) se encarga de atender a todos los estudiantes extranjeros del centro, ya sean de intercambio becarios, autofinanciados o financiados por el gobierno. De los estudiantes se les recogen datos como el número del contrato en el caso de los financiados de gobierno y los autofinanciados, nombre y apellidos, fecha de entrada, fecha de caducidad, tipo de estudio que van a realizar, carrera que van a cursar, facultad donde la van a cursar y el tiempo que la van a cursar. La Oficina Coordinadora de Servicios Académicos (OCSA) se encarga de la contratación de los estudiantes extranjeros financiados por el gobierno y autofinanciados. En él son recogidos los datos tales como el número del contrato, el nombre del estudiante, el monto total a remesar, el país de donde proviene, el programa que va a cursar (pregrado o posgrado), el tipo de estudio que pretende realizar (carrera completa, pasantía, curso corto, preparatoria, doctorado, maestría, curso, especialización, entrenamiento), la facultad en la cual pretende realizar los estudios, el nombre del decano de la facultad y la fecha de inicio y cierre del contrato. La OCSA también se encarga de atender y orientar los profesores con misiones aprobadas de asistencia técnica, esta actividad se conoce como Profesor Invitado (PI), confeccionándosele el expediente necesario para presentar en CUBATECNICA, ANTEX o en cualquier otra institución de intercambio de servicios con el extranjero. Además, se registran los datos correspondientes al profesor, tales como carné, nombre y apellidos, país, institución y facultad a la cual pretende viajar, fecha de salida y fecha de regreso, salario mensual, salario total, monto a remesar y monto remesado, fecha de entrega del expediente y los estados de aprobación. Otra de las tareas a realizar por la OCSA es el paquete de agencia. Por esta vía se manejan las visitas de personas extranjeras al centro. Estas pueden visitarlo con diferentes propósitos. De estas visitas se recogen los siguientes datos: nombre de la agencia (pueden ser varias agencias), fecha de solicitud, fecha de aceptación y fecha de visita, número de pax (cantidad de personas), tipo del servicio (pueden ser recorridos, conferencias especializadas, entre otros), el monto, la fecha de solicitud de factura al departamento de finanzas, fecha de entrega de factura a la DRI, fecha de entrega de factura a la agencia, fecha de pago y el país del cual provienen los visitantes. El Departamento de Colaboración Internacional (CI) es el encargado de varias tareas, dentro de estas se encuentra la atención de visitas. De estas visitas se registran los datos de los visitantes tales como nombre y apellidos, ciudadanía, objetivo de la visita, actividad a realizar, fecha de entrada, fecha de salida y observaciones. Además, este maneja las redes y asociaciones a las que pertenece la UCLV. De ellas se recopilan su nombre, año de afiliación, su representante en la UCLV, país a la que pertenece, cuota de afiliación, monto de pago de la afiliación, la fecha de pago en el año, área (Latino América, Europa, etc.), financiamiento y observaciones. También el departamento se encarga de la recepción de estudiantes de intercambio (becarios). A partir de las solicitudes de recepción de estudiantes extranjeros que desean desarrollar pasantías por la modalidad de intercambio académico, los datos a recopilar son: nombre y apellidos, su número de pasaporte, universidad de la que provienen, carrera que pretenden estudiar, fecha de comienzo de los estudios y fecha de fin de estudios, observaciones y el responsable que los va a atender; con el fin de llevar un registro exhaustivo del estudiante. 1.1.2 Procesos de Gestión de la DRI La DRI-UCLV maneja todo el proceso de la Estrategia de Internacionalización Institucional de la Universidad. Los principales procesos manejados por la DRI-UCLV se describen seguidamente. • Propuesta de Salida En la UCLV, todas las personas, ya sean trabajadores, profesores o estudiantes, tienen la posibilidad de realizar viajes hacia otra institución universitaria en el exterior. El proceso comienza cuando la persona que pretende realizar un viaje hace entrega al especialista del Departamento de Trámites da la propuesta de salida y este revisa la propuesta de salida. Esta puede ser aceptada o rechazada, pues puede presentar datos incorrectos o estar incompleta. En caso de ser rechazada, se le pide a la persona que realice la solicitud nuevamente. En caso de ser aceptada, se registran en la diáspora los datos de la propuesta. Luego de registrar los datos en la diáspora, el especialista formula un resumen para la rectoría con todas las propuestas de salida que todavía no han sido discutidas o quedaron pendientes. El especialista envía a la rectoría el resumen con todas las propuestas de salida. Dichas propuestas son analizadas y posteriormente se envía al departamento de trámites la respuesta sobre las solicitudes de salida que fueron aprobadas, las que no y las que quedaron pendientes para la próxima discusión. Luego de ello, el especialista actualiza el campo “Estado de las solicitudes” en la diáspora. El especialista envía mediante un correo la respuesta a la persona para comunicarle si fue aprobada o no su propuesta. En caso de ser aprobada, el especialista actualiza la diáspora agregando la fecha de aprobación de la rectoría, fecha real de salida y fecha real de regreso. El especialista revisa si la persona que fue aprobada tiene pasaporte. Si tiene pasaporte y no está vencido. Se revisa si al país al cual va a viajar necesita visa. Si necesita visa se le solicitan todos los datos referentes al país. La persona entrega los datos referentes al país. El especialista recoge los datos. En el caso de no tener pasaporte el especialista entrega a la persona una solicitud de pasaporte. La persona llena la solicitud y la entrega. El especialista revisa la solicitud de pasaporte, de estar correcta envía la solicitud a Inmigración. Luego Inmigración confecciona el pasaporte y lo envía al especialista y este a su vez entrega el pasaporte a la persona solicitante del trámite. • Proceso de Realizar Convenio Se recibe una solicitud de firma de convenio por parte de las facultades de la UCLV o de una universidad extranjera a través de una carta de intención dirigida a la directora. La directora aprueba la solicitud. A partir de la aprobación de la solicitud empiezan las negociaciones. Luego, se intercambian las proformas de convenio entre la UCLV y la universidad extranjera. El Departamento Jurídico del Rectorado revisa y dictamina el documento a firmar. El documento es firmado por ambos rectores. Se registra el convenio en la base de datos. Los procesos anteriormente expuestos se encuentran implementados en el sistema informático, pero existen algunos errores internos como el registro de los usuarios al sistema, formularios que no incluyen todos los datos necesarios para los trámites. Por ello, estos procesos son sometidos a mejoras dentro del sistema para la DRI. Además, existe un proceso que no está implementado en el sitio, el de Realizar Contratos. Este será añadido en el sistema informático por su importancia dentro de la Dirección. • Proceso de Realizar Contratos Este contrato se confecciona en el momento de la llegada por primera vez del estudiante al centro. El estudiante debe realizar los pagos de acuerdo con el contrato firmado. Estos pagos se harán, siempre, antes de empezar los diferentes semestres hasta alcanzar el monto total a pagar especificado en el contrato. Se inicia cuando el especialista de OCSA adiciona un nuevo contrato al sistema. El especialista OCSA debe estar autenticado en el sistema. Luego de realizado el contrato, se le envía al DAEE un documento con los datos de todos los estudiantes que hayan realizado contratos y sus datos respectivos. 1.2 Refactorización. Proceso de la Ingeniería Informática Desde su creación los sistemas de software han sido utilizados, probados e incluso modificados. Desde entonces los seres humanos han interactuado con ellos en su vida cotidiana. No se puede concebir la vida actual del hombre sin la presencia de los sistemas informáticos (comunicaciones, medicina, transporte, etc.). A tal punto que paulatinamente los procesos de negocio consumen cada vez más información procesada por los sistemas de software, incluso hasta ser controlados y guiados por estos. Por ende, las especificaciones y el diseño de estos sistemas requieren de supuestos acerca de la aplicación dada, del dominio de la aplicación y de su ámbito operativo, hecho que a su vez se refleja en el software (Méndez, 2017). Una de las características esenciales del software es la complejidad. Es difícil encontrar un producto construido por el hombre que posea el grado de complejidad que tiene el software, ya sea, como proceso constructivo o como producto en sí mismo. La complejidad en la cual está sumergido el proceso de desarrollo de software se refleja en la rapidez de la evolución de los lenguajes de programación, herramienta fundamental en este proceso (Mendez, 2011). En los últimos 50 años la ingeniería de software ha visto nacer, crecer, vivir y perder notoriedad a cinco paradigmas de programación: el declarativo, el funcional, el estructurado, el orientado a objetos y el orientado a frameworks. A partir de los problemas detectados en el desarrollo de software se han realizado estudios sobre el ciclo de vida del proceso de desarrollo encontrándose algunos aspectos notables. Uno de ellos, se centra en la etapa de mantenimiento del software. Esta constituye la fase que requiere de más esfuerzos dentro del ciclo de vida del desarrollo del producto (Favre, 2006). A medida que el software evoluciona a través de sucesivas liberaciones de distintas versiones del producto, su código fuente también va cambiando. Es de vital importancia conocer qué componentes del producto siguen siendo estables y cuáles necesitan que se le aplique mantenimiento correctivo y cuáles no. Los softwares son susceptibles a que el código fuente decaiga en lo que se refiere a legibilidad, correctitud, calidad y otros aspectos internos. Las modificaciones hacen que el código empeore versión tras versión debido a la introducción de errores (bugs) en nuevas correcciones, a la adaptación a nuevos requisitos, etc. A partir de esta problemática una rama de la Ingeniería de Software se abocó a la investigación de cómo mejorar el código fuente, en base a la aplicación de transformaciones al código ya existente. La reestructuración de código fuente nació como la “aplicación de modificaciones al código fuente para hacerlo más fácil de cambiar y de comprender, o hacerlo menos susceptible a errores cuando futuros cambios fueran aplicados”. 1.2.1 Concepto y características La refactorización surge como un intento de mejorar la producción de software reusable. Para Fowler, citado por (Dallal, 2015), la refactorización es el proceso de cambio de un sistema de software de manera tal que no se altere el comportamiento externo del código, pero mejora su estructura interna. Es una manera disciplinada de limpiar código que minimiza las posibilidades de introducir errores. En esencia cuando se refactoriza se está mejorando el diseño del código después de que ha sido escrito. A medida que el software se va implementado, el equipo de desarrollo va haciendo cambios que pueden afectar la comprensión del problema a resolver. Esto puede ocasionar que el diseño original vaya desvaneciéndose, y sea más difícil comprenderlo mediante el código. Estos cambios pueden causar que se pierda el orden en el código y produce dificultad en la comprensión y mantenimiento. Refactorizar regularmente ayuda a que el código siga representando el diseño (Fowler, 1999). Una forma importante de mejorar el código es eliminando código duplicado, lo que tiene un impacto directo en las modificaciones futuras del código fuente. Mientras más código hay, más complicado es modificarlo correctamente, ya que hay más código para analizar. La reestructuración de programas surge como herramienta necesaria para ser aplicada en los procesos de mantenimiento debido a las características esenciales del software para reducir los costos de esta fase del proceso de desarrollo y como herramienta en la introducción de nueva funcionalidad dentro del ciclo evolutivo de las aplicaciones. El objetivo de la reestructuración de software es principalmente mantener o aumentar el valor del mismo (Mendez, 2011). La refactorización de código fuente reduce los costos de mantenimiento, a su vez aumenta la posibilidad de reutilización de componentes en otros sistemas y amplía el ciclo de vida del sistema aumentando de esta manera el valor del mismo. Existen algunos motivos por los cuales la refactorización del código fuente debe ser tenida en cuenta por los ingenieros de Softwares son: • Factores que están asociados a la comprensibilidad del código fuente: o Facilitar la documentación. o Facilitar las tareas de testing. o Facilitar las tareas de auditoría. o Reducir potencialmente la complejidad del software. • Reducir el tiempo que necesitan los programadores para familiarizarse con el sistema antes de implementar tareas de mantenimiento. • Hacer más fácil el reconocimiento de errores. • Facilitar la introducción de nueva funcionalidad. • Implementación de estándares en la estructura del código. 1.2.2 Ventajas y desventajas El proceso de refactorización favorece el mantenimiento del diseño del sistema, incremento de facilidad de lectura y comprensión del código fuente. Además, la detección temprana de fallos, aumento en la velocidad de programación (Dallal, 2015). Algunas de las ventajas más importantes, según Campo (2009) se detallan seguidamente. • Facilita la comprensión del código fuente, principalmente para los desarrolladores que no estuvieron involucrados desde el comienzo del desarrollo. El hecho de que el código fuente sea complejo de leer reduce mucho la productividad, ya que se necesita demasiado tiempo para analizarlo y comprenderlo. Invertir tiempo en refactorizarlo ayuda a que sea lo más auto documentable posible, facilita su comprensión y mejora la productividad. • Mejora la robustez del código escrito. Permite detectar errores. Cuando el código fuente es más fácil de comprender permite detectar condiciones propensas a fallos, o analizar supuestos desde los que se partió al inicio del desarrollo, que pueden no ser correctos. • Permite programar más rápido, lo que eleva la productividad de los desarrolladores. Un punto importante a la hora de desarrollar es qué tan rápido se puede hacer, de hecho, un factor clave para permitir el desarrollo rápido es contar con buenos diseños de base. La velocidad en la programación se obtiene al reducir los tiempos que lleva la aplicación de cambios. Si el código fuente no es fácilmente comprensible, entonces los cambios llevaran más tiempo. • Mejora el diseño del software. Evita que el diseño comience a perderse. Ayuda a eliminar código duplicado. Incrementa la lecto-comprensión del código fuente y reduce la cantidad de posibles fallas. Garantiza la calidad del software entregado, lo que aumenta la velocidad de desarrollo. A pesar de sus beneficios trae consigo algunas desventajas, según Campo (2009) como son: • Cambiar de base de datos, que trae dos problemas incluidos. El primero, los sistemas están fuertemente acoplados a los esquemas de las bases de datos. El segundo de ellos radica en la migración tanto estructural como de datos. Se debe separar el sistema por capas cuidadosamente para minimizar las dependencias entre el esquema de la base de datos y el modelo, lo que resulta muy costoso. • Cambiar de interfaz: Uno de los beneficios de la Programación Orientada a Objetos es el hecho de poder cambiar la implementación sin alterar la interface expuesta. El problema del cambio de interface no tiene demasiada complejidad si se tiene acceso al código fuente de todos los clientes de la interface a refactorizar. Es problemático cuando esta se convierte en interface pública (published interface) y no se dispone del código fuente modificable de los clientes de la misma. • Cambios en el diseño: Esta es un área en la que existen datos muy incompletos, por lo que a veces hay lugares donde esto se hace difícil. Refactorizar un sistema construido sin requisitos de seguridad es mucho más trabajoso que en otro con buena seguridad. Para cambiar de un diseño se debe pensar bien y analizar, poner el mayor esfuerzo posible, el diseño que se va a hacer nuevo. Otras desventajas, según (Khanam, 2018): • Cambiar de lenguaje de programación: La extracción de fragmentos de código suele ser una tarea ardua, ya sea de un método o de una clase varía con los diferentes paradigmas y lenguajes de programación. • Manual de implementación: Muy a menudo la refactorización se suele hacer manual debido a la falta de disponibilidad de la herramienta adecuada. Resulta engorroso el trabajo y muy duradero. 1.2.3 Tipos de código que necesitan una refactorización Para saber si algún código necesita una refactorización es necesario comprobar la lista de “Bad Smells”. Un Bad Smell es un indicio de que existe código de poca calidad. Según (Fowler, 1999), en su libro “Refactoring: Improving the Desing of Existing Code” expone sus consideraciones con respecto a cuándo emplear la refactorización según la lista de “Bad Smells”. Se muestran a continuación algunos tipos de refactorización: • Código duplicado (Duplicated Code): Si existe la misma estructura de código en varios sitios, lo mejor es unificarla en un único punto. • Método largo (Long Method): Los métodos pequeños son más claros en lo que hacen. Permiten compartir el código y elegir el método a llamar según el caso. La sobrecarga en la llamada a un método es casi despreciable, por lo que no debe ser excusa para usar métodos lo más pequeños posible. • Clase muy grande (Large Class): Una clase que hace demasiadas cosas suele tener muchas variables de instancia y tras ellas, suele haber código duplicado. Si una clase que no utiliza todas las variables de instancia en todo momento, las que no se usen se deberían eliminar o extraer a otra clase. • Cambio divergente (Divergent Change): Cuando hay que hacer un cambio, se debe identificar un único punto en el programa donde deba hacerse. Si hay una clase donde se deban cambiar tres métodos por una razón y otros cuatro por otra distinta, tal vez este objeto debería ser dividido en dos con distintas responsabilidades. • Agrupaciones de datos (Data Clumps): Si un grupo de datos aparecen constantemente juntos y se usan siempre en los mismos momentos, suele ser buena solución hacer una clase que contenga esos parámetros y pasar la clase en vez de todos los parámetros. Especialmente si esos parámetros suelen tener que ver unos con otros y suelen ir juntos siempre. • Lista muy larga de parámetros (Long Parameter List): En los Programas Orientados a Objetos, las listas de parámetros tienden a ser mucho más pequeñas que en los programas tradicionales. Las listas largas de parámetros son difíciles de entender porque se convierten en inconsistentes y difíciles de usar y, además, siempre se están cambiando a medida que se necesiten más datos. La mayoría de los cambios se eliminan al pasar objetos porque es más probable que necesite hacer solo un par de solicitudes para obtener un nuevo dato. • Comentarios (Comments): A veces los comentarios están enmascarando uno de los "malos olores" que se han visto anteriormente. Es mejor invertir el tiempo en mejorar este código que en comentarlo. Cuando se termina una refactorización se deben eliminar los comentarios redundantes. Es importante resaltar que el sistema informático existente necesita de una actualización en los procesos que tiene automatizados; por lo que se debe, antes de ello, hacer una refactorización del código fuente, pues, dicha técnica permite mejorar la comprensibilidad, la claridad, el diseño, la legibilidad y a su vez reducir la cantidad de errores, en definitiva, para mejorar la calidad del software. 1.3 Tendencias y tecnologías actuales empleadas en la implementación Para la actualización y refactorización del sistema informático se utilizó como framework para su desarrollo Symfony 3.0, que utiliza el lenguaje PHP en la versión 5.0 para el modelo y los controladores y el motor de plantillas Twig para las vistas. Se usó, además, MySQL como Sistema Gestor de Base de Datos (SGBD). 1.3.1 Framework Symfony Symfony es un completo framework diseñado para optimizar, gracias a sus características, el desarrollo de las aplicaciones web. Para empezar, separa la lógica de negocio, la lógica de servidor y la presentación de la aplicación web. Proporciona varias herramientas y clases encaminadas a reducir el tiempo de desarrollo de una aplicación web compleja. Además, automatiza las tareas más comunes, permitiendo al desarrollador dedicarse por completo a los aspectos específicos de cada aplicación. El resultado de todas estas ventajas es que no se debe reinventar la rueda cada vez que se crea una nueva aplicación web. Symfony está desarrollado completamente con PHP5. Ha sido probado en numerosos proyectos reales y se utiliza en sitios web de comercio electrónico de primer nivel. Symfony es compatible con la mayoría de gestores de bases de datos, como MySQL, PostgreSQL, Oracle y SQL Server de Microsoft. Se puede ejecutar tanto en plataformas *nix (Unix, Linux, etc.) como en plataformas Windows (Symfony, 2016). Symfony se diseñó para que se ajustara a los requisitos siguientes: • Fácil de instalar y configurar en la mayoría de plataformas (y con la garantía de que funciona correctamente en los sistemas Windows y *nix estándares). • Independiente del sistema gestor de bases de datos. • Sencillo de usar en la mayoría de los casos, pero lo suficientemente flexible como para adaptarse a los casos más complejos. • Basado en la premisa de “convenir en vez de configurar”, en la que el desarrollador solo debe configurar aquello que no es convencional. • Sigue la mayoría de las mejores prácticas y patrones de diseño para la web. • Preparado para aplicaciones empresariales y adaptable a las políticas y arquitecturas propias de cada empresa. Además de ser lo suficientemente estable como para desarrollar aplicaciones a largo plazo. • Código fácil de leer que incluye comentarios de phpDocumentor y permite un mantenimiento muy sencillo. • Fácil de extender, permitiendo su integración con bibliotecas desarrolladas por terceros. Doctrine y DQL Doctrine es un mapeador de objetos-relacional escrito en PHP que proporciona una capa de persistencia para objetos PHP. El componente que se encarga por defecto de gestionar el modelo en Symfony es una capa de tipo ORM (object/relational mapping). En las aplicaciones Symfony, el acceso y la modificación de los datos almacenados en la base de datos se realiza mediante objetos así. Nunca se accede de forma explícita a la base de datos. Este comportamiento permite un alto nivel de abstracción y permite una fácil portabilidad. La principal ventaja que aporta el ORM es la reutilización, permitiendo llamar a los métodos de un objeto de datos desde varias partes de la aplicación e incluso desde diferentes aplicaciones. La capa ORM también encapsula la lógica de los datos. La utilización de objetos en vez de registros y de clases en vez de tablas permiten añadir métodos accesores en los objetos que no tienen relación directa con una tabla. Twig y PHP Twig es un motor de plantillas desarrollado para el lenguaje de programación PHP. Nace con el objetivo de facilitar a los desarrolladores de aplicaciones web, que utilizan la arquitectura MVC, el trabajo con la parte de las vistas. Gracias a, que se trata de un sistema que resulta muy sencillo de aprender y capaz de generar plantillas con un código preciso y fácil de leer. Actualmente el código se distribuye bajo licencia BSD y es utilizado por el framework Symfony, aunque puede ser utilizado directamente con proyectos desarrollados en PHP en el que no interviene ese framework. Principales características de Twig (Pacheco, 2013): • Rápido: Compila las plantillas hasta código PHP regular optimizado. El costo general en comparación con código PHP regular se ha reducido al mínimo. • Seguro: Tiene un modo de recinto de seguridad para evaluar el código de plantilla que no es confiable. Esto te permite utilizar Twig como un lenguaje de plantillas para aplicaciones donde los usuarios pueden modificar el diseño de la plantilla. • Flexible: Es alimentado por flexibles analizadores léxico y sintáctico. Esto permite al desarrollador definir sus propias etiquetas y filtros personalizados. 1.3.2 Lenguaje PHP PHP es un lenguaje de programación para páginas y sitios web del lado del servidor. Las características principales son la independencia de plataforma y su gratuidad. Se ejecuta en el servidor web. Para poder programar en PHP se requiere de un servidor preparado para ello (Rodríguez, 2019). Para poder programar en PHP se requiere de un servidor preparado para ello. Como el lenguaje de programación es multiplataforma, cualquiera de los principales servidores web servirá para su uso adecuado. Además, es un lenguaje no posicional, separa las sentencias por ‘;’ y es sensible a mayúsculas y minúsculas (case sensitive). Es considerado un lenguaje fácil de aprender, con abundante documentación. Posee gran capacidad de conexión con la mayoría de los motores de base de datos utilizados actualmente y tiene la capacidad de expandir su potencial utilizando módulos. Es libre, su diseño modular y sencillo ha dejado una multitud de bibliotecas que facilitan el trabajo con la web. Algunas de las ventajas y desventajas que presenta PHP, según (Abreu, 2016a): • Es un lenguaje multiplataforma, completamente orientado al desarrollo de aplicaciones web dinámicas con acceso a información almacenada en una Base de Datos. • El código fuente escrito en PHP es invisible al navegador y al cliente ya que es el servidor el que se encarga de ejecutar el código y enviar su resultado HTML al navegador. Esto hace que la programación en PHP sea segura y confiable. • Capacidad de conexión con la mayoría de los motores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL y PostgreSQL. • Es libre, por lo que se presenta como una alternativa de fácil acceso para todos. • Permite aplicar técnicas de programación orientada a objetos. • No requiere definición de tipos de variables, aunque sus variables se pueden evaluar también por el tipo que estén manejando en tiempo de ejecución. • Tiene manejo de excepciones (desde PHP5). Una de las desventajas fundamentales es que al ser un lenguaje interpretado se necesita tener el intérprete de PHP, y esto lleva al alto consumo de las aplicaciones, ya que son imposibles de compilar. 1.3.3 Sistema Gestor de Base de Datos MySQL MySQL es un gestor de bases de datos, y actualmente uno de los más usados y reconocidos del mercado. Especialmente en lo que se refiere a desarrollo web, está clasificada como la base de datos de código abierto más popular del mundo. Está desarrollado mayormente por una mezcla de los lenguajes C y C++. Es uno de los cuatro componentes del paquete de desarrollo LAMP, para Linux y WAMP, para Windows Server. MySQL es utilizado por sitios webs muy populares y de gran tamaño. Está muy ligado a PHP en lo que se refiere a este tipo de desarrollos. Es una base de datos que presenta rapidez en lectura, sobre todo cuando se utilizan ciertos motores como MylSAM o InnoDB. Características de MySQL • Permite escoger múltiples motores de almacenamiento para cada tabla. • Agrupación de transacciones, pudiendo reunirlas de forma múltiple desde varias conexiones con el fin de incrementar el número de transacciones por segundo. • Conectividad segura. • Ejecución de transacciones y uso de claves foráneas. • Presenta un amplio subconjunto del lenguaje SQL. • Replicación • Disponible en casi todas las plataformas o sistemas. • Búsqueda e indexación de campos de texto. • Utiliza varias herramientas para portabilidad. • Tablas hash en memorias temporales • Uso de tablas en disco b-tree para búsquedas rápidas con compresión de índice. • Ofrece un sistema de contraseñas y privilegios seguros de verificación basada en el host y tráfico de contraseñas encriptado al conectarse a un servidor. • Uso de multihilos mediante hilos de kernel. • Soporta gran cantidad de datos, incluso con más de 50 millones de registros. • En las últimas versiones, se permiten hasta 64 índices por tablas. Cada índice puede consistir desde 1 a 16 columnas o partes de columnas. El máximo ancho de límite es de 1000 bytes. 1.4 Conclusiones Parciales En este capítulo se determinan los cambios en los procesos que se desarrollan internamente en la DRI-UCLV a partir de la caracterización de esta Dirección, sus departamentos y los procesos que se llevan a cabo en cada uno de ellos. Además, se selecciona una versión más actualizada del framework de Symfony para el desarrollo de la nueva versión del sistema informático y un conjunto de herramientas de apoyo. CAPÍTULO 2: DISEÑO E IMPLEMENTACIÓN Capítulo 2: Diseño e Implementación 22 2. DISEÑO E IMPLEMENTACIÓN En este capítulo se presentan el modelo del negocio de la DIR-UCLV teniendo en cuenta las modificaciones y actualizaciones de sus procesos. Se muestran los diagramas UML más importantes, modelos, requisitos funcionales y no funcionales del negocio. Además, se explican los pasos más relevantes del proceso de refactorización aplicado al código fuente del software SIRI-UCLV. Así como, la justificación de cada uno de ellos. 2.1 Reglas del Negocio El Lenguaje Unificado de Modelado (UML) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad. Se le puede definir como un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema (Orallo, 2017). UML ofrece un estándar para describir un plano del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación y esquemas de bases de datos. Existen dos tipos de diagramas: los estructurales que entre ellos se encuentran los diagramas de clases, componentes, despliegue y objetos; y los diagramas de comportamiento como son el diagrama de actividades, casos de uso, máquinas de estado y secuencia. Para el sistema informático que se pretende actualizar y refactorizar deben considerarse las reglas y políticas que se establecen en el negocio. Anteriormente, en el capítulo 1 se presenta el modelo del negocio mediante una descripción del funcionamiento de los procesos llevados a cabo en la DRI-UCLV. A partir de ello se plantean las reglas a tener en cuenta en dicho negocio. 2.1.1 Reglas del negocio a considerar Seguidamente se muestran las reglas del negocio relacionadas con la DRI-UCLV descritas por Raúl y Alejandro (2016). • RN1: Pasaporte • RN2: Pagos de estudiantes autofinanciados • RN3: Viajar por ANTEX • RN4: Validez de los Convenios • RN5: Convenio Activo Capítulo 2: Diseño e Implementación 23 • RN6: Visa Académica para estudiantes • RN7: Acuerdos de Contratación • RN8: Pagos de visitas por paquete de agencia Se añadió el siguiente: • RN9: Contrato Activo Un contrato está activo mientras el estudiante se encuentre cursando una materia. 2.1.2 Actores del Negocio Un actor es alguien o algo que interactúa con el sistema, pero que es externo al sistema, según (Mediavilla, 2014). El actor envía o recibe mensajes a y desde el sistema. Un caso de uso siempre es iniciado por un actor que le envía un mensaje o estímulo; es por eso que los actores llevan a cabo los casos de uso. Cuando un caso de uso se realiza, el caso de uso podría enviar mensajes a uno o más actores. Estos mensajes también pueden ir a otros actores además del que inició el caso de uso. En (Abreu, 2016b) se presentaron y describieron mediante la tabla 1 de la página 27 a los actores del negocio, estos son: Personal de la UCLV (estudiante, profesor, investigador o trabajador de la UCLV) y Estudiante extranjero (becario por concepto de intercambio bilateral, auto financiado y financiado por el gobierno). 2.1.3 Diagrama de Casos de Uso Los Casos de Uso del sistema informático se muestran y describen de forma correcta en el trabajo de los autores (Abreu, 2016a). Seguidamente se mencionan los Casos de Uso según el actor que lo realizan: • Especialista del Departamento de Colaboración Internacional: gestionar redes o asociaciones, gestionar visitas a la UCLV, realizar convenios, gestionar estudiantes de intercambio, gestionar personas, confeccionar reportes. • Especialista del DAEE: registrar estudiantes extranjeros, gestionar personas, chequear pagos de contratos, confeccionar reportes. Capítulo 2: Diseño e Implementación 24 • Especialista de OCSA: gestionar viajes por ANTEX, gestionar viajes por CUBATECNICA, gestionar visitas por paquete de agencias, gestionar persona, confeccionar contrato, confeccionar reportes. • Especialista de oficina de trámites: gestionar propuestas de salida, gestionar persona, gestionar tarjeta de datos, confeccionar reportes. • Director: tiene derecho a realizar todas las acciones listadas anteriormente. • Administrador: gestionar usuarios. Es muy importante resaltar que el Caso de Uso “Confeccionar Contrato” no estaba implementado en el sistema precedente. Como parte de las modificaciones realizadas al sistema, se implementó este Caso de Uso. 2.1.3 Descripción de los Casos de Uso del Sistema Según (IVAR JACOBSON, G. B., 2000), un modelo de caso de uso del negocio describe los procesos de una empresa en términos de casos de uso del negocio y actores del mismo que se corresponden con los procesos del negocio y los clientes, respectivamente. El modelo de casos de uso del negocio presenta un sistema, desde la perspectiva de su uso, y esquematiza como proporciona valor a sus usuarios. Las descripciones de los Casos de Uso del Sistema informático se muestran y describen de forma correcta en el trabajo de los autores (Abreu, 2016a). En la Tabla se muestra, adicionalmente, la descripción del Caso de Uso “Confeccionar Contrato”. Caso de Uso del Sistema Confeccionar Contrato Actores Especialista de OCSA, Director de DRI Propósito Insertar un contrato Resumen El Caso de Uso del Sistema inicia cuando el especialista de OCSA adiciona un nuevo contrato al sistema Precondiciones El especialista de OCSA debe estar autenticado en el sistema Descripción Capítulo 2: Diseño e Implementación 25 Flujo normal de los eventos Acciones del actor Respuesta del sistema 1. El especialista de OCSA elige la opción Crear Contrato (A). 3. El especialista de OCSA inserta los datos en el formulario (todos los valores del 1 al 16), los campos que tiene el asterisco (*) rojo son obligatorios. 4. El especialista de OCSA escoge la opción Adicionar (17). 2. El sistema muestra la ventana para la inserción de los datos (B). 5. El sistema revisa que no existan campos obligatorios vacíos y que los datos insertados sean correctos (B). 6. El sistema guarda los datos en la base de datos. 7. El sistema muestra la vista de los datos del contrato que acaba de ser insertado (C). Otra sección Capítulo 2: Diseño e Implementación 26 Presionar Botón Cancelar 4. El especialista de OCSA escoge la opción Cancelar (18). 5. El sistema regresa a la pantalla inicial (A). Flujo alternativo de eventos Mensajes de error por presentar campos vacíos o datos incorrectos 4. El especialista de OCSA escoge la opción Adicionar (17). 5.El sistema revisa que no existan campos obligatorios vacíos y que los datos insertados sean correctos. 6. El sistema muestra mensaje de error por la existencia de campos vacíos o con datos incorrectos. 7. El sistema regresa a la pantalla inicial (A). 2.1.4 Diagramas de Paquetes Los Diagramas de Paquetes son un tipo de modelado que muestran cómo se divide en agrupaciones lógicas de un sistema, de acuerdo a las relaciones de interdependencia que presentan dichas agrupaciones. Por tanto, a través de los Diagramas de Paquetes se puede descomponer, para la fácil comprensión de la estructura de una aplicación, la jerarquía lógica que presenta el sistema. Las agrupaciones lógicas que presenta la aplicación desarrollada en este trabajo son las descritas en (Abreu, 2016a). 2.2 Pasos para la refactorización Se decidió refactorizar el sistema porque era necesario hacerlo más entendible para que el código quedara preparado para adicionarle nuevas funcionalidades y de esta manera simplificar la implementación de las nuevas funcionalidades. Además, se necesitaban corregir algunos errores de implementación y de cambios de funcionalidad. Primeramente, se aplicaron algunas técnicas de reestructuración de software. El objetivo de la reestructuración principalmente es mantener o aumentar el valor del mismo durante los procesos de mantenimiento. La reestructuración crea nuevas versiones que implementan o proponen cambios al sistema, no provoca modificaciones a raíz de las variaciones realizadas en los requisitos del sistema. Capítulo 2: Diseño e Implementación 27 En cuanto al Estilo de programación, se reestructuró el código fuente para hacerlo más fácil de comprender. Se aplicaron: Bien mostrado y formateado el código (Pretty printing and code formatting): con ella se mejoró el aspecto del código fuente aplicando la identación, espaciado, se organizó a una instrucción por línea, etc. Estandarización del estilo de programación (Programming Style Standarization): Se modificó el código fuente del programa para hacerlo compatible con Symfony 3.0. Esto conllevó muchos cambios en la forma de implementar las funcionalidades, cambios en las funciones básicas de Symfony, cambios en la lógica interna, en la forma de implementar los formularios. Algunos ejemplos de los cambios son en la forma de realizar los formularios, para la utilización de los diferentes tipos de datos y en la forma de mostrarlo en las vistas. Otro cambio relevante es en la utilización de los componentes request del sistema. En cuanto a la información gestionada por el sistema, se hicieron cambios en el diseño y la estructura de la base de datos. Hubo campos redundantes que se eliminaron, entidades que se adicionaron y se establecieron nuevas relaciones. La entidad Contrato se creó nueva, con los campos id, nro_contrato, monto_total, monto_reduccion, fecha_inicio, fecha_expiracion, anno_cursa, curso_academico, especialidad, estado, estudianteext, facultad, carrera, diplomado, doctorado, maestria y tipo_estudio, y los métodos gets y sets.. Además, se crearon los ficheros que facilitan la creación de los formularios para Realizar los Contratos. Se decidió cambiar el SGBD a MySQL pues este es el gestor por defecto que contienen los servidores de páginas web más utilizados, como por ejemplo el XAMPP que se utilizó en el desarrollo del trabajo. Luego de establecidas las bases se comenzó a revisar en el código fuente los malos olores (Bad Smell).  El código era difícil de entender debido a: o Variables con nombres ambiguos o Lógica condicional muy compleja o Bloques de código muy extensos o Baja cohesión de módulos Capítulo 2: Diseño e Implementación 28 o Alto acoplamiento de módulos o En Programación Orientada a Objetos: • Clases mal definidas • Métodos mal definidos Algunas refactorizaciones realizadas:  Refactorización simple: o Renombre de variables. o Renombre de Métodos o Cambio en el tipo de una variable interna. o Externalizar una variable.  Refactorización compleja: o Externalizar un método o Extraer una interface. o Eliminar una serie de if usando polimorfismo. 2.3 Conclusiones del capítulo En este capítulo se refleja la arquitectura del sistema que está estrechamente vinculada al framework de desarrollo Symfony en su versión XXX. Se ajustan los elementos descritos para reflejar los cambios y las adiciones de la nueva versión del software. Se hace el proceso de refactorización para garantizar un mejor código e implementar a partir de este los cambios y extensiones en los procesos de la DRI-UCLV. 29 CAPÍTULO 3: Descripción de la propuesta de solución Capítulo 3: Descripción de la propuesta de solución 30 3. Descripción de la propuesta de solución En este capítulo se desarrolla la propuesta de refactorización del sistema, describiendo los servicios web diseñados, la arquitectura del sistema. Se muestran los diagramas de clase, de secuencia y el diagrama de despliegue, así como el diseño de la base de datos y el modelo de componentes. 3.1 Arquitectura del sistema El sistema se implementó en Symfony en su versión 3.1.6. Este presenta una arquitectura Modelo Vista Controlador (MVC): Symfony está basado en un patrón clásico del diseño web conocido como arquitectura MVC, que está formado por tres niveles (SENSIOLABS, 2010):  El modelo: representa la información con la que trabaja la aplicación, es decir, su lógica de negocio.  La vista: transforma el modelo en una página web que permite al usuario interactuar con ella.  El controlador: se encarga de procesar las interacciones del usuario y realiza los cambios apropiados en el modelo o en la vista. La arquitectura MVC separa la lógica de negocio (el modelo) y la presentación (la vista) por lo que se consigue un mantenimiento más sencillo de las aplicaciones. Si por ejemplo una misma aplicación debe ejecutarse tanto en un navegador estándar como un navegador de un dispositivo móvil, solamente es necesario crear una vista nueva para cada dispositivo; manteniendo el controlador y el modelo original. El controlador se encarga de aislar al modelo y a la vista de los detalles del protocolo utilizado para las peticiones (HTTP, consola de comandos, email, etc.). El modelo se encarga de la abstracción de la lógica relacionada con los datos, haciendo que la vista y las acciones sean independientes de, por ejemplo, el tipo de gestor de bases de datos utilizado por la aplicación. 3.2 Diagrama de Clases del Diseño Los Diagramas de Clases del Diseño del Sistema Informático se muestran y describen de forma correcta en el trabajo de los autores (Abreu, 2016a). En la Figura se hace referencia al Diagrama de Clases del Diseño correspondiente al especialista de OCSA y al caso de uso “Crear contrato”. Capítulo 3: Descripción de la propuesta de solución 31 Figura 12 Diagrama de clases de diseño para el especialista de Colaboración Internacional Partiendo de la clase principal, el especialista de OCSA tiene la opción de acceder a varios enlaces (Estudiantes extranjeros, Acciones ANTEX, Acciones ACORED, Paquete de agencia y Contratos). Al acceder al enlace Contrato se muestra la opción “Crear un nuevo contrato”. Cuando se escoge dicha opción, el sistema a través de la clase controladora ContratoController muestra una página al cliente, compuesta por un formulario ContratoType donde se deben insertar los datos siempre que se pretenda realizar un nuevo contrato. Luego, de insertados los datos, estos son enviados a la clase controladora ContratoController. Esta es la encargada de guardar los datos en la clase modelo Contrato. 3.3 Diagrama de secuencia Un Diagrama de Secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada Caso de Uso. Mientras que el Diagrama de Casos de Uso permite el modelado de una vista del escenario del negocio, el Diagrama de Secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos. Típicamente se examina la descripción de un Caso de Uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de Cada caso de Uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un Diagrama de Secuencia muestra Capítulo 3: Descripción de la propuesta de solución 32 los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales. Los diagramas de secuencias para el Caso de Uso “Gestionar propuesta de salida” se muestra y describe de forma correcta en el trabajo de los autores (Abreu, 2016a). En la Figura 13 se presenta la secuencia que persigue el sistema en el Caso de Uso relacionado con “Gestionar la Contratos de la UCLV “que es la funcionalidad nueva que se le añade al sistema. 3.4 Tratamiento de errores El tratamiento de los errores es fundamental para el buen funcionamiento de cualquier sistema. Particularmente en el sistema SIRI, se validarán todos los formularios de entrada de datos para garantizar así que toda la información que se almacena en la base de datos sea correcta. Por ejemplo, si se dejan campos en blancos se indicará al usuario lo que está ocurriendo Si se introduce información que ya se encuentra en la base de datos, recibirá un mensaje indicándole que dicha información ya está almacenada. Además, cuando sea posible se utilizarán campos de selección de información para evitar así que el usuario entre información errónea y si se le olvida seleccionar la información, recibirá un mensaje indicándole que le faltó. Los tratamientos de errores del Sistema Informático se muestran y describen de forma correcta en el trabajo de los autores (Abreu, 2016a). Se describen los tratamientos de errores por validaciones de campos como “carné de identidad”, “nombres” que deben comenzar con Capítulo 3: Descripción de la propuesta de solución 33 mayúscula, de campos “emails”. Además, se mencionan validaciones con lenguaje JavaScript para evitar repeticiones de carné de identidad. 3.5 Diseño de la Base de Datos El modelado de la Base de Datos es de gran importancia, ya que esta muestra cómo están encauzadas las disímiles entidades que conforman la Base de Datos. Además, se muestra un conjunto de condiciones que deben cumplir los datos que van a ser insertados. Dicho modelado de la Base de Datos sirve como respaldo para un mejor entendimiento de los tipos de datos que la conforman, así como el tipo de relación que existe entre estos. El diseño de la Base de Datos del Sistema se muestra y describe de forma correcta en el trabajo de los autores(Abreu, 2016a). Al modelo planteado se le realizaron algunos cambios en el proceso de refactorización. Se hicieron cambios en el diseño y la estructura de la Base de Datos. Hubo campos y entidades redundantes que se eliminaron y se establecieron nuevos campos para suplir las entidades eliminadas. Las entidades eliminadas fueron convenio_documentos, viaje_aprobación y profesor_integración. Para suplir las entidades se crearon campos que relacionan las entidades que permanecieron en el modelo. La figura muestra el modelo físico de datos completos del sistema descritas por Raúl y Alejandro (2016). Las entidades marcadas con un óvalo rojo se mantuvieron en la refactorización. Las amarillas no existían realmente y se realizó un análisis y se determinó que no eran necesarias añadirlas al sistema ya que se podían modelar de una forma más sencilla añadiendo campos a la entidad con las que relacionaban, en vez de tener una nueva entidad, la cual no iba a cumplir ningún objetivo. Las marcadas en negro son entidades que en la refactorización se decidieron eliminar ya que eran entidades intermedias entre dos entidades que no aportaban ninguna relevancia lógica. Para la acomodar el modelo a los nuevos cambios se hizo necesario el cambio de atributos de las entidades que se mantuvieron. Capítulo 3: Descripción de la propuesta de solución 34 3.6 Modelo de Componentes Los Diagramas de Componentes son utilizados para modelar una vista estática del sistema. Muestran la organización y las dependencias lógicas entre un conjunto de componentes software como son: componentes de código fuente, bibliotecas o componentes de código ejecutable. En la Figura 19 se muestra el Diagrama de Componentes correspondiente al sistema, mostrando un componente de tipo file llamado “Principal”. Este conduce a la vista. Mediante la vista se Capítulo 3: Descripción de la propuesta de solución 35 accede al controlador, el cual es el encargado de gestionar toda la lógica del software para su correcto funcionamiento Además del controlador, la vista está relacionada con varias bibliotecas, tales como la biblioteca Boostraps. Esta actúa como complementario de la vista. La biblioteca jQuery, brindado todos los métodos JavaScripts necesarios para el funcionamiento correcto de la vista. También, se encuentra la DataTable, la cual posee las funciones correspondientes para el filtrado de los datos en las tablas. Otra biblioteca es la FormValidation, encargada de proporcionar las reglas para la validación de la entrada de los datos suministrados por los usuarios del sistema. Figura 19 Modelo de componentes 3.7 Diagrama de Despliegue Un Diagrama de Despliegue muestra un conjunto de nodos y sus relaciones. Los Diagramas de Despliegue se utilizan para describir la vista de despliegue estática de una arquitectura. Dicho diagrama está conformado por distintos componentes, según Raúl y Alejandro. “Estos componentes son los necesarios y suficientes para formar un sistema ejecutable, tales como las bibliotecas dinámicas (DLL, Dynamic Link Libraries) y los ejecutables (EXE), que quizás impliquen páginas web dinámicas, tablas de bases de datos y ejecutables que utilicen mecanismos de comunicación propietarios”. Capítulo 3: Descripción de la propuesta de solución 36 La aplicación necesitará al menos una computadora cliente, la cual se conectará a la computadora servidor mediante el protocolo HTTP. A continuación, se presenta el diagrama propuesto. En la siguiente Figura 20 se muestra el Diagrama de Despliegue para conocer cómo se encuentra distribuida la aplicación. Figura 20 Diagrama de despliegue EL nodo “Servidor SIRI-UCLV”, provee los servicios del sistema a los nodos clientes, almacena todos los archivos que conforman el entorno y procesa las solicitudes de los clientes en la red. Este se conecta vía TCP/IP al nodo servidor de Base de Datos en el cual se encuentra montado el servidor Apache al que está conectado el Servidor de Base de Datos de MySQL. El nodo “PC del Cliente” accede a los servicios del sistema en el servidor de forma remota a través de la red, a su vez tiene conectado una impresora vía USB. En el nodo “Servidor” hace falta tener instalado un servidor Apache y para la Base de Datos se necesita el Gestor de Base de Datos MySQL. El sistema se despliega en el servidor apache y se ejecutan los siguientes comandos desde la línea de comandos para crear el esquema de la base de datos. php bin/console doctrine:database:create php bin/console doctrine:schema:create Capítulo 3: Descripción de la propuesta de solución 37 Luego se accede al panel de administración del Sistema Gestor de Base de Datos y se importan los datos existentes en el fichero siri.sql, el cual contiene los nomencladores listos para comenzar a trabajar con el sistema 3.8 Conclusiones del capítulo XXXXXXXXXXXXXXXXXXXXX 38 CAPÍTULO 4: PRUEBAS Y ANÁLISI DE FACTIBILIDAD Capítulo 4: Pruebas realizadas al sistema 39 4. PRUEBAS Y ANÁLISIS DE FACTIBILIDAD En el presente capítulo se desarrolla además de los casos de prueba apoyados en caja negra, el análisis de factibilidad utilizando la planificación basada en uno de los métodos de estimación, siendo el de casos de uso el seleccionado para esta ocasión. 4.1 Planificación basada en uno de los métodos de estimación La planificación es un proceso de toma de decisiones para alcanzar un futuro deseado, teniendo en cuenta la situación actual y los factores internos y externos que pueden influir en el logro de los objetivos. 4.1.1 Estimación basada en Casos de Uso La estimación mediante el análisis de puntos de Casos de Uso es un método propuesto originalmente por Gustav Karner de Objectory AB, y posteriormente refinado por muchos otros autores. Se trata de un método de estimación del tiempo de desarrollo de un proyecto mediante la asignación de "pesos" a un cierto número de factores que lo afectan, para finalmente, contabilizar el tiempo total estimado para el proyecto a partir de esos factores (Josue Carralero Iznaga, 2006). 4.1.1.1 Estimación del Esfuerzo Basada en Casos de Uso. Cálculo de Puntos de Casos de Uso sin Ajustar (UUCP). Este valor se calcula a partir de la siguiente ecuación: UUCP = UAW + UUCW donde, UUCP: Puntos de Casos de uso sin Ajustar UAW: Factor de Peso de los actores sin Ajustar UUCW: Factor de Peso de los Casos de Uso sin Ajustar Determinación del Factor de Peso de los Actores sin Ajustar (UAW) Este valor se calcula mediante un análisis de la cantidad de Actores presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de los actores se establece, teniendo en cuenta en primer lugar, si se trata de una persona o de otro sistema y, en segundo lugar, la forma en que el actor interactúa con el sistema como aparece a continuación en la Tabla 7 correspondiente a los Factores de Peso de los Actores: Tabla 7 Factores de peso de los actores Capítulo 4: Pruebas realizadas al sistema 40 Tipo de actor Descripción Factor de peso Número de actores Resultado Simple Otro sistema que interactúa con el sistema a desarrollar mediante una interfaz de programación (API, Aplication Programming Interface) 1 0 0 Promedio Otro sistema que interactúa con el sistema a desarrollar mediante un protocolo o una interfaz basada en texto. 2 0 0 Complejo Una persona que interactúa con el sistema mediante una interfaz gráfica. 3 6 18 Total 18 De manera que UAW = 18 Determinación del Factor de Peso en los Casos de Uso sin Ajustar (UUCW). Este valor se calcula mediante un análisis de la cantidad de Casos de Uso presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de los Casos de Uso se establece teniendo en cuenta la cantidad de transacciones efectuadas en el mismo, donde una transacción se entiende como una secuencia de actividades atómicas, es decir, se efectúa la secuencia de actividades completa, o no se efectúa ninguna de las actividades de la secuencia. Determinación del factor de peso en los casos de uso sin ajustar (UUCW) Este valor se calcula mediante un análisis de la cantidad de Casos de Uso presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de los Casos de Uso se establece teniendo en cuenta la cantidad de transacciones efectuadas en el mismo, donde una transacción se entiende como una secuencia de actividades atómicas, es decir, se efectúa la secuencia de actividades completa, o no se efectúa ninguna de las actividades de la secuencia. En la Tabla 8 se muestran los Factores de Peso correspondiente a los Casos de Uso. Tabla 8 Factores de peso de los casos de uso. Tipos de Casos de uso Descripción Factor de peso Número de Casos de Uso Resultado Simple 1-3 Transacciones 5 2 10 Promedio 4-7 Transacciones 10 13 130 Complejo Mayor de 8 Transacciones. 15 1 15 Total 145 Capítulo 4: Pruebas realizadas al sistema 41 UUCW = 145 Calculando UUCP = UAW + UUCW UUCP = 18 + 145 UUCP = 163 Cálculo de Puntos de Casos de Uso ajustados. Seguidamente de calcular los Puntos de Casos de Uso sin Ajustar, se debe ajustar este valor mediante la siguiente ecuación: UCP = UUCP x TCF x EF donde, UCP: Puntos de Casos de Uso ajustados UUCP: Puntos de Casos de Uso sin ajustar TCF: Factor de complejidad técnica EF: Factor de ambiente Determinación del Factor de Complejidad Técnica (TCF) Este coeficiente se calcula mediante la cuantificación de un conjunto de factores que determinan la complejidad técnica del sistema. Cada uno de los factores se cuantifica con un valor de 0 a 5, donde 0 significa un aporte irrelevante y 5 un aporte muy importante. En la siguiente Tabla 9 se muestran los factores de complejidad técnica a tener en cuenta. Tabla 9 Factores de complejidad técnica. Número de factor Descripción Peso Valor Factor Comentario T1 Sistema Distribuido 2 4 8 El sistema es Web, por lo que posee cierto nivel de distribución. T2 Tiempo de respuesta 1 3 3 El tiempo de respuesta respalda los objetivos que se persiguen con el proyecto realizado, por lo que es el adecuado. T3 Eficiencia por el usuario 1 3 3 El usuario no tiene que ser eficiente necesariamente. T4 Proceso interno complejo 1 2 2 El sistema no posee cálculos complejos, aunque proporciona una serie de datos lógicos que necesitan un nivel medio de conocimiento para lograr su correcta comprensión. Capítulo 4: Pruebas realizadas al sistema 42 T5 Reusabilidad 1 5 5 Se desea que el código sea lo más reutilizable posible por las magnitudes que puede alcanzar el software. T6 Facilidad de instalación 0.5 1 0.5 Por ser un sistema Web la complejidad de instalación es mínima. T7 Facilidad de uso 0.5 5 2.5 El software debe ser muy fácil de usar por cuanto los clientes no siempre tienen dominio sobre el trabajo con sistemas informáticos. T8 Portabilidad 2 2 4 Los usuarios del sistema no pretenden hacer cambios en el SO. T9 Facilidad de cambio 1 5 5 El sistema se encuentra estructurado para que los cambios realizados afecten lo menos posible las funcionalidades. T10 Concurrencia 1 5 5 La concurrencia es tratada con suma importancia, pues pueden existir varios clientes conectados a la vez en el mismo instante. T11 Objetivos especiales de seguridad 1 5 5 La seguridad del sistema es un tema bastante controlado, ya que el sistema sólo permite que un usuario realice las funcionalidades correspondientes a su rol dentro del sitio. T12 Acceso directo a terceras partes 1 2 2 La aplicación es accesible a cualquier usuario. T13 Facilidades especiales de entrenamiento a usuarios finales 1 1 1 No se hace necesario el entrenamiento de los usuarios finales, debido a la facilidad de uso que presenta el sistema, pero se debe incluir un manual de usuario para garantizar la correcta usabilidad de dicho sistema. Total factor 46 El Factor de complejidad técnica se calcula mediante la siguiente ecuación: TCF = 0.6 + 0.01 * Σ(Pesoix Valor asignadoi) TCF = 0.6 + 0.01* 46 TCF = 1.06 Determinación del Factor Ambiente (EF). Las habilidades y el entrenamiento del grupo involucrado en el desarrollo tienen un gran impacto en las estimaciones de tiempo. Estos factores son los que se contemplan en el cálculo del Factor de Ambiente mostrado en la Tabla 10. Capítulo 4: Pruebas realizadas al sistema 43 Tabla 10 Factores de ambiente. Número del factor Descripción Peso Valor Factor Comentario E1 Familiaridad con el modelo del proyecto usado. 1.5 5 7.5 Se está familiarizado con el modelo del proyecto, pero la experiencia en el modelado es media. E2 Experiencia en la aplicación 0.5 5 2.5 Con el estudio profundo a cerca del lenguaje a utilizar se ha adquirido suficiente experiencia durante el período de trabajo. E3 Experiencia OO. 1 5 5 Se considera cierto grado de experiencia en la Programación Orientada a Objetos (OO), debido a que esta es la que se ha estudiado en cursos anteriores. E4 Capacidad del analista líder. 0.5 5 2.5 No existe analista líder, los analistas que integran el equipo de trabajo poseen capacidad media. E5 Motivación. 1 5 5 Existe alta motivación ya que con este proyecto se van a agilizar la ejecución de todos los procesos que se llevan a cabo en la DRI-UCLV. E6 Estabilidad de los requerimientos. 2 5 10 Aunque el sistema se encuentra sujeto a cambios, el mismo brinda las funcionalidades esenciales que dan cumplimiento a los objetivos que iniciaron su realización. E7 Personal media jornada. -1 0 0 Se trabajará a tiempo completo. E8 Dificultad en lenguaje de programación. -1 0 0 Como el lenguaje empleado fue C# y este ofrece grandes facilidades y ventajas, se considera una dificultad media su empleo. Total 32.5 El factor de ambiente se calcula mediante la siguiente ecuación: EF = 1.4 – 0.03 * Σ (Pesoix Valor asignadoi) EF = 1.4 – 0.03 * 32.5 EF = 0.42 Capítulo 4: Pruebas realizadas al sistema 44 Cálculo de los Puntos de Casos de Uso Ajustados UCP = UUCP * TCF * EF UCP = 163 * 1.06* 0.42 UCP = 72.57 Cálculo del esfuerzo El esfuerzo en horas-hombre viene dado por: E = UCP * CF donde: E: esfuerzo estimado en horas-hombre. UCP: Puntos de Casos de Uso ajustados. CF: Factor de conversión (20 horas-hombre por defecto) E= 72.57* 20 E = 1451.4 Horas-Hombre Para la obtención de una estimación más exacta de la duración del proyecto, se hace necesario agregar a la estimación del esfuerzo obtenida por los puntos de Casos de Uso, las estimaciones de esfuerzo de las restantes actividades que se llevaron a cabo durante el desarrollo del software; así la distribución del esfuerzo entre dichas actividades está dada por la siguiente aproximación mostrada en la Tabla 11. Tabla 11 Distribución genérica del esfuerzo Actividad Porcentaje Análisis 10.00% Diseño 20.00% Programación 40.00% Pruebas 15.00% Sobrecarga(otras actividades) 15.00% Con este criterio y tomando como entrada la estimación de tiempo calculada a partir de los puntos de Casos de Uso, se pueden calcular las demás estimaciones para obtener la duración total del proyecto. En la Tabla 12 se muestra la distribución real del esfuerzo. Capítulo 4: Pruebas realizadas al sistema 45 Tabla 12 Distribución real del esfuerzo. Actividad Porcentaje Análisis 362.85 Diseño 725.70 Programación 1451.4 Pruebas 544.27 Sobrecarga(otras actividades) 544.27 Total 3628.5 Cálculo del esfuerzo total: ETotal = 3628.5 horas / hombre Cálculo del tiempo de desarrollo: TDesarrollo = ETotal/CHTotalCHTotal: Cantidad de hombres =1 TDesarrollo = 3628.5/1 horas TDesarrollo =3628.5 horas Considerando que se trabajan 8 horas diarias: TDesarrollo = TDesarrollo/8 horas/día TDesarrollo= 3628.5 horas/8 horas/día TDesarrollo= 453 días aproximadamente Cálculo del costo: Costo Total = ETotal * 1 * TH TH: El salario promedio de 1 desarrollador es de $400 y por tanto la TH = 400 / 160 = 2.50 Costo Total = 3628.5 * 1 * 2.5 Costo Total = $9071.25 Capítulo 4: Pruebas realizadas al sistema 46 4.1.2 Conclusiones Teniendo en cuenta los resultados arrojados respecto a la factibilidad del software después del estudio perpetrado en este capítulo, se puede expresar que se brinda suficientes beneficios para cubrir sus costos, o sea, que se apoya la realización del sistema la para la DRI-UCLV, ya que es factible y económico; el mismo implicará un esfuerzo total de 3628.5 horas/hombre, para un tiempo de desarrollo de 453 días aproximadamente, se contarán con 1 hombre para su realización, lo que implica un costo de $9071.25 para una tarifa horaria de $2.50. 4.2 Casos de Pruebas (caja negra) Las pruebas de caja negra son las llevadas a cabo sobre la interfaz del software. O sea, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado correcto, así como que la integridad de la información externa (por ejemplo, archivos de datos) se mantiene. Una prueba de caja negra examina algunos aspectos del modelo fundamental del sistema sin tener mucho en cuenta la estructura lógica interna del software. Según (Pressman, 2002), las pruebas de caja negra, también denominada prueba de comportamiento, se centran en los requisitos funcionales del software. Estas pruebas permiten obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. La prueba de caja negra no es una alternativa a las técnicas de prueba de caja blanca. Más bien se trata de un enfoque complementario que intenta descubrir diferentes tipos de errores que los métodos de caja blanca. A continuación, en la siguiente Tabla 13 y Tabla 14 se muestran las pruebas de caja negra correspondientes a los casos de uso Gestionar persona y Gestionar propuesta de salida respectivamente Tabla 13 Escenarios a probar en el caso de uso “Gestionar propuesta de salida”. Id del escenario Escenario Var.1 Fecha Var.2 Nombre Var.3 Cargo Respuesta del Sistema Resultado de la Prueba EC 1 Gestionar Propuesta de Salida C C C El sistema envía los datos insertados por el usuario a la base de datos. Los datos son guardados. EC 2 C I C Inserte solo texto poniendo la primera letra en mayúsculas. Los datos no son guardados. C . C I Inserte solo texto poniendo la Capítulo 4: Pruebas realizadas al sistema 47 primera letra en mayúsculas I C C El campo fecha no puede estar vacío. Tabla 14 Escenarios a probar en el caso de uso “Gestionar persona”. Id del escenari o Escenari o Va r 1 CI Var. 2 Nombr e Var.3 Corre o Var.4 Teléfon o Var.5 Estatur a Var.6 Fecha Nacimien to Respuesta del Sistema Resultad o de la Prueba EC 1 Gestiona r Persona C C C C C C El sistema envía los datos insertados por el usuario a la base de datos. Se guardan los datos EC 2 C I C C C C Inserte solo texto poniendo la primera letra en mayúscula s. Los datos no son guardad os C C I C C C Entre una dirección de email válida. C C C I C C Entre un número válido. C C C C I C Entre un número válido C C C C C I Entre un número válido. 4.3 Conclusiones del capítulo Conclusiones 48 5. CONCLUSIONES Se aplicaron algunas técnicas de refactorización para mejorar el código de la versión anterior y ajustarlos a las especificaciones de la versión de Symfonyutilizada para la implementación de esta versión del sistema. Se implementaron aquellos cambios detectados en el funcionamiento de los procesos de la DRI-UCLV. Se realizaron un conjunto de pruebas para verificar el correcto funcionamiento del sistema, obteniéndose resultados satisfactorios en las mismas. Referencias Bibliográficas 49 6. REFERENCIAS BIBLIOGRÁFICAS Abreu, M. (2016a) Título: Sistema informático para la gestión de los procesos de la Dirección de Relaciones Internacionales en la Universidad Central ‘Marta Abreu’ de Las Villas (SIRI- UCLV). Universidad Central ‘Marta Abreu’ de Las Villas. Abreu, M. (2016b) Título: Sistema informático para la gestión de los procesos de la Dirección de Relaciones Internacionales en la Universidad Central ‘Marta Abreu’ de Las Villas (SIRI- UCLV). Campo, G. D. (2009) ‘Patrones de Diseño , Refactorización y Antipatrones . Ventajas y Desventajas de su Utilización en el Software Orientado a Objetos’, pp. 101–136. Dallal, J. Al (2015) ‘Identifying Refactoring Opportunities in Object-Oriented Code : A Systematic Literature Review’, (September). doi: 10.1016/j.infsof.2014.08.002. Favre, J. (2006) ‘Languages evolve too ! Changing the Software Time Scale’. Fowler, M. (1999) ‘Refactoring: Improving the ...’, Surveys in High Energy Physics, 14(1), pp. 145–173. doi: 10.1080/01422419908228843. IVAR JACOBSON, G. B., J. R. (2000) ‘El Proceso Desarrollo de Software’, pp. 1–54. Josue Carralero Iznaga, Javier F. Travieso Arencibia, Julio Martinez Prieto, Jose A. Franco Navarro, Saylis Cabrera Sierra, Paula Ardanza Menendez, N. B. H. (2006) ‘“Hotel X” Un ejemplo práctico para la asignatura de Ingenieria de Software’, p. 97. Khanam, Z. (2018) ‘Barriers to Refactoring : Issues and Solutions Barriers to Refactoring : Issues and Solutions’, (February). Mediavilla, E. (2014) ‘PROGRAMACIÓN ORIENTADA A Master de Computación UML Concepto de objeto y de clase’, pp. 1–63. Mendez, M. (2011) ‘Universidad de La Plata Facultad De Informática Refactoring de código estructurado Trabajo de Especialización’, (January 2010), p. 66. Available at: https://www.researchgate.net/profile/Mariano_Mendez2/publication/261724775_Refactoring_ de_codigo_estructurado/links/591ee7120f7e9b64281df4a2/Refactoring-de-codigo- estructurado.pdf?origin=publication_detail. Orallo, E. H. (2017) ‘Unificado de Modelado ( UML )’, pp. 1–6. Pacheco, N. (2013) Twig — Manual de Twig en Español. Available at: http://gitnacho.github.io/Twig/ (Accessed: 30 May 2019). Referencias Bibliográficas 50 Pressman, R. S. (2002) Ingeniería del software. Rodríguez, C. R. (2019) ‘Personalización del Moodle mediante la integración de las tecnologías educativas de la web más empleadas en la educación superior Personalization of Moodle with the integration of most used web technologies in higher education’, 16, pp. 48– 63. Symfony (2016) Symfony, Symfony is a set of reusable PHP components. Available at: https://symfony.com/. UCLV (2019) ‘Dirección - Universidad Central Marta Abreu de Las Villas’. Available at: https://www.uclv.edu.cu/relaciones-internacionales/direccion/ (Accessed: 30 May 2019).