Sistema Automatizado de Control de Averías de Servicio (SACAS)

Resumen
Universidad Central de Venezuela

Facultad de Ciencias
Escuela de Computación
Trabajo Especial de Grado de Sistemas de Información
Sistema de Gestión Automatizada de Control de Averías de Servicio

(SACAS)
Trabajo Especial de Grado

Presentado ante la Ilustre
Universidad Central de Venezuela
Por el bachiller
Edwin Alberto Abreu Silva
Para optar por el título de Licenciado en Computación
Tutor:
Dr. Pedro Bonillo
Caracas, 22 de mayo de 2017
Sistema Automatizado de Control de Averías de Servicio (SACAS)

Resumen

Resumen
DEDICATORIAS
A dios por darme salud y fuerzas para seguir adelante.
A la memoria de mi madre Gloria, quien siempre fue fuente infinita de
ejemplo y amor, esto es por TI, desde allá arriba sé que estarás muy
contenta y brincando en un solo pie por este logro, es todo tuyo.
A mis hermanos David y Simón, por el apoyo incondicional en todo momento.
A toda mi familia, por su motivación y apoyo.

Resumen
AGRADECIMIENTOS
A mi tutor y amigo Pedro Bonillo, por la gran oportunidad de este trabajo y
por la calidad humana y profesional, mi admiración total, que dios te bendiga.
A todas esas personas que estuvieron ahí todo este tiempo motivándome a
cerrar este ciclo.

Resumen
RESUMEN
El principal objetivo de este Trabajo Especial de Grado es el

implementar el Sistema de Gestión de Averías de Servicios (SACAS) bajo una
herramienta de Gestión de Procesos de Negocio en Software Libre para la
Empresa de Telecomunicaciones de Venezuela CANTV.
Bajo el dominio de Tecnologías de Información se analizó, diseño, modelo y

automatizo el proceso para llevar a cabo una Gestión de Control de Averías y
Servicios, de manera eficiente y mediante una arquitectura orientada a
servicios (SOA, por sus siglas en inglés Software Oriented Architecture) que
define la utilización de Servicios Web, y que especifica los requisitos de
gobierno para la gestión de calidad de los servicios en tiempo de desarrollo y
en tiempo de ejecución..
Con la finalidad de poner en práctica el proceso de Control de Averías y

Servicios, se utilizó el modelo operativo de Gestión de Procesos de Negocio
(BPM, por sus siglas en inglés Business Process Management)
Palabras Claves: Proceso de Gestión de Control de Averías y Servicios,

Gestión de Tecnologías de Información, BPM, SOA.

Índice de Contenido
INDICE DE CONTENIDO
INTRODUCCIÓN .......................................................................................................... 4
CAPITULO I: EL PROBLEMA ...................................................................................... 1
CAPITULO II: MARCO TEÓRICO .............................................................................. 4
1..1 JSP (JavaServer Pages) ........................................................................... 4
1..2 Motor JSP ................................................................................................... 4
1..3 Java............................................................................................................. 5
1..4 Servidor ...................................................................................................... 6
1..5 Servicios Web ............................................................................................ 7
1..6 Gestión de procesos de negocio .......................................................... 12
1..7 Arquitectura Orientada a Servicios ...................................................... 13
CAPITULO III: MARCO METODOLÓGICO ............................................................. 17
3.1 Metodología de desarrollo de software .................................................. 17
3.1.1 Proceso Unificado Ágil............................................................................ 18
CAPITULO IV: MARCO APLICATIVO ...................................................................... 22
1. Diagramas de Casos de Uso.................................................................... 22
Manejo de Usuarios .......................................................................................... 23
Manejo de Tickets ............................................................................................. 24
Manejo de Archivos .......................................................................................... 25
Clase Generar Archivo ...................................................................................... 25
Clase Recibir Archivo ........................................................................................ 26
Auditoría ............................................................................................................. 27
Manejo de Reportes ......................................................................................... 28
2. Diagramas de Secuencia.......................................................................... 28
Manejo de Tickets ............................................................................................. 29
Abrir Ticket......................................................................................................... 29
Consultar Ticket ................................................................................................ 30
Consultar Listado de Tickets ........................................................................... 30
Modificar Ticket ................................................................................................. 31
Cancelar Ticket .................................................................................................. 31
Manejo de Archivos .......................................................................................... 32
Auditoría ............................................................................................................. 33
3. Diagrama de Clases .................................................................................. 33
4. Diagramas de Estados.............................................................................. 34
Ticket .................................................................................................................. 34
Usuario ............................................................................................................... 34
5. Diagramas de Despliegue ........................................................................ 35
Diagrama de Despliegue de PIC ..................................................................... 35
Diagrama de Despliegue Usuario ................................................................... 36

Índice de Contenido
Diagrama de Despliegue SACAS ..................................................................... 37

Diagramas BPM de los procesos SACAS ........................................................ 37
Modelo Entidad-Relación ................................................................................. 38
CONCLUSIONES Y RESULTADOS ......................................................................... 119
RECOMENDACIONES .............................................................................................. 121
REFERENCIAS .......................................................................................................... 122

Introducción
INDICE DE FIGURAS
Figura 1. Ejemplo de Página JSP ................................................................. 5

Figura 2. Ejemplo de REST ......................................................................... 8
Figura 3. Arquitectura de Axis2................................................................. 10
Figura 4. Motor Extensible de Mensajería .................................................. 11
Figura 5. Arquitectura de Módulos ............................................................ 11
Figura 6. Ciclo de Vida del Proceso Unificado Ágil ó AUP ............................ 20
Figura 7. Caso de Uso: Manejo de Usuarios ............................................... 23
Figura 8. Caso de Uso: Manejo de Tickets ................................................. 24
Figura 9. Caso de Uso: Generar Archivo .................................................... 25
Figura 10. Caso de Uso: Recibir Archivo .................................................... 26
Figura 11. Caso de Uso: Auditoría............................................................. 27
Figura 12. Caso de Uso: Manejo de Reportes ............................................ 28
Figura 13. Caso de Uso: Manejo de Reportes ............................................ 29
Figura 14. Caso de Uso: Consultar Ticket .................................................. 30
Figura 15. Caso de Uso: Consultar Listado de Ticket .................................. 30
Figura 16. Caso de Uso: Modificar Ticket................................................... 31
Figura 17. Caso de Uso: Cancelar Ticket ................................................... 31
Figura 18. Caso de Uso: Manejo de Archivos ............................................. 32
Figura 19. Diagrama de Clases ................................................................. 33
Figura 20. Diagrama de Estado: Ticket ..................................................... 34
Figura 21. Diagrama de Estado: Usuario ................................................... 34
Figura 22. Diagrama de Despliegue: PIC ................................................... 35
Figura 23. Diagrama de Despliegue: Usuario ............................................. 36
Figura 24. Diagrama de Despliegue: SACAS .............................................. 37
Figura 25. Diagrama BPM: Manejo General de Tickets ............................... 38
Figura 26. Diagrama Modelo Entidad-Relación ........................................... 38
Figura 27. Crear incidente tipo cliente ....................................................... 43

Introducción

Figura 34. Crear incidente tipo interno ...................................................... 54
Figura 40. Crear incidente tipo circuito ...................................................... 63
Figura 46. Consultar incidente por número o Id ......................................... 71
Figura 48. Modificar incidente................................................................... 76
Figura 51. Enrutar incidente ..................................................................... 79
Figura 54. Cerrar incidente ....................................................................... 82
Figura 57. Asignar incidente ..................................................................... 85

Introducción

Figura 60. Escalar incidente ..................................................................... 88
Figura 61. Escalar incidente ..................................................................... 89
Figura 62. Consultar historia del teléfono .................................................. 90
Figura 63. Exportar resultados.................................................................. 91
Figura 64. Consultar historia del incidente ................................................. 92
Figura 65. Exportar resultados.................................................................. 93
Figura 66. Consultar incidente por Id ........................................................ 94
Figura 68. Visualizar incidente .................................................................. 96
Figura 69. Histórico del teléfono o circuito................................................. 97
Figura 70. Consultar Incidente.................................................................. 98
Figura 71. Último incidente ...................................................................... 99
Figura 72. Último incidente por área de trabajo ....................................... 100
Figura 73. Último incidente por área de trabajo ....................................... 101
Figura 74. Mi lista de incidentes ............................................................. 102
Figura 75. Diagrama BPM Proceso Primer Nivel ....................................... 103
Figura 76. Diagrama BPM Proceso de Telefonía Básica ............................. 105
Figura 77. Diagrama BPM Proceso de Negocio de Telefonía Pública .......... 106
Figura 78. Diagrama BPM Proceso de Negocio de CNE ............................. 108
Figura 79. Diagrama BPM Proceso de Negocio de Mantenimiento Correctivo
ABA ...................................................................................................... 109
Figura 80. Diagrama BPM Proceso de Negocio de Provisión ABA ............... 110
Figura 81. Proceso de Negocio Mantenimiento Correctivo TFI ................... 111
Figura 82. Proceso de Negocio Averías Masivas TFI ................................. 112
Figura 83. Diagrama BPM Proceso de Negocio Genérico ........................... 113
Figura 84. Diagrama BPM Proceso de Gestión de Incidente ...................... 114
Figura 85. Diagrama BPM Proceso de Incidentes Mayores ........................ 117

Introducción
INTRODUCCIÓN
El desarrollo de nuevos estilos arquitectónicos basados en

construcciones tales como objetos y componentes, podría provocar que no se
produjeran avances significativos en el campo del software. Para evitar esto,
los desarrolladores tendrían que adquirir otro punto de vista, viendo cómo
siguiendo otros paradigmas, el software puede entregar su funcionalidad a
los usuarios de una manera distinta a la habitual.
Esta nueva concepción entiende que el software debe entregarse en

forma de servicio. El concepto de software como servicio, es una visión de
futuro que nos permite ofrecer soporte a las necesidades de un mercado del
software muy competitivo en el que los negocios recopilarán o proveerán
servicios según los requisitos que necesiten cubrir. Este nuevo paradigma
pretende separar los conceptos de posesión y propiedad del concepto de uso.
Para la implementación del software como un servicio, es necesario

considerar los procesos que soportan dichos servicios, la Gestión de los
Procesos de Negocio, es un nuevo modelo operativo que utiliza una notación
basada en eventos para establecer al comunicación entre las funciones, las
actividades, los roles y las personas que utilizan el software como servicio.
En este Trabajo Especial de Grado se presentan todas lasactividades

académicas y prácticas para la implementación del sistema automatizado del
proceso de gestión de control de averías y servicios (SACAS), en la empresa
de Telecomunicaciones de Venezuela CANTV, bajo el enfoque BPM y con una
arquitectura SOA.

Introducción
Con la finalidad de alcanzar los objetivos planteados, este documento

se estructura de la siguiente manera:
En el Capítulo I, El Problema, se inicia con la contextualización en

espacio y tiempo del problema de investigación, sus manifestaciones y
evidencias, luego se presentan los objetivos, la justificación, delimitación y las
limitaciones.
El Capítulo II se refiere al Marco Teórico, en el cual se especifica

lenguaje de programación utilizado, el enfoque BPM, el uso de servicios web,
entre otros puntos. Se estudia las bases teóricas de dicho proceso.
El Capítulo III se refiere al Marco Metodológico, en el cual se especifica

la metodología utilizada para desarrollar el sistema SACAS.
El Capítulo IV se refiere al Marco Aplicativo, en el cual se especifica el

análisis, diseño y construcción del sistema SACAS.
Para finalizar, se realizará las conclusiones de este Trabajo Especial de

Grado.
A continuación se inicia con el planteamiento del objeto de estudio o

contexto.

Capítulo I
CAPITULO I: EL PROBLEMA
Objetivo General
El principal propósito es brindar un sistema de manejo de tickets

por averías de servicios y red, para el manejo y seguimiento de los
procesos implicados en tal gestión, mediante la sustitución funcional y
tecnológica del sistema actual TAS, permitiendo mejorar la operatividad
del proceso, de cara a los usuarios y a los aplicativos que interactuarán
con SACAS. Se garantiza el funcionamiento del sistema, tal como funciona
el sistema actual, así como un nivel superior en el sentido operativo,
aprovechando las nuevas tecnologías disponibles y la plataforma de
comunicaciones con las que se cuentan. Se proveerán interfaces que
permitirán a las partes competentes interactuar con el sistema y se
mantendrá la información en una base de datos propia del aplicativo.
Todo esto bajo el modelo operativo de BPM en una Arquitectura SOA y
con herramientas de software libre.
Objetivos Específicos
Estudio del contexto, a través del análisis del sistema actual TAS. El
sistema tiene como finalidad sustituir al aplicativo TAS, el cual se
encuentra actualmente operativo para la creación y manejo de reportes
por averías de servicios, sin afectar ninguna de las aplicaciones que
actualmente interactúan con este sistema. La réplica de las
funcionalidades de TAS será exacta, de forma tal de permitir que las
entradas y salidas hacia otros aplicativos se mantengan y que garantice la
interoperabilidad con los sistemas.
Las actividades llevadas a cabo por robots serán sustituidas por

