Sistema para el control de traslados telefónicos pendientes (SCTTP)

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas. Facultad Matemática, Física y Computación. INGENIERÍA INFORMÁTICA TRABAJO DE DIPLOMA. Sistema para el Control de Traslados Telefónicos Pendientes (SCTTP). Autor: Maura Elena Díaz Boente. Tutores: Dr. C. Carlos Ernesto García González Ing. Frank Antonio Rodríguez Díaz. Santa Clara, 2017.

(2) Hago constar que el presente trabajo de diploma fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad de Ingeniería en 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 publicados sin autorización de la Universidad.. Firma del Autor. Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo 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 Autor. Firma del Jefe de Departamento donde se defiende el trabajo. Firma del Responsable de Información Científico-Técnica.

(3) Agradecimientos A mi madre por ser el principal estímulo que me hizo ponerle más ganas de lo que acostumbro, sin su presencia, este día nunca hubiese llegado, gracias por ser toda una guerrera. A mi padre por estar siempre ahí, por animarme a seguir, por tener esa confianza infinita en mí y por hacerme ver, que los límites se los pone uno mismo, nadie más…todos los mayores logros de mi vida le pertenecen. A mi hermano, por seguir mis pasos, aunque esto me traerá muchas noches de desvelo. A mi tutor Frank por su ayuda incondicional y desinteresada desde el primer año de la carrera, por ser una fuente de conocimientos sin límites y marcarme el camino a seguir, por estar disponible a toda hora y en todo momento, por tener no solo una solución sino la mejor solución a todos los problemas y ayudarme a combatir mi finalismo nato. A su esposa Meralys por dedicarme su tiempo y ayudarme a corregir hasta el más mínimo error, sin ellos esto no hubiera sido posible. A mi tutor Carlos García, porque guardo un grato recuerdo del año que le tuve como profesor, y en el que pensé siempre como la persona ideal para dirigirme el proyecto; y no me equivoqué. A Juan Daniel, por brindarme una amistad verdadera y ser mi “complemento informático” desde el primer año de la carrera, sinceramente pienso que unidos somos imparables, espero que el futuro nos dé la oportunidad de seguir superándonos juntos. A Jennifer y Yailen, por su eterna generosidad y estar siempre ahí, en los buenos momentos y en los no tan buenos, gracias por ser tan buenas amigas, es un privilegio contar con ustedes. A Basel por liberarme del estrés de manera inconsciente y darme momentos de total alegría en medio de la “tempestad”.. I.

(4) A Tania por ser una persona increíble, llena de valores y un corazón que no le cabe en el pecho, gracias por darnos tu apoyo en esta etapa tan difícil por la que estamos pasando. A mi pequeña verdadera familia paterna, que incluye a esas personas que siempre están presentes (gracias Mariana, Cedi, Adita, Amarilis). A todo mi grupo de informática, compañeros de viaje, de horas de estudio, de tristeza por los suspensos y de alegrías por los aprobados, no podría haber tenido compañeros mejor.. II.

(5) Resumen A partir de la puesta en vigor de la Resolución Ministerial Nº82 aumentó significativamente el número de traslados telefónicos en todo el territorio nacional, ocasionando dificultades para gestionar dichas solicitudes, debido a la carga de operaciones que se llevan a cabo de forma manual. Con el objetivo de mejorar el proceso de gestión de un traslado telefónico se propone implementar una aplicación que le permita a los especialistas comerciales dar seguimiento al traslado de acuerdo a su estado, así como facilitar la toma de decisiones futuras por parte de los directivos. La herramienta es implementada mediante el uso de diferentes tecnologías actuales, como AngularJs, Bootstrap y CodeIgniter; está basada en una arquitectura Cliente/Servidor guiada por el patrón arquitectónico Modelo Vista Controlador (MVC), asegurando de este modo su flexibilidad y extensibilidad. Cuenta con un módulo que representa el comportamiento anual de los traslados telefónicos mediante el uso de gráficos con el objetivo de aumentar de manera visual el nivel de comparabilidad en las consultas del usuario.. III.

(6) Abstract Since the enactment of Ministerial Resolution Nº82, the number of telephone transfers throughout the country has increased significantly, causing difficulties in managing these requests, due to the burden of operations carried out manually. With the aim of improving the process of management of a telephone transfer, it is proposed to implement an application that allows commercial specialists to follow the transfer according to their status, as well as to facilitate future decision making by the managers. The tool is implemented through the use of different current technologies, such as AngularJs, Bootstrap and CodeIgniter; Is based on a client / server architecture guided by the architectural pattern MVC, thus ensuring its flexibility and extensibility. It has a module that represents the annual behavior of telephone transfers through the use of graphics with the aim of visually increasing the level of comparability in user queries.. IV.

(7) Índice Introducción..................................................................................................................... 1 Capítulo 1. Fundamentación Teórica .............................................................................. 5 1.1. Introducción........................................................................................................ 5. 1.2. Trámites comerciales de la telefonía fija ............................................................ 5. 1.3. Sistemas automatizados existentes vinculados al campo de acción ................. 5. 1.4. Clasificación del tipo de aplicación..................................................................... 6. 1.5. Tendencias y Tecnologías Actuales ................................................................... 7. 1.5.1. Metodología utilizada ................................................................................... 7. 1.5.2. Lenguajes de programación ........................................................................ 8. 1.5.3. Tecnologías ................................................................................................. 8. 1.5.4. Gestor de Base de Datos .......................................................................... 11. 1.5.5. Servidor de Aplicaciones Web ................................................................... 13. 1.5.6. Herramienta para pruebas de software ..................................................... 13. 1.6. Conclusiones parciales .................................................................................... 14. Capítulo 2. Modelo del Negocio y Requisitos ................................................................ 15 2.1. Introducción...................................................................................................... 15. 2.2. Modelo del negocio actual ............................................................................... 15. 2.2.1. Flujo actual del proceso ............................................................................. 15. 2.2.2. Análisis crítico de la ejecución del proceso ............................................... 16. 2.2.3. Procesos objeto de automatización ........................................................... 17. 2.3. Reglas del negocio a considerar ...................................................................... 17. 2.4. Actores del negocio .......................................................................................... 18. 2.5. Diagrama de casos de uso del negocio ........................................................... 18. 2.6. Trabajadores del negocio ................................................................................. 19 V.

(8) 2.7. Casos de uso del negocio ................................................................................ 20. 2.8. Actores del sistema a automatizar ................................................................... 21. 2.9. Definición de los requisitos funcionales ........................................................... 22. 2.10. Definición de los requisitos no funcionales ................................................... 26. 2.11. Paquetes y sus relaciones ............................................................................ 28. 2.12. Diagrama de Casos de Uso del Sistema ...................................................... 29. 2.13. Determinación de los casos de Uso del Sistema más significativos ............. 31. 2.14. Descripción de los casos de uso del Sistema más significativos .................. 33. 2.14.1. Caso de Uso del Sistema Autenticar usuario ......................................... 33. 2.14.2. Caso de Uso del Sistema Gestionar usuario .......................................... 34. 2.15. Conclusiones parciales ................................................................................. 37. Capítulo 3. Descripción de la propuesta de solución .................................................... 38 3.1. Introducción...................................................................................................... 38. 3.2. Arquitectura del sistema ................................................................................... 38. 3.3. Diagrama de clases de diseño ......................................................................... 38. 3.3.1. Caso de Uso del Sistema Gestionar Traslado ........................................... 39. 3.3.2. Caso de Uso del Sistema Autenticar usuario ............................................ 40. 3.4. Diagrama de secuencia ................................................................................... 41. 3.4.1. Caso de Uso del Sistema Gestionar Traslado ........................................... 41. 3.4.2. Caso de Uso del Sistema Autenticar usuario ............................................ 43. 3.5. Patrón de arquitectura ...................................................................................... 43. 3.6. Patrones de diseño .......................................................................................... 44. 3.7. Tratamiento de errores ..................................................................................... 45. 3.8. Esquema de la base de datos .......................................................................... 47. 3.8.1. Esquema lógico de datos .......................................................................... 47 VI.

