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
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
I
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”.
II
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.
III
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.
IV
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.
V
Í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
VI
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
VII
3.8.2 Esquema físico de datos ........................................................................... 48
3.9 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
VIII
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
IX
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
Introducción
1
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.
Introducción
2
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.
Introducción
3
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
Introducción
4
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.
Capítulo 1: Fundamentación Teórica
5
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
Capítulo 1: Fundamentación Teórica
6
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.
Capítulo 1: Fundamentación Teórica
7
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:
Capítulo 1: Fundamentación Teórica
8
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
Capítulo 1: Fundamentación Teórica
9
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.
Capítulo 1: Fundamentación Teórica
10
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).
Capítulo 1: Fundamentación Teórica
11
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
parte de su competencia ya que
tiene la posibilidad de selección de
mecanismos de almacenamiento
que ofrecen diferentes velocidades
de operación, soporte físico,
capacidad, distribución geográfica,
transacciones. Aprovecha la
potencia de sistemas
multiprocesador, gracias a su
implementación multihilo.
La velocidad de respuesta que
ofrece este gestor con bases de
datos relativamente pequeñas
puede parecer un poco deficiente,
aunque esta misma velocidad la
mantiene al gestionar bases de
datos realmente grandes, cosa que
resulta loable. Es capaz de
ajustarse al número de CPUs y a la
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
Capítulo 1: Fundamentación Teórica
12
Conceptual
Fiabilidad Resulta fácil de utilizar y
administrar. Las herramientas de
MySQL son potentes y flexibles,
sin sacrificar su capacidad de uso.
Sus características técnicas la
hacen una de las bases de datos
más potentes.
Arquitectura de
Implementación
Cliente / servidor Cliente / servidor
Manejo de
transacciones
MySQL cuenta con la agrupación
de transacciones, reuniendo
múltiples transacciones de varias
conexiones para incrementar el
número de transacciones por
segundo.
Limitación: Actualmente, las
transacciones abortan
completamente si se encuentra un
fallo durante su ejecución.
Plataforma
soportada
Multiplataforma. Cuenta con
disponibilidad en gran cantidad de
plataformas y sistemas, tales
como; GNU/Linux. Y en sistemas
operativos de Microsoft Windows.
Usa GNU Automake, Autoconf, y
Libtool para portabilidad
Multiplataforma. Cualquier
plataforma moderna tipo Unix debe
ser capaz de ejecutar PostgreSQL,
también corre de forma nativa en
sistemas operativos basados en
Microsoft Windows NT como
Win2000 SP4, WinXP y Win2003.
Tabla 1.1: Comparación entre PostgreSQL y MySQL (10)
Capítulo 1: Fundamentación Teórica
13
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 configurable 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
Capítulo 1: Fundamentación Teórica
14
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.
Capítulo 2: Modelo de Negocio y Requisitos
15
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.
Capítulo 2: Modelo de Negocio y Requisitos
16
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.
Capítulo 2: Modelo de Negocio y Requisitos
17
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
Capítulo 2: Modelo de Negocio y Requisitos
18
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
Capítulo 2: Modelo de Negocio y Requisitos
19
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
Capítulo 2: Modelo de Negocio y Requisitos
20
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
Capítulo 2: Modelo de Negocio y Requisitos
21
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 Descripción
Administrador del Sistema (admin) 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
Capítulo 2: Modelo de Negocio y Requisitos
22
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.
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.
Figura 2.3: Relación entre los actores del sistema
Capítulo 2: Modelo de Negocio y Requisitos
23
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.
Capítulo 2: Modelo de Negocio y Requisitos
24
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.
Capítulo 2: Modelo de Negocio y Requisitos
25
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.
Capítulo 2: Modelo de Negocio y Requisitos
26
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.
Capítulo 2: Modelo de Negocio y Requisitos
27
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:
Capítulo 2: Modelo de Negocio y Requisitos
28
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 Se ubican los archivos públicos css generales.
Libraries Se encuentran almacenadas las librerías que usa el sistema.
Img 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.
Capítulo 2: Modelo de Negocio y Requisitos
29
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)
Capítulo 2: Modelo de Negocio y Requisitos
30
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:
Capítulo 2: Modelo de Negocio y Requisitos
31
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
Capítulo 2: Modelo de Negocio y Requisitos
32
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 Casos de Uso del Sistema
Críticos
Autenticar usuario
Mostrar reporte
Gestionar traslado
Secundarios
Gestionar provincia
Gestionar municipio
Gestionar localidad
Gestionar consejo
popular
Gestionar reparto
Gestionar causa de
pendiente
Gestionar subcausa de
pendiente
Gestionar tipo de
movimiento
Gestionar estado
Gestionar tipo de servicio
Capítulo 2: Modelo de Negocio y Requisitos
33
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 Autenticar usuario
Actores 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
SCTTP.
2-El sistema solicita que introduzca la cuenta ycontraseña.
3-El usuario introduce los datos
requeridos y pulsa el botón
4-El sistema comprueba los datos introducidos.
Auxiliares Gestionar usuario
Gestionar rol
Registrar trazas
Visualizar gráfico
Filtrar datos
Exportar datos
Opcionales Gestionar Unidades
Gestionar Áreas
Gestionar Centros de
Telecomunicaciones
Tabla 2.5: Clasificación de los casos de uso del sistema
Capítulo 2: Modelo de Negocio y Requisitos
34
“Aceptar”.
5- Accede a SCTTP al haber
introducido los datos
correctamente.
_
Flujos alternativos
Sección Principal: entre la línea 4 y la línea 5.
Si el usuario no se encuentra registrado en el sistema o simplementecometió un error al
introducir los datos aparece un mensaje de error, indicando que los datos de acceso son
incorrectos.
Post condiciones Sesión abierta.
Tabla 2.6: Descripción del caso de uso del sistema “Autenticar usuario”
2.14.2 Caso de Uso del Sistema Gestionar usuario
En la Tabla 2.7 se realiza la descripción de la funcionalidad Listar Traslado
correspondiente al caso de uso del sistema Gestionar traslado.
Caso de uso del sistema Listar traslado
Actores Todos los actores del sistema tienen acceso a este caso de
uso.
Propósito Visualizar todos los traslados que se encuentran almacenados
en la Base de Datos.
Resumen El caso de uso inicia luego de que el usuario inicia sesión y
cliquea en la opción de traslado.
Responsabilidades Proveerle al usuario una visualización de todos los traslados
que se encuentran almacenados en la Base de Datos
Requisitos especiales _
Precondiciones Usuario logado en el sistema.
Flujo normal de los eventos
Acción del actor Respuesta del sistema
1-El usuario pulsa en la opción
Traslado de la barra de
navegación.
2-El sistema muestra una tabla con toda la información de los
traslados existentes.
Capítulo 2: Modelo de Negocio y Requisitos
35
Post condiciones _
Tabla 2.7: Descripción de la funcionalidad Listar traslado
En la Tabla 2.8 se realiza la descripción de la funcionalidad Insertar Traslado
correspondiente al caso de uso del sistema Gestionar traslado.
Caso de uso del sistema Insertar traslado
Actores Administrador, Ejecutiva de Punto de Venta y Especialista de
Comercial.
Propósito Insertar un nuevo traslado en la Base de Datos.
Resumen El caso de uso inicia luego de que el usuario inicia sesión y
cliquea en la opción de traslado para luego dirigirse a
adicionar uno.
Responsabilidades Actualizar la Base de Datos con la información relativa a todos
los traslados telefónicos.
Requisitos especiales _
Precondiciones Usuario logado en el sistema.
Flujo normal de los eventos
Acción del actor Respuesta del sistema
1-El usuario pulsa en la opción
Insertar traslado.
2-El sistema muestra un formulario con los datos requeridos.
3-Rellena los datos necesarios
con la información del traslado
y pulsa “Aceptar”.
4- Guarda el traslado en la Base de Datos y actualiza la
sección con la nueva información.
Flujos alternativos
Sección Principal: entre la línea 3 y la línea 4.
Si el usuario cometió un error al introducir los datos aparece un mensaje de error, indicando que
los datos de acceso son incorrectos.
Post condiciones Un nuevo traslado quedará registrado en la Base de Datos.
Tabla 2.8: Descripción de la funcionalidad Insertar traslado
Capítulo 2: Modelo de Negocio y Requisitos
36
En la Tabla 2.9 se realiza la descripción de la funcionalidad Modificar Traslado
correspondiente al caso de uso del sistema Gestionar traslado.
Caso de uso del sistema Modificar traslado
Actores Administrador, Ejecutiva de Punto de Venta y Especialista de
Comercial.
Propósito Modificar los datos relativos a un traslado determinado.
Resumen El caso de uso inicia luego de que el usuario inicia sesión y
cliquea en la opción de traslado para luego dirigirse a
modificar uno.
Responsabilidades Actualizar la Base de Datos con la información relativa a todos
los traslados telefónicos.
Requisitos especiales _
Precondiciones Usuario logado en el sistema.
Flujo normal de los eventos
Acción del actor Respuesta del sistema
1-El usuario pulsa en la opción
Modificar traslado.
2-El sistema muestra un formulario con los datos del traslado
que será modificado.
3-Modifica los datos deseadosy
pulsa “Aceptar”.
4- Guarda el traslado en la Base de Datos y actualiza la
sección con la nueva información.
Flujos alternativos
Sección Principal: entre la línea 3 y la línea 4.
Si el usuario cometió un error al introducir los datos aparece un mensaje de error, indicando que
los datos de acceso son incorrectos.
Post condiciones Actualización de los datos relativos a un traslado.
Tabla 2.9 Descripción de la funcionalidad Modificar traslado
En la Tabla 2.10 se realiza la descripción del caso de uso del sistema Mostrar reporte:
Caso de uso del sistema Mostrar reporte
Actores Administrador, Ejecutiva de Punto de Venta, Visualizador,
Visualizador de Oficina y Especialista de Comercial.
Propósito Brindarle al usuario un resumen de los traslados pendientes.
Capítulo 2: Modelo de Negocio y Requisitos
37
Resumen El caso de uso inicia luego de que el usuario inicia sesión y
cliquea en la opción de Informes.
Responsabilidades Mantener un resumen actualizado con la información de todos
los traslados.
Requisitos especiales _
Precondiciones Usuario autenticado en el sistema.
Flujo normal de los eventos
Acción del actor Respuesta del sistema
1-El usuario pulsa en la opción
Reporte.
2-El sistema muestra una tabla de resumen con información
relativa a los traslados pendientes.
Flujos alternativos
Sección Principal: entre la línea 1 y la línea 2.
El sistema no muestra ningún reporte si no se encuentran datos de los traslados almacenados en
la Base de Datos.
Post condiciones _
Tabla 2.10:Descripción del caso de uso del sistema “Mostrar reporte”
2.15 Conclusiones parciales
En este capítulo se realizó un análisis del negocio, se definieron las reglas del negocio,
los requisitos funcionales y se describieron los casos de uso del sistema más
significativos con lo cual quedaron resumidas las principales funcionalidades del
sistema.
Capítulo 4: Pruebas y análisis de factibilidad
38
Capítulo 3. Descripción de la propuesta de solución
3.1 Introducción
En este capítulo se modelan las clases del diseño y las relaciones entre ellas en
función de la propuesta del sistema y teniendo en cuenta las funcionalidades
requeridas. Se muestra además, el modelo de datos y el diagrama de clases
persistentes, para una mejor comprensión de la información que será gestionada por el
Sistema de Control de Traslados Telefónicos Pendientes. Se define la arquitectura para
la implementación y se especifican los patrones de que serán usados.
3.2 Arquitectura del sistema
Para la creación del sistema se tiene en cuenta una arquitectura Cliente/Servidor en
tres niveles: el cliente, el servidor de aplicaciones web y el servidor de datos. (Véase
Figura 3.1)
Figura 3.1: Arquitectura del sistema
3.3 Diagrama de clases de diseño
Algunos de los ejemplos más comunes de estereotipos que se pueden asociar a las
clases para representar una aplicación en web son los mostrados en la Tabla 3.1:
Capítulo 4: Pruebas y análisis de factibilidad
39
Estereotipos para las clases
Server Page
Representa una página web que tiene scripts ejecutados por el
servidor. Estos scripts interactúan con los recursos que se encuentran
al alcance del servidor. Sólo puede mantener relaciones con objetos
que se encuentren en el servidor
Client Page
Representan páginas que son dibujadas por el navegador web y
pueden ser una combinación de algún o algunos lenguajes de marcado,
scripts del lado del cliente, islas de datos, etc.
Form
Representa una colección de campos de entrada que forman parte con
una página del lado cliente (Client Page). Tiene una correspondencia
directa con la etiqueta <FORM> de XHTML.
Client Script Object
Es una colección de scripts del lado del cliente que existe como un
archivo separado y que son incluidos mediante una petición
independiente por parte del navegador.
Tabla 3.1: Estereotipos web para el diagrama de clases
3.3.1 Caso de Uso del Sistema Gestionar Traslado
En la Figura 3.2 se muestra el diagrama de clases correspondiente al caso de uso del
sistema Gestionar Traslado.
Capítulo 4: Pruebas y análisis de factibilidad
40
Figura 3.2 :Diagrama de clases del caso de uso del sistema Gestionar Traslado
3.3.2 Caso de Uso del Sistema Autenticar usuario
En la Figura 3.3 se muestra el diagrama de clases correspondiente al caso de uso del
sistema Autenticar usuario.
Capítulo 4: Pruebas y análisis de factibilidad
41
Figura 3.3:Diagrama de clases del caso de uso del sistema Autenticar usuario
3.4 Diagrama de secuencia
El diagrama de interacción es el artefacto que se encarga de expresar las interacciones
que se dan entre los objetos para cumplir los requerimientos del sistema. Este nombre
se utiliza para una clasificación de diagramas donde se identifican dos tipos: diagrama
de secuencia y diagrama de comunicación (o colaboración).
A continuación se presentan los diagramas de secuencia relativos a los diagramas de
clases derivados del análisis, los mensajes, que implican responsabilidades son
transformados en operaciones que finalmente definen las responsabilidades de las
clases.
3.4.1 Caso de Uso del Sistema Gestionar Traslado
En la Figura 3.4 se muestra el diagrama de secuencia correspondiente a la
funcionalidad de listar traslado que incluye el caso de uso del sistema Gestionar
traslado.
Capítulo 4: Pruebas y análisis de factibilidad
42
Figura 3.4: Diagrama de secuencia de la funcionalidad Listar traslado
En la Figura 3.5 se muestra el diagrama de secuencia correspondiente a la
funcionalidad de crear traslado que incluye el caso de uso del sistema Gestionar
traslado.
Figura 3.5: Diagrama de secuencia de la funcionalidad Crear traslado
En la Figura 3.6 se muestra el diagrama de secuencia correspondiente a la
funcionalidad de editar traslado que incluye el caso de uso del sistema Gestionar
traslado.
Capítulo 4: Pruebas y análisis de factibilidad
43
Figura 3.6: Diagrama de secuencia de la funcionalidad Editar traslado
3.4.2 Caso de Uso del Sistema Autenticar usuario
En la Figura 3.7 se muestra el diagrama de secuencia correspondiente a la
funcionalidad de autenticación del usuario.
Figura 3.7: Diagrama de secuencia del caso de uso del sistema Autenticar usuario
3.5 Patrón de arquitectura
Son patrones de diseño de software que ofrecen soluciones a problemas de
arquitectura de software en ingeniería de software. Dan una descripción de los
elementos y el tipo de relación que tienen junto con un conjunto de restricciones sobre
Capítulo 4: Pruebas y análisis de factibilidad
44
cómo pueden ser usados. Un patrón arquitectónico expresa un esquema de
organización estructural esencial para un sistema de software, que consta de
subsistemas, sus responsabilidades e interrelaciones. En comparación con los
patrones de diseño, los patrones arquitectónicos tienen un nivel de abstracción
mayor(12).
- Modelo-Vista-Controlador (MVC):
El patrón arquitectónico MVC define objetos en una aplicación en una de tres
funciones: Modelo, Vista o Controlador. El patrón define no sólo las funciones que
juegan los objetos en la aplicación web, sino que define la forma en que los objetos se
comunican entre sí. Cada uno de los tres tipos de objetos está separado de los otros
por límites abstractos con objetos de los otros tipos a través de esos límites. En
resumen: el modelo es datos, la vista representa estos datos, el controlador es el
enlace entre el modelo y la vista.
Figura 3.8: Representación del patrón arquitectónico MVC
3.6 Patrones de diseño
Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el
desarrollo de software. En otras palabras, brindan una solución ya probada y
documentada a problemas de desarrollo de software que están sujetos a contextos
similares (12).
Capítulo 4: Pruebas y análisis de factibilidad
45
-La Inyección de Dependencias (DI-Dependency Injection):
Es un patrón de diseño orientado a objetos, nos dice que los objetos necesarios en una
clase serán suministrados y que por tanto no se necesita que la propia clase cree estos
objetos. El framework AngularJs gestiona la inyección de dependencias, por lo tanto,
las dependencias serán suministradas por AngularJs. Por ello, al crear un componente
se deben indicar las dependencias que se esperan y será el propio framework el que
proporcione los objetos que se solicitan.
- Modelo Vista-Vista Modelo (MVVM):
MVVM es un refinamiento del diseño MVC y el Vista Modelo en MVVM se utiliza para la
simplificación de la separación de la presentación. En el MVVM, la lógica se almacena
en el presentador y la vista está completamente aislada del modelo. Mientras que el
presentador no es consciente de la vista, la vista es consciente del presentador - el
presentador en MVVM se utiliza para representar una vista abstracta de la interfaz de
usuario. Una vista pasiva significa que la vista no tiene ningún conocimiento del
modelo. En el patrón de diseño de MVVM, View está activo y contiene
comportamientos, eventos y datos vinculantes. Tenga en cuenta que la vista en MVVM
no es responsable de la gestión de la información de estado - la vista se sincroniza con
el modelo de vista. Vista Modelo en MVVM es responsable de la separación de la
presentación y expone métodos y comandos para administrar el estado de una vista y
manipular el modelo.
3.7 Tratamiento de errores
En el desarrollo de aplicaciones uno de los puntos que se deben destacar es el ingreso
de datos, este tipo de funcionalidad generalmente se hace con la utilización de un
formulario, si se van a pedir datos de un usuario se deben validar que no vengan con
errores. En este caso se validó del lado del cliente usando los mecanismos de
AngularJS y del lado del servidor mediante CodeIgniter.
Capítulo 4: Pruebas y análisis de factibilidad
46
AngularJS posee algunos mecanismos internos que nos permiten hacer las
validaciones de un modo sencillo, permitiendo de esta forma que solo se envíe el
formulario cuando las condiciones del formato de los datos sean cumplidas.(13)
Las propiedades o estados de un formulario de Angular nos brindan información sobre
la interacción del usuario con los componentes que conforman el formulario. Así, se
conocen 4 posibles estados o propiedades en los que se puede encontrar el formulario:
1. $valid: booleano que marca True si el formulario es válido de acuerdo a las
reglas definidas sobre este.
2. $invalid: booleano que marca True si al menos un componente del formulario no
cumple con las reglas definidas.
3. $dirty: booleano que marca True si el usuario ha interactuado con al menos un
componente del formulario. Por ejemplo, si el formulario consiste en dos campos
de texto y el usuario ingresa información en uno de estos.
4. $pristine: booleano que marca True si el usuario no ha ingresado nada en el
formulario, es decir si el formulario no se ha usado.
Además, dispone de 9 tipos de validaciones distintas:
1. email: El campo debe tener el formato de un correo electrónico.
2. max: El campo debe tener un valor máximo.
3. maxlength: El campo debe tener un nº máximo de caracteres.
4. min: El campo debe tener un valor mínimo.
5. minlength: El campo debe tener un nº mínimo de caracteres.
6. number: El campo debe ser un número.
7. pattern: El campo debe seguir una expresión regular.
8. required: el campo es requerido.
9. url: El campo debe tener el formato de una URL(14).
El tratamiento de errores del lado del servidor se manejó a través de la captura de
excepciones que se recogen en el bloque try/catch haciendo uso de la clase Exception
en PHP, dicha clase tiene las siguientes propiedades:
Capítulo 4: Pruebas y análisis de factibilidad
47
message: El mensaje de la excepción.
code: El código de la excepción.
file: El nombre del fichero donde se originó la excepción.
line: La línea donde se originó la excepción.
3.8 Esquema de la base de datos
Estructura de una base de datos, en un lenguaje formal soportado por un sistema de
gestión de base de datos. El esquema define sus tablas, sus campos en cada tabla y
las relaciones entre cada campo y cada tabla.
3.8.1 Esquema lógico de datos
Parte del esquema conceptual de una base de datos. Un esquema lógico de una base
de datos es una descripción de su estructura que puede procesar un SGBD.
En la Figura 3.9 se representa el modelo lógico de la base de datos.
Figura 3.9: Modelo conceptual de la base de datos
Capítulo 4: Pruebas y análisis de factibilidad
48
3.8.2 Esquema físico de datos
El modelo físico especifica detalles adicionales del almacenamiento. Esencialmente
resume el modo en que las relaciones descritas en el esquema lógico se guardan
realmente en dispositivos de almacenamiento secundario como discos y cintas. Es
necesario decidir la organización de archivos que se va a utilizar para guardar las
relaciones y crear estructuras de datos auxiliares, denominadas índices, para acelerar
las operaciones de recuperación.
El modelo físico de la base de datos se muestra en la Figura 3.10:
Figura 3.10: Modelo físico de la base de datos
3.9 Diagrama de Componentes
Un diagrama de componentes muestra las dependencias lógicas entre componentes de
software, sean éstos componentes fuentes, binarios o ejecutables, ilustran las piezas
del software, controladores embebidos, etc.
Capítulo 4: Pruebas y análisis de factibilidad
49
Para el Caso de Uso del sistema “Gestionar traslado”, se tiene el diagrama de
componentes representado en la Figura 3.11:
Figura 3.11: Diagrama de componentes del caso de uso del sistema “Gestionar traslado”
Para el Caso de Uso del sistema “Autenticar usuario”, se obtiene el diagrama de
componentes de la Figura 3.12:
Capítulo 4: Pruebas y análisis de factibilidad
50
Figura 3.12: Diagrama de componentes del caso de uso del sistema Autenticar usuario.
3.10 Diagrama de Despliegue
Los diagramas de despliegue muestran la disposición física de los distintos nodos que
entran en la composición de un sistema y el reparto de los programas ejecutables sobre
estos nodos. Los nodos se interconectan mediante soportes bidireccionales que pueden
a su vez estereotiparse.
En la Figura 3.13 se representa el Diagrama de Despliegue perteneciente a la aplicación.
Capítulo 4: Pruebas y análisis de factibilidad
51
Figura 3.13: Diagrama de Despliegue
Recurso Breve descripción de su uso
Nodo PC Cliente PC que interactúa con los servidores web. Se visualizan
las interfaces del sistema.
Nodo Servidor Web Se utiliza el Servidor Web Apache, contiene los
componentes necesarios para montar el sistema.
Nodo Servidor de Base de Datos Se utiliza el SGBD MySQL, contiene la base de datos
donde se encuentra almacenada toda la información
gestionada por el sistema.
Tabla 3.2: Descripción de los nodos que integran el Diagrama de Despliegue
3.11 Conclusiones parciales
En este capítulo se definió la arquitectura del Sistema para el Control de Traslados
Pendientes de la DTVC, describiéndose detalladamente cada proceso, los cuales
sirven de base para el desarrollo del software. Los diagramas clases que se proponen,
constituyen una guía para la implementación que se ha diseñado; se organizaron las
clases y librerías en forma de componentes, se definió el Modelo Físico de Datos que
Capítulo 4: Pruebas y análisis de factibilidad
52
permitirá acceder a cada una de las entidades que componen las distintas clases. A
través de los diagramas de despliegue y de componentes se especificó como está
estructurado el sistema físicamente para un correcto desarrollo y despliegue de la
solución.
Capítulo 4: Pruebas y análisis de factibilidad
53
Capítulo 4. Pruebas y análisis de factibilidad
4.1 Introducción
En el siguiente capítulo se describe el análisis del costo, tiempo y recursos requeridos
para el desarrollo de la aplicación y las pruebas de software realizadas al mismo.
4.2 Planificación basada en casos de uso
La planificación incluye la actividad de estimar los resultados del proyecto y los valores
de costo, tiempo y recursos requeridos. Su objetivo principal es establecer planes
razonables para desarrollar la Ingeniería de Software y manejar los cambios de los
proyectos de Software.
4.2.1 Cálculo de Puntos de Casos de Uso sin ajustar
El primer paso para la estimación consiste en calcular los Puntos de Casos de Uso sin
ajustar, se calcula mediante la siguiente fórmula:
Ecuación:
UUCP=UAW+UUCW
Siendo:
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
4.2.1.1 Factor de Peso de los Actores sin ajustar (UAW)
Este valor corresponde a la relación que existe entre la cantidad de actores presentes
en el sistema y la complejidad de cada uno de ellos, para establecer la complejidad
están los criterios expuestos en la Tabla 4.1:
Tipo de Actor Descripción Factor de
Peso
Cantidad de
Actores
Simple Otro sistema que interactúa con
el sistema a desarrollar
1 0
Capítulo 4: Pruebas y análisis de factibilidad
54
mediante una interfaz de
programación
Medio Otro sistema que interactúa con
el sistema a desarrollar
mediante un protocolo o una
interfaz basada en texto
2 0
Complejo Una persona que interactúa con
el sistema mediante una interfaz
gráfica
3 5
Tabla 4.1: Criterios para establecer la complejidad de los actores del sistema
Se han identificado cinco actores complejos ya que son personas que interactúan con
el sistema.
Entonces:
UAW = ∑ (Actor i * Factor de Pesoi)
UAW = 3 * 5= 15
4.2.1.2 Factor de Peso de los Casos de Uso sin ajustar (UUCW)
Este valor se calcula mediante un análisis de la cantidad de Casos de Uso del sistema
y la complejidad de cada uno de ellos. La complejidad se establece teniendo en cuenta
la cantidad se transacciones efectuadas por cada caso de uso. (Ver Tabla 4.2)
Tipo de Caso de
Uso
Descripción Factor de
Peso
Número de
Casos de Uso
Simple El Caso de Uso contiene de 1 a
3 transacciones
5 5
Medio El Caso de Uso contiene de 4 a
7 transacciones
10 14
Complejo El Caso de Uso contiene al
menos 8 transacciones
15 0
Tabla 4.2: Criterios para establecer la complejidad de los casos de uso del sistema
En la Tabla 4.3 se muestran la cantidad de transacciones por caso de uso:
Capítulo 4: Pruebas y análisis de factibilidad
55
Caso de uso Cantidad de transacciones Peso
Autenticar Usuario 1 5
Mostrar reporte 4 10
Gestionar traslado 6 10
Gestionar Provincia 5 10
Gestionar Municipio 5 10
Gestionar localidad 6 10
Gestionar consejo popular 6 10
Gestionar causa de pendiente 5 10
Gestionar subcausa de pendiente 6 10
Gestionar tipo de movimiento 5 10
Gestionar usuarios 6 10
Visualizar gráfico 2 5
Registrar trazas 3 5
Gestionar unidades 5 10
Gestionar áreas 5 10
Gestionar Centros 5 10
Gestionar rol 5 10
Filtrar datos 2 5
Exportar datos 1 5
Tabla 4.3: Cantidad de transacciones por caso de uso
Entonces:
UUCW = ∑ (Caso de Uso i* Factor de Pesoi)
UUCW= 5 *5 + 10 * 14 = 165
Por consiguiente, UUCP = 15 + 165 = 180
4.2.2 Cálculo de Puntos de Casos de Uso ajustados
Ecuación:
UCP=UUCP*TCF*EF
Siendo:
Capítulo 4: Pruebas y análisis de factibilidad
56
UCP: Puntos de Casos de Uso ajustado
UUCP: Puntos de Casos de Uso sin ajustar
TCF: Factor de complejidad técnica
EF: Factor de Ambiente
4.2.2.1 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. Para cuantificar estos valores se
establece un valor de cero a cinco, donde cero significa un aporte irrelevante y cinco un
máximo de importancia del aporte.
Los factores tenidos en cuenta y el peso de cada uno se representan en la Tabla 4.4:
Factor Descripción Peso
1 Sistema distribuido 2
2 Objetivos de performance o tiempo de respuesta 1
3 Eficiencia del usuario final 1
4 Procesamiento interno complejo 1
5 El código debe ser reutilizable 1
6 Facilidad de instalación 0.5
7 Facilidad de uso 0.5
8 Portabilidad 2
9 Facilidad de cambio 1
10 Concurrencia 1
11 Incluye objetivos especiales de seguridad 1
12 Provee acceso directo a terceras partes 1
13 Se requieren facilidades especiales de entrenamiento a usuarios 1
Tabla 4.4: Factores para determinar la complejidad técnica del sistema
Realizando un análisis de lo que se plantea, cada factor a medir y las características
del sistema que se desea realizar se asignaron los valores a cada factor. (Véase Tabla
4.5)
Capítulo 4: Pruebas y análisis de factibilidad
57
Factor Valor asignado Valor asignado*Peso
1 4 (es distribuido) 8
2 5 (debe responder de forma rápida a los pedidos) 5
3 3 (los usuarios no tienen por qué ser eficientes) 3
4 5 (procesamiento complejo) 5
5 5 (código reutilizable) 5
6 0 0
7 5 (fácil de usar) 2,5
8 5 (funciona en cualquier sistema operativo) 10
9 5 (adaptable al cambio) 5
10 0 0
11 0 0
12 0 0
13 0 0
Tabla 4.5: Valores que toma cada factor para el sistema
Entonces:
TCF = 0,6 + 0,01 * ∑ (Peso i * valor asignado)
TCF = 0,6 + 0,01 * (8+5+3+5+5+2,5+10+5) =1,035
4.2.2.2 Factor de ambiente (EF)
El entrenamiento y las actividades realizadas por el grupo involucrado en el desarrollo
tienen un gran impacto en la estimación del tiempo. Estos factores son los que se
contemplan para calcular el Factor de Ambiente.
La Tabla 4.6 muestra el significado y el peso de cada uno de estos factores:
Factor Descripción Peso
1 Familiaridad con el modelo de proyecto utilizado 1.5
2 Experiencia en la aplicación 0.5
3 Experiencia en orientación a objetos 1
4 Capacidad del analista líder 0.5
5 Motivación 1
6 Estabilidad de los requerimientos 2
Capítulo 4: Pruebas y análisis de factibilidad
58
7 Personal part-time -1
8 Dificultad del lenguaje de programación -1
Tabla 4.6: Peso asociado a cada factor de ambiente
Consideraciones a tener en cuenta:
Para los factores del 1 al 4, un valor asignado de 0 significa sin experiencia, 3
experiencia media y 5 amplia experiencia (experto).
Para el factor 5, 0 significa sin motivación para el proyecto, 3 motivación media y 5 alta
motivación.
Para el factor 6, 0 significa requerimientos extremadamente inestables, 3 estabilidad
media y 5 requerimientos estables sin posibilidad de cambios.
Para el factor 7, 0 significa que no hay personal part-time (es decir todos son full-time),
3 significa mitad y mitad, y 5 significa que todo el personal es part-time (nadie es full-
time).
Para el factor 8, 0 significa que el lenguaje de programación es fácil de usar, 3 medio y
5 que el lenguaje es extremadamente difícil.
Factor Valor asignado Valor asignado* Peso
1 3 4,5
2 2 1
3 2 2
4 4 2
5 5 5
6 4 8
7 0 0
8 3 -3
Tabla 4.7: Valor asignado por cada factor de ambiente
Entonces:
EF = 1,4 – 0,03 * Σ (Peso i x Valor asignado)
EF= 1,4 – 0,03 *(4,5+1+2+2+5+8-3) = 0,815
Por consiguiente, UCP = 180 * 1,035 * 0,815= 151,835
Capítulo 4: Pruebas y análisis de factibilidad
59
4.2.3 Estimación del esfuerzo por los Puntos de Casos de Uso
El esfuerzo en horas-hombre viene dado por:
E=UCP*CF
Siendo:
E: Esfuerzo estimado en horas-hombre
UCP: Puntos de Casos de Uso ajustados
CF: Factor de conversión.
Para el cálculo se siguen los siguientes pasos:
1. Se contabilizan cuántos factores de los que afectan al Factor de ambiente
están por debajo del valor medio (3), para los factores del 1 al 6.
2. Se contabilizan cuántos factores de los que afectan al Factor de ambiente
están por encima del valor medio (3), para los factores 7 y 8.
3. Si el total es 2 o menos, se utiliza el factor de conversión 20 horas-
hombre/Punto de Casos de Uso, es decir, un Punto de Caso de Uso toma 20
horas-hombre.
4. Si el total es 3 o 4, se utiliza el factor de conversión 28 horas-hombre/Punto
de Casos de Uso, es decir, un punto de Caso de Uso toma 28 horas-hombre.
5. Si el total es mayor o igual que 5, se recomienda efectuar cambios en el
proyecto, ya que se considera que el riesgo de fracaso del mismo es
demasiado alto.
Dado que quedó un total de 2 se toma como Factor de conversión 20 horas-hombre.
Por consiguiente, E = 151,835 * 20= 3036.7
Se debe tener en cuenta que este método proporciona una estimación del esfuerzo en
horas-hombre contemplando sólo el desarrollo de la funcionalidad especificada en los
casos de uso.
Capítulo 4: Pruebas y análisis de factibilidad
60
4.2.4 Estimación del esfuerzo total del proyecto
Para una estimación más completa de la duración total del proyecto, hay que agregar a
la estimación del esfuerzo obtenida por los Puntos de Casos de Uso, las estimaciones
del esfuerzo de las demás actividades relacionadas con el desarrollo del software.
Para ello se puede tener en cuenta el siguiente criterio, el cual plantea la distribución
del esfuerzo entre las diferentes actividades de un proyecto de la siguiente forma:
(Véase Tabla 4.8)
Actividad Porcentaje
Análisis 10,00%
Diseño 20,00%
Programación 40,00%
Pruebas 15,00%
Sobrecarga(otras actividades) 15,00%
Tabla 4.8: Esfuerzo asociado a cada una de las actividades vinculadas al proyecto
Con este criterio y tomando como entrada la estimación de tiempo calculada a partir de
los Puntos de Casos de Uso que se considera como el esfuerzo que se requiere para la
implementación, se pueden calcular las demás estimaciones para obtener la duración
total del proyecto. (Véase Tabla 2.9)
Actividad Porcentaje Horas / hombre
Análisis 10,00% 759,175
Diseño 20,00% 1518,35
Programación 40,00% 3036.7
Pruebas 15,00% 1138,7625
Sobrecarga(otras actividades) 15,00% 1138,7625
Total 100% 7591.75
Tabla 4.9: Cálculo de la cantidad de horas por hombre que requiere cada actividad del proyecto
Ecuación:
ETotal=∑ actividades
ETotal = 7591,75HH
Capítulo 4: Pruebas y análisis de factibilidad
61
Siendo:
ETotal: esfuerzo total
4.2.5 Estimación del tiempo de desarrollo del proyecto
El tiempo de desarrollo aproximado del proyecto se calcula de la siguiente manera:
TDesarrollo=ETotal/CHTotal
Siendo:
TDesarrollo: tiempo de desarrollo total en horas
CHTotal: cantidad de hombres que desarrollan el proyecto
Por consiguiente, TDesarrollo = 7591,75/ 1= 7591,75h
4.2.6 Estimación del costo de desarrollo del proyecto
Después de estimar el tiempo de desarrollo del proyecto y conocida la cantidad de
desarrolladores y el pago que recibe cada uno de estos se puede realizar una
estimación del costo por concepto de desarrolladores, dado por:
CTotal=ETotal*CHH
Siendo:
CHH: costo por hombre-hora
CHH = K * THP
Siendo:
K: coeficiente que tiene en cuenta los costos indirectos (1,5 y 2,0).
THP: Tarifa Horaria Promedio. Se calcula por la siguiente fórmula:
THP = ST/CHM, donde:
ST: Representa el salario del trabajador.
CHM: 190,6: Este valor representa la cantidad de horas mensuales, se calcula teniendo
en cuenta que un trabajador labora aproximadamente 7,33 horas por día, lo que
significa que si en este mes se trabaja 26 días, la CHM = 7,33 * 26.
Capítulo 4: Pruebas y análisis de factibilidad
62
Entonces:
Si cada desarrollador cuenta con un salario de $1000
CTotal = ETotal * K * THP
THP = 1000/190,6 = 5,25; por consiguiente:
CTotal = 7591,75* 2 * 5,25 = $ 79 713,375
4.3 Pruebas de software
Las pruebas de software de clasifican en relación a los siguientes tipos: Pruebas
Funcionales, Pruebas de Características de Software no Funcionales, Pruebas de
Estructura del Software (Arquitectura) y Pruebas relacionadas con cambios, tales como
Repruebas y Regresión.
Existen varios niveles a la hora de automatizar pruebas. La pirámide de pruebas de
Mike Cohn, descrita en su libro “Succeeding with Agile”, ha sido un referente en este
campo durante mucho tiempo.
En ella Cohn señala el grado en el que se debería automatizar las pruebas:
Figura 4.1: Niveles de pruebas en la Pirámide de Cohn
Capítulo 4: Pruebas y análisis de factibilidad
63
-Nivel 1: Pruebas unitarias automáticas, porque un primer punto primordial para
detectar fallos es a nivel de desarrollador. Si una funcionalidad en este punto falla,
podrían fallar pruebas de los siguientes niveles: integración, API etc.
-Nivel 2: Pruebas a nivel de API, integración de componentes, servicios, que son los
más estables y candidatos a automatizar.
-Nivel 3: Pruebas de interfaz de usuario automatizadas. Ya que estas pruebas son
variables, lentas en su ejecución y con muchas dependencias con otros componentes.
-Nivel 4: Un nivel estable de pruebas automáticas, que vayan detectando las pruebas
manuales y se vayan automatizando paulatinamente, para que llegue un momento en
el que invirtiendo los mismos recursos se logre cada vez una cobertura mayor de
pruebas.
4.3.1 Pruebas funcionales
Para analizar el tiempo de respuesta del servidor se utilizó la herramienta Jmeter que
permite realizar pruebas de comportamiento funcional y medir el rendimiento. También
se puede utilizar para realizar pruebas de estrés. Para estas pruebas, se configuró un
servidor Proxy que provee Jmeter, para poder construir un camino de navegación
aleatorio, y así simular la visita de usuarios.
Los resultados fueron evaluados usando el componente Agreggate Graph provisto por
la herramienta, tomando en consideración los siguientes datos:
Etiqueta: título.
Muestra: cantidad de hilos utilizados para la URL.
Promedio: promedio del tiempo de respuesta de transacción de los usuarios.
Mínimo: tiempo mínimo de la muestra de una determinada URL.
Máximo: tiempo mínimo de la muestra de una determinada URL.
Desviación estándar: desviación entre los tiempos de respuesta: promedio,
mínimo y máximo. (no debe ser mayor que 5%)
Capítulo 4: Pruebas y análisis de factibilidad
64
Error: porcentaje de errores que ocurrieron durante la prueba.
Rendimiento: cantidad de requerimientos que son procesados por el servidor en
cada segundo.
Kb/Sec: cantidad de datos que la aplicación descargo del servidor.
Se realizaron tres pruebas, definiendo un total de 50 usuarios en cada una y los valores
totales obtenidos se muestran en la Tabla 4.10:
Etiq. Muestra Media Mín Máx Desv. Estándar Error Rendimiento Kb/Sec
Prueba 1 20000 4 0 1002 39.57 0.00% 3.571.888 30.66
Prueba 2 20000 5 0 1091 47.08 0.00% 3.573.554 30.57
Prueba 3 20000 6 0 1051 54.9 0.00% 3.573.573 30.43
TOTAL 60000 5 0 1091 47.6 0.00% 10.715.644 91.63
Tabla 4.10: Resultados de las pruebas funcionales
Según el autor Jakob Nielsen, en el libro “Usability Engineering” existen tres límites
importantes en el tiempo de respuesta:
• 0,1 segundo (100 milisegundos): es el límite en el cual el usuario siente que está
“manipulando” los objetos desde la interfaz de usuario.
• 1 segundo: es el límite en el cual el usuario siente que está navegando
libremente sin esperar demasiado una respuesta del servidor.
• 10 segundos: es el límite en el cual se pierde la atención del usuario, si la
respuesta tarda más de 10 segundos se deberá indicar algún mecanismo por el cual el
usuario pueda interrumpir la operación.
El tiempo total utilizado para los 50 usuarios se puede calcular con la siguiente fórmula:
Tiempo Total = #Muestras * Media
Para la primera prueba se tiene: 50 * 4 = 200 milisegundos.
Para la segunda prueba se tiene: 50 * 5 = 250 milisegundos.
Capítulo 4: Pruebas y análisis de factibilidad
65
Para la tercera prueba se tiene: 50 * 6 = 300 milisegundos.
Tomando como base el criterio de Jakob Nielsen se puede concluir que los valores
obtenidos como tiempo de respuesta muestran muy buenos resultados en el
funcionamiento de la aplicación.
4.3.2 Pruebas de Estructura del Software
Para probar el correcto funcionamiento de la API se realizaron pruebas usando
Postman.
En las siguientes imágenes se muestran los resultados obtenidos:
En la Figura 4.2 se muestra el método GET como el seleccionado para el caso de
prueba, que solicita el listado de traslados telefónicos almacenados en la base de
datos, estableciendo como restricción que la cantidad de traslados sea mayor que cero.
Figura 4.2: Interfaz de prueba de la herramienta Postman (funcionalidad Listar traslado)
Capítulo 4: Pruebas y análisis de factibilidad
66
En la Figura 4.3 se muestran seis pruebas automáticas realizadas a la funcionalidad de
gestionar traslados, donde se muestran parámetros como el código de retorno, el
tiempo de respuesta y la cantidad de Kbits transferidos. El estado verde de la prueba
nos da el correcto funcionamiento de la misma, la coloración roja indica un error en el
proceso de chequeo.
Figura 4.3: Interfaz de prueba de la herramienta Postman (caso de uso del sistema Gestionar traslado)
4.4 Conclusiones parciales
Se realizó una planificación basada en casos de uso, donde se estima un tiempo de
desarrollo del proyecto de aproximadamente 7591,75 h y un costo de $ 79 713,375. Se
destaca la importancia de que las pruebas de software se realicen en etapas
tempranas, pudiendo esto condicionar el posterior desarrollo del mismo, para ellos se
seleccionaron dos herramientas (JMeter y Postman) que permitieron realizar pruebas
automáticas de una manera sencilla y eficiente.
Conclusiones
67
Conclusiones
Se concluye este trabajo de diploma dando cumplimiento al objetivo propuesto para la
realización del mismo.
Durante la investigación se obtuvieron los siguientes resultados:
Se determinaron las actividades del negocio presentes en el proceso de solicitud
de traslados telefónicos, lo que permitió identificar las dificultades y
oportunidades de mejora que dieron lugar a los requisitos de software de la
propuesta de automatización.
Se creó una base de datos para el control y persistencia de los traslados
efectuados en la provincia de Villa Clara, agrupando de manera lógica los datos
involucrados.
Se realizó el sistema para el control de traslados telefónicos, que permite darle
un seguimiento a los mismos de acuerdo a su estado, facilita la toma de
decisiones para que en todo momento los directivos y especialistas comerciales
puedan saber cuáles son las causas de los traslados pendientes más comunes
en la provincia de Villa Clara y en sus municipios.
Se realizó un análisis de estimación basado en casos de uso, permitiendo
determinar el tiempo y costo de desarrollo del proyecto.
Se realizaron pruebas al software que permitieron evaluar cada una de las
funcionalidades y detectar errores en puntos de desarrollo.
Recomendaciones
68
Recomendaciones
A continuación se listan las recomendaciones en vistas de posibles mejoras al “Sistema
para el Control de los Traslados Telefónicos Pendientes” para la DTVC:
Módulo de mensajería o de avisos entre los especialistas comerciales para
recibir notificación sobre procesos de los traslados pendientes.
Utilizar tecnología web socket en el módulo de visualización de gráficos en
tiempo real.
Módulo que permita la ubicación geográfica de los traslados pendientes en la
provincia de Villa Clara.
Extender el “Sistema de control de traslados telefónico pendientes” hacia todo el
territorio nacional.
69
Referencias Bibliográficas
1. ETECSA - EcuRed [Internet]. [cited 2017 Jun 14]. Available from: https://www.ecured.cu/Etecsa
2. ETECSA - Empresa de Telecomunicaciones de Cuba S.A. [Internet]. [cited 2017 Jun 14]. Available from: http://www.etecsa.cu/
3. Beneficios de la Metodología Rup y ventajas. | METODOLOGÍA RUP [Internet]. [cited 2017 Jun 14]. Available from: http://rupmetodologia.blogspot.com/2012/06/beneficios-de-la-metodologia-rup-y.html
4. JAVA - ActaUML.PDF [Internet]. [cited 2017 Jun 14]. Available from: http://www.disca.upv.es/enheror/pdf/ActaUML.PDF
5. Visual Paradigm para UML [Internet]. [cited 2017 Jun 14]. Available from: http://www.software.com.ar/p/visual-paradigm-para-uml
6. Programación en PHP - Wikilibros [Internet]. [cited 2017 Jun 14]. Available from: https://es.wikibooks.org/wiki/Programaci%C3%B3n_en_PHP
7. Tutorialspoint. What are Web Services [Internet]. 2017 [cited 2017 Jan 30]. Available from: https://www.tutorialspoint.com/webservices/what_are_web_services.htm
8. Qué es un servicio RESTFUL [Internet]. [cited 2017 Jun 14]. Available from: http://www.i2factory.com/es/integracion/qu%C3%A9-es-un-servicio-restful
9. Qué es la autenticación basada en Token [Internet]. [cited 2017 Jun 14]. Available from: https://carlosazaustre.es/blog/que-es-la-autenticacion-con-token/
10. López Herrera Patricia. Comparación del desempeño de los Sistemas Gestores de Bases de Datos MySQL y PostgreSQL. 2016.
11. Apache Server: Ventajas y Desventajas [Internet]. [cited 2017 Jun 15]. Available from: http://webapache.blogspot.com/p/ventajas-y-desventajas.html
12. Patrones de arquitectura vs. Patrones de diseño | Ingenieria del Software [Internet]. [cited 2017 Jun 15]. Available from: https://arlethparedes.wordpress.com/2012/08/27/patrones-de-arquitectura-vs-patrones-de-diseno/
13. Validar ingreso de datos con AngularJS - Solvetic [Internet]. [cited 2017 Jun 15]. Available from: https://www.solvetic.com/tutoriales/article/1104-validar-ingreso-de-datos-con-angularjs/
70
14. Aprendiendo AngularJS: Validación de un Formulario - Aprende a Programar - Codejobs [Internet]. [cited 2017 Jun 15]. Available from: https://www.codejobs.biz/es/blog/2015/01/31/aprendiendo-angularjs-validacion-de-un-formulario