servicios Web.

Capítulo I
La sustitución llevará consigo la mejora de aquellos procesos de

TAS, que pueden ser optimizados y la automatización de aquellas
actividades que, dada la naturaleza del nuevo aplicativo, SACAS, puedan
ser realizadas por este.
Los estándares de seguridad de SACAS serán adoptados en su

totalidad del sistema actual, TAS, para cada una de las capas que lo
componen. Los elementos de seguridad a los cuales se hace referencia
son, entre otros, seguridad Web, seguridad de servicios Web, seguridad
en la transferencia de archivos, seguridad en el acceso a la base de datos,
etc.
Descripción de la Solución
Para el logro de la meta principal de este sistema, se han planteado

los siguientes objetivos:
 Desarrollo de un Flujo de Procesos que se encargará de

orquestar el procesamiento de los requerimientos (BPM).
 Desarrollo de interfaces gráficas para proveer a los usuarios de
un mecanismo sencillo de interacción con la plataforma.
 Desarrollo de una Base de Datos.
 Desarrollo de Servicios Web que operan entre el BPM y los
aplicativos.
 Desarrollo de Jobs para disparar la ejecución de procesos en los
aplicativos.
La interfaz Hombre-Máquina de SACAS se realizará bajo los

lineamientos de desarrollo de páginas Web conocidos o comunes, además

Capítulo I
de que se aplicará un esquema metodológico de iteraciones, tal como se

describe en la metodología AUP que se muestra en el capítulo III.

Capítulo II
CAPITULO II: MARCO TEÓRICO
Este capitulo presenta las bases conceptuales para la realización del

sistema propuesto, explicando el proceso de desarrollo a utilizar, describiendo
brevemente las tecnologías Web involucradas en la implementación del sistema.
1..1 JSP (JavaServer Pages)

JSP es un acrónimo de Java Server Pages, que en castellano vendría a
decir algo como Páginas de Servidor Java. Es, pues, una tecnología orientada a
crear páginas web con programación en Java [1].
Con JSP podemos crear aplicaciones web que se ejecuten en variados

servidores web, de múltiples plataformas, ya que Java es en esencia un lenguaje
multiplataforma. Las páginas JSP están compuestas de código HTML/XML
mezclado con etiquetas especiales para programar scripts de servidor en sintaxis
Java. Por tanto, las JSP podremos escribirlas con nuestro editor HTML/XML
habitual.
1..2 Motor JSP
El motor de las páginas JSP está basado en los servlets de Java -

programas en Java destinados a ejecutarse en el servidor-, aunque el
número de desarrolladores que pueden afrontar la programación de JSP
es mucho mayor, dado que resulta mucho más sencillo aprender que los
servlets.
En JSP creamos páginas de manera parecida a como se crean

en ASP o PHP -otras dos tecnologías de servidor-. Generamos archivos
con extensión .jsp que incluyen, dentro de la estructura de etiquetas
HTML, las sentencias Java a ejecutar en el servidor. Antes de que sean

Capítulo II
funcionales los archivos, el motor JSP lleva a cabo una fase de traducción
de esa página en un servlet, implementado en un archivo class (Byte
codes de Java). Esta fase de traducción se lleva a cabo habitualmente
cuando se recibe la primera solicitud de la página .jsp, aunque existe la
opción de precompilar en código para evitar ese tiempo de espera la
primera vez que un cliente solicita la página.
Ejemplo de página JSP
En la imagen siguiente se puede ver un ejemplo extremadamente simple

de una página JSP y el esquema de conversión de esa página en un
servlet.
Figura 1. Ejemplo de Página JSP
1..3 Java
Java es un lenguaje de programación y una plataforma informática
comercializada por primera vez en 1995 por Sun Microsystems. Hay muchas
aplicaciones y sitios web que no funcionarán a menos que tenga Java
instalado y cada día se crean más. Java es rápido, seguro y fiable. Desde

Capítulo II
portátiles hasta centros de datos, desde consolas para juegos hasta súper
computadoras, desde teléfonos móviles hasta Internet, Java está en todas
partes [2].
Java es un lenguaje orientado a objetos, aunque no de los denominados

puros; en Java todos los tipos, a excepción de los tipos fundamentales de
variables (int, char, long...) son clases. Sin embargo, en los lenguajes
orientados a objetos puros incluso estos tipos fundamentales son clases, por
ejemplo en Smalltalk.
El código generado por el compilador Java es independiente de la

arquitectura: podría ejecutarse en un entorno UNIX, Mac o Windows. El
motivo de esto es que el que realmente ejecuta el código generado por el
compilador no es el procesador del ordenador directamente, sino que este se
ejecuta mediante una máquina virtual. Esto permite que los Applets de una
web pueda ejecutarlos cualquier máquina que se conecte a ella
independientemente de qué sistema operativo emplee (siempre y cuando el
ordenador en cuestión tenga instalada una máquina virtual de Java).
1..4 Servidor
Un servidor es un programa en ejecución (un proceso) en un
computador en red que acepta peticiones de programas que se están
ejecutando en otros computadores para realizar un servicio y responder
adecuadamente [3]. Existen muchos tipos de servidores, pero el más
utilizado en aplicaciones java es Jboss y Apache Tomcat, el cual son
servidores de aplicaciones o contenedores Web, son usados en la
implementación de las especificaciones de Java Servlets y JavaServer
Pages (JSP), de Sun Microsystems, proporcionando un ambiente para que
el código Java pueda ejecutarse con la cooperación de un servidor Web.
Jboss y Tomcat poseen herramientas para su configuración y

administración, pero también pueden ser configurados modificando los

Capítulo II
archivos de configuración que poseen formato XML. Además, contienen su

propio servidor HTTP interno.
Incluye el compilador Jasper, que compila JSPs convirtiéndolas en

servlets. El motor de servlets de Jboss y Tomcat a menudo se presenta en
combinación con el servidor Web Apache.
La jerarquía de directorios de instalación de Jboss y Tomcat incluyen:
Bin: Arranque, cierre, y otros scripts y ejecutables.
Common: Clases comunes que pueden utilizar Catalina y las aplicaciones

Web.
Conf: Archivos XML y los correspondientes DTD para la configuración de

Tomcat.
Logs: Logs de Catalina y de las aplicaciones.
Server: Clases utilizadas solamente por Catalina.
Shared: Clases compartidas por todas las aplicaciones Web.
Webapps: Directorio que contiene las aplicaciones Web.
Work: Almacenamiento temporal de archivos y directorios.
1..5 Servicios Web

Los servicios Web son usados para establecer la comunicación entre dos
aplicaciones, ya que estos son una colección de protocolos y estándares que
sirven para intercambiar datos entre aplicaciones, las cuales pueden estar
desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre
cualquier plataforma. En el caso de estudio serán utilizados para comunicar una
aplicación desarrollada en XUL del lado del cliente y una aplicación desarrollada
en Java del lado del Servidor.
La interoperabilidad se consigue mediante la adopción de estándares

abiertos. Las organizaciones OASIS y W3C son los comités responsables de la

Capítulo II
arquitectura y reglamentación de los servicios Web. Para mejorar la

interoperabilidad entre distintas implementaciones de servicios Web ha sido
creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir
de manera más exhaustiva estos estándares.
Existen distintas formas de usar los servicios Web, la estudiada en este

caso será Representional State Transafer (REST), la cual una técnica de
arquitectura software para sistemas hipermedia distribuidos como la World Wide
Web. El término se originó en el año 2000, en una tesis doctoral sobre la Web
escrita por Roy Fielding [4], uno de los principales autores de la especificación
del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de
desarrollo.
Según el autor, REST está pensada para evocar una imagen de cómo se
comporta una aplicación Web bien diseñada; una red de páginas Web, donde los
usuarios avancen en la aplicación a través de links (transiciones de estado),
obteniendo como resultado que la siguiente página (representando el próximo
estado de la aplicación) sea transferida al usuario y ofrecida para su uso.
La razón por la cual se llama REST, es porque un usuario hace una

referencia a una página Web usando el URL, la cual devuelve una representación
del recurso (en la Figura 2 es un documento HTML). Esta representación coloca
al usuario en un estado. Cuando el usuario selecciona un hyperlink en la página
HTML es otro recurso, por lo que la nueva representación coloca al usuario en un
nuevo estado.
http://www.boeing.com/aircraft/747
Cliente Recurso
s
Requerimientos de Combustible
Horarios de Mantenimiento
Figura 2. Ejemplo de REST

Capítulo II
Las principales características de REST son:
Protocolo cliente/servidor sin estado: Cada mensaje HTTP contiene

toda la información necesaria para comprender la petición. Como
resultado, ni el cliente ni el servidor necesitan recordar ningún estado de
las comunicaciones entre mensajes. Sin embargo, en la práctica, muchas
aplicaciones basadas en HTTP utilizan cookies y otros mecanismos para
mantener el estado de la sesión (algunas de estas prácticas, como la
reescritura de URLs, no son permitidas por REST).
Conjunto de operaciones bien definidas: Se aplican a todos los

recursos de información; HTTP en sí define un conjunto pequeño de
operaciones, las más importantes son POST, GET, PUT y DELETE. Con
frecuencia estas operaciones equivalen a las operaciones CRUD (create,
read, update, delete), que se requieren para la persistencia de datos,
aunque POST no encaja exactamente en este esquema.
Sintaxis universal: Usado para identificar los recursos. En un sistema

REST, cada recurso es direccionable únicamente a través de su URI.
Uso de hipermedios: Para la información de la aplicación y las

transiciones de estado de la aplicación: la representación de este estado
en un sistema REST son típicamente HTML o XML. Como resultado de
esto, es posible navegar de un recurso REST a muchos otros,
simplemente siguiendo enlaces sin requerir el uso de registros u otra
infraestructura adicional.
En cuanto a las plataformas a usar para el desarrollo de servicios Web,

existen múltiples arquitecturas que pueden ser usados, en este caso
estudiaremos Axis2, ya que posee un componente de soporte a Rest.
Axis2 está compuesta por los siguientes componentes (Figura 3) [5]:

Capítulo II
Figura 3. Arquitectura de Axis2
AXIOM
El Modelo del Objeto de Axis (AXIOM), es un modelo de objeto XML

desarrollado para mejorar el uso y desempeño de la memoria durante el
procesamiento del XML, basado en pull parser. Usando el Streaming API para
XML (StAX) pull parser, AXIOM puede controlar el proceso de parseo para
proveer soporte de construcción diferido. Construcción diferida es la habilidad
que posee AXIOM de construir un modelo de objeto parcialmente mientras el
resto del modelo es construido según las necesidades del usuario. La ventaja es
que la memoria solo es usada para satisfacer las necesidades del usuario.
Motor Extensible de Mensajería
El motor de Axis2 es un procesador de SOAP puro y no depende de

ninguna especificación de Java. El funcionamiento de este motor (Figura 4)
comienza cuando un mensaje es recibido a través de un transporte, luego el
motor llama un conjunto de interceptores predefinidos llamados manejadores.
Los manejadores procesan normalmente la información dentro de las cabeceras
de SOAP, aunque ellos no tienen limitaciones para procesar otras partes de
mensaje también. El mensaje es entonces entregado a un receptor de mensajes.

Capítulo II
Figura 4. Motor Extensible de Mensajería
Arquitectura de Módulos
Los módulos proveen un mecanismo de extensión al servidor. Cada

módulo de Axis2 contiene un conjunto de manejadores relacionados. Por
ejemplo, existe un módulo denominado WS-Addresing el cual contiene los
manejadores para el soporte de ES-Addresing por parte del motor de Axis2. Si un
administrador de Axis2 desea agregar este módulo, solo debe desplegar el
mismo en el motor de Axis2. Las reglas, para designar los manejadores que van
en cada fase y tubo, se encuentran en el archivo modules.xml. (Figura 5)
Figura 5. Arquitectura de Módulos

Capítulo II
Modelo de Desarrollo Mejorado
Axis2 permite el despliegue de servicios en su motor durante su uso, lo

cual permite que los usuarios desplieguen servicios sin necesidad de reiniciar el
servidor. Los servicios deben estar comprimidos en archivos con extensión .aar
(archivos Axis2).
1..6 Gestión de procesos de negocio
Business Process Management (BPM) es un conjunto de métodos,

herramientas y tecnologías utilizados para diseñar, representar, analizar y
controlar procesos de negocio operacionales. BPM es un enfoque centrado en los
procesos para mejorar el rendimiento que combina las tecnologías de la
información con metodologías de proceso y gobierno. [6]
En una forma resumida, BPM se precisa como una disciplina de gestión

por procesos de negocio y mejora continua apoyada por tecnologías de la
información.
En la actualidad, las organizaciones apuntan de forma inequívoca a lograr

la correcta especificación de sus procesos de negocio, con la premisa de lograr la
integración operacional y el aumento de su rentabilidad en el negocio.
Las situaciones más comunes que demandan la aplicabilidad de BPM de