(9) 3.8.2 3.9. Esquema físico de datos ........................................................................... 48. Diagrama de Componentes ............................................................................. 48. 3.10. Diagrama de Despliegue .............................................................................. 50. 3.11. Conclusiones parciales ................................................................................. 51. Capítulo 4. Pruebas y análisis de factibilidad ................................................................ 53 4.1. Introducción...................................................................................................... 53. 4.2. Planificación basada en casos de uso ............................................................. 53. 4.2.1. Cálculo de Puntos de Casos de Uso sin ajustar ........................................ 53. 4.2.2. Cálculo de Puntos de Casos de Uso ajustados ......................................... 55. 4.2.3. Estimación del esfuerzo por los Puntos de Casos de Uso ........................ 59. 4.2.4. Estimación del esfuerzo total del proyecto ................................................ 60. 4.2.5. Estimación del tiempo de desarrollo del proyecto ..................................... 61. 4.2.6. Estimación del costo de desarrollo del proyecto ........................................ 61. 4.3. Pruebas de software ........................................................................................ 62. 4.3.1. Pruebas funcionales .................................................................................. 63. 4.3.2. Pruebas de Estructura del Software .......................................................... 65. 4.4. Conclusiones parciales .................................................................................... 66. Conclusiones ................................................................................................................. 67 Recomendaciones......................................................................................................... 68 Referencias Bibliográficas ............................................................................................. 69. Índice de Tablas Tabla 1.1: Comparación entre PostgreSQL y MySQL (10) ........................................... 12 Tabla 2.1: Descripción de los trabajadores del negocio ................................................ 20 Tabla 2.2: Descripción de los casos de uso del negocio ............................................... 21 Tabla 2.3: Descripción de los actores del sistema ........................................................ 21 VII.

(10) Tabla 2.4: Descripción de los paquetes en los que se divide el sistema ....................... 28 Tabla 2.5: Clasificación de los casos de uso del sistema.............................................. 33 Tabla 2.6: Descripción del caso de uso del sistema “Autenticar usuario” ..................... 34 Tabla 2.7: Descripción de la funcionalidad Listar traslado ............................................ 35 Tabla 2.8: Descripción de la funcionalidad Insertar traslado ......................................... 35 Tabla 2.9 Descripción de la funcionalidad Modificar traslado ........................................ 36 Tabla 2.10:Descripción del caso de uso del sistema “Mostrar reporte” ......................... 37 Tabla 3.1: Estereotipos web para el diagrama de clases .............................................. 39 Tabla 3.2: Descripción de los nodos que integran el Diagrama de Despliegue ............ 51 Tabla 4.1: Criterios para establecer la complejidad de los actores del sistema ............ 54 Tabla 4.2: Criterios para establecer la complejidad de los casos de uso del sistema ... 54 Tabla 4.3: Cantidad de transacciones por caso de uso ................................................ 55 Tabla 4.4: Factores para determinar la complejidad técnica del sistema ...................... 56 Tabla 4.5: Valores que toma cada factor para el sistema ............................................. 57 Tabla 4.6: Peso asociado a cada factor de ambiente.................................................... 58 Tabla 4.7: Valor asignado por cada factor de ambiente ................................................ 58 Tabla 4.8: Esfuerzo asociado a cada una de las actividades vinculadas al proyecto ... 60 Tabla 4.9: Cálculo de la cantidad de horas por hombre que requiere cada actividad del proyecto ........................................................................................................................ 60 Tabla 4.10: Resultados de las pruebas funcionales ...................................................... 64. Índice de Figuras Figura 2.1: Modelo del negocio ..................................................................................... 16 Figura 2.2: Diagrama de casos de uso del negocio ...................................................... 19 Figura 2.3: Relación entre los actores del sistema ........................................................ 22 Figura 2.4: Diagrama de paquetes ................................................................................ 29 Figura 2.5: Diagrama de casos de uso del sistema ...................................................... 30 Figura 2.6: Empaquetamiento de casos de uso del sistema ......................................... 31 Figura 3.1: Arquitectura del sistema .............................................................................. 38 Figura 3.2 :Diagrama de clases del caso de uso del sistema Gestionar Traslado ........ 40 Figura 3.3:Diagrama de clases del caso de uso del sistema Autenticar usuario ........... 41 VIII.

(11) Figura 3.4: Diagrama de secuencia de la funcionalidad Listar traslado ........................ 42 Figura 3.5: Diagrama de secuencia de la funcionalidad Crear traslado ........................ 42 Figura 3.6: Diagrama de secuencia de la funcionalidad Editar traslado ........................ 43 Figura 3.7: Diagrama de secuencia del caso de uso del sistema Autenticar usuario .... 43 Figura 3.8: Representación del patrón arquitectónico MVC .......................................... 44 Figura 3.9: Modelo conceptual de la base de datos ...................................................... 47 Figura 3.10: Modelo físico de la base de datos ............................................................. 48 Figura 3.11: Diagrama de componentes del caso de uso del sistema “Gestionar traslado” ........................................................................................................................ 49 Figura 3.12: Diagrama de componentes del caso de uso del sistema Autenticar usuario. ...................................................................................................................................... 50 Figura 3.13: Diagrama de Despliegue ........................................................................... 51 Figura 4.1: Niveles de pruebas en la Pirámide de Cohn ............................................... 62 Figura 4.2: Interfaz de prueba de la herramienta Postman (funcionalidad Listar traslado) ...................................................................................................................................... 65 Figura 4.3: Interfaz de prueba de la herramienta Postman (caso de uso del sistema Gestionar traslado) ........................................................................................................ 66. IX.

(12) Introducción. Introducción Contexto A inicios de la década de los 90, problemas organizativos y de financiamiento ocasionaron un serio perjuicio a la telefonía, por lo cual no estaba a la altura de las exigencias del desarrollo del país. Por ello se decidió crear una empresa que integrara las actividades de telecomunicaciones, frenara el deterioro e impulsara a este sector. El proceso de fusión se extendió desde inicios de 1994 hasta febrero de 1995, cuando ETECSA realizó la contratación de sus trabajadores. Desde ese momento la institución ha atravesado períodos de cambios tecnológicos, de estructura, de sistemas gerenciales, de orientación estratégica y de desarrollo de nuevos servicios(1). A lo largo de estos años, desde su fundación, la empresa ha ganado en eficiencia y compromiso con sus clientes. Se han ampliado sus prestaciones y la calidad de los parámetros tecnológicos se ha incrementado, logrando elevar la cantidad de líneas instaladas, el índice de digitalización y el respaldo al desarrollo socioeconómico del país. La empresa comercializa sus productos, accesorios y servicios de telecomunicaciones a través de la red de Telepuntos, Minipuntos, Centros Multiservicios y Oficinas Comerciales, dentro de las que también pueden coexistir Puntos de Ventas y en el eslabón más cercano al barrio los Agentes de Telecomunicaciones. En la Oficina Comercial se realizan los trámites comerciales relativos al servicio telefónico y sus relaciones contractuales, además de la atención integral al usuario y a la población en general. Actualmente, en la División Territorial de Villa Clara (DTVC), se realizan disímiles trámites comerciales relativos al servicio telefónico, tales como: . Cambio de nombre del titular.. . Cambio de número telefónico.. . Cambio de montaje.. . Cambio de profesión. 1.

