sistema para el control de traslados telefónicos

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


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.


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:


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


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.


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

http://carlosazaustre.es/blog/como-implementar-una-api-rest-con-mongodb-node-js-usando-express-v4/

http://carlosazaustre.es/blog/como-implementar-una-api-rest-con-mongodb-node-js-usando-express-v4/


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


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)


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


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.


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.


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


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


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


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


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


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


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.


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


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


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.


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


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


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


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.


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.


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:


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.


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)


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:


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


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


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


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


Precondiciones Usuario logado en el 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.


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


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.


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.






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


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


36

En la Tabla 2.9 se realiza la descripción de la funcionalidad Modificar 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.


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.






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


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.


37


cliquea en la opción de Informes.

Responsabilidades Mantener un resumen actualizado con la información de todos

los traslados.


Precondiciones Usuario autenticado en el sistema.




Reporte.

2-El sistema muestra una tabla de resumen con información

relativa a los traslados pendientes.

Flujos alternativos


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”


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:


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.


40

Figura 3.2 :Diagrama de clases del caso de uso del sistema Gestionar Traslado


En la Figura 3.3 se muestra el diagrama de clases correspondiente al caso de uso del

sistema Autenticar usuario.


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.


42

Figura 3.4: Diagrama de secuencia de la funcionalidad Listar traslado


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


funcionalidad de editar traslado que incluye el caso de uso del sistema Gestionar

traslado.


43

Figura 3.6: Diagrama de secuencia de la funcionalidad Editar traslado



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


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


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.


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:


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


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.


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:


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.


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


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


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.


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


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:


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:


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)


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


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


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.


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


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.


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


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


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.


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)


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)


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

sistema para el control de traslados telefónicos

Documents