gestión son las siguientes:
Redefinir y optimizar procesos en su rendimiento con el soporte de TI.
Identificar y documentar procesos actuales con la finalidad de

automatizarlos.
Implantar un nuevo proceso en la organización.
BPM combina métodos ya probados y establecidos de gestión de procesos

con una nueva clase de herramientas de software empresarial. Ha posibilitado

Capítulo II
adelantos muy importantes en cuanto a la velocidad y agilidad con que las

organizaciones mejoran el rendimiento de negocio. (Garimella Kiran, 2008)
Entendiendo que los procesos constituyen cadenas de valor que

normalmente se propagan más allá de las fronteras de los departamentos, BPM
introduce considerables cambios en la estructura y la práctica de la gestión
empresarial integrando los procesos, lo que inevitablemente repercute en las
formas en las que las personas están acostumbradas a comunicarse.
Como disciplina de gestión de procesos, el concepto de BPM es amplio;

tiene objetivos claros y bien definidos:
Mejorar la agilidad de negocio: concepto que se entiende como la

capacidad que tiene una organización de adaptarse a los cambios del entorno a
través de los cambios en los procesos integrados.
Lograr mayor eficacia: capacidad de una organización para lograr, en

mayor o menor medida, los objetivos estratégicos o de negocio.
Mejorar los niveles de eficiencia: relación entre los resultados obtenidos y

los recursos utilizados. [7]
1..7 Arquitectura Orientada a Servicios
Desde hace muchos años ha existido la necesidad de integrar

aplicaciones en las organizaciones. La rápida evolución de la tecnología y el
crecimiento del mercado obligan a las mismas a tener constantes cambios para
poder afrontar las nuevas exigencias.
Las organizaciones para enfrentar los retos actuales se dedican a crear

aplicaciones de manera desorganizada. Estas aplicaciones van creciendo
rápidamente a medida que se incrementan las necesidades de los clientes. Estas
necesidades se han abordado de forma puntual, pensando en abaratar costos a
corto plazo y cumplir objetivos inmediatos, sin una visión estratégica, ni
gobierno.

Capítulo II
Erróneamente pensado en una posible solución, las organizaciones han

desarrollado servicios web para sus aplicaciones, sin darse cuenta que están en
el mismo problema, dado que no tienen forma de gobernar el diseño, desarrollo
y la puesta en producción de los servicios.
Una solución para gobernar este caos es la implementación de una

Arquitectura Orientada a Servicios (SOA), como un estilo arquitectural (forma de
ordenar un sistema de información y sus componentes), que permite el
intercambio de datos de manera interoperable e independiente.
Sin embargo, una Arquitectura Orientada a Servicios, no es únicamente

convertir todas las funcionalidades de la organización en servicios web, sino que
se tiene que pensar en cómo hacer Gobierno de la misma.
El Gobierno SOA se refiere a los procesos que la organización establece

para garantizar que las acciones realizadas se adhieren a las mejores prácticas,
normativas, estándares y principios de arquitectura, con objeto de gobernar la
adopción e implementación de SOA.
La ausencia del Gobierno SOA puede desembocar en los siguientes

problemas:
El proyecto SOA entrega resultados inconsistentes.
Crecimiento caótico a nivel de infraestructura y servicios.
Servicios con funcionalidad redundante.
Disponer de servicios que no se pueden reutilizar en la organización.
Inconsistencia en la identificación, diseño y uso de los servicios.
No se definen métricas para cuantificar el éxito.
Ausencia de coordinación entre proyectos.
El estilo arquitectural SOA, está conformado por 3 conceptos

fundamentales:

Capítulo II
• Servicio: Es una pieza independiente de la funcionalidad del

negocio, que permite que un cliente solicite a un servidor una actividad o tarea.
• Bus de Servicio Empresarial (ESB): Es una infraestructura que

permite la interoperabilidad entre los servicios y entre sistemas distribuidos. Hace
que sea fácil distribuir los procesos de negocios sobre múltiples sistemas usando
diferentes plataformas y tecnologías.
• Bajo Acoplamiento: El objetivo de este concepto es el de reducir las

dependencias entre los sistemas. Debido a que los procesos de negocio se
encuentran distribuidos sobre múltiples plataformas y lenguajes, sin embargo
existe un lenguaje universal que los comunica y que permite que las
interacciones sean simples y las funcionalidades sean únicas evitando
repeticiones [8]
La finalidad de SOA es tener tareas individuales, las cuales son ejecutadas

por componentes especializados llamados servicios. El objetivo de los servicios es
coordinar los procesos de negocio, cada servicio es diseñado para facilitar su
reutilización, si otro proceso requiere que la misma tarea sea ejecutada, ésta
hace uso del servicio existente. Las ventajas de la utilización de SOA son las
siguientes:
• Desarrollo eficiente: SOA promueve la modularidad porque los

servicios son independientes, esta modularidad tiene implicaciones positivas para
el desarrollo de aplicaciones compuestas.
• Mayor reutilización: los servicios reutilizables disminuyen el costo

de desarrollo y velocidad de tiempo en la comercialización.
• Mantenimiento simplificado: manejando un lenguaje simple y único,

reduciendo los costos debido a que las aplicaciones desarrolladas en SOA son
aplicaciones modulares e independientes.
• Evolución: Un servicio y su contrato de servicio encapsulan la lógica

del negocio, de forma tal, que otros servicios no necesitan conocer nada acerca

Capítulo II
de la forma en la cual se provee el servicio, solamente necesitan conocer lo que

el servicio toma como entrada y lo regresa como salida.
SOA en combinación con los servicios web facilita el desarrollo de servicios

que encapsulan funciones de negocio y que son fácilmente accesibles desde
cualquier otro servicio. Además, servicios complejos permiten un amplio rango
de opciones para combinar servicios web y crear nuevas aplicaciones
funcionales. La tecnología de los servicios web puede ser usada para resolver
varios problemas de las tecnologías de información, especialmente cuando se
asocian piezas de software diferentes. Los servicios web proveen la
interoperabilidad y pueden fácilmente ser extendidos para ser utilizados en
arquitecturas empresariales por su bajo costo y por su valor en las tecnologías
de información, sin embargo, adquieren más valor cuando utilizan
implementaciones basadas en SOA [9]
Una vez descritos los principales componentes del marco teórico, a

continuación en el siguiente capítulo se describe la metodología utilizada.

Capítulo III
CAPITULO III: MARCO METODOLÓGICO
A continuación se muestra los aspectos metodológicos tanto para el

desarrollo del software como para desarrollo de la investigación.
3.1 Metodología de desarrollo de software

Una metodología de desarrollo de software se define como ―un conjunto
de procedimientos, técnicas, herramientas, y un soporte documental que ayuda a
los desarrolladores a producir nuevo software‖ (Piattini. et al., 2001).
Maddison define a la metodología de desarrollo como:
―Un conjunto de filosofías, fases, procedimientos, reglas, técnicas,

herramientas, documentación y aspectos de formación para los
desarrolladores de Sistemas de Información‖. Maddison (1999)
En base a las definiciones anteriormente planteadas se puede decir que

una metodología de desarrollo de software es un conjunto de pasos y
procedimientos que deben seguirse para desarrollar software. Una metodología
debe especificar los siguientes aspectos:
División de un proyecto en etapas

Tareas que se llevan a cabo en cada etapa
Restricciones que deben aplicarse
Técnicas y herramientas que se emplean
Control y gestión de un proyecto. (Cavalho, 2005)
Con una buena metodología se pretende reducir costos y retrasos de

proyectos así como mejorar la calidad del software.

Capítulo III
Al momento de elegir una metodología general para desarrollar software

debe tomarse en cuenta aquella que permita en todas sus fases la fácil
adaptabilidad a cualquier tipo de requerimientos que el desarrollo exija.
Ante esta necesidad surgen las metodologías ágiles como respuesta a los
problemas que presentan las metodologías tradicionales.
El desarrollo ágil persigue minimizar los tiempos de recolección y

consolidación de requisitos y apostar en el desarrollo rápido e incremental que
permita perfeccionar el software conforme se va construyendo. (Torres. et al,
2008).
El resultado es un software en menos tiempo y que se ajusta a las

necesidades del cliente impuestas en muchos casos por un mercado que cambia
de forma trepidante.
Ya que los procesos ágiles permiten una construcción rápida de software

y, alternativamente, introducir cambios tan pronto como sea posible en cualquier
paso, estos fueron tomados en cuenta en el desarrollo de esta investigación,
específicamente el método planteado por el Proceso Unificado Ágil (Agile UP -
AUP).
A continuación toda la descripción de esta metodología.
3.1.1 Proceso Unificado Ágil
El Proceso Unificado Ágil (Ágile Unified Process o Ágile UP) es un marco de

desarrollo de software iterativo e incremental. Especifica muchas actividades y
artefactos involucrados en el desarrollo de un proyecto software. Dado que es un
marco de procesos, puede ser adaptado y la más conocida es RUP (Rational
Unified Process) de IBM.

Capítulo III
AUP se preocupa especialmente de la gestión de riesgos. ―Propone que

aquellos elementos con alto riesgo obtengan prioridad en el proceso de
desarrollo y sean abordados en etapas tempranas del mismo. Para ello, se crean
y mantienen listas identificando los riesgos desde etapas iniciales del proyecto‖
(Ambler - 2007).
Especialmente relevante en este sentido es el desarrollo de prototipos

ejecutables durante la base de elaboración del producto, donde se demuestre la
validez de la arquitectura para los requisitos clave del producto y que determinan
los riesgos técnicos.
Al igual que en el Proceso Unificado Rational (RUP – Rational Unified

Process), en AUP se establecen cuatro fases que transcurren de manera
consecutiva:
Concepción: el objetivo de esta fase es obtener una comprensión común

cliente-equipo de desarrollo del alcance del nuevo sistema y definir una o
varias arquitecturas candidatas para el mismo.
Elaboración: el objetivo es profundizar en la comprensión de los requisitos
del sistema y en validar la arquitectura.
Construcción: durante la fase de construcción el sistema es desarrollado y
probado totalmente en el ambiente de desarrollo.
Transición: el sistema se lleva a los entornos de preproducción donde se
somete a pruebas de validación y aceptación y finalmente se despliega en
los sistemas de producción.

Capítulo III
Figura 6. Ciclo de Vida del Proceso Unificado Ágil ó AUP
Fuente: Ambler. 2007
Las disciplinas de AUP son las siguientes:
Modelado: su objetivo es entender el negocio de la organización, el

dominio del problema del proyecto y determinar una solución viable para
resolver el problema.
Implementación: transforma el modelo en código ejecutable y realiza
pruebas básicas.
Prueba: realiza una evaluación objetiva para garantizar la calidad. Esto
incluye la búsqueda de defectos, validar que el sistema funcione como se
estima y verificar el cumplimiento de requisitos.
Despliegue: se encarga de planificar la forma en que el sistema estará a la
disposición de los usuarios finales.
Gestión de configuraciones: maneja el acceso a los artefactos del
proyecto. Esto no sólo implica un seguimiento a las versiones del
artefacto, sino también el control y la gestión de cambio de los mismos.
Gestión de proyectos: dirige las actividades que se llevan a cabo en el
proyecto. Incluye la gestión de riesgos, coordinación con el personal y

Capítulo III
sistemas que estén fuera del alcance del proyecto para garantizar que el
proyecto se entregue a tiempo y dentro del presupuesto establecido.
Entorno: garantiza que el proceso adecuado, la orientación y las
herramientas necesarias estén disponibles para el equipo cuando lo
requieran.

Capítulo IV
CAPITULO IV: MARCO APLICATIVO
En este capítulo se presenta el análisis, diseño y construcción de SACAS

elaborado en este trabajo especial de grado con el fin de describir todas las
funcionalidades del sistema y cumplir los objetivos propuestos al comienzo de
esta investigación.
En este inciso se incluirán los diagramas que representan el modelado del

aplicativo SACAS., como son el diagrama de clases, los diagramas de casos de
uso con sus respectivas clases, los diagramas de estado y los diagramas de
secuencia.
1. Diagramas de Casos de Uso
Los diagramas que se presentan en este inciso describen las actividades y

motivaciones reales del desarrollo de SACAS, con el fin de reflejar interfaces
detalladas con los usuarios, relaciones con los aplicativos a un nivel mayor de
detalle y detalles de diseño.

Capítulo IV
Manejo de Usuarios
Crear Usuario
Autorizar Usuario
Administrador
Modificar Usuario
Eliminar Usuario
Figura 7. Caso de Uso: Manejo de Usuarios

Capítulo IV
Manejo de Tickets
S.A.C.A.S.
Crear Ticket
Aplicativos CANTV
SISE, Remedy,
CISABA, GOR,
Usuario Operador
CORETP,
Consultar Ticket (SIAC, 151,
SICDS)
«uses»
Consultar Listado
de Tickets
SAD/WAP
Modificar Ticket
Usuario Supervisor
Reasignar Ticket
Aplicativos CANTV
GestorTP,
IVR
Cancelar Ticket
Figura 8. Caso de Uso: Manejo de Tickets