(13) Introducción . Traslado del servicio a otra dirección.. . Desconexión especial y conexión.. . Reconexión.. . Reinstalación.. . Instalación de extensiones.. . Pase a privado.. . Solicitud de servicios suplementarios.. . Solicitud de la salida internacional (Tarifa Mixta).. . Solicitud del servicio de identificador de llamadas.. . Inserción en el Directorio Telefónico(1).. A partir de la puesta en vigor de la Resolución Ministerial Nº82 publicada en la Gaceta Oficial el 25 de mayo del 2012, donde el titular tendría derecho a ceder la titularidad del servicio telefónico a cualquier persona natural con residencia permanente en el territorio nacional, en el momento que lo estime oportuno; se desató una mayor cantidad de traslados en todo el territorio nacional haciéndose engorroso en las Oficinas Comerciales llevar el control de los traslados pendientes, ocasionando así un aumento de las quejas de la población hacia la Empresa de Telecomunicaciones de Cuba, debido a la falta de rapidez con que se restablecía el funcionamiento de estos servicios. Problema de Investigación Las dificultades existentes en la gestión de las solicitudes de traslados telefónicos que realiza la población debido a la carga de operaciones que se llevan a cabo manualmente. Objeto de estudio El proceso de gestión de un traslado telefónico realizado en las Oficinas Comerciales de la DTVC. Campo de acción Soluciones informáticas para gestionar los traslados telefónicos. 2.

(14) Introducción Objetivo general Obtener una solución informática para automatizar el proceso de gestión de un traslado telefónico en la DTVC. Objetivos específicos 1. Puntualizar los requisitos de software para la gestión de los traslados telefónicos pendientes en la DTVC. 2. Diseñar un esquema conceptual de la base de datos que permita la captura de toda la información. 3. Realizar el análisis, diseño y desarrollo para la creación de una aplicación que gestione el proceso de solicitud de un traslado telefónico. 4. Realizar un análisis del costo, tiempo y recursos requeridos basado en uno de los métodos de estimación. 5. Aplicar pruebas a la solución de software para garantizar el correcto funcionamiento de la gestión de los traslados pendientes en la DTVC. Preguntas de Investigación 1. ¿Cuáles son las actividades que están involucradas en el proceso de traslados telefónicos? 2. ¿Cuál es el flujo de trabajo que guía el proceso de traslados telefónicos? 3. ¿Qué solución, en cuanto a arquitectura y tecnología, sería la más adecuada para dar solución al problema planteado? 4. ¿Qué pruebas de software realizar para comprobar que el sistema funcione en óptimas condiciones? Justificación de la Investigación Por parte de la dirección de la empresa no se cuenta actualmente con un sistema que permita de forma inmediata ver el estado de los traslados pendientes para la toma de decisiones basado en criterios como: Oficinas Comerciales, municipios, consejos populares y causas de por qué está pendiente el traslado. Actualmente este trabajo se realiza de forma manual por parte de las ejecutivas y especialistas comerciales de cada. 3.

(15) Introducción territorio, archivando en formato papel todo lo relacionado con un traslado, esto hace que el trabajo de las ejecutivas y directivos se haga engorroso y lento provocando pérdidas económicas para la empresa e insatisfacción por parte de los clientes. Estructura del documento Presenta cuatro capítulos: Capítulo 1: Se titula “Fundamentación Teórica”, dentro del cual se describen los objetivos estratégicos de la organización, los sistemas automatizados existentes vinculados al campo de acción, se clasifica el tipo de aplicación y se fundamentan las tendencias y tecnologías actuales. Capítulo 2: Se titula “Modelo del Negocio y Requisitos”, se explica el modelo de negocio actual, se identifican las reglas y actores del negocio, los requisitos funcionales y no funcionales, se muestra el diseño del diagrama de paquetes, el de casos de uso del negocio y del sistema, así como una descripción de los casos de uso del sistema que son más significativos. Capítulo 3: Se titula “Descripción de la propuesta de solución”, dentro del mismo se encontrarán: la arquitectura del sistema, el diagrama de clases del diseño y diagrama de secuencia (casos de uso más significativos), el tratamiento de los errores del sistema, el diseño de la base de datos (Modelo lógico y físico), una descripción del modelo, el diagrama de componentes y el diagrama de despliegue. Capítulo 4: Se titula “Pruebas y análisis de factibilidad”, se realiza una planificación basada en uno de los métodos de estimación y se aprecian los resultados del proyecto y los valores de costo, tiempo y recursos requeridos, así como una descripción de las pruebas de software realizadas.. 4.

(16) Capítulo 1: Fundamentación Teórica. Capítulo 1. Fundamentación Teórica 1.1. Introducción. Para desarrollar un sistema se requiere de un análisis previo que justifique las razones en las que se explique la necesidad de implementación. Es por ello que el presente capítulo contiene un estudio del estado del arte que aborda la definición de elementos del negocio en cuestión, así como los aspectos teóricos que fundamentan el desarrollo de la aplicación, tales como: la justificación del conjunto de herramientas y metodologías de desarrollo de software que permiten darle solución al problema planteado. 1.2. Trámites comerciales de la telefonía fija. La telefonía fija o básica consiste en una línea telefónica que se instala en las casas y entidades de los abonados a través de un equipo telefónico principal fijo con prestaciones básicas. Entre la empresa y el cliente existe una relación contractual que es un documento cuyas cláusulas son de obligatorio cumplimiento. Este servicio abarca el servicio telefónico local, de larga distancia nacional e internacional, ya sea a través de la marcación directa por teleselección o mediante operadoras nacionales e internacionales. Permite realizar determinados trámites comerciales (como conexión, reconexión, cambio de lugar, cambio de nombre del titular, traslados, etc.). La Telefonía Fija Alternativa, conocida también como TFA, es una modalidad de servicio telefónico fijo que utiliza la infraestructura de acceso inalámbrico a través de la red móvil para ofrecer servicios en aquellos lugares donde no hay disponibilidad técnica en las redes telefónicas tradicionales(2). Al establecerse la Resolución Nº82 de 2012 del Ministro del Ministerio de Comunicaciones (MIC) se agudizó en las Oficinas Comerciales los trámites concernientes al traspaso de la titularidad del contrato del servicio telefónico básico en lo relativo a cesión o transferencia, haciéndose muy engorroso para las Ejecutivas Comerciales llevar un control manual de todos los datos relacionados con estos trámites. 1.3. Sistemas automatizados existentes vinculados al campo de acción 5.

(17) Capítulo 1: Fundamentación Teórica La DTVC contaba con un sistema automatizado que llevaba de forma básica el control de los traslados pendientes. Esta aplicación fue retirada por presentar las siguientes desventajas: . La base de datos anterior tenía problemas en su normalización.. . Fue implementada usando un lenguaje de programación que no corresponde a las exigencias actuales de la empresa.. . Falta de un correcto mantenimiento debido a la ausencia de documentación que la respaldara.. . Bajo nivel de seguridad para proteger la información manipulada por el sitio.. Estas desventajas constituyen el punto de partida para la propuesta de solución. 1.4. Clasificación del tipo de aplicación. La aplicación es empresarial a la medida, teniendo en cuenta los requisitos del cliente. El sistema tiene que estar disponible desde la intranet corporativa y cumplir con los estándares de diseño de la institución. El desarrollo de una aplicación web posee las siguientes ventajas: . Gran disponibilidad ya que el servicio se ofrece desde varias localizaciones para asegurar la continuidad del mismo.. . No ocupa espacio en el disco duro.. . Se puede usar desde cualquier sistema operativo (multiplataforma).. . No hay problemas de compatibilidad: basta tener un navegador actualizado para poder utilizarlas.. . Consumo de recursos bajo: dado que toda (o gran parte) de la aplicación no se encuentra en la computadora.. Basadas en estas características y en las exigencias actuales de la empresa se realizó una selección de la tecnología a usar para la implementación del sitio se expone en el siguiente epígrafe.. 6.

(18) Capítulo 1: Fundamentación Teórica 1.5. Tendencias y Tecnologías Actuales. Para el desarrollo de un sistema informático es de suma importancia definir las herramientas, lenguajes y metodologías que se utilizaran por lo que se debe hacer un correcto análisis de las que se emplearán en la solución propuesta. 1.5.1 Metodología utilizada Existen diferentes metodologías de desarrollo, cada una con características diferentes pero encaminadas a lograr el mismo objetivo: ensamblar las tecnologías y hacer que salga un producto en tiempo y con la calidad requerida. Es necesario realizar un análisis previo del proyecto de software con el fin de determinar qué enfoque de gestión de proyecto tomar: Tradicional o Ágil. Dado que el proyecto mantiene requisitos estables, bien definidos desde el inicio y no es indispensable obtener resultados de forma inmediata, se guiará el enfoque de gestión de proyecto hacia el uso de metodologías tradicionales usando el Proceso Racional Unificado (RUP), debido a que está centrado en la arquitectura y guiado por casos de usos, esto permite que exista una trazabilidad entre el caso de uso y los demás artefactos vinculados a él, lo que permitirá describir las características del sistema a desarrollar hasta lograr la entrega final, permitiendo reconocer los problemas, para así corregirlos de forma temprana. Quien promueve la reusabilidad, reduce la complejidad de mantenimiento y disminuye las brechas semánticas entre la visión interna y la visión externa del sistema(3). 1.5.1.1 Lenguaje de modelado Se propone el Lenguaje de Modelado Unificado (UML), ya que es un es un lenguaje para la especificación, visualización, construcción y documentación de los artefactos de un proceso de sistema intensivo. A pesar de que no define qué metodología o proceso utiliza, se puede aplicar en una gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como RUP). Sirve para el modelado completo de sistemas complejos, tanto en el diseño de los sistemas software como para la arquitectura hardware donde se ejecuten. Aporta las siguientes ventajas: 7.

(19) Capítulo 1: Fundamentación Teórica . Mayor rigor en la especificación.. . Permite realizar una verificación y validación del modelo realizado.. . Se pueden automatizar determinados procesos y permite generar código a partir de los modelos y a la inversa (a partir del código fuente generar los modelos). Esto permite que el modelo y el código estén actualizados, con lo que siempre se puede mantener la visión en el diseño, de más alto nivel, de la estructura de un proyecto(4).. 1.5.1.2 Herramienta CASE Visual Paradigm es una herramienta para desarrollo de aplicaciones utilizando modelado UML para Ingenieros de Software, Analistas de Sistemas y Arquitectos de Sistemas que están interesados en construcción de sistemas a gran escala y necesitan confiabilidad y estabilidad en el desarrollo(5). Además, Visual Paradigm cuenta con las siguientes características: Ser independiente de la plataforma, permitiendo la ingeniería inversa. Tiene soporte para generar código en lenguaje SQL, ya sea en PostgreSQL y MySQL. Esta herramienta CASE brinda la posibilidad de crear artefactos utilizados durante la confección de un software y ofrece estereotipos para la realización de distintos diagramas. 1.5.2 Lenguajes de programación PHP es un lenguaje de programación de uso general de código del lado del servidor. Originalmente fue diseñado para el desarrollo web de contenido dinámico. Permite a páginas estáticas convertirse en dinámicas. El nombre "PHP" es un acrónimo que significa "PHP: Hypertext Preprocessor", en español "PHP: Preprocesador de hipertexto". Esto permite a desarrolladores crear potentes aplicaciones(6). 1.5.3 Tecnologías Otro análisis significativo es el relacionado a la selección de los framework para aplicaciones web:  AngualrJS 8.

(20) Capítulo 1: Fundamentación Teórica Es uno de los framework más rápidos y crecientes de java script. Podemos usar patrones de diseño MVC y MVVM que son esenciales para construir sitios web modernos en la actualidad. Este marco permite utilizar características tales como enlace de datos, controlador, vinculación profunda, validación de formularios, comunicación con el servidor, directivas y localización.  Bootstrap Es un framework desarrollado y liberado por Twitter que tiene como objetivo facilitar el diseño web. Permite crear de forma sencilla webs de diseño adaptable, es decir, que se ajusten a cualquier dispositivo y tamaño de pantalla, simplificando de este modo el proceso de maquetación.  CodeIgniter Es un framework para el desarrollo de aplicaciones en php, que utiliza el MVC. Esto permite a los programadores o desarrolladores Web mejorar su forma de trabajar, además de dar una mayor velocidad a la hora de crear páginas Webs.  Servicios web Los servicios web son aplicaciones autónomas, modulares, distribuidas y dinámicas que se pueden describir, publicar, localizar o invocar a través de la red para crear productos, procesos, y cadenas de suministro. Estas aplicaciones pueden ser locales, distribuidas, o basadas en web. Los servicios web están construidos sobre estándares como TCP/IP, HTTP, Java, HTML y XML. Un servicio web habilita la comunicación entre varias aplicaciones utilizando los estándares como HTML, XML, WSDL, y SOAP (7).  Aplicaciones RESTfull La Transferencia de Estado Representacional (Representation State Transfer REST) describe un estilo arquitectónico de sistemas en red como, por ejemplo, aplicaciones Web. Está comprendida por una serie de limitaciones y principios arquitectónicos. Si una aplicación o diseño cumple con esas limitaciones y principios, se considera RESTfull. 9.

(21) Capítulo 1: Fundamentación Teórica Uno de los principios REST de mayor importancia para las aplicaciones web es que la interacción entre el cliente y el servidor no tiene estado entre solicitudes. Cada solicitud del cliente al servidor debe contener toda la información necesaria para comprender la solicitud. El cliente puede almacenar los datos en caché para mejorar su rendimiento. Todos los recursos comparten una interfaz uniforme para la transferencia de estados entre cliente y servidor. Se usan métodos estándar HTTP como GET, PUT, POST y DELETE(8). REST simplifica la implementación tanto para el cliente como para el servidor.  Autenticación basada en Token Una de las nuevas tendencias en cuanto al desarrollo web moderno se refiere, es la autenticación por medio de Tokens y que backend sea un API restful sin información de estado. El funcionamiento es el siguiente: El usuario se autentica en nuestra aplicación y a partir de entonces, cada petición HTTP que haga el usuario va acompañada de un Token en la cabecera. Este Token no es más que una firma cifrada que permite a API identificar al usuario. Pero este Token no se almacena en el servidor, si no en el lado del cliente y el API es el que se encarga de descriptar ese Token y redirigir el flujo de la aplicación en un sentido u otro. Como los tokens son almacenados en el lado del cliente, no hay información de estado y la aplicación se vuelve totalmente escalable. Podemos usar el mismo API para diferentes aplicaciones (Web, Mobile, Android, iOS,) solo debemos preocuparnos de enviar los datos en formato JSON y generar y descriptar tokens en la autenticación y posteriores peticiones a través de un middleware(9).. 10.

(22) Capítulo 1: Fundamentación Teórica 1.5.4 Gestor de Base de Datos La mayoría de las organizaciones públicas buscan un Sistema Gestor de Base de Datos (SGBD) que permita un buen desempeño, que les convenga y a su vez que cumpla todos los requerimientos necesarios y sea lo menos vulnerable para así mantener la información de sus datos segura. Hoy en día existen muchos SGBD dentro del mercado por lo que resulta complejo realizar una selección del que tiene mejores estrategias de seguridad y desempeño. Dentro de los SGBD más populares cabe destacar los siguientes: Oracle, SQL Server, PostgreSQL y MySQL Community Edition; sin embargo nuestro estudio comparativo estará enfocado en los dos últimos. La Tabla 1.1 muestra las propiedades de los gestores respecto a distintos criterios de comparación, teniendo una visión más amplia de lo que los hace diferentes y los caracteriza, haciéndolos mejor en el desempeño de un área específica. Criterio. MySQL. PostgreSQL. Velocidad. Es mucho más rápido que la mayor. La velocidad de respuesta que. parte de su competencia ya que ofrece este gestor con bases de tiene la posibilidad de selección de datos. relativamente. pequeñas. mecanismos de almacenamiento puede parecer un poco deficiente, que ofrecen diferentes velocidades. aunque esta misma velocidad la. de. mantiene al gestionar bases de. operación,. soporte. físico,. capacidad, distribución geográfica, datos realmente grandes, cosa que transacciones. potencia. Aprovecha de. multiprocesador,. la resulta. loable.. Es. capaz. de. sistemas ajustarse al número de CPUs y a la gracias. implementación multihilo.. a. su cantidad de memoria que posee el sistema. de. forma. óptima,. haciéndole capaz de soportar una mayor. cantidad. de. peticiones. simultáneas de manera correcta, se dice que ha llegado a soportar el triple de carga de lo que soporta MySQL. Multiprocesos. Modelo. Relacional. Orientado a Objetos. 11.