Capítulo IV
Manejo de Archivos
Clase Generar Archivo
Generar Archivo de
Averías Cerradas
GenerarArchivo de
Averías Abiertas
Generar Archivo
GestionX
«extends» «extends»
«extends»
Generar Archivo de
Despachos de Tickets por Averías
de Voz
«extends»
«extends»
Generar Archivo
Generar Archivo de
* * Reclamos y Ajustes (Art. 8)
«extends»
Scheduler
«extends»
Generar Archivo de Cálculo
de Reclamos y Ajustes
«extends» (Cláusula 47)
«extends»
Generar Archivo de
Tickets por Averías
Generar Archivo de
Tickets por Órdenes de
Generar Archivo de
Servicio
Averías de Voz de
Corporaciones
Figura 9. Caso de Uso: Generar Archivo

Capítulo IV
Clase Recibir Archivo
Recibir Archivo de
Corte y Reconexión
Recibir Archivo de
Cortes Efectivos
«extends»
«extends»
Recibir Archivo de
Reconexiones Efectivas
«extends»
«extends»
Recibir Archivo Recibir Archivo de
Nuevos Números
* *
«extends»
Scheduler
«extends» Recibir Archivo de

Averías de Corporaciones
«extends»
Averías de
Circuitos
Averías de
Circuitos Resueltas
Figura 10. Caso de Uso: Recibir Archivo

Capítulo IV
Auditoría
S.A.C.A.S.
Auditar Operaciones
Auditar Fecha
Administrador Auditar Usuario
Permite usar más de un criterio para la auditoría:

Auditar por Usuario y Fecha,
Múltiples Criterios Operación y Fecha,
Usuario y Operación
Fecha, Usuario y Operación
Figura 11. Caso de Uso: Auditoría

Capítulo IV
Manejo de Reportes
Existe la necesidad de que el aplicativo SACAS permita la consulta de

información en línea, referente a los tickets, según características específicas, lo
cual genera una lista de tickets que cumplen tales condiciones. Para este fin,
SACAS presentará en la interfaz de Operación, la opción de ver reportes en línea.
El diagrama del caso de uso que se presenta a continuación, asociado a esta
facilidad, es genérico.
Generar Reporte de
Abiertos
«extends»
Interfaz de Reportes Generar Reporte

«extends»
Generar Reporte de
Cerrados
Figura 12. Caso de Uso: Manejo de Reportes
2. Diagramas de Secuencia
Los diagramas que se presentan en este inciso describen las secuencias

que llevarán a cabo en cada clase del caso de uso Manejo de Tickets de SACAS,
con el fin de reflejar interfaces detalladas con los usuarios, relaciones con los
aplicativos a un nivel mayor de detalle y detalles de diseño.

Capítulo IV
Manejo de Tickets
Abrir Ticket
SACAS
Top Package::Usuario Interfaz Nro. Servicio()
Busca Datos del Cliente()

Busca la informacion del cliente en la BD ASAP:
Cliente no existe
¿Servicio activo?() Valida que el servicio reportado esté activo:

Servicio Reportado No Activo
¿Servicio Cortado?()
Valida si el servicio no ha sido cortado:
Servicio Cortado por Pago
¿Tiene Ticket abierto?() Valida si el servicio no tiene ticket abierto:

Ticket Servicio/Causa ya existe
Secciona Ticket() Asigna Área Resolutoria y Cuadrilla:

Ticket abierto exitosamente
SAD/WAP, SICDS,
SIAC, SISE, Remedy,
CISABA, CoreTP, GOR,
Aplicativo GestorTP e IVR
CANTV SACAS
Datos del Ticket
Ticket creado exitosamente Se realizan todas las validaciones y

Ticket creado exitosamente las tareas requeridas para la creación.
Ticket no pudo ser creado No se cumple alguna de las condiciones

Error al crear Ticket
o no hay recursos para crear el ticket.
Figura 13. Caso de Uso: Manejo de Reportes

Capítulo IV
Consultar Ticket
SACAS
Top Package::Usuario Interfaz
Número de Ticket()
Datos de Ticket Busca la informacion del ticket en la BD SACAS:
Datos del Ticket
Figura 14. Caso de Uso: Consultar Ticket
Consultar Listado de Tickets
Cualquier campo o combinación de

campos permitida por la interfaz SACAS
Top Package::Usuario Interfaz DAC/Área Resolutoria/Status
Listado de Tickets
Busca en la BD de SACAS todos aquellos tickets
que cumplen con el(los) criterio(s) establecidos en
Listado de Tickets
la búsqueda.
SISE, Remedy, SIAC,

SICDS, CoreTP,
CISABA, GOR
Aplicativo
SACAS
CANTV
DAC/Área Resolutoria/Status
Cualquier campo o combinación de

campos permitida por la interfaz
Listado de Tickets
Listado de Tickets
Figura 15. Caso de Uso: Consultar Listado de Ticket

Capítulo IV
Modificar Ticket
SACAS
Top Package::Usuario Interfaz Número de Ticket()
Datos del Ticket Busca la informacion del ticket en la BD SACAS:
Datos del Ticket

Datos Modificados()
Actualizar BD SACAS()
Ticket actualizado exitosamente
Figura 16. Caso de Uso: Modificar Ticket
Cancelar Ticket
SACAS
Top Package::Usuario Interfaz
Nro de Ticket/Status
Datos del Ticket Busca la informacion del ticket en la BD SACAS:
Actualizar BD SACAS()
Ticket Cancelado
Figura 17. Caso de Uso: Cancelar Ticket

Capítulo IV
Manejo de Archivos
SACAS Productividad SAD/WAP Desarrollo Kenan SISE RMCA ASAP Datamart de Corporaciones
Averías Cerradas
Averías Abiertas
GestiónX
GestiónX
Despachos de Tickets por Averías de Voz
Corte y Reconexión
Retorno Corte y Reconexión
Corte y Reconexión
Cortes Efectivos
Reconexiones Efectivas
Averías de Circuitos
Averías Cerradas de Circuitos
Reclamos y Ajustes (Artículo 8)
Cálculo Reclamos y Ajustes (Cláusula 47)
Tickets por Averías
Tickets por Órdenes de Servicio
Datos de Clientes
Configuración de Servicios
Notificación de Nuevos Números
Averías de Voz
Averías de Clientes Corporativos
Figura 18. Caso de Uso: Manejo de Archivos

Capítulo IV
Auditoría
Usuario/Operación/Fecha,
Usario y Fecha,
Usuario y Operación,
Operación y Fecha,
Usuario, Operación y Fecha SACAS
Top Package::Usuario Administrador Datos de Consulta
Listado de Resultados
Busca en la BD de SACAS todos aquellos registros

que cumplen con los criterios de consulta establecidos
Listado de Resultados por el administrador que desea auditar
3. Diagrama de Clases
Usuario Ticket
#Grupo de Trabajo : char #Fuera de Franquicia : char = OOF
#Nombre y Apellido : char #No Publicado : char = NON-PUB
#Nombre de Usuario : char #Desconexión Temporal : char = TD
#Contraseña : char #Bloqueo de Llamadas : char = TB
#Rol : char #Crédito a Favor : char = CH
+Crear() 1 #Color del Par : char
+Autorizar() #Llamada Touch : char = TC
+Eliminar() #Garantía de Reparación : char
+Modificar() #Status : char = CLRD
#CL/B : char
#CLC : char
#Acción : char
1..*
#DAC : char
#Oficina Central : char
#Centro de Reporte : char
#Fecha de Apertura : Date
#Hora de Apertura
#Razón Crítica : char
#Servicio : char
#No Regulado : char
#Nombre : char
#Segmento de Mercado : char
#CLEC : char = N
#Ausencia de Facilidad : char
#Portabilidad : char = N
#Dirección : char
#Prioridad Serv. Telecom. : char
#Prioridad de Servicio : char
#CPNI : char = N
#Ciudad : char
#Número alterno : char
#IWMP : char = N
#Resultados de la Prueba : char
#Fecha de Compromiso : Date
#Hora de Compromiso
#Ubicacion en Mapa : char
#Número de Ticket : char
#Tipo de Problema : char
#Vía Rec : char = N
#Sospecha FdS : char = N
#Medición Especial : char
#Area Resolutoria : char
+Crear() : char
+Consultar() : Ticket
+Modificar() : Ticket
+Reasignar() : Ticket
+Cancelar() : char
TicketDeCliente
TicketDeCircuito
TicketDeCompañía -Oficina Comercial : char = 001
-NÚMERO DE CIRCUITO : char
-Información Contrato Mtto. : char
-UBICACIÓN SEGMENTO/CIRCUITO : char -Oficina Comercial : char = 001
-Número de Teléfono : char
-SVB/CLD : char -Información Contrato Mtto. : char
-Estación : char
-CAC : char = N -Número de Teléfono : char
-Party Line : char
-Reportado por : char -Estación : char
-IXC : char = N
-Problema Reportado : char -Party Line : char
-Reportado por : char
-OTRAS UBICACIONES : char -CABLE : char
-CAC : char = N
-Acceso : char -PAR : char
-Problema Reportado : char
-Fecha de Cita : Date -EQUIPO ORIGEN : char
-Todos los Teléfonos : char = D
-Hora de Cita -ORIGINADO POR : char
-Todas las Llamadas : char = D
-Tipo de Cita : char -REMARKS : string
-Acceso : char
-SV OF : char -ASIGNAR PRIORIDAD DE CLIENTE : char
-Unidad de Negocios : char
-Unidad de Negocios : char
-Fecha de Cita : Date
-ORIGEN : char
-Hora de Cita
-Tipo de Ticket : char
-Tipo de Cita : char
-ORIGINADO POR : char
-Cita por Defecto : char
-Cargos por Visita : char
-Tipo de Ticket : char
-Cargos Cotizados : char
-Cargos por Visita : char
-SV OF : char
-Cargos Cotizados : char
Figura 19. Diagrama de Clases

Capítulo IV
4. Diagramas de Estados
Ticket
Abierto
Asignado Cancelado
sin asignar
En Histórico
Figura 20. Diagrama de Estado: Ticket
Usuario
Creado Autorizado Bloqueado
Figura 21. Diagrama de Estado: Usuario

Capítulo IV
5. Diagramas de Despliegue
Diagrama de Despliegue de PIC
Figura 22. Diagrama de Despliegue: PIC

Capítulo IV
Diagrama de Despliegue Usuario
Figura 23. Diagrama de Despliegue: Usuario

Capítulo IV
Diagrama de Despliegue SACAS
Figura 24. Diagrama de Despliegue: SACAS
Diagramas BPM de los procesos SACAS
A continuación se anexan los documentos que contienen los diagramas BPM del
sistema SACAS

Capítulo IV
Manejo general de Tickets
Figura 25. Diagrama BPM: Manejo General de Tickets

Modelo Entidad-Relación
Figura 26. Diagrama Modelo Entidad-Relación
Definición de Entidades:

Capítulo IV
Parámetros Generales
Contiene un único registro con la configuración general del sistema SACAS. Esta
tabla es utilizada para almacenar parámetros de funcionamiento general del
sistema.
Alarmas
Tabla que contiene las alarmas críticas generadas por el sistema; estas alarmas
son eventos que impiden el funcionamiento correcto de SACAS.
Auditoría
Tabla que contiene los registros de las acciones que ejecutan los diferentes
usuarios del sistema SACAS. Esta auditoría se refiere a las acciones realizadas
sobre campos o procesos que modifiquen la configuración.
Roles
Tabla que contiene los diferentes roles o perfiles de los usuarios del sistema
SACAS.
Permisos
Tabla que contiene los permisos de cada uno de los roles o perfiles del sistema.
Existe un permiso por cada acción relativa a inserción, modificación, eliminación,
etc. que se puede realizar en la interfaz Web de SACAS.
Tracking

Capítulo IV
Tabla donde se almacenan los registros de tracking o seguimiento operacional.

Cada vez que una avería pasa de un área resolutoria a otra o es cancelada, se
registra un record de tracking con una marca de tiempo. Esto permite hacer
inteligencia operacional y verificar los tiempos de atención, cuellos de botella,
etc.
Averías
Esta es la tabla principal del sistema SACAS, en la cual se almacenan todos los
tickets por averías creados en SACAS.
Transacción Averías
Esta tabla contiene información transaccional de los cambios que ha sufrido un

ticket en su ciclo de vida.
Teléfonos
Contiene la base instalada de teléfonos con sus características principales. Esta

tabla es actualizada todos los días con la información proveniente del sistema
ASAP.
Áreas de Despacho
Contiene las diferentes áreas de despacho o DAC en las cuales se divide la

operación del sistema SACAS.

Capítulo IV
Central
Contiene la información referente a todas las centrales que maneja la

infraestructura.
Áreas
Esta tabla contiene una división lógica de áreas geográficas que componen toda
la red de teléfonos CANTV.
Metas de Despacho
Contiene los registros de las metas deseadas de atención de tickets de averías,

discriminada por centro o área de despacho.
Origen del reporte
Esta tabla contiene un listado de los posibles centros de llamadas,

departamentos u unidades de negocio donde se originan los tickets de averías.
Área resolutoria
Esta tabla contiene un listado de las posibles áreas resolutorias que pueden
atender un ticket de avería.
Tipo de servicio
Tabla que identifica los diferentes tipos de servicios que pueden generar un
ticket de avería.

Capítulo IV
Tipo de problema
Esta tabla contiene las diferentes tipificaciones de problemas que pueden ser el
origen de un ticket de avería.
Causa
Esta tabla contiene un listado de las posibles causas con las cuales puede ser
tipificado un ticket de averías.
Código Cancelación
Tabla que contiene los códigos de cancelación de averías. Estos están codificados
como códigos compuestos de cancelación y sub-código de cancelación.
Unidad de Negocios
Tabla que contiene las diferentes unidades de negocios que comprenden la

estructura organizativa.
Grupo de Trabajo
Tabla que contiene los diferentes grupos de trabajo en los que está dividido el
personal que opera el sistema SACAS.
Patrón de Averías
Tabla que contiene los parámetros que permiten detectar patrones de averías
que se producen en los diferentes componentes de la red.

Capítulo IV
Sistema SACAS, en su módulo de operación, se desarrolló de la siguiente

manera:
4.1.1 Crear Incidente:

Para crear un reporte de avería se debe seleccionar que tipo de incidente
se quiere abrir. Los tipos de incidentes son: cliente, interno y circuito.
4.1.1.1 Crear Incidente Tipo Cliente
Un incidente tipo cliente es aquel que se genera a partir de la llamada de

un cliente, para reportar una falla en alguno de sus servicios.
Figura 27. Crear incidente tipo cliente
Para crear un incidente de tipo cliente primero se debe especificar:

Código de área y número de teléfono que presenta la falla.
Tipo de servicio el cual presenta falla. Los tipos de servicio que existen
son:
DESCRIPCIÓN
ESPECIALES
MENSAJES

Capítulo IV
TELEFONOS INTERNOS
PAGINA
CENTRAL PRIVADA
AUTOMATICA
GOBIERNO
MONEDERO
COMERCIAL
RESIDENCIAL
SERVICIO 800
SERVICIO DATA DIGITAL
ALTA CAPACIDAD
Una vez ingresados el número de teléfono y el tipo de servicio se presiona el

botón Buscar. Al presionar el botón Buscar se pueden presentar las siguientes
posibilidades:
1. No existe incidente: quiere decir que para el número de teléfono y tipo de

servicio ingresados no existe un reporte creado en la base de datos de
SACAS, por lo tanto se presentara la pantalla de creación de un incidente
tipo cliente, la cual tiene la siguiente forma:
Datos del cliente: se muestra la información del cliente.
Datos técnicos: información técnica del teléfono.
Datos del reporte: todos los datos que se deben completar para crear el
incidente.

Capítulo IV
Los campos que se presentan en esta pantalla son:

Armario/Terminal/FXB: campo de lectura que describe el punto final de la
red donde se conecta el teléfono.
Cable: campo de lectura que describe al cable correspondiente al tramo
de red donde está el teléfono.
Ciudad: campo opcional que describe la ciudad de donde se está
reportando la falla.
Código central: campo de lectura que representa el número de la central
del teléfono.
Comentario: campo opcional donde se coloca alguna observación que la
persona que está reportando menciona.
Con servicio: campo obligatorio donde se coloca si la línea presenta
servicio o no.

Capítulo IV
CR: campo de lectura que describe el centro de reporte correspondiente a

la central del teléfono.
DAC: campo de lectura que describe el centro de despacho del teléfono.
Dirección: campo de lectura que describe la ubicación física del servicio.
Enrutar a: campo obligatorio donde se selecciona a que área de trabajo se
envía el reporte inicialmente. Las áreas de trabajo que existen en SACAS
están descritas en el Anexo 1: Tabla de Área de Trabajo.
Extra: campo de lectura que contiene información técnica adicional del
teléfono, como por ejemplo de ABA.
Fecha hora compromiso: campo obligatorio que define la fecha la cual el
incidente debe estar cerrado.
Fecha hora cita: campo opcional que define la fecha de visita al cliente.
Info 1: campo opcional abierto.
Localización: campo opcional que indica la localización del incidente y el
cual puede ser utilizados por sistemas externos como SAD WAP para
colocar información propia del incidente.
Nombre: campo de lectura que describe el nombre completo del cliente.
Número de teléfono: campo de lectura que describe el número de
teléfono.
Origen del reporte: campo obligatorio donde se selecciona el origen de
donde está creando el reporte. Los posibles valores son:
1 - ALIT (Automatic Line Insulation Test)
2 - LATS (Loop Analysis Test System)
3 - EAX (Electronic Automatic Exchange)
4 - COIN CTR (Coin Center)
5 - OPR (Operator)
6 - OTH EMP (Other Employee)
7 - PRESSURE.
Par: campo de lectura que describe al par correspondiente al cable del
tramo de red de teléfono.

Capítulo IV
Persona que Reporta: campo opcional que describe la persona que

reporto la falla.
Problema reportado: campo opcional abierto que describe el problema
que presenta el servicio.
Razón crítica: campo de lectura que describe si el teléfono presenta algún
servicio crítico.
Resultado del test: campo opcional donde se coloca el resultado de la
prueba que se realiza en 4tel al teléfono.
Teléfono contacto: campo opcional donde se coloca un número de
teléfono donde se puede contactar al cliente.
Tipo origen reporte: campo obligatorio donde se selecciona el tipo de
persona que está reportando. Los tipos son: Primera, Segunda y Tercera.
Tipo problema: campo obligatorio donde se selecciona el tipo de problema
que presenta el servicio. Los posibles valores son:
01 NDT: no tiene tono
02 CCO: no se puede llamar
03 CBC: no pueden llamar
04 NCR: no devuelve la moneda
05 RWN: RCH WRONG NBR
06 MISC: MISCELLANEOUS
07 OOL: otros en la línea
08 PHYS: físico
09 NOISE: ruido
10 CH: no escucho
11 CBH: no me escuchan
12 CUTOF: se corta
13 CCALL: CUSTOM CALL
14 DATA: falla en data
Tipo de servicio: campo de lectura que describe el servicio que presenta la
falla. Los posibles valores son:
DESCRIPCIÓN
ESPECIALES
MENSAJES
TELEFONOS INTERNOS
PAGINA

Capítulo IV
CENTRAL PRIVADA
AUTOMATICA
GOBIERNO
MONEDERO
COMERCIAL
RESIDENCIAL
SERVICIO 800
ALTA CAPACIDAD
Unidad de negocio: campo de lectura que describe a que unidad de

negocio pertenece el teléfono.
Una vez ingresados los datos del reporte se debe presionar el botón ―Crear‖ para
guardar los cambios. Si presionar Crear el sistema preguntara si está seguro de
que quiere crear el incidente, si acepta se crea el incidente o si cancela volverá a
la página de creación de incidente tipo cliente.

Capítulo IV
Si presiona el botón ―Salir‖ volverá a la pantalla de crear incidente tipo cliente.

Una vez aceptada la creación del incidente se pueden presentar las siguientes
posibilidades:
Incidente creado: esto quiere decir que el incidente fue creado

exitosamente en la base de datos SACAS, y se presenta la siguiente
pantalla con el mensaje de éxito.

Capítulo IV
Error requerido: esto quiere decir que alguno de los datos que son
requeridos para crear un incidente no se ingresó, y se muestra en la
pantalla mensaje de error.

Capítulo IV
Error sistema: esto quiere decir que ocurrió algún error inesperado en los
servicios web o base de datos, para ellos el sistema mostrara un mensaje
de error.
2. Existe incidente: significa que para este número de teléfono y tipo de

servicio existe un reporte en la base de datos SACAS, el reporte puede ser
de tipo cliente o interno, para ambos casos se muestra la pantalla de
visualizar incidente. La funcionalidad de la visualización se describe más
adelante.
3. No existe teléfono: quiere decir que el número de teléfono ingresado no

existe en la base de datos de SACAS y fue imposible asociarlo a una
central, se presentara la siguiente pantalla con el mensaje de error.

Capítulo IV
Por otro lado si el teléfono ingresado no existe en la base de datos SACAS, pero
se logra asociar a una central a través del serial, el sistema permitirá abrir el
incidente y se muestra la siguiente pantalla. La funcionalidad para crear un
incidente fue descrita anteriormente.

Capítulo IV
4. Error de sistema: esto quiere decir que ocurrió algún error inesperado en
los servicios web o base de datos, para ellos el sistema mostrara un
mensaje de error.
4.1.1.2 Crear Incidente Tipo Interno
Un incidente tipo interno es aquel que se genera cuando se detecta alguna falla
en algún servicio.

Capítulo IV
Figura 34. Crear incidente tipo interno
Para crear un incidente de tipo interno primero se debe especificar:

Código de área y número de teléfono que presenta la falla
Tipo de servicio el cual presenta falla. Los tipos de servicio que existen
son:
DESCRIPCIÓN
ESPECIALES
MENSAJES
TELEFONOS INTERNOS
PAGINA
CENTRAL PRIVADA
AUTOMATICA
GOBIERNO
MONEDERO
COMERCIAL
RESIDENCIAL
SERVICIO 800
ALTA CAPACIDAD

Capítulo IV
Una vez ingresados el número de teléfono y el tipo de servicio se presiona el

botón ―Buscar‖. Al presionar el botón buscar se pueden presentar las siguientes
posibilidades:
1. No existe incidente: quiere decir que para el número de teléfono y tipo de

servicio ingresados no existe un reporte creado en la base de datos de
SACAS, por lo tanto se presentara la pantalla de creación de un incidente
tipo interno, la cual tiene la siguiente forma:
Datos del reporte: todos los campos que se deben completar para crear
el incidente.

Capítulo IV

Ciudad: campo opcional que describe la ciudad de donde se está
del teléfono.
Comentario: campo opcional donde se coloca alguna observación que la
servicio o no.
envía el reporte inicialmente.
Fecha hora cita: campo opcional que define la fecha de visita al cliente.

Capítulo IV

teléfono.
donde está creando el reporte. Los posibles valores son:
5 - OPR (Operator)
7 - PRESSURE.
reporto la falla.
servicio crítico.
Teléfono contacto: campo opcional donde se coloca un numero de
teléfono donde se puede contactar al cliente
08 PHYS: físico
09 NOISE: ruido
10 CH: no escucho

Capítulo IV
12 CUTOF: se corta
DESCRIPCIÓN
ESPECIALES
MENSAJES
TELEFONOS INTERNOS
PAGINA
CENTRAL PRIVADA
AUTOMATICA
GOBIERNO
MONEDERO
COMERCIAL
RESIDENCIAL
SERVICIO 800
ALTA CAPACIDAD

Una vez ingresados los datos del reporte se debe presionar el botón ―Crear‖ para
guardar los cambios. Si presionar Crear el sistema preguntara si está seguro de
la página de creación de incidente tipo interno.

Capítulo IV
Si presiona el botón ―Salir‖ volverá a la pantalla de crear incidente tipo interno.
posibilidades:


Capítulo IV

Capítulo IV
de error.
2. Existe incidente: significa que para este número de teléfono y tipo de

servicio existe un reporte tipo interno en la base de datos SACAS, para
este caso se muestra la pantalla de visualizar incidente. La funcionalidad
de la visualización se describe más adelante.
3. No existe teléfono: quiere decir que el número de teléfono ingresado no

existe en la base de datos de SACAS y fue imposible asociarlo a una
central, se presentara la siguiente pantalla con el mensaje de error.

Capítulo IV
Por otro lado si el teléfono ingresado no existe en la base de datos SACAS, pero
se logra asociar a una central a través del serial, el sistema permitirá abrir el
incidente y se muestra la siguiente pantalla. La funcionalidad para crear un
incidente esta descrita anteriormente.
4. Error de Sistema: esto quiere decir que ocurrió algún error inesperado en
mensaje de error.
4.1.1.3 Crear Incidente Tipo Circuito
Un incidente tipo circuito es aquel que se crea a partir de una falla en algún
circuito de un teléfono.

Capítulo IV
Figura 40. Crear incidente tipo circuito
Para crear un incidente de tipo circuito primero se debe especificar:

Número de circuito que presenta la falla.
Central a la cual pertenece el circuito.
Una vez ingresados el número de circuito y la central se presiona el botón

Buscar. Al presionar el botón Buscar se pueden presentar las siguientes
posibilidades:
1. No existe incidente: quiere decir que para el número de circuito y central

ingresados, no existe un reporte creado en la base de datos de SACAS con
estatus abierto, por otra parte ,de existir un incidente con estatus cerrado
el sistema mostrara la información del mismo para generar el reporte a
partir del último que se creó. Para ambos casos se presentara la pantalla
de creación de un incidente tipo circuito, la cual tiene la siguiente forma:

Capítulo IV
Datos del circuito: muestra el número de circuito y la central.