(23) Capítulo 1: Fundamentación Teórica Conceptual Fiabilidad. Resulta. fácil. de. utilizar. y. Sus. características. técnicas. la. administrar. Las herramientas de hacen una de las bases de datos MySQL son potentes y flexibles, más potentes. sin sacrificar su capacidad de uso. Arquitectura. de Cliente / servidor. Cliente / servidor. Implementación Manejo transacciones. de MySQL cuenta con la agrupación Limitación: de. transacciones,. Actualmente,. reuniendo transacciones. las. abortan. múltiples transacciones de varias completamente si se encuentra un conexiones para incrementar el fallo durante su ejecución. número. de. transacciones. por. segundo. Plataforma. Multiplataforma.. soportada. disponibilidad en gran cantidad de plataforma moderna tipo Unix debe plataformas. y. Cuenta. sistemas,. con Multiplataforma.. Cualquier. tales ser capaz de ejecutar PostgreSQL,. como; GNU/Linux. Y en sistemas también corre de forma nativa en operativos de Microsoft Windows. sistemas operativos basados en Usa GNU Automake, Autoconf, y Microsoft Libtool para portabilidad. Windows. NT. como. Win2000 SP4, WinXP y Win2003.. Tabla 1.1: Comparación entre PostgreSQL y MySQL (10). 12.

(24) Capítulo 1: Fundamentación Teórica Las características técnicas de PostgreSQL lo hacen una de las bases de datos más potentes y robustas de todos los tiempos, cuenta con estabilidad y potencia. Funciona muy bien con grandes cantidades de datos y una alta concurrencia de usuarios. Pero no todo son beneficios ya que PostgreSQL en comparación con MySQL es más lento en inserciones y actualizaciones, pues cuentan con cabeceras de intersección que no tiene MySQL, por lo que consume más recursos que este. Respecto a la documentación de ambos gestores es más fácil encontrar soporte para MySQL que para PostgrsSQL. Con base en el supuesto establecido en la investigación se concluye que MySQL tiene mejor desempeño en entornos web. 1.5.5 Servidor de Aplicaciones Web Se propone Apache como servidor web ya que es un servidor HTTP de código abierto. El mismo presenta diferentes ventajas que sustentan su elección: •. Es multiplataforma.. •. Es gratuito y de código de fuente abierto.. •. Es un servidor conﬁgurable de diseño modular.. •. Trabaja con PHP y otros lenguajes de script.. •. Permite personalizar la respuesta ante los posibles errores que se puedan dar en el servidor(11).. 1.5.6 Herramienta para pruebas de software Existen un gran número de herramientas gratuitas y propietarias para realizar pruebas de software. Dentro de las gratuitas se encuentran PhpUnit, JWebUnit, JMeter y Postman; destacando por su versatilidad y estabilidad. Para realizar pruebas de estrés y rendimiento al software se usará JMeter y para probar el correcto funcionamiento de la API se realizará un test de regresión usando Postman. -JMeteres una herramienta que permite realizar Pruebas de Rendimiento y Pruebas Funcionales sobre Aplicaciones Web. Es una herramienta de carga para llevar a cabo simulaciones sobre cualquier recurso software. Posee la capacidad de realizar desde una solicitud sencilla hasta secuencias de requisiciones que permiten diagnosticar el comportamiento de una aplicación en condiciones de producción. En este sentido, simula todas las funcionalidades de un Navegador, o de cualquier otro cliente, siendo. 13.

(25) Capítulo 1: Fundamentación Teórica capaz de manipular resultados en una determinada solicitud y reutilizarlos para ser empleados en una nueva secuencia. -Postman es una herramienta para hacer peticiones a APIs y generar colecciones de peticiones que nos permitan probarlas de una manera rápida y sencilla. Está compuesto por diferentes herramientas y utilidades gratuitas que permiten realizar tareas diferentes dentro del mundo API REST: creación de peticiones a APIs internas o de terceros, elaboración de pruebas para validar el comportamiento de APIs y posibilidad de crear entornos de trabajo diferentes (con variables globales y locales). 1.6. Conclusiones parciales. En este capítulo se realizó un estudio del estado del arte de los elementos del negocio y de los sistemas automatizados existentes vinculados al campo de acción. Esto constituye el punto de partida para la propuesta de solución a la herramienta de gestión de los traslados pendientes de la DTVC. Por último se justificó la selección de las metodologías, tecnologías y herramientas necesarias para desarrollar la propuesta de solución.. 14.

(26) Capítulo 2: Modelo de Negocio y Requisitos. Capítulo 2. Modelo del Negocio y Requisitos 2.1. Introducción. En el presente capítulo se realiza la descripción de las características que va a presentar el sistema, para ello se describen los procesos del negocio que se encuentran dentro del campo de acción. Por otra parte, se realiza un estudio detallado con el objetivo de definir los casos de uso y actores del negocio, requisitos funcionales y no funcionales. 2.2. Modelo del negocio actual. Para la modelación del negocio se realizó una entrevista a la Ejecutiva Comercial y se identificó como proceso la solicitud de un traslado telefónico. 2.2.1 Flujo actual del proceso En los diagramas de procesos se define la forma en que la organización crea, captura y entrega la información mediante la interacción de los trabajadores del negocio por medio de cada una de las actividades que se les son asignadas. La Figura 2.1 muestra el diagrama que describe el proceso de solicitud de un traslado telefónico, se hace visible un evento de comienzo denominado Solicitud que es el que va a dar paso a todas las actividades que están involucradas en el proceso y que no culmina hasta la llegada del evento de finalización, que puede estar representado por una Solicitud rechazada o por el Servicio completado. Cada una de las particiones horizontales se hace corresponder a los trabajadores del negocio involucrados en el proceso de traslado telefónico.. 15.

(27) Capítulo 2: Modelo de Negocio y Requisitos. Figura 2.1: Modelo del negocio. 2.2.2 Análisis crítico de la ejecución del proceso El proceso de solicitud de un traslado telefónico inicia cuando el cliente acude a la empresa y contacta a la Ejecutiva Comercial para realizar el traslado de su teléfono hacia otro domicilio. La Ejecutiva Comercial verifica que el cliente es el titular del servicio al solicitarle su carnet de identidad para compararlo con los datos registrados del mismo, si existe una correspondencia prosigue a tomar los datos correspondientes a la solicitud. En el caso de que el traslado se desee efectuar hacia otra provincia se le informa al cliente que debe acudir a la Oficina Comercial correspondiente a dicho destino; en caso contrario se le envía la solicitud al Reparador para que este la analice y determine si existe la disponibilidad. En caso de existir se ejecuta la instalación del mismo, en caso contrario se le informa a la Ejecutiva Comercial las causas por las que no es posible el traslado, esta tiene la responsabilidad de clasificarlos asignándole un estado. 16.