Datos del cliente: muestra información del cliente que presenta la falla en
el circuito.
Datos del reporte: muestra todos los campos que se deben completar del
incidente.
Central: campo de lectura que representa el número de la central del

teléfono.
Ciudad: campo opcional que describe la ciudad de donde se genera el
reporte.

Capítulo IV
Comentario: campo opcional donde se coloca alguna observación del

reporte.
servicio o no.
DAC: campo de lectura que describe el centro de despacho al cual
pertenece el circuito.
donde esta creando el reporte. Los posibles valores son:
5 - OPR (Operator)
7 - PRESSURE.
reporto la falla.
que presenta el circuito.

Capítulo IV

Teléfono contacto: campo opcional donde se coloca un numero de
08 PHYS: físico
09 NOISE: ruido
10 CH: no escucho
12 CUTOF: se corta
DESCRIPCIÓN
ESPECIALES
MENSAJES
TELEFONOS INTERNOS
PAGINA
CENTRAL PRIVADA
AUTOMATICA
GOBIERNO
MONEDERO
COMERCIAL
RESIDENCIAL
SERVICIO 800
ALTA CAPACIDAD

Capítulo IV
Una vez ingresados los datos del reporte se debe presionar el botón Crear para
guardar los cambios. Si presionar ―Crear‖ el sistema preguntara si esta seguro de
la página de creación de incidente tipo circuito.
Si presiona el botón ―Salir‖ volverá a la pantalla de crear incidente tipo cliente.
posibilidades:


Capítulo IV

Capítulo IV
de error.
2. Existe Incidente: quiere decir que para el número de circuito y central

ingresados, existe un incidente con estatus abierto en la base de datos,
para lo cual se presentara la pantalla de visualización de incidente tipo
circuito. La funcionalidad de la visualización se describe más adelante.
3. Central no existe: si el número de central que se ingresa no existe en la

base de datos de SACAS se muestra un mensaje de error en la pantalla de
crear incidente tipo circuito.

Capítulo IV
mensaje de error.
4.1.2 Consultar Incidente
Se puede seleccionar varios tipos de búsqueda, por número de incidente o

teléfono, ultimo incidente, ultimo incidente por área de trabajo y mi lista de
incidentes.
4.1.2.1 Consultar incidente por número o Id
Un incidente puede ser visualizado a través de la búsqueda por número de

teléfono o incidente

Capítulo IV
Figura 46. Consultar incidente por número o Id
4.1.2.1.1 Por número de incidente
Para realizar una búsqueda por número de incidente se debe especificar el

número de incidente que se desea buscar.
Al presionar el botón ―Visualizar‖ se pueden presentar las siguientes

posibilidades:
1. Existe el incidente: quiere decir que existe el incidente para el número que
se ingresó, por lo cual se muestra la pantalla con los datos del reporte de
la siguiente manera:
Datos del incidente: muestra información del incidente

Capítulo IV

Datos del reporte: información del incidente.
Los campos que se presenta en la pantalla son:

Ciudad: campo de lectura que describe la ciudad de donde se esta
del teléfono.
Comentario: campo de lectura donde se coloca alguna observación que la

Capítulo IV
Con servicio: campo de lectura donde se coloca si la línea presenta

servicio o no.
Enrutar a: campo de lectura donde se selecciona a que área de trabajo se
Estatus: campo de lectura que describe el estatus del incidente. Los
posibles estatus son:
1- En proceso
2- Pendiente
3- Cerrado
4- Asignado
Fecha hora compromiso: campo de lectura que define la fecha la cual el
Fecha hora cita: campo de lectura que define la fecha de visita al cliente.
Fecha del Incidente: campo de lectura que indica la fecha de creación del
incidente.
Horas de gestión: campo de lectura que indica las horas que lleva el
incidente gestionándose.
Info 1: campo de lectura abierto.
Info 2: campo de lectura abierto.
Localización: campo de lectura que indica la localización del incidente y el

Capítulo IV

teléfono.
Origen del reporte: campo de lectura donde se selecciona el origen de
donde esta creando el reporte. Los posibles valores son:
5 - OPR (Operator)
7 - PRESSURE.
Persona que Reporta: campo de lectura que describe la persona que
reporto la falla.
Problema reportado: campo de lectura abierto que describe el problema
servicio crítico.
Resultado del test: campo de lectura donde se coloca el resultado de la
Teléfono contacto: campo de lectura donde se coloca un numero de
Tipo problema: campo de lectura donde se selecciona el tipo de problema
08 PHYS: físico
09 NOISE: ruido
10 CH: no escucho

Capítulo IV
12 CUTOF: se corta
DESCRIPCIÓN
ESPECIALES
MENSAJES
TELEFONOS INTERNOS
PAGINA
CENTRAL PRIVADA
AUTOMATICA
GOBIERNO
MONEDERO
COMERCIAL
RESIDENCIAL
SERVICIO 800
ALTA CAPACIDAD

Esta pantalla tiene las siguientes funcionalidades:
1. Modificar Incidente: para realizar la modificación de los datos de un

reporte se debe presionar el botón Modificar y se muestra la pantalla.

Capítulo IV
Figura 48. Modificar incidente
En esta pantalla el usuario debe:

Modificar los datos del reporte. Los campos que pueden ser
modificables son:
o Comentario: campo opcional libre para colocar alguna
observación del incidente.
o Info 1 y 2: campo opcional abierto.
o Llamada subsiguiente: campo opcional que indica que el
cliente ha llamado de nuevo.
o Localización: campo opcional que indica la localización del
incidente y el cual puede ser utilizados por sistemas
externos como SAD WAP para colocar información propia
del incidente.
o Persona que reporta: campo opcional que describe el
nombre de la persona que reporto la falla.

Capítulo IV
o Resultado del test: campo opcional donde se coloca el

resultado de la prueba 4tel.
o Telf. Contacto: campo opcional donde se coloca el teléfono
donde se puede contactar al cliente.
Presionar ―Guardar‖, el sistema preguntara si está seguro de los

cambios a realizar, si se presiona aceptar se guardaran los
cambios, si presiona cancelar se vuelve a la pantalla de la
modificación.
Si se acepta la modificación del incidente se pueden presentar las siguientes

posibilidades:

Capítulo IV
 Incidente modificado: esto quiere decir que el incidente fue modificado

con éxito en la base de datos SACAS, en la pantalla se muestra el
mensaje de éxito.
 Error: esto quiere decir que ocurrió algún error inesperado en base de
datos o servicios y el sistema mostrara el mensaje de error.
2. Enrutar Incidente: para cambiar el área de trabajo de un incidente se

debe presionar el botón ―Enrutar‖ que muestra la siguiente pantalla

Capítulo IV
Figura 51. Enrutar incidente

Completar los datos para enrutar un incidente. Los campos son:
o Enrutar a: campo obligatorio donde se selecciona el área de
trabajo a donde se está enrutando el incidente.
o Comentario: campo opcional donde el usuario coloca alguna
observación al enrutar.
o Código de causa: campo obligatorio donde se selecciona
según el área de trabajo el código de causa del incidente.
o Subcódigo de causa: campo obligatorio donde se selecciona
según el código el subcódigo de causa del incidente.
Presionar ―Enrutar‖, el sistema preguntara si está seguro de realizar
la operación, si se presiona aceptar se guardaran los cambios, si
presiona cancelar volverá a la pantalla de enrutar.

Capítulo IV
Si se acepta el enrutamiento del incidente se pueden presentar las siguientes

posibilidades:
 Incidente enrutado: esto quiere decir que el incidente fue enrutado

con éxito en la base de datos SACAS, en la pantalla se muestra el
mensaje de éxito.

Capítulo IV
Presionar ―Salir‖, el sistema volverá a la pantalla de la consulta del

incidente.
3. Cerrar Incidente: para cerrar un incidente se debe presionar el botón

―Cerrar‖ que muestra la siguiente pantalla.

Capítulo IV
Figura 54. Cerrar incidente

Completar los datos del cierre de incidente. Los campos que se
ingresan son:
o Cliente notificado: campo obligatorio donde se selecciona si
fue notificado el cliente del cierre del incidente.
o Código causa: campo obligatorio donde se selecciona el
código de causa del incidente.
o Código cierre: campo obligatorio donde se selecciona el
código de cierre del incidente.
o Comentario: campo obligatorio donde se coloca alguna
observación del cierre del incidente.
o Falla común: campo opcional donde se coloca si la falla es
masiva.

Capítulo IV
o Subcódigo causa: campo obligatorio donde se selecciona el

subcódigo causa del incidente.
o Subcódigo cierre: campo obligatorio donde se selecciona el
subcódigo de cierre del incidente.
Presionar ―Cerrar‖, el sistema preguntara si está seguro de realizar
la operación, si se acepta se guardaran los cambios, si cancela
volverá a la pantalla de cerrar.
Si se acepta cerrar el incidente se pueden presentar las siguientes posibilidades:
 Incidente cerrado: esto quiere decir que el incidente fue cerrado con
éxito en la base de datos SACAS, en la pantalla se muestra el mensaje
de éxito.

Capítulo IV

incidente.
4. Asignar Incidente: para asignar una cuadrilla al incidente se debe

presionar el botón ―Asignar‖, este muestra la siguiente pantalla.

Capítulo IV
Figura 57. Asignar incidente

Completar los datos del despacho. Los campos que se ingresan
son:
o Asignado a: campo obligatorio donde se coloca la
identificación la cuadrilla o el usuario que atenderá el
incidente (el incidente puede ser asignado al mismo
usuario).
o Ayudante: campo opcional donde se van agregando los
integrantes de cuadrilla.
Presionar ―Asignar‖, el sistema preguntara si está seguro de realizar
la operación, si se acepta se guardaran los cambios, si cancela
volverá a la pantalla de asignar.

Capítulo IV
Si se acepta asignar el incidente se pueden presentar las siguientes

posibilidades:
 Incidente asignado: esto quiere decir que el incidente fue asignado con
de éxito.

Capítulo IV

incidente.
5. Escalar incidente: cuando se quiere escalar un incidente, se presiona el

botón ―Escalar‖, el sistema preguntara si está seguro de realizar la
operación, si se acepta se guardaran los cambios, si cancela volverá a la
pantalla de consulta de incidente.

Capítulo IV
Figura 60. Escalar incidente
Si se acepta escalar el incidente se pueden presentar las siguientes posibilidades:
 Incidente escalado: esto quiere decir que el incidente fue escalado con
de éxito.

Capítulo IV
Figura 61. Escalar incidente
6. Consultar Historia del Teléfono: para poder ver la historia del teléfono se
debe presionar hipervínculo que dice ―Historia del Teléfono‖, este muestra
la pantalla.

Capítulo IV
Figura 62. Consultar historia del teléfono
En esta pantalla el usuario puede ver la lista de los incidentes asociados al

teléfono. Para ver el detalle de un incidente se presiona el hipervínculo del
número de incidente y este mostrará la pantalla de visualización del incidente.
Si se presiona ―Atrás‖ el usuario vuelve a la consulta del incidente. O si presiona

Salir regresa a la pantalla principal de consultar por número de teléfono o id.
La historia del teléfono puede ser exportada presionando el hipervínculo

―Exportar Resultados‖ el cual muestra la pantalla para que el usuario seleccione
el nombre del archivo, los datos del reporte.

Capítulo IV
Figura 63. Exportar resultados
Una vez ingresado el nombre del archivo y los datos del reporte se presiona el
botón ―Exportar‖, y descargado el archivo se puede visualizar.
7. Consultar Historia del Incidente: para poder ver la historia del incidente se
debe presionar el hipervínculo que dice Historia del Incidente, este
muestra la pantalla.

Capítulo IV
Figura 64. Consultar historia del incidente
En esta pantalla el usuario puede ver una tabla que lista todas las modificaciones
y enrutamiento que ha tenido en el incidente.
Si se presiona Atrás el usuario vuelve a la consulta del incidente. O si presiona

Salir regresa a la pantalla principal de consultar por número de teléfono o id.
La historia del incidente puede ser exportada presionando el hipervínculo

―Exportar Resultados‖ el cual muestra la pantalla para que el usuario seleccione
el nombre del archivo, los datos del reporte.

Capítulo IV
Figura 65. Exportar resultados
Una vez ingresado el nombre del archivo y los datos del reporte se presiona el
botón ―Exportar‖, y descargado el archivo se puede visualizar.
8. Salir: para salir del detalle del incidente se presiona Salir y volverá a la
pantalla de la consulta por número de teléfono o id.
2. No existe el incidente: quiere decir que el número de incidente que se

ingresó no existe en la base de datos de SACAS, por lo cual se muestra en
la pantalla un mensaje de error.

Capítulo IV
Figura 66. Consultar incidente por Id
mensaje de error.
4.1.2.1.2 Por número de teléfono o circuito
Otra manera de consultar un incidente es a través de su número de teléfono o

circuito. Para ello se debe especificar el número de teléfono o circuito.

Capítulo IV
Al presionar el botón Visualizar, se pueden presentar las siguientes posibilidades:
1. Existe incidente: quiere decir que para el número de teléfono o circuito

ingresado existe un solo incidente en la base de datos, por lo que se
muestra la pantalla con el detalle del reporte. La funcionalidad del
visualizar incidente esta descrita anteriormente.

Capítulo IV
Figura 68. Visualizar incidente
2. Existe más de un incidente: quiere decir que para el número de teléfono o

circuito ingresado existe más de un incidente en la base de datos, por lo
que se muestra la pantalla de histórico del teléfono donde se listan los
incidentes existentes. Para ver el detalle de un incidente se debe presionar
el hipervínculo del número del incidente. La funcionalidad del visualizar
anteriormente.

Capítulo IV
Figura 69. Histórico del teléfono o circuito
3. No existe incidente: quiere decir que el número de teléfono o circuito

ingresado no tiene ningún incidente asociado en la base de datos SACAS,
por lo cual se mostrara en la pantalla un mensaje de alerta al usuario que
indica si desea crear un incidente al número de teléfono o circuito
ingresado. Si se presiona aceptar se mostrara la página para creación de
incidente. Si presiona cancelar vuelve a la pantalla de consultar incidente
por numero o id.

Capítulo IV
Figura 70. Consultar Incidente
mensaje de error.
4.1.2.2 Último incidente
Un incidente también puede ser visualizado a través de la funcionalidad último

incidente.
Al presionar el hipervínculo ―Ultimo Incidente‖, se muestra la pantalla con la

visualización del incidente listo para ser modificado. El incidente que se muestra
es el último con estatus pendiente en el área de trabajo con la cual el usuario
inicio sesión, prioridad alta y más antiguo. La funcionalidad de la modificación

Capítulo IV
esta descrita en la visualización del incidente parte Modificar Incidente (pagina

40).
Figura 71. Último incidente
4.1.2.3 Último incidente por área de trabajo
El usuario también puede consultar el último incidente en un área de trabajo

determinada, para ello se debe especificar:
Área de trabajo: campo obligatorio donde se selecciona el área de
trabajo. Las áreas de trabajo que se listan son todas aquellas a las
cuales el usuario tiene permiso de ver.
Centro de despacho: campo obligatorio se selecciona el centro de
despacho.
Central: campo obligatorio donde se selecciona la central.

Capítulo IV
Figura 72. Último incidente por área de trabajo
Una vez ingresada el área de trabajo, centro de despacho y central se debe

presionar el botón ―Buscar‖. Se puede presentar las siguientes posibilidades:
1. Existe el incidente: esto quiere decir que para el área de trabajo, centro
de despacho y central seleccionada existe un incidente con estatus
pendiente, entonces aparece en la pantalla el último incidente listo para
ser modificado. La funcionalidad de la modificación esta descrita en la
visualización del incidente en su modificación.
2. No existe incidente pendiente: esto quiere decir que para los datos
ingresados no existe un incidente con estatus pendiente, por lo tanto en la
pantalla muestra un mensaje error.

Capítulo IV
Figura 73. Último incidente por área de trabajo
mensaje de error.
4.1.2.4 Mi lista de incidentes
Mi lista de incidentes muestra en una tabla, los incidentes que están asignados a
un usuario, este usuario es el que inicio sesión. La tabla muestra información
relevante del incidente como el número de teléfono, tipo de incidente, el tipo de
servicio, el problema reportado y el número de incidente que es un hipervínculo
que al presionar muestra el detalle del incidente. La funcionalidad de la consulta
del incidente por número de incidente esta descrita anteriormente.

Capítulo IV
Figura 74. Mi lista de incidentes

Capítulo IV
Procesos de Negocio BPM de SACAS

Proceso Primer Nivel
Permite atender el incidente e identifica el evento que lo genera, para realizar el

direccionamiento al proceso de negocio que le corresponda.
Nombre: ProcesoPrimerNivel
Propósito: Describe quienes pueden ser los iniciadores del proceso de Gestión de
Incidentes y además describe las actividades que se ejecutan manualmente por
el usuario, representa cómo se maneja el incidente en primera instancia, esto
quiere decir, que se hace la identificación, verificación de requerimiento,
diagnóstico inicial, consulta de base de datos de errores conocidos, realiza la
categorización, registra el incidente y por último se instancia el proceso
ejecutable de primer nivel que tiene como función determinar el proceso de
negocio al cual pertenece el incidente.
Figura 75. Diagrama BPM Proceso Primer Nivel

Capítulo IV
Descripción: Este proceso puede ser iniciado a través de: IVR, email, aplicación
web, eventos, SMS y otros. Posteriormente, se realiza la identificación del
elemento o dispositivo mediante el número telefónico, luego se verifica si ya
existe un incidente para este dispositivo, de ser así se realiza un proceso de
documentación donde se actualiza la información del incidente. En caso de ser
un nuevo incidente se clasifica en incidente o requerimiento, si es un
requerimiento se realiza un proceso de gestión de requerimiento (Ver
ProcesoGestionRequerimiento); de ser un incidente se procede a realizar un
diagnóstico inicial para determinar si se pude resolver en primer nivel (en el caso
de SACAS no se resuelven en el primer nivel, solo se registran), luego se hace
una consulta en una Base de Datos (BD) de errores conocidos, a continuación se
clasifica el incidente de acuerdo a diversos parámetros. En el caso de SACAS se
categoriza por: tipo de incidente, tipo de servicio y tipo de problema.
Posteriormente se realiza el registro del mismo en la BD, si el incidente es
resuelto en primer nivel se cierra, de no ser así se invoca el proceso de nivel 0,
para determinar a qué proceso de negocio corresponde.
En este proceso dada la categorización se instancia el proceso de negocio

correspondiente: Telefonía Básica, Telefonía Pública, CNE, Mantenimiento
Correctivo ABA, Provisión ABA, Mantenimiento Correctivo Telefonía Fija
Inalámbrica, Averías Masivas Telefonía Fija Inalámbrica y Proceso Genérico.
Proceso de Negocio de Telefonía Básica
Permite atender los incidentes inherentes a Telefonía Básica, con el fin de

resolverlo.
Nombre: ProcesoNegocioTelefoniaBasica

Capítulo IV
Propósito: Describe las actividades que son propias del negocio de telefónica
básica para la resolución del incidente. Este proceso expone el servicio
IniciarProcesoNegocioTB que instancia el proceso de negocio (tiene como
parámetro el número de incidente). Además, el proceso de negocio invoca el
servicio de IniciarProceso_ResolucionIncidente.
Figura 76. Diagrama BPM Proceso de Telefonía Básica
Descripción: El inicio de este proceso es mediante un mensaje que informa que

hay un incidente en el área de Telefonía Básica, luego este proceso realiza un
llamado al proceso de Gestión de incidente (Ver procesoGestiónIncidentes) para
que sea atendido y posteriormente se recibe por parte del proceso de Gestión de
Incidentes una notificación con el estado del incidente (En SACAS debe ser
cerrado) finalizando así este proceso.

Capítulo IV
Proceso de Negocio de Telefonía Pública
Permite atender los incidentes inherentes a Telefonía Pública, con el fin de

resolverlo.
Nombre: ProcesoNegocioTelefoniaPublica
Propósito: Describe las actividades que son propias del negocio de telefónica
publica para la resolución del incidente. Este proceso expone el servicio
IniciarProcesoNegocioTP que instancia el proceso de negocio (tiene como
Figura 77. Diagrama BPM Proceso de Negocio de Telefonía Pública

Capítulo IV

hay un incidente en el área de Telefonía Pública, luego este proceso realiza un
Proceso de Negocio CNE
Permite atender los incidentes inherentes al proceso del CNE, con el fin de
resolverlo.
Nombre: ProcesoNegocioCNE
Propósito: Describe las actividades que son propias del negocio para la
resolución del incidente relacionados con el CNE. Este proceso expone el servicio
IniciarProcesoNegocioCNE que instancia el proceso de negocio (tiene como

Capítulo IV
Figura 78. Diagrama BPM Proceso de Negocio de CNE

hay un incidente en el proceso de CNE, luego este proceso realiza un llamado al
proceso de Gestión de incidente (Ver procesoGestiónIncidentes) para que sea
atendido y posteriormente se recibe por parte del proceso de Gestión de
Proceso de Negocio ABA
Existen dos procesos para el negocio ABA, uno para el mantenimiento correctivo
de incidentes ABA y otro para la provisión del servicio ABA.
Proceso de Negocio Mantenimiento Correctivo ABA
Nombre: ProcesoMantenimientoCorrectivoABA

Capítulo IV
Propósito: Describe las actividades que son propias del negocio de

mantenimiento correctivo ABA, para la resolución del incidente. Este proceso
expone el servicio IniciarProcesoMantenimientoCorrectivoABA que instancia el
proceso de negocio (tiene como parámetro el número de incidente). Además, el
proceso de negocio invoca el servicio de IniciarProceso_ResolucionIncidente.
Figura 79. Diagrama BPM Proceso de Negocio de Mantenimiento

Correctivo ABA

hay un incidente en el área de Mantenimiento correctivo ABA, luego este proceso
realiza un llamado al proceso de Gestión de incidente (Ver
procesoGestiónIncidentes) para que sea atendido y posteriormente se recibe por
parte del proceso de Gestión de Incidentes una notificación con el estado del
incidente (En SACAS debe ser cerrado) finalizando así este proceso.
Proceso de Negocio Provisión ABA

Capítulo IV
Nombre: ProcesoProvisionABA
Propósito: Describe las actividades que son propias del negocio de provisión del
servicio ABA para la resolución del incidente. Este proceso expone el servicio
IniciarProcesoProvisionABA que instancia el proceso de negocio (tiene como
Figura 80. Diagrama BPM Proceso de Negocio de Provisión ABA

hay un incidente en el área de Provisión ABA, luego este proceso realiza un
Proceso de Negocio de Telefonía Fija Inalámbrica

Capítulo IV
Existen dos procesos para el negocio telefonía inalámbrica, uno para el

mantenimiento correctivo TFI y otro para las averías masivas TFI.
Proceso de Negocio Mantenimiento Correctivo TFI

Nombre: ProcesoMantenimientoCorrectivoTFI
Propósito: Describe las actividades que son propias del negocio de
mantenimiento correctivo TFI para la resolución del incidente. Este proceso
expone el servicio IniciarMantenimientoCorrectivoTFI que instancia el proceso de
negocio (tiene como parámetro el número de incidente). Además, el proceso de
negocio invoca el servicio de IniciarProceso_ResolucionIncidente.
Figura 81. Proceso de Negocio Mantenimiento Correctivo TFI

hay un incidente en el área de Mantenimiento Correctivo Telefonía Fija
Inalámbrica, luego este proceso realiza un llamado al proceso de Gestión de
incidente (Ver procesoGestiónIncidentes) para que sea atendido y
posteriormente se recibe por parte del proceso de Gestión de Incidentes una

Capítulo IV
notificación con el estado del incidente (En SACAS debe ser cerrado) finalizando
así este proceso.
Proceso de Negocio Averías Masivas TFI
Nombre: ProcesoNegocioMasivasTFI
Propósito: Describe las actividades que son propias del negocio de averías
masivas TFI para la resolución del incidente. Este proceso expone el servicio
IniciarProcesoNegocioMasivasTFI que instancia el proceso de negocio (tiene
como parámetro el número de incidente). Además, el proceso de negocio invoca
el servicio de IniciarProceso_ResolucionIncidente.
Figura 82. Proceso de Negocio Averías Masivas TFI

hay un incidente en el área de Averías Masivas Telefonía Fija Inalámbrica, luego
este proceso realiza un llamado al proceso de Gestión de incidente (Ver

Capítulo IV
Proceso de Negocio Genérico
Permite atender el incidente el cual no corresponde a ninguno de los procesos de

negocios descritos anteriormente, con el fin de resolverlo.
Nombre: ProcesoNegocioGenerico
Propósito: Describe las actividades genéricas para los procesos de negocio que
no se han identificado para SACAS. Este proceso expone el servicio
IniciarProcesoNegocioGenerico que instancia el proceso de negocio (tiene como
parámetro el número de incidente). Además, el proceso de negocio invoca la
tarea de IniciarProceso_ResolucionIncidente.
Figura 83. Diagrama BPM Proceso de Negocio Genérico

hay un incidente en el área de Proceso de Negocio general, luego este proceso
realiza un llamado al proceso de Gestión de incidente (Ver

Capítulo IV
Proceso de Gestión de Incidente
Permite atender el incidente, el cual corresponde a alguno de los procesos de

negocios descritos anteriormente, con el fin de resolverlo.
Nombre: ProcesoGestionIncidente
Propósito: Describe las actividades que se realizan después de que el incidente
esté registrado en la base de datos, y son ejecutadas por el proceso a través de
la invocación de servicios.
Figura 84. Diagrama BPM Proceso de Gestión de Incidente
Descripción: Al iniciar este proceso lo primero que se hace es una priorización del
incidente, esto mediante la consulta de una tabla de decisión en la BD, luego de
esto se calcula el tiempo de escalamiento dependiendo del tipo de incidente, a

Capítulo IV
continuación se invoca un servicio que notifica si existe un posible incidente

mayor.
Si la respuesta es afirmativa se invoca al proceso de incidentes mayores (Ver

ProcesoIncidenteMayores) para que sea atendido este tipo de incidente y al ser
solventado el incidente mayor se cierran todos los incidentes relacionados con el
mismo.
Si no es un incidente mayor, el incidente queda en estatus pendiente y se espera

por que ocurra uno de los siguientes eventos:
Si el incidente no es tratado antes del tiempo de escalamiento, el incidente

automáticamente se marca como escalado, y en este momento se determina a
quien se le enviará la información correspondiente a un supervisor, en este caso
se ejecutará un ciclo para atender los incidentes escalados. Cuando el supervisor
toma el incidente escalado, realiza una investigación y diagnóstico, luego de
estas operaciones puede tomar una de las siguientes 4 opciones.
Resolver el incidente y se cerrar el mismo.

Escalar en forma jerárquica, es decir, a un nivel superior y el incidente repetiría
los pasos de un incidente escalado.
Decidir que el incidente debe ser enviado a un área resolutoria de segundo nivel,
para ser resuelto por esta.
Escalar funcionalmente, es decir, enviar el incidente a un área de trabajo (cola)
diferente.
Al salir del ciclo que atiende incidentes escalados se verifica si:
El incidente ya fue atendido por el supervisor y está cerrado.

Capítulo IV
El supervisor envío el incidente a un área resolutoria de segundo nivel, para ser

atendido.
Volvió a escalar en forma jerárquica el incidente, en este caso se debe
determinar a quién va dirigida esta escalación y luego se marca el incidente
como escalado de nuevo.
En cualquiera de los casos anteriores, en que no se cerró el incidente, se efectúa

un nuevo cálculo de tiempo para resolver el incidente y se vuelve al principio de
este proceso.
Si el incidente fue cerrado retorna al proceso de negocio que invoco el proceso

de Gestión de incidentes, para notificar y culminar el proceso.
Si el incidente es tomado dentro del tiempo de atención se pasa aun ciclo de

atención de incidentes (Subproceso de gestión incidentes en segundo nivel), se
realiza la investigación y diagnóstico, a continuación se consulta en la BD de
errores conocidos si este incidente ya tiene una solución ya aplicada
anteriormente con buenos resultados. Luego con toda la información que se
obtuvo anteriormente se pueden tomar tres decisiones:
Se puede solucionar el incidente y salir del ciclo de atención de incidentes.

Se puede escalar jerárquicamente el incidente a un superior ya sea por
requerirse materiales o por no poder solucionar el incidente, entre otras. Y se
sale del ciclo de atención de incidentes.
También se pude hacer una escalación funcional que no es más que enrutar el
incidente pasándolo a otra área de trabajo (cola) y se repite este ciclo, hasta
tanto el mismo sea resuelto o escalado jerárquicamente.
Al salir del ciclo anterior se valida si el incidente fue escalado, de ser así sigue los
pasos mencionados anteriormente para un incidente escalado, por otro lado si no

Capítulo IV
fue escalado quiere decir que ya fue resuelto por lo que fue cerrado y se culmina
este proceso, enviando un mensaje al proceso de negocio que lo invoco.
Proceso de Incidentes Mayores
Permite atender el incidente, el cual fue identificado por el Proceso de Gestión de

Incidente, con el fin de resolverlo.
Nombre: ProcesoIncidenteMayores
Propósito: Describe las actividades que se realizan cuando se detecta un
incidente mayor o masivo.
Figura 85. Diagrama BPM Proceso de Incidentes Mayores
Descripción: Cuando se inicia este proceso se presume que hay un incidente

mayor, por lo cual lo primero que se realiza es una notificación al centro de
servicio (CDS) por una posible falla masiva, cuando llega esta notificación al CDS
el mismo envía al supervisor la información. El supervisor realiza la verificación
del elemento con falla y toma la decisión si existe realmente una falla masiva, de
no ser así realiza una notificación de que no es un incidente mayor y el mismo
continua su tratamiento normal (Ver ProcesoGestiónIncidentes). Si el superviso

Capítulo IV
detecto que es un incidente mayor, hace una llamada al Centro de Operaciones

Red (COR) notificando la falla masiva, el COR crea el incidente de averías
masivas y luego se le notifica al CDS. El CDS crea el incidente masivo en el
Sistema de Mantenimiento de Planta (SMP), a continuación se verifica si esta
avería requiere material, de ser así se crea un ticket en Nettrip y se notifica al
CDS de este incidente mayor. Culminado así el proceso de incidentes mayores.

Conclusiones y Resultados
CONCLUSIONES Y RESULTADOS
Para realizar la modelación del proceso de gestión de control de averías y

servicios de manera efectiva, se construyó este proceso con una
herramienta que aporte altos niveles de calidad y beneficios. Esta
herramienta es Intalio BPM Community, la cual es un BPM que
implementa SOA y está bajo licencia de Software libre, de esta forma se
puede concluir que se cumplió a cabalidad con los objetivos específicos
planteados en el aparte de la solución. Debido a que:
o Intalio BPM, proporciona un entorno de desarrollo basado en web

services que permite ejecutar componentes de procesos de negocio
manera estandarizada.
o Su enfoque hacia los estándares de BPM y sus características de

―open source‖, le proporciona a Intalio una arquitectura altamente
operativa al momento de modelar procesos de negocios.
o La integración de Intalio con otras herramientas software libre

como Liferay, Alfresco, Apache, Eclipse y MySQL, brinda un
software de modelado de procesos 100% confiable y adaptable.
o Además provee de componentes importantes para el diseño,

despliegue y gestión de la mayoría de procesos de negocio
complejos (BAM, BRE, ECM, ESB, Portal).
En resumen, el proceso de gestión de control bajo el código de buenas

prácticas y modelado Intalio BPM, proporciona excelentes beneficios en el
sistema que se vaya a establecer, un ejemplo es SACAS.

Conclusiones y Resultados
Actualmente, SACAS se encuentra siendo utilizado en la empresa CANTV,

ya con un tiempo de 3 años desde su puesta en producción, dicho sistema ha ido
creciendo en sus funcionalidades.

Recomendaciones
RECOMENDACIONES
El sistema SACAS fue diseñado para ser utilizado por personas con
conocimientos en el área de computación. Por lo que es importante divulgar
entre estos todo el conocimiento necesario para poder utilizar el sistema.
El sistema se encuentra desarrollado de tal forma que cumple con los

objetivos y requerimientos planteados en un inicio por el usuario, pero una vez
mostrado a otros usuarios estos realizaron sugerencias de funcionalidades
adicionales que permitan un mejor funcionamiento y que los usuarios puedan
explotar al máximo las cualidades del sistema. Entre las recomendaciones se
encuentra:
Incluir reportes.
Agregar la tickera para la distribución y fácil manejo de cada una de las

cuadrillas.
Módulo administrativo para la configuración de cada una de las tablas

configuradas de SACAS.
Módulo de seguridad para la configuración de los perfiles, roles y

permisos.
Adicionalmente este es uno de los sistemas más estables desarrollado bajo

BPM SOA en CANTV, por lo que se recomienda publicar los resultados
académicamente en alguna conferencia o revista de sistemas de
información.

Referencias
REFERENCIAS
[1] Desarrolloweb.com, Introducción a los lenguajes del Web, Manual de

JSP, http://www.desarrolloweb.com/articulos/831.php
[2] Wikilibros, Programación en JAVA, características del lenguaje

https://es.wikibooks.org/wiki/Programaci%C3%B3n_en_Java/Caracter%C3%ADs
ticas_del_lenguaje
[3] Coulouris G, Dollimore J, Kindberg T. (2001). Sistemas Distribuidos

Conceptos y Diseño. Tercera Edición. PEARSON EDUCACIÓN, S.A., Madrid,
España.
[4] Fielding, Roy. (2000). Architectural Styles and the Design of the
Network-based Software Architectures. Universidad de Califormia, Irvine.
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
[5] Chinthaka, Eran (2006). Web services and Axis2 architecture .

http://www.ibm.com/developerworks/webservices/library/ws-
apacheaxis2/#N10239.
[6] Garimella Kiran, L. M. (2008). Introducción a BPM para Dummies.

Indianápolis, Indiana: Wiley Publishing, Inc.
[7] López, E. G. (2013). BPMN Estándar para modelar procesos de

negocio. INNOTEC Gestión, 60.
[8] Krafzig, D. B. (2004). Enterprise SOA: Service – Oriented Architecture

Best Practices. Pearson Education.
[9] Newcomer, E. y. (2004). Understanding SOA with Web Services.

Pearson Education.

Lecturas Recomendadas
Bibliografía
Abreo, Rene y Windle, Daniel R. Software Requirements Using the Unified

Process. Prentice Hall. 16 Agosto 2002.
Alhir, Sinain Si. Understanding the Unified Process (UP). Febrero 2001.Extraído el
7 de Noviembre de 2008 de:
http://www.methodsandtools.com/archive/archive.php?id=32
Barros, Oscar. Reingeniería de Procesos de negocio. Editorial Dolmen, Chile,

1994.
Bonillo, Pedro. Evaluación de Arquitecturas de Gerencia de Procesos de Negocio.

ASOVAC 2005.
Booch, Jacobson, Rumbaugh. El proceso unificado del desarrollo de software.

(Capítulos 4, 5, 6 y 7). Págs. 64. 123.
Haren, Van. Mejora Continua del Servicio basada en ITIL V3: Guía de Gestión.
Colección Best Practice. Págs. 57-58 (2004)
G. Alonso, F. Casati, H. Kuno, and V. Machiraju. Web Services. Concepts,

Architectures and Applications. Springer, 2004.
Jorge Humberto Arias B. SOA: ¿Sólo un estilo de arquitectura más o una burbuja
en evolución?, 2001.
J. A. Fisteus, C. D. Kloos, and A. M. L´opez. Modelo formal para la verificación de

procesos de negocio. In Actas del III Congreso Iberoamericano de Telemática
(CITA 2003), Montevideo, Uruguay, Octubre 2003.
J. Pasley. How BPEL and SOA are changing Web services development. IEEE
Internet Computing, 9(3):60–67, May-June 2005.
Krafzig, D. et al., 2004. Enterprise SOA: Service-Oriented Architecture Best

Practices. Prentice Hall, UK.
Pin, Enrique y Delgado Marrero, Yoalis María. Indicadores, una herramienta para
medir la Eficiencia en el uso de las Tecnologías de la Información y las
Comunicaciones en los Centros de Educación Superior. Universidad de LA
Habana. 2006

Lecturas Recomendadas
Rabih Kraidli. Understanding the Unified Process (UP) - Part 1. 29 de Marzo de

2007. Extraído el 14 de Noviembre de 2008 de:
http://aspalliance.com/1222_Understanding_the_Unified_Process_UP__Part_1.all
Thomas Erl. Service-Oriented Architecture: Concepts, Technology and

Design. Editorial: Prentice-Hall, Año: 2005.
WorldWideWeb Consortium. Web Services Glossary, February 2004. W3CWorking

Group Note.
White Papers
ITIL y la Norma ISO/IEC 20000. Alfredo Zayas de Glynx. Mexico.
Pekka Helkiö, Antti Seppälä y Ossi Syd. Evaluation of Intalio BPM Tool. Special
Course in Information System Integration.
Marcos de referencia para la gestión de TI. Eduardo Poggi. Argentina. Julio 2006.
10 Best Practices for Reducing the Stress of IT Audits. Quest Software Inc. Alison
Viejo, California, USA.
Infografía
BPMN vs. UML, By Ismaël Ghalimi, Chief Strategy Officer, Intalio

(www.intalio.com) — September 2002
E. Christensen, F. Curbera, G. Meredith, and S.Weerawarana. Web Services

Description Language Version 1.1. W3C Note 15 March 2001. WorldWideWeb
Consortium, 2001. Available at http://www.w3.org/TR/2001/NOTE-wsdl-
20010315.
Fundamentos de Gestión de Servicios de TI de Osiatis, disponible en:

http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/fundamentos_de_la_gestion
_TI/vision_general_gestion_servicios_TI/vision_general_gestion_servicios_TI.php
Business Process Management Initiative (BPMI). Business Process Modeling

Notation (BPMN). Version 1.0 - May 3, 2004. www.BPMI.org
ITIL y la Mesa de Ayuda, disponible en: http://www.dric.com.mx/help-desk/itil-y-

la-mesa-de-ayuda.html

Sistema Automatizado de Control de Averías de Servicio (SACAS)

Cargado por

Copyright:

Formatos disponibles

Sistema Automatizado de Control de Averías de Servicio (SACAS)

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistema Automatizado de Control de Averías de Servicio (SACAS)

Cargado por

Copyright:

Formatos disponibles

Resumen

Universidad Central de Venezuela

Sistema de Gestión Automatizada de Control de Averías de Servicio

Trabajo Especial de Grado

Edwin Alberto Abreu Silva

Para optar por el título de Licenciado en Computación

Caracas, 22 de mayo de 2017