(28) Capítulo 2: Modelo de Negocio y Requisitos El estado que tenga el traslado va a determinar la manera de proseguir con el mismo. En el caso de estado cancelado se le informa al cliente del rechazo y finaliza el proceso sin la obtención de una solución satisfactoria; en cambio cuando se encuentra en estado pendiente es el Reparador el que debe darle un mantenimiento periódico evaluando su situación hasta lograr modificar su estado a realizado que es cuando se logra el traslado del servicio. Finalmente la Ejecutiva Comercial elabora un informe que recoge todos los datos relacionados con los traslados telefónicos incluyendo en este sus causas y estado. 2.2.3 Procesos objeto de automatización Después de analizar rigurosamente los procesos del negocio en conjunto con el cliente se identificaron las actividades que van a ser objeto de automatización, siendo aquellas que se llevan actualmente de forma manual como es el caso de: la toma de los datos relacionados con la solicitud y la realización del informe que recoge las estadísticas vinculadas a los traslados; igualmente se determinó que las actividades que involucran la toma de decisiones basadas en lo conocimientos de los especialistas no serían automatizadas, tal es el caso de: clasificación del Traslado por su causa y la instalación del servicio hacia el lugar donde se efectuará el traslado. 2.3. Reglas del negocio a considerar. Las reglas del negocio son aquellas condiciones que deben ser satisfechas, regulando algún aspecto del negocio. En el caso de la empresa de ETECSA y más específico, en las Oficinas Comerciales que es donde se realizan los trámites relacionados con el traslado telefónico deben considerarse las siguientes reglas: . Reglas de estructura: Se identificaron tres reglas de estructura que representan conceptos del contexto del negocio que se analiza. RN1: Cesión de la titularidad: Acto jurídico mediante el cual el titular del servicio telefónico básico cede la titularidad del mismo a la persona natural de su elección, deviniendo la misma en nueva titular del servicio. RN2: Transmisión de la titularidad: Acto jurídico mediante el cual se transmite la titularidad del servicio telefónico básico a partir del fallecimiento, presunción de 17.

(29) Capítulo 2: Modelo de Negocio y Requisitos muerte o salida definitiva del país de su titular, a otra persona natural que deviene en nueva titular del servicio; según lo regulado a estos efectos. RN3: Edad de un traslado: Tiempo transcurrido en estado de pendiente. . Reglas de acción: Se identificaron tres reglas de acción que son aquellas condiciones que restringen el flujo de la información. RN4: Cada trámite comercial solicitado debe realizarlo el titular del servicio presentando su documento de identidad. o su representante con su. correspondiente poder notarial. RN5: El cambio de titularidad se le aplicará a todas las solicitudes realizadas con anterioridad a la fecha del 25 de mayo de 2012 que se encuentren pendientes y a las nuevas solicitudes. RN6: Cuando el cliente acude a la institución a realizar el traslado del servicio hacia otra dirección debe presentar su documento de identidad y un recibo del último mes debidamente pagado. 2.4. Actores del negocio. Rol que expresa el comportamiento de un agente externo al negocio que busca extraer determinado valor del mismo. En este caso se puede identificar como actor al cliente ya que es el que acude a la institución con el objetivo de solicitar un servicio. 2.5. Diagrama de casos de uso del negocio. Describe los procesos de negocio de una empresa en términos de casos de uso y actores del negocio, que se corresponden con los procesos del negocio y los clientes, respectivamente. La Figura 2.2 representa el diagrama de casos de uso del negocio, muestra al cliente como actor del mismo, ya que este es el que dispara el proceso y da inicio a los casos de uso: registrar traslado y cambiar titularidad. Se identifica el caso de uso reanudar contrato que mantiene una relación de inclusión con cambiar titularidad, ya que va depender de la previa ejecución de este. Por último se define el caso de uso ejecutar instalación, este proceso comienza por acciones internas del negocio, es decir el cliente no es el que inicializa el proceso sino que espera a que le ejecuten la. 18.

(30) Capítulo 2: Modelo de Negocio y Requisitos instalación, por este motivo se puede visualizar la flecha de relación en sentido contrario.. Figura 2.2: Diagrama de casos de uso del negocio. 2.6. Trabajadores del negocio. Rol que expresa el comportamiento de un agente interno en el negocio, es decir, que participa dentro del proceso, lo hace funcionar y tiene responsabilidades dentro del mismo. Ejecuta las acciones que se llevan a cabo internamente en los procesos. La Tabla 2.1 muestra a los trabajadores que intervienen en el negocio. Trabajador. Justificación. Ejecutiva Comercial. Es la encargada de recibir la solicitud del traslado por parte del cliente y archivar la información vinculada al mismo. Realiza un informe con los datos de todos los traslados pendientes. clasificando. los. mismos. por. estados y causas. Reparador. Es el encargado de verificar la disponibilidad del traslado y en caso de que exista ejecutar la instalación del mismo, en caso contrario. 19.

(31) Capítulo 2: Modelo de Negocio y Requisitos informa a la Ejecutiva Comercial las causas por las que no se puede realizar el servicio de manera momentánea o definitoria. Tabla 2.1: Descripción de los trabajadores del negocio. 2.7. Casos de uso del negocio. Un caso de uso del negocio representa a un proceso del negocio, por lo que se corresponde con una secuencia de acciones que producen un resultado observable para ciertos actores del negocio. Desde la perspectiva de un actor individual, define un flujo de trabajo completo que produce resultados deseables. La Tabla 2.2 describe los casos de uso que intervienen en el negocio: CUN1. Registrar traslado. Descripción. Este caso de uso tiene como objetivo el traslado del servicio hacia otra dirección y solo será posible si existe la disponibilidad técnica para efectuar el movimiento de domicilio y si no existen demandas insatisfechas pendientes por solucionar.. CUN2. Cambiar titularidad. Descripción. Este caso de uso tiene como objetivo efectuar el traspaso de la titularidad del contrato del servicio telefónico básico en lo concerniente a cesión o transferencia y se le aplicará a todas las solicitudes de traspaso de titularidad realizadas con anterioridad a la fecha del 25 de mayo de 2012 que se encuentren pendientes y a las nuevas solicitudes.. CUN3. Reanudar contrato. Descripción. Para la realización de este caso de uso es necesario que el Usuario haya efectuado el CUN2, tiene como objetivo legalizar el estado del servicio ya que al realizar un cambio de titularidad se requiere de una actualización del contrato con los datos del nuevo propietario.. CUN4. Ejecutar instalación. 20.

(32) Capítulo 2: Modelo de Negocio y Requisitos Descripción. En el momento que exista la disponibilidad técnicapara efectuar el movimiento de domicilio y todas las demandas insatisfechas pendientes por solucionar hayan sido resueltas, la empresa ejecuta la instalación del servicio cumpliendo de esta manera con lo solicitado por el Usuario en el CUN1.. Tabla 2.2: Descripción de los casos de uso del negocio. 2.8. Actores del sistema a automatizar. Los actores del sistema son los trabajadores del negocio vinculados a las actividades a automatizar, además de aquel actor del negocio que va a interactuar con el sistema. La Empresa de Telecomunicaciones tiene una estructura compuesta por Unidades que representan a cada una de las provincias del territorio nacional, la correspondiente es la Dirección Territorial de Villa Clara que a su vez está integrada por diferentes Centros de Telecomunicaciones que pertenecen a los municipios, aclarada esta estructura empresarial se puede justificar la intervención de los siguiente actores en el sistema (Véase Tabla2.3). Actor Administrador del Sistema (admin). Descripción Es el encargado de la configuración del sistema.. Ejecutiva de Punto de Venta (exec). Se encarga de la gestión de los traslados pertenecientes a su centro.. Visualizador (viewer). Visualiza los traslados pendientes de su unidad.. Visualizador de Oficina (cviewer). Visualiza solo los traslados pertenecientes a su centro.. Especialista de Comercial (epcm). Es la encargada de administrar su División Territorial.. Tabla 2.3: Descripción de los actores del sistema. 21.

(33) Capítulo 2: Modelo de Negocio y Requisitos Una relación de generalización de una clase hija a una clase padre entre actores indica que el hijo hereda el rol que la clase padre puede jugar respecto a un caso de uso. La Figura 2.3 representa esta relación en los actores Administrador, Especialista de comercial y Visualizador hacia Usuario ya que existen casos de uso que van a ser comunes a ellos; ocurriendo lo mismo para el caso de Ejecutiva de punto de venta y Visualizador de Oficina.. Figura 2.3: Relación entre los actores del sistema. 2.9. Definición de los requisitos funcionales. Los requisitos funcionales son todos aquellos servicios que provee una aplicación. Para el desarrollo del Sistema de Control de Traslados Telefónicos Pendientes se definieron los siguientes: . RF1: Autenticación: El usuario tendrá que autenticarse introduciendo su usuario y contraseña. Si los datos introducidos son correctos, accederá a la aplicación. 22.

(34) Capítulo 2: Modelo de Negocio y Requisitos . RF2: Registrar trazas: El sistema debe registrar las trazas de cada usuario que se logue para contribuir a la seguridad del mismo.. . RF3: Visualizar usuarios: Se podrá visualizar una lista con todos los usuarios que tienen acceso a la aplicación.. . RF4: Visualizar roles: Se podrá visualizar una lista con todos los roles que tienen los usuarios que intervienen en la aplicación.. . RF5: Crear rol: Se podrá adicionar nuevos roles de usuarios a la base de datos.. . RF6: Modificar rol: Se podrá editar los roles de usuarios que se encuentran almacenados en la base de datos.. . RF7: Eliminar rol: Desde esta opción el usuario podrá eliminar un rol existente.. . RF8: Visualizar traslado: Se muestra una lista con la información referente a todos los traslados que se encuentran registrados, independientemente de su estado.. . RF9: Modificar traslado: Se podrá editar la información referente a los traslados que se encuentran almacenados en la base de datos.. . RF10: Insertar Traslado: Se adicionan traslados, definiéndole un estado de pendiente de forma inicial.. . RF11: Visualizar gráfico: Se muestra un resumen de los traslados agrupados por causas y por los centros correspondientes.. . RF12: Mostrar reporte: Se agrupan los traslados por centros clasificándolos en dependencia del tiempo que llevan en estado de pendientes.. . RF13: Exportar datos: Se tiene la opción de exportar hacia documentos Excel los datos almacenados.. . RF14: Filtrar datos: Se proporcionaran filtros que le permitirá al usuario agrupar datos a conveniencia o realizar una búsqueda entre todos de una forma rápida y eficiente.. . RF15: Visualizar unidad: Se muestra una lista con todas las unidades y los datos asociados a las mismas.. . RF16: Insertar unidad: Se adiciona una nueva unidad a la base de datos.. . RF17: Modificar unidad: Se modifican los datos relativos a una unidad.. 23.

(35) Capítulo 2: Modelo de Negocio y Requisitos . RF18: Eliminar unidad: Se elimina una unidad de la base de datos.. . RF19: Visualizar área: Se muestra una lista con todas las áreas y los datos asociados a las mismas.. . RF20: Insertar área: Se adiciona una nueva área a la base de datos.. . RF21: Modificar área: Se modifican los datos relativos a un área determinada.. . RF22: Eliminar área: Se elimina un área determinada de la base de datos.. . RF23: Visualizar Centro de Telecomunicaciones: Se muestra una lista con los Centros de Telecomunicaciones y los datos asociados a los mismos.. . RF24: Insertar Centro de Telecomunicaciones: Se adiciona un nuevo Centro de Telecomunicaciones a la base de datos.. . RF25: Modificar Centro de Telecomunicaciones: Se modifican los datos relativos a los Centros de Telecomunicaciones.. . RF26: Eliminar Centro de Telecomunicaciones: Se elimina un Centro de Telecomunicaciones de la base de datos.. . RF27: Visualizar provincia: Se muestra una lista con las provincias y los datos asociados a las mismas.. . RF28: Insertar provincia: Se adiciona una nueva provincia a la base de datos.. . RF29: Modificar provincia: Se modifican los datos relativos a las provincias.. . RF30: Eliminar provincia: Se elimina una provincia determinada de la base de datos.. . RF31: Visualizar municipio: Se muestra una lista con los municipios y los datos asociados a los mismos.. . RF32: Insertar municipio: Se adiciona un nuevo municipio a la base de datos.. . RF33: Modificar municipio: Se modifican los datos relativos a los municipios.. . RF34: Eliminar municipio: Se elimina un municipio determinado de la base de datos.. . RF35: Visualizar consejo popular: Se muestra una lista con los consejos populares y los datos asociados a los mismos.. . RF36: Insertar consejo popular: Se adiciona un nuevo consejo popular a la base de datos. 24.

(36) Capítulo 2: Modelo de Negocio y Requisitos . RF37: Modificar consejo popular: Se modifican los datos relativos a los consejos populares.. . RF38: Eliminar consejo popular: Se elimina un consejo popular determinado de la base de datos.. . RF39: Visualizar localidad: Se muestra una lista con las localidades y los datos asociados a los mismos.. . RF40: Insertar localidad: Se adiciona una nueva localidad a la base de datos.. . RF41: Modificar localidad: Se modifican los datos relativos a las localidades.. . RF42: Eliminar localidad: Se elimina una localidad determinada de la base de datos.. . RF43: Visualizar reparto: Se muestra una lista con los repartos y los datos asociados a los mismos.. . RF44: Insertar reparto: Se adiciona un nuevo reparto a la base de datos.. . RF45: Modificar reparto: Se modifican los datos relativos a los repartos.. . RF46: Eliminar reparto: Se elimina un reparto determinado de la base de datos.. . RF47: Visualizar servicio: Se muestra una lista con los servicios y los datos asociados a los mismos.. . RF48: Insertar servicio: Se adiciona un nuevo servicio a la base de datos.. . RF49: Modificar servicio: Se modifican los datos relativos a los servicios.. . RF50: Eliminar servicio: Se elimina un servicio determinado de la base de datos.. . RF51: Visualizar estado: Se muestra una lista con los estados que puede presentar un traslado.. . RF52: Insertar estado: Se adiciona un nuevo estado del traslado a la base de datos.. . RF53: Modificar estado: Se modifican los estados de los traslados.. . RF54: Eliminar estado: Se elimina un estado de la base de datos.. . RF55: Visualizar tipo de movimiento: Se muestra una lista con los tipos de movimientos que se pueden realizar.. . RF56: Insertar tipo de movimiento: Se adiciona un nuevo tipo de movimiento a la base de datos. 25.

(37) Capítulo 2: Modelo de Negocio y Requisitos . RF57: Modificar tipo de movimiento: Se modifican los tipos de movimientos almacenados.. . RF58: Eliminar tipo de movimiento: Se elimina un tipo de movimiento de la base de datos.. . RF59: Visualizar causa de pendiente: Se muestra una lista con las causas de pendientes de los traslados.. . RF60: Insertar causa de pendiente: Se adiciona una nueva causa a la base de datos.. . RF61: Modificar causa de pendiente: Se modifican las causas existentes en la base de datos.. . RF62: Eliminar causa de pendiente: Se elimina la causa de la base de datos.. . RF63: Visualizar subcausa de pendiente: Se muestra una lista con todas las subcausas asociadas a una causa de pendiente de un traslado.. . RF64: Insertar subcausa de pendiente: Se adiciona una nueva subcausa de pendiente a la base de datos.. . RF65: Modificar subcausa de pendiente: Se modifican las subcausas asociadas a una cauda de pendiente de un traslado.. . RF66: Eliminar subcausa de pendiente: Se elimina una subcausa de la base de datos.. 2.10 Definición de los requisitos no funcionales Los requisitos no funcionales especifican criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos. Se refiere a todos los requisitos que no describen información a guardar, ni funciones a realizar, sino características de funcionamiento. Para el desarrollo del Sistema de Control de Traslados Telefónicos Pendientes se definieron los siguientes: RNF1: Software:  Se necesita Apache versión 2.0.50 o superior para el servidor web.  El sistema necesita un servidor de base de datos MySQL. 26.

(38) Capítulo 2: Modelo de Negocio y Requisitos  En las computadoras de los clientes se necesita un navegador (Mozilla Firefox versión >=42, Google Chrome versión >=48, etc.). RNF2: Hardware:  Se necesita como mínimo una máquina que servirá de servidor de 1 GB de RAM, HD mayor de 50 GB. RNF3: Apariencia o interfaz interna:  Debe utilizarse un plantilla que cumpla con los estándares de la empresa, predominando el azul y el gris como colores bases.  Para nombrar los menús, botones y cajas de diálogo se solicitó opinión del cliente. RNF4: Seguridad:  Para acceder al sistema siempre habrá que autenticarse.  Solo los usuarios con derechos de administración podrán realizar las funciones administrativas.  Se almacenarán las trazas relativas a cada usuario que se haya autenticado en la aplicación. RNF5: Usabilidad:  El diseño de la herramienta mostrará al usuario el estado de las acciones que se realizarán, a través de los mensajes de confirmación y de error.  La herramienta contará con un menú principal que responde a las funcionalidades pactadas con el cliente, desde el cual el usuario podrá acceder a las mismas mediante el uso del mouse.  En la página principal se mostrará enlaces para acceder a los reportes solicitados por los usuarios. RNF6: Escalabilidad:  La aplicación permitirá incorporar nuevas funciones sin afectar a las ya existentes. RNF7: Rendimiento: 27.

(39) Capítulo 2: Modelo de Negocio y Requisitos  Las aplicaciones de una sola página implementadas con AngularJs, permiten tiempos de carga muy cortos. RNF8: Estabilidad:  Se pretende conseguir que el sistema tenga el menor número de fallos posibles. 2.11 Paquetes y sus relaciones Un diagrama de paquetes representa la agrupación lógica en la que se divide el sistema. Los elementos dentro del paquete pueden ser dependientes de los elementos contenidos en otros paquetes; esto da origen a dependencias entre paquetes. En la Tabla 2.4 se describen los principales paquetes que intervienen en la aplicación. Paquete. Descripción. Controllers. Se encuentran almacenados cada uno de los archivos que representan las clases que controlan la lógica del sistema.. Models. Se encuentra ubicados los archivos que contienen las consultas específicas a la base de datos.. Modules. Se encuentran almacenados los módulos de nuestra aplicación, que son paquetes que contienes los archivos que suministran el código relativo a las interfaces de interacción con el usuario.. Config. Se encuentra almacenado el archivo database.php que se encarga de la configuración para la conexión a la base de datos y el archivo routes.php donde se definen las rutas para el servidor.. Vendors. Se encuentran almacenados todos aquellos plugins de angular que se vayan a utilizar.. Css Libraries Img. Se ubican los archivos públicos css generales. Se encuentran almacenadas las librerías que usa el sistema. Se ubican las imágenes que usan las interfaces de interacción con el usuario.. Tabla 2.4: Descripción de los paquetes en los que se divide el sistema. En la Figura 2.4 se muestra la relación de dependencia que existe entre los principales paquetes del sistema, considerando siempre que la saeta sale del paquete dependiente y apunta hacia el paquete de donde se genera la dependencia.. 28.

(40) Capítulo 2: Modelo de Negocio y Requisitos. Figura 2.4: Diagrama de paquetes. 2.12 Diagrama de Casos de Uso del Sistema En el diagrama de casos de uso del sistema se muestra la interacción de los cinco actores que intervienen en el sistema con los casos de uso a los que estos tienen acceso. Se puede visualizar las relaciones entre casos de uso como por ejemplo la relación de Inclusión (include) que se usa cuando el comportamiento definido para el caso de uso de inclusión se inserta explícitamente dentro del comportamiento definido para el caso de uso base; en el caso de la relación de Extensión (extend) que también está visible en el diagrama se usó para representar flujos distintos que pueden ejecutarse en base a la selección del actor. Una vez identificado el flujo de cada caso de uso, se pueden encontrar estructuras y comportamientos que son comunes a varios casos de uso. Para no tener que describir el mismo flujo varias veces, se puede colocar el comportamiento común en un caso de uso, generando de este modo una relación de Generalización/Especialización entre ellos. (Véase Figura 2.5). 29.

(41) Capítulo 2: Modelo de Negocio y Requisitos. Figura 2.5: Diagrama de casos de uso del sistema. Si el sistema se hace extenso entonces se debería organizar en paquetes, lo cual facilitaría la comprensión de la vista de casos de uso. Existen tres criterios que justifican el empaquetamiento de los casos de uso, ellos son los siguientes:. 30.

(42) Capítulo 2: Modelo de Negocio y Requisitos 1. Los casos de usos requeridos para dar soporte a un determinado proceso de negocio. 2. Los casos de usos requeridos para dar soporte a un determinado actor del sistema. 3. Los. casos de. usos. que. están. relacionados mediante. relaciones de. generalización y extensión. En este caso se empaquetaron los casos de uso que están relacionados mediante relaciones de generalización como se muestra en la Figura 2.6.. Figura 2.6: Empaquetamiento de casos de uso del sistema. 2.13 Determinación de los casos de Uso del Sistema más significativos. 31.

(43) Capítulo 2: Modelo de Negocio y Requisitos Es necesario determinar cuáles casos de Uso son más necesarios para el desarrollo en las primeras iteraciones y cuáles pueden dejarse para más tarde. Las siguientes clasificaciones de casos de uso nos ayudan a la hora de priorizarlos: . Críticos: Son aquellos casos de uso que representan mayor importancia para los. usuarios ya que cumplen las principales tareas que el sistema debe realizar, definen la arquitectura básica. . Secundarios: Sirven de apoyo a los casos de uso críticos, involucran funciones secundarias y tienen un impacto más modesto sobre la arquitectura, pero deben implementarse pronto porque responden a requerimientos de interés para los usuarios.. . Auxiliares: Estos casos de uso no son claves para la arquitectura, completan casos de usos críticos o secundarios.. . Opcionales: Son los casos uso asociados a funcionalidades que pueden o no estar en la aplicación, pero que no es imprescindible su implementación en las primeras versiones. En la Tabla 2.5 se agruparon los casos de uso del sistema de acuerdo a su clasificación. Clasificaciones. Críticos. Casos de Uso del Sistema  Autenticar usuario.  Gestionar traslado.  Mostrar reporte Secundarios.  Gestionar provincia.  Gestionar.  Gestionar municipio. pendiente.  Gestionar localidad.  Gestionar.  Gestionar. consejo.  Gestionar reparto. de. subcausa. de. tipo. de. pendiente  Gestionar. popular. causa. movimiento  Gestionar estado  Gestionar tipo de servicio. 32.

(44) Capítulo 2: Modelo de Negocio y Requisitos Auxiliares. Opcionales.  Gestionar usuario.  Visualizar gráfico.  Gestionar rol.  Filtrar datos.  Registrar trazas.  Exportar datos.  Gestionar Unidades.  Gestionar.  Gestionar Áreas. Centros. de. Telecomunicaciones. Tabla 2.5: Clasificación de los casos de uso del sistema. 2.14 Descripción de los casos de uso del Sistema más significativos De acuerdo a las clasificaciones establecidas anteriormente se puede determinar como casos de uso más significativos: Autenticar usuario, Gestionar traslado y Mostrar reporte, ya que son los tres de mayor prioridad para el cliente. 2.14.1 Caso de Uso del Sistema Autenticar usuario En la Tabla 2.6 se realiza la descripción del caso de uso del sistema Autenticar usuario. Caso de uso del sistema Actores. Autenticar usuario Todos los actores del sistema tienen acceso a este caso de uso.. Propósito. Autenticación de los usuarios en el sistema.. Resumen. El caso de uso inicia cuando el usuario carga la página de SCTTP y el sistema muestra la página de autenticación donde solicita al usuario el nombre de su cuenta.. Responsabilidades. Proveer seguridad al sitio.. Requisitos especiales. _. Precondiciones. Usuario autenticado en el sistema Flujo normal de los eventos. Acción del actor. Respuesta del sistema. 1-El usuario carga la página de 2-El sistema solicita que introduzca la cuenta ycontraseña. SCTTP.. 3-El usuario introduce los datos 4-El sistema comprueba los datos introducidos. requeridos y pulsa el botón. 33.