Sunteți pe pagina 1din 178

REPBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA


EDUCACIN SUPERIOR
UNIVERSIDAD NACIONAL EXPERIMENTAL
RMULO GALLEGOS
REA DE INGENIERA DE SISTEMAS
ESCUELA DE INGENIERA EN INFORMTICA

SISTEMA WEB PARA EL SEGUIMIENTO DE REPARACIONES DE


AVERAS TELEFNICAS DEL DEPARTAMENTO DE UNIDAD DE
SEGUIMIENTO (USE) DE CANTV, SAN JUAN DE LOS MORROS ESTADO
GURICO.
Trabajo de grado para optar al ttulo de Ingeniero en Informtica

Autor:
Tutor Acadmico:

Ibarra Guerrero, Joel Rafael


Ing. Miguel Padrn

San Juan de Los Morros, Julio de 2014.

REPBLICA BOLIVARIANA DE VENEZUELA


MINISTERIO DEL PODER POPULAR PARA LA
EDUCACIN SUPERIOR
UNIVERSIDAD NACIONAL EXPERIMENTAL
RMULO GALLEGOS
REA DE INGENIERA DE SISTEMAS
ESCUELA DE INGENIERA EN INFORMTICA

SISTEMA WEB PARA EL SEGUIMIENTO DE REPARACIONES DE


AVERAS TELEFNICAS DEL DEPARTAMENTO DE UNIDAD DE
SEGUIMIENTO (USE) DE CANTV, SAN JUAN DE LOS MORROS ESTADO
GURICO.
Trabajo de grado para optar al ttulo de Ingeniero en Informtica

Autor:
Tutor Acadmico:

Ibarra Guerrero, Joel Rafael


Ing. Miguel Padrn

San Juan de Los Morros, Julio de 2014.

Repblica Bolivariana de Venezuela


Ministerio del Poder Popular Para la Educacin Universitaria
Universidad Nacional Experimental Rmulo Gallegos
rea de ingeniera de Sistemas
Escuela de ingeniera en informtica

APROBACION DEL TUTOR ACADMICO

En mi carcter de Tutor del Trabajo Especial de Grado, Presentado por


el Bachiller JOEL RAFAEL IBARRA GUERRERO titular de la Cedula de
Identidad Nro. 20.522.569 para optar al Ttulo de INGENIERO EN
INFORMATICA, considero que dicho trabajo el cual tiene por ttulo:
SISTEMA WEB PARA EL SEGUIMIENTO DE REPARACIONES DE
AVERAS TELEFONICAS DEL DEPARTAMENTO DE UNIDAD DE
SEGUIMIENTO (USE) DE CANTV, SAN JUAN DE LOS MORROS ESTADO
GUARICO rene los requisitos y mritos suficientes para ser sometidos a la
presentacin pblica y evaluacin por parte del jurado examinador que se
designe.
En la Ciudad de San Juan de Los Morros, a los 14 das del mes de Julio
de 2014.

______________________
Ing. Miguel Padrn
C.I.: 9.883.255.

REPBLICA BOLIVARIANA DE VENEZUELA


UNIVERSIDAD NACIONAL EXPERIMENTAL
RMULO GALLEGOS
REA DE INGENIERA DE SISTEMAS
ESCUELA DE INGENIERA EN INFORMTICA
SISTEMA WEB PARA EL SEGUIMIENTO DE REPARACIONES DE
AVERAS TELEFNICAS DEL DEPARTAMENTO DE UNIDAD DE
SEGUIMIENTO (USE) DE CANTV, SAN JUAN DE LOS MORROS ESTADO
GURICO.
Autor:
Tutor:
Fecha:

Ibarra Guerrero, Joel Rafael


Ing. Miguel Padrn
Julio de 2014

Resumen
El propsito de la presente investigacin, es el desarrollo de una aplicacin
web, para el seguimiento de las reparaciones de averas telefnicas que
maneja el departamento de Unidad de Seguimiento (USE) de CANTV, San
Juan de Los Morros, Estado Gurico, buscando sistematizar los procesos
manuales para mejorar su productividad, tiempo de respuesta y toma de
decisiones. Para ello, el presente trabajo se fundament en la experiencia del
tesista como antiguo miembro de la USE. La obtencin y el manejo de los
datos se realizo a travs de la observacin directa y la experiencia del
tesista. Durante el desarrollo de este proyecto se utilizaron dos enfoques
metodolgicos: el enfoque UWE (UML-based Web Engineering) y el enfoque
estructural Top-Down del Ing. Leonel Jimnez de la Universidad Rmulo
Gallegos (2013). El anlisis de la situacin actual y propuesta del producto
tecnolgico, se realizo mediante la aplicacin de distintas tcnicas de
diagramacin UML embebidas en la metodologa UWE. Para el diseo se
utilizo lenguaje de marcado HTML5, lenguaje de programacin PHP, tcnicas
AJAX, gestor de base de datos MySQL y hojas de estilo en cascada CSS,
obteniendo como resultado un sistema que permite el buen uso del tiempo
dedicado al seguimiento de las reparaciones de averas, contribuyendo en la
toma de decisiones fundamentales para la empresa.
Descriptores: Aplicacin web, sistema web, averas, gerencia red Gurico,
CANTV, helpdesk, seguimiento de reparaciones.

DEDICATORIA

Primeramente a Dios, por permitirme tener la fuerza de voluntad para


culminar este gran paso que estoy dando.
A mi abuela Rosa Cristina Delgado, merecedora de todo lo bueno de
este mundo, apoyo incondicional y compresin absoluta. A ti abuela, porque
desde siempre me apoyaste en todas mis decisiones, a ti porque te amo y
eres uno de mis principales pilares y fuentes de inspiracin. Este ttulo te
pertenece!
A mi madre, Debbie Rosa Guerrero Delgado, por ser aquella mujer de
carcter que siempre ha sabido guiarme e inspirarme de manera muy
certera. Con toda su ayuda, comprensin, amor de madre y con mucha
humildad me ha erguido como el hombre que soy hoy. Gracias Becla.
A mi padre, Jos Celestino Ibarra, influyente de mi camino por
naturaleza. Tu apoyo, tu veracidad y tus directrices siempre supieron
orientarme a ser cada da mejor. Por ti y para ti Cheo.
A mis hermanos y familiares, que de una u otra forma me apoyaron en
el caminar de este trayecto.
A mis amigos, los que an permanecen y los que no. Los que creyeron
en mi y se mantuvieron a mi lado brindndome su amistad y apoyo.
Y por ltimo, a todos aquellos que me han influenciado en la
culminacin de este trayecto.

Mil Gracias a todos! Se les quiere!

AGRADECIMIENTOS

En especial a Dios Todopoderoso, por escuchar todas mis dudas,


mostrarme que si se puede lograr lo que nos proponemos, y por siempre
mantenerte presente.
A la Universidad Rmulo Gallegos, por recibirme, guiarme, influir, y
demostrarme que todo en la vida, con esfuerzo, empeo y dedicacin tiene
su recompensa.
A mi amiga incondicional, Karla Marina Gonzales Molina de Itriago
Guaimaran, por siempre estar a mi lado, por ser mi hermana, mi compaera,
mi consejera, mi escucha. A ti Karla, muchsimas gracias. Te quiero amiga!
A todos aquellos profesores que conoc en el transcurso del desarrollo
de cada materia, en especial a mi tutor acadmico Miguel Padrn, por
recibirme como tesista y encaminarme en la bsqueda de mi destino, as
como tambin a la Prof. Adrienne Rangel, Shirley Suarez, Yusara Reina,
Johyce Navas, Aholimar Hernndez, Alejandro Garca, Gregory Snchez,
Soleidy Pea, entre muchos otros.
A mi Jefe, Jonathan Jos Torres Alvelaez, y a su hermosa esposa,
Deyanira Marrero, a ustedes dos los quiero demasiado, gracias por todo ese
apoyo incondicional. As como tambin agradezco a toda la familia CANTV,
que desde siempre, me recibieron con agrado y me acobijaron como uno de
los suyos. A usted Seor Tocayo, Darmelys Villanueva y Eva Lamon, todos
ustedes son maravillosos. Su amistad vale oro.
A Armando Prez Cabarcas, por ser aquella persona que no dudo en
ponerme las cartas sobre la mesa y mostrarme que el presente solo dura 7
segundos. Gracias Armando.
iMuchas gracias a todos!

INDICE GENERAL
Indice de cuadros .....vi
Indice de figuras...vii viii
Indice de graficos ..ix
Introduccion

INDICE CUADROS
Cuadro Nro. 01 Flujo de Informacin del Sistema Actual....50-51
Cuadro Nro. 02 Tabla de Campos de Datos del Sistema Actual...66-68
Cuadro Nro. 03 Tabla de Requerimientos del Sistema Propuesto.77-84
Cuadro Nro. 04 Descripcin del Modelo UML....84
Cuadro Nro. 05 Tabla de Campos de Datos del Sistema Propuesto.90-94
Cuadro Nro. 06
Cuadro Nro. 07

ix

INDICE FIGURAS
Figura Nro. 01 Procesos del Sistema Actual..43
Figura Nro. 02

Entrega de Reportes Diarios de Averas y Mtodos de

Seguimiento..48
Figura Nro. 03 Proceso de Recepcin de Averas del Sistema Actual53
Figura Nro. 04 Proceso de Solicitud de Enrutamiento del Sistema Actual55
Figura Nro. 05 Proceso de Solicitud de Actualizacin del Sistema Actual57
Figura Nro. 06 Proceso de Direccin Imprecisa del Sistema Actual59
Figura Nro. 07 Proceso de Cancelar Averas del Sistema Actual61
Figura Nro. 08 Proceso de Verificacin de Averas del Sistema Actual.63
Figura Nro. 09 Diagrama de Actividades del Sistema Actual.65
Figura Nro. 09

Diagrama de Caso de Uso General del Sistema

Propuesto85
Figura Nro. 10 Diagrama de Caso de Uso de la Relacin entre Actores del
Sistema Propuesto...86
Figura Nro. 11 Diagrama de Caso de Uso del Usuario Administrador del
Sistema Propuesto...87
Figura Nro. 12 Diagrama de Caso de Uso del Usuario Ejecutivo del Sistema
Propuesto..88
Figura Nro. 13 Sujetos que Interactan en el Producto Tecnolgico
Propuesto..89
Figura Nro. 14 Diagrama Entidad Relacin del Sistema Propuesto95
Figura Nro. 15 Esquema Lgico de la Base de Datos del Sistema Propuesto
96
Figura Nro. 16 Diagrama de Navegacin del Sistema Propuesto97

Figura Nro. 17 Interfaz abstracta de sesin de usuarios del sistema


propuesto.
Figura Nro. 18 Interfaz abstracta de la pgina principal del sistema
propuesto.
Figura Nro. 19 Diagrama de clases del sistema propuesto.

xi

INDICE DE GRAFICOS

xii

INTRODUCCIN

Existen infinidades de antecedentes que propagan ideas, sugerencias


y tcnicas para ayudar a los ejecutivos a tener una mejor administracin
gerencial. La mayor parte de estas ideas son de inters, sin embargo tanta
informacin puede llegar a ser abrumadora para algunos.
Cuando una empresa sobrevive y crece la supervisin de las
actividades relacionadas con ella, nace la necesidad emplear tcnicas
administrativas que sustenten el desarrollo de las misma, pero que no
siempre arrojan los resultados esperados.
Es indiscutible que el proceso administrativo de cualquier

gerencia

comprende actividades iterrelacionadas de planificacin, organizacin,


direccin y control de todas las actividades, que implican relaciones humanas
y tiempo, por lo que el elemento humano y la tecnologa cumplen un papel
fundamental dentro de cualquier gestin administrativa .Por esta razn las
tecnologas de la informacin han sido conceptualizadas como la integracin
y convergencia de la computacin, las telecomunicaciones y la tcnica para
el procesamiento de datos, donde sus principales componentes son: el factor
humano, los contenidos de la informacin, el equipamiento, la infraestructura,
el software y los mecanismos de intercambio de informacin adems de los
recursos financieros.
Los componentes anteriores, se establecen como los protagonistas del
desarrollo informtico en una organizacin, tanto para su desarrollo como
para su aplicacin, adems se reconoce que las tecnologas de la
informacin constituyen el ncleo central de una transformacin que
experimenta la economa y la sociedad.
13

Nuestros das se caracterizan por un explosivo y colosal desarrollo de


la tecnologa, y su aplicacin cada vez ms extensa a todos los mbitos de la
vida humana. Las nuevas tecnologas de la informacin han permitido la
rpida difusin de los conocimientos cientficos, contribuyendo sin lugar a
dudas a la introduccin de nuevas tcnicas en el desarrollo de la produccin
material y los servicios.
Una de estas tcnicas son los sistemas los han cambiado la forma en
que operan las

organizaciones actuales. A travs de su uso, se logran

importantes mejoras, pues automatizan los procesos operativos, suministran


una plataforma de informacin necesaria para la toma de decisiones y, lo
ms importante, su implantacin logra ventajas competitivas, entendindose
que estos son

un conjunto de elementos que interactan entre s y

conforman un todo con el fin de apoyar las actividades de una empresa o


negocio, es decir, obtienen, procesan, almacenan y distribuye informacin
para apoyar la toma de decisiones y el control en una organizacin.
Proporcionar informacin en respuesta a rdenes, solicitudes o
mandatos originados por una autoridad legislativa o administrativa, llevar a
cabo tareas de cierta manera, o realizar cambios a la informacin o tal vez el
desempeo, son razones suficientes para proponer el desarrollo de sistemas
web como mtodo idneo para facilitar los procesos de registro, elaboracin
y procesamiento de la informacin, lo que la convierte en una herramienta
viable para lograr la adopcin de decisiones, he all su importancia ya que
estos constituyen una de las mejores formas de regular los procesos de
control y gestin dentro de una organizacin, proporcionando la formalidad
necesaria a estos proceso y fomentando la confianza de entes empresariales
debido a las grandes virtudes que ofrecen estos sistemas al otorgarles
seguridad y consistencia al activo ms preciado que puede tener cualquier
14

organizacin como es la informacin.


Una empresa como CANTV, hace

referencia a la magnitud de la

necesidad de implementar sistemas capaces de gestionar rpidamente a las


solicitudes que su tamao le exige. Es por ello, que la presente investigacin
se ha estructurado en 5 fases, divididos de la siguiente manera:
- La primera fase se compone por la descripcin del problema, los
objetivos de la investigacin y la justificacin.
- La segunda fase comprende el marco terico y la metodologa a
implementar durante el desarrollo de la investigacin.
- La tercera fase se distingue por el diseo del sistema, el modelaje del
mismo y la base de datos. Esta compuesto por todos aquellos diagramas que
permitieron la abstraccin de la investigacin.
- La cuarta fase se constituye por el diseo y desarrollo del producto
tecnolgico terminado, as como sus interfaces.
- La quinta fase

15

FASE I

EL PROBLEMA
Descripcin del Problema

En el mundo en que vivimos la tecnologa marca el ritmo del avance, la


idea del progreso est ntimamente asociada al desarrollo y el uso de nuevas
tecnologas. Todas las organizaciones a nivel mundial utilizan la tecnologa
para ejecutar sus operaciones, para funcionar correctamente y para alcanzar
sus objetivos. Pero el uso ubicuo de nuevas tecnologas es lo que marca la
pauta incluso para el hombre comn.
La tecnologa suele estar incorporada a bienes fsicos o bienes de
capital, ya sea en materias primas bsicas, materias primas intermedias o
componentes (hardware), y la no incorporada en las personas, tales como
los tcnicos, los peritos, los especialistas y los ingenieros, a travs de su
conocimientos intelectual u operacional, habilidades y tcnicas para ejecutar
las operaciones; o en documentos que la registran y contienen con el fin de
asegurar su conservacin y transmisin, tales como mapas, plantas, diseos
y programas de computacin (software).
Estas tecnologas se aplican o usan en mltiples mbitos sociales,
como la salud, la educacin, la economa, la medicina, la industria y las
telecomunicaciones, entre otros. Desde hace muchos aos las empresas se
han visto en la necesidad de incluir la tecnologa en sus procesos de
desarrollo ya sea a nivel interno o externo, buscando

una integracin

completa de todos sus procedimientos para lograr los objetivos.


La Compaa Annima Nacional de Telfonos de Venezuela CANTV,
empresa lder de telefona pblica y servicio de telecomunicaciones en
16

Venezuela, se ha caracterizado desde siempre por mantener la vanguardia


tecnolgica en todos los servicios que ofrece.
CANTV se encuentra dividida en distintos departamentos que realizan
labores y actividades mediante el uso de las tecnologas y las
telecomunicaciones. Uno de estos departamentos es la Unidad de
Seguimiento (USE) el cual otorga apoyo primordial a las autoridades
gerenciales en materia de seguimiento, vigilancia y control del personal
tcnico que tiene la responsabilidad y el compromiso de reparar las averas
telefnicas emanadas del departamento de Acceso (AX), Conmutacin (CX),
Datos (DX), Transmisin (TX) y Provisin (PRV).
Igualmente, dicho departamento se encarga de garantizar la reparacin
efectiva de dichas averas, otorgando mayor importancia a los incidentes
crticos y premium, provenientes de empresas privadas, instituciones
gubernamentales e industrias. La USE de CANTV est adscrita a la Gerencia
Red del Estado Gurico y se incluye como un valor agregado de la empresa,
ya que ejerce funciones en materia de soluciones operacionales, cumpliendo
con el rol de garantizar un control del personal tcnico y la productividad de
las reparaciones.
Actualmente no cuentan con un sistema automatizado para monitorear
y registrar toda la informacin suministrada por los tcnicos que reparan las
averas. Dicho sistema podr llevar un control de las reparaciones de los
incidentes, evitando el registro manual, evitando la manipulacin de los datos
y dejando constancia de una solucin cuantificada, monitoreada, confiable y
blindada.
En los actuales momentos, CANTV supervisa las averas mediante el
uso del sistema SACAS (Sistema Automatizado para el Control de Averas de

17

Servicios) desde la ciudad de Caracas, el cual permite extraer un reporte


diario de los indicadores de incidentes crticos que son los de mayor inters y
prioridad para la gerencia y para los departamentos encargados de coordinar
dichas reparaciones. Las averas de servicios son fallas locales que
denuncian los clientes al detectar una deficiencia en su servicio. Una vez
presentado el reclamo ante la institucin este es canalizado por la central
telefnica digital regional de CANTV.
A travs del sistema SACAS se registran los datos del cliente y el
motivo de la falla. El Centro de Operaciones de la Red (COR) de CANTV
ubica la falla dentro de las redes y distribuye esa data a las gerencias y
supervisiones correspondientes. La Gerencia de Red del Estado Gurico
recibe un informe diario, mediante correos electrnicos emanados de la
Gerencia General de Tecnologa y Operacin, que sirve de indicador para la
planificacin de trabajos que mejoren la gestin operacional de la empresa.
La USE atiende entre 90 y 200 averas diariamente, slo en el rea de
San Juan de Los Morros. Realiza el seguimiento a travs de llamadas
telefnicas durante todo el da. La informacin recabada mediante estas
llamadas se registra mediante anotaciones en un formato creado por USE.
Esto genera abundante informacin proveniente del personal tcnico y los
clientes. Por lo cual se genera la necesidad de una revisin constante a
travs del sistema SACAS y un conteo manual de resultados, reiterado e
ineficiente, lo cual ocasiona un cmulo de notas desordenadas que afectan la
gestin positiva del departamento, la prdida de informacin valiosa para la
toma de decisiones y, por ende, el retraso en la respuesta efectiva y eficiente
a los incidentes.
Debido a que el flujo de averas aumenta gradualmente y el proceso de

18

vigilancia es tedioso, se hace necesaria una respuesta rpida al momento de


presentarse cualquier falla, lo cual podra solventarse con la implementacin
de un sistema automatizado que se encargue de controlar toda la
informacin y llevando un seguimiento local a travs de esta herramienta.
Por lo mencionado anteriormente se crea la necesidad de llevar a cabo
esta investigacin, que tiene como finalidad desarrollar un sistema que
genere la informacin necesaria para una ptima gestin de la USE y la
obtencin de una elevada calidad en el servicio a los usuarios de CANTV.
Atendiendo estas consideraciones y en pro de dar solucin a la
problemtica existente se propone la realizacin de un sistema web para el
seguimiento de reparaciones de averas telefnicas del departamento USE
de CANTV, cuyo objetivo ser servir como una fuente de registro de datos,
realizar el seguimiento constante del estatus de la avera, as como tambin
arrojar resultados diarios al finalizar la jornada. Todo esto dar confiabilidad a
la informacin y permitir la deteccin temprana de inconvenientes que
entorpecen la gestin y coadyuvan a bajar la productividad de la USE.
De esta manera surgen las siguientes interrogantes:
Cul es la situacin actual de los procesos de seguimiento de las
reparaciones de las averas del Departamento de la Unidad de Seguimiento
de CANTV San Juan de Los Morros?
Cules son los requerimientos necesarios para el diseo de una
aplicacin web automatizada que permita realizar seguimiento efectivo de las
reparaciones de averas de la Unidad de Seguimiento de CANTV San Juan
de Los Morros?
Cules son los beneficios obtenidos por la Unidad de Seguimiento de

19

CANTV San Juan de Los Morros con la solucin que se plantea?

Objetivos de la Investigacin

Objetivo General:
Implementar un sistema web basado en software libre para el
seguimiento de reparaciones de averas telefnicas del Departamento de
Unidad de Seguimiento (USE) de CANTV, San Juan de los Morros Estado
Gurico.

Objetivos Especficos:

1.

Analizar la situacin actual referente a las reparaciones de las

averas telefnicas del departamento de la Unidad de Seguimiento (USE) de


CANTV San Juan de Los Morros, Estado Gurico.
2.

Determinar los requerimientos de hardware y software del

departamento de la Unidad de Seguimiento (USE) de CANTV San Juan de


Los Morros Estado Gurico.
3.

Disear una aplicacin web basada en estndares de software

libre que optimice los procesos involucrados en el seguimiento de las


reparaciones de las averas telefnicas
4.

Desarrollar una aplicacin web

basada en estndares de

software libre para el seguimiento de reparaciones de averas telefnicas del


departamento de Unidad de Seguimiento de CANTV, San Juan de Los
Morros Estado Gurico.

20

Justificacin

Debido a la cantidad de informacin que maneja el departamento de


seguimiento de CANTV y a la desorganizacin en la ejecucin de los
procesos, se tiene la necesidad de implementar un sistema automatizado
que sea capaz de llevar el seguimiento de las reparaciones de averas de
forma eficaz y eficiente. La creciente demanda de averas ha suscitado la
bsqueda de soluciones eficaces en el menor tiempo posible.
La implementacin de esta herramienta facilitara la bsqueda de
soluciones en un rango de tiempo menor, generando beneficios como la
disminucin del tiempo de la recepcin de la avera a travs de un mejor
control de la informacin, la disminucin del tiempo de respuesta y el
mejoramiento de la calidad de servicio.
Las anotaciones manuales, el conteo manual y la revisin constante e
improductiva del sistema SACAS, son elementos que se buscan eliminar.
Adems contribuir a la ampliacin y mejoramiento del desempeo laboral,
puesto que al automatizar la vigilancia del incidente, el personal podr
realizar otras labores.
Es importante sealar que esta investigacin posee una justificacin
terica ya que su realizacin generar reflexiones sobre las distintas formas
de utilizar el conocimiento informtico para idear soluciones a problemas de
una empresa como CANTV. Estos conocimientos son necesarios para la
creacin de un sistema de control para el seguimiento de las reparaciones de
averas del departamento de acceso (AX I), a travs del departamento de la
unidad de seguimiento USE de CANTV, beneficiando a toda la empresa y en
particular a todos los trabajadores de esta unidad, permitindoles laborar de
21

manera organizada y cohesionada, obteniendo la informacin confiable,


verificable y cuantificada que deben presentar ante la gerencia.
Se justifica desde el mbito social debido a que va orientado a la mejora
de la prestacin de servicios dirigidos a la comunidad, permitiendo reparar
fallas lo ms pronto posible y monitorear la efectividad de las reparaciones
ofrecidas por la empresa. Los miembros de la unidad de seguimiento sern
capacitados para el aprovechamiento de esta herramienta. Todo esto
redundar en el mejoramiento de la relacin de la USE con el usuario final
que ha venido incrementando sus quejas y experimentando una disminucin
de la calidad del servicio.
Se justifica desde el mbito tecnolgico ya que el uso continuo del
sistema a travs de un ordenador genera un control ms eficaz de la
informacin, evita el trabajo manuscrito y el cmulo de papeles y permite
digitalizar el seguimiento de la informacin para organizar los datos
registrados y emitir informes que facilitar la visualizacin de los resultados,
para optimizar la toma de decisiones de la Gerencia Red del Estado Gurico.

22

FASE II

MARCO TERICO
Marco terico conceptual

Siendo el marco conceptual una de las fases ms importantes de


cualquier trabajo de investigacin, el desarrollo de los conceptos tericos
fundamenta las bases del planteamiento del problema, delimitndolo y
formulando definiciones y fundamentando las hiptesis. La teora cumple el
papel fundamental de participar en la produccin de nuevo conocimiento,
orientando la investigacin y el enfoque epistemolgico que se sustenta.

Gerencia
Segn Crisby (1988) la gerencia es el arte de hacer que las cosas
ocurran.
Viendo la informacin como un arma competitiva, Burch y Grudnitski
(1992) consideran a la gerencia como un cuerpo de conocimientos
aplicables a la direccin efectiva de una organizacin (p. 35 -36).
Claramente, todas las organizaciones operan en un ambiente
competitivo y a veces hostil, un ambiente que demanda ciertamente gerentes
bien informados. El fracaso inminente es la alternativa para aquellas
organizaciones cuyos gerentes estn desinformados o mal informados. A
decir verdad, el gran enemigo a vencer de la gerencia es la incertidumbre.
Los gerentes deben saber que hacer y cmo hacerlo; deben ser capaces de
adaptarse a los cambios vertiginosos; deben tener acceso a la informacin
de la organizacin tanto interna como externa; deben obtener seales de

23

avisos oportunos y poder prever las amenazas y los riesgos; deben ser
capaces de identificar tanto las nuevas oportunidades como los esfuerzos
intiles.
Para entender como ayuda la informacin a los gerentes a afrontar sus
responsabilidades, primero se deben comprender las responsabilidades
clave de la gerencia.

Estilo Gerencial

Un estilo gerencial es definido por Burch J. y Grudnitski G. (1992) como


el quinto factor organizacional que afecta a los requerimientos de
informacin (pag.34). Cualquier filosofa gerencial que resalte el desarrollo
de

una

planeacin

extensiva

intensiva

tendr

un

requerimiento

correspondiente de informacin para pronsticos.

Informacin
La informacin segn Burch J. y Grudnitski G. (1992) la componen
dato que se han colocado en un contexto significativo y til y se ha
comunicado a un receptor, quien la utiliza para tomar decisiones(p.19). La
informacin implica la comunicacin y recepcin de inteligencia o
conocimiento.

Evala

notifica,

sorprende

estimula,

reduce

la

incertidumbre, revela alternativas adicionales o ayuda a eliminar las


irrelevantes o pobres, e influye sobre otros individuos y los estimula a la
accin.

24

Registro
Un registro es definido por Senn James (1992) como el conjunto
completo de datos relacionados pertenecientes a una entrada(p.596).
Cuando el nmero y tamao de los datos en un registro son constantes para
cada registro, este se denomina de longitud fija. Los registros de longitud
variable son menos comunes en la mayora de las aplicaciones de las
empresas. El tamao del registro puede variar debido a que los datos varan
en longitud (cada registro puede tener un numero diferente de bytes) o
debido a que el nmero de datos en un registro cambie de un caso al otro.

Archivo

Un archivo es un conjunto de informacin sobre un mismo tema, tratada


como una unidad de almacenamiento y organizada de forma estructurada
para la bsqueda de un dato individual. Est compuesto de registros
homogneos que contienen informacin sobre el tema.
A su vez, Senn James (1992), lo define como una coleccin de
registros relacionados. Se incluye cada registro en un archivo ya que
pertenece a la misma entidad (p.598). El tamao del archivo se determina
por el nmero de registros que hay en l.

25

Base de Datos

Es el componente estructural clave en el diseo de sistemas de


informacin. Es la principal fuerza de integracin del sistema de informacin
de una organizacin. Debe lograrse un buen ajuste entre las necesidades de
procesamiento y de toma de decisiones de la organizacin y la estructura y
composicin de la base de datos.

Dato

De acuerdo a los planteamientos de Dan Oja (1999) en relacin a un


dato lo define como las palabras, nmeros, y grficos que describen a las
personas, eventos, cosas e ideas(p.A-4). Se pueden incluir en los
programas o se pueden crear, como los nmeros para trazar una grfica. Las
computadoras los manejan de muchos modos y esa manipulacin se llama
procesamiento.

Administracin de Datos

La administracin de datos es definido por Burch y Grudnitski (1992)


como el proceso de almacenar y recuperar datos(p.440). La administracin
de datos est compuesta de tres tareas bsicas: (1) describir la organizacin
real y la interrelacin de los datos en una definicin estndar de datos, (2)
almacenar fsicamente los datos en un formato especifico en un medio de
almacenamiento y (3) recuperar los datos almacenados en una forma tal que
proporcionen informacin valida a los usuarios del sistema.

26

El analista de sistemas tiene la responsabilidad de disear un sistema


que cubra de manera eficaz las tres tareas de la administracin de datos.

Sistema
Segn James Senn (1992), un sistema es un conjunto de componentes
que interaccionan entre s para lograr un objetivo comn(p.)

Sistema de control

Un sistema de control est definido como un conjunto de componentes


que pueden regular su propia conducta o la de otro sistema con el fin de
lograr un funcionamiento predeterminado, de modo que se reduzcan las
probabilidades de fallos y se obtengan los resultados buscados.
Hoy en da los procesos de control son sntomas del proceso industrial
de antao. Estos sistemas se usan tpicamente en sustituir un trabajador
pasivo que controla una determinado sistema ( ya sea elctrico, mecnico,
entre otros) con una posibilidad nula o casi nula de error, y un grado de
eficiencia mucho ms grande que el de un trabajador. Los sistemas de
control ms modernos en ingeniera automatizan procesos en base a
muchos parmetros y reciben el nombre de controladores de automatizacin
programables (PAC).

Los sistemas de control deben conseguir los siguientes objetivos:


1. Ser estables y robustos frente a perturbaciones y errores en los
modelos.

27

2.

Ser

eficiente

segn

un

criterio

preestablecido

evitando

comportamientos bruscos e irreales.

Clasificacin de los sistemas de control segn su comportamiento

1. Sistema de control de lazo abierto: Es aquel sistema en que solo


acta el proceso sobre la seal de entrada y da como resultado una seal de
salida independiente a la seal de entrada, pero basada en la primera. Esto
significa que no hay retroalimentacin hacia el controlador para que ste
pueda ajustar la accin de control. Es decir, la seal de salida no se convierte
en seal de entrada para el controlador. Ejemplo 1: el llenado de un tanque
usando una manguera de jardn. Mientras que la llave siga abierta, el agua
fluir. La altura del agua en el tanque no puede hacer que la llave se cierre y
por tanto no nos sirve para un proceso que necesite de un control de
contenido o concentracin. Ejemplo 2: Al hacer una tostada, lo que hacemos
es controlar el tiempo de tostado de ella misma entrando una variable (en
este caso el grado de tostado que queremos). En definitiva, el que nosotros
introducimos como parmetro es el tiempo.
Estos sistemas se caracterizan por:
Ser sencillos y de fcil concepto.
Nada asegura su estabilidad ante una perturbacin.
La salida no se compara con la entrada.
Ser afectado por las perturbaciones. stas pueden ser tangibles o
intangibles.
La precisin depende de la previa calibracin del sistema.

28

2. Sistema de control de lazo cerrado: Son los sistemas en los que la


accin de control est en funcin de la seal de salida. Los sistemas de
circuito cerrado usan la retroalimentacin desde un resultado final para
ajustar la accin de control en consecuencia. El control en lazo cerrado es
imprescindible cuando se da alguna de las siguientes circunstancias:
- Cuando un proceso no es posible de regular por el hombre.
- Una produccin a gran escala que exige grandes instalaciones y el
hombre no es capaz de manejar.
- Vigilar un proceso es especialmente difcil en algunos casos y requiere
una atencin que el hombre puede perder fcilmente por cansancio o
despiste, con los consiguientes riesgos que ello pueda ocasionar al
trabajador y al proceso.

Caractersticas de un sistema de control


Ser complejos, pero amplios en cantidad de parmetros.
La salida se compara con la entrada y le afecta para el control del
sistema.
Su propiedad de retroalimentacin.
Ser ms estable a perturbaciones y variaciones internas.

Tipos de sistemas de control

Los sistemas de control son agrupados en tres tipos bsicos:


1. Hechos por el hombre. Como los sistemas elctricos o electrnicos
que estn permanentemente capturando seales de estado del sistema bajo
su control y que al detectar una desviacin de los parmetros pre-

29

establecidos del funcionamiento normal del sistema, actan mediante


sensores, para llevar al sistema de vuelta a sus condiciones operacionales
normales de funcionamiento.
2. Naturales, incluyendo sistemas biolgicos. Por ejemplo, los
movimientos corporales humanos como el acto de indicar un objeto que
incluye como componentes del sistema de control biolgico los ojos, el brazo,
la mano, el dedo y el cerebro del hombre.
3. Cuyos componentes estn unos hechos por el hombre y los otros son
naturales. Se encuentra el sistema de control de un hombre que conduce su
vehculo. ste sistema est compuesto por los ojos, las manos, el cerebro y
el vehculo. La entrada se manifiesta en el rumbo que el conductor debe
seguir sobre la va y la salida es la direccin actual del automvil.
4. Un sistema de control puede ser neumtico, elctrico, mecnico o de
cualquier tipo, su funcin es recibir entradas y coordinar una o varias
respuestas segn su lazo de control (para lo que est programado).
5. Control Predictivo, son los sistemas de control que trabajan con un
sistema predictivo, y no activo como el tradicional ( ejecutan la solucin al
problema antes de que empiece a afectar al proceso). De esta manera,
mejora la eficiencia del proceso contrarrestando rpidamente los efectos.

Principios de Control

Los sistemas de control se basan en una serie de principios bsicos, los


cuales permiten alcanzar los objetivos propuestos por todo sistema de
control. A saber son:
Uso de la Contabilidad como elemento informativo

30

Economa del Control


Control por excepcin
Control por responsabilidades
Integracin de los sistemas de control
Coincidencia entre el presupuesto y el plan de cuentas contable
Informacin pertinente, precisa, sinttica y oportuna
Medidas adecuadas como consecuencia del control

Control de Gestin

El control de gestin es un proceso que sirve para guiar la gestin


empresarial hacia los objetivos de la organizacin y un instrumento para
evaluarla.
Existen diferencias importantes entre las concepciones clsica y
moderna de control de gestin. La primera es aquella que incluye
nicamente al control operativo y que lo desarrolla a travs de un sistema de
informacin relacionado con la contabilidad de costos, mientras que la
segunda integra muchos ms elementos y contempla una continua
interaccin entre todos ellos. El nuevo concepto de control de gestin centra
su atencin por igual en la planificacin y en el control, y precisa de una
orientacin estratgica que dote de sentido sus aspectos ms operativos.
Segn Huge Jordan (1995), el control de Gestion es un instrumento de
la gestin que aporta una ayuda a la decisin y sus tiles de direccin van a
permitir

los

directores

alcanzar

los

objetivos;

es

una

funcin

descentralizada y coordinada para la planificacin de objetivos, acompaada


de un plan de accin y la verificacin de que los objetivos han sido
alcanzados.
31

Sistema de seguimiento de incidentes

Un sistema de seguimiento de incidentes es definido por Spolsky (2000)


como un paquete de software que administra y mantiene listas de
incidentes, conforme son requeridos por una institucin. (p.). Los sistemas
de este tipo son comnmente usados en la central de llamadas de servicio al
cliente de una organizacin para crear, actualizar y resolver incidentes
reportados por usuarios, o inclusive incidentes reportados por otros
empleados de la organizacin. Un sistema de seguimiento de incidencias
tambin contiene una base de conocimiento que contiene informacin de
cada cliente, soluciones a problemas comunes y otros datos relacionados.
Un sistema de reportes de incidencias es similar a un Sistema de
seguimiento de errores (bugtracker) y, en algunas ocasiones, una compaa
de software puede tener ambos, y algunos bugtrackers pueden ser usados
como un sistema de seguimiento de incidentes, y viceversa.

Ticket
Spolky Joel (2000) lo define como un archivo contenido en el sistema
de seguimiento que contiene informacin acerca de intervenciones de
software hechas por personal de soporte tcnico o terceros a pedido de un
usuario final que ha reportado un incidente que est impidindoles trabajar.
Los tickets se crean generalmente en un ambiente de help desk o call center.
Poseen nmero nico de referencia, tambin conocido como un nmero de
caso, incidente o reporte de llamada, el cual es usado para permitir al cliente
o al personal de soporte localizar, aadir o comunicar el estado del incidente
o requerimiento. Estos tickets tambin son llamados as debido a su origen

32

como pequeas tarjetas con un pequeo muro a manera de un sistema de


planificacin de trabajo acumulado.

Incidentes

Los incidentes pueden tener muchos aspectos. Cada incidente en el


sistema puede tener un nivel de urgencia asignado, basado en la importancia
total de ese incidente. Los incidentes crticos son los ms severos que deben
ser resueltos en la forma ms expedita posible, tomando precedencia sobre
todos los dems incidentes. Los incidentes de urgencia baja o cero son
menores, y deben ser resueltos como lo permita el tiempo. Otros detalles de
los incidentes incluyen la experiencia del cliente con el incidente (sea interna
o externa), fecha de registro, descripciones detalladas del problema
experimentado, intentos de soluciones y otra informacin relevante. Cada
incidente mantiene un historial de cada cambio.

Mesa de ayuda (Help Desk)


Middleton (1996) lo define como un conjunto de recursos tecnolgicos
y humanos, para prestar servicios con la posibilidad de gestionar y solucionar
todas las posibles incidencias de manera integral, junto con la atencin de
requerimientos relacionados a las Tecnologas de la Informacin y la
Comunicacin (TIC). El personal o recurso humano encargado de Mesa de
Ayuda (MDA) debe proporcionar respuestas y soluciones a los usuarios
finales, clientes o beneficiarios (destinatarios del servicio), y tambin puede
otorgar asesoramiento en relacin con una organizacin o institucin,
productos y servicios. Generalmente, el propsito de MDA es solucionar

33

problemas o para orientar acerca de computadoras, equipos electrnicos o


software.
Las organizaciones suelen proporcionar soporte de MDA a sus usuarios
a travs de varios canales, como nmeros de telfono gratuitos, sitios web,
mensajera instantnea o correo electrnico. Tambin, pueden brindar
asistencia con miras a los usuarios o empleados, dentro de la organizacin.
Por lo tanto, los usuarios finales pueden ser internos o ajenos a la
organizacin donde se encuentre MDA.

Aplicacin Web

De acuerdo a lo planteado por Lujan Mora, Sergio (2001), una


aplicacin web se define como aquellas herramientas que los usuarios
pueden utilizar accediendo a un servidor web a travs de Internet o de una
intranet mediante un navegador. En otras palabras, es una aplicacin
software que se codifica en un lenguaje soportado por los navegadores web
en la que se confa la ejecucin al navegador.
Las aplicaciones web son populares debido a lo prctico del navegador
web como cliente ligero, a la independencia del sistema operativo, as como
a la facilidad para actualizar y mantener aplicaciones web sin distribuir e
instalar software a miles de usuarios potenciales.

34

Avera
Considerada por Moliner Lpez, Francisco Javier (2005) como una
desviacin del comportamiento de un sistema respecto de su especificacin.
Las averas son el resultado de estados inesperados en el interior del
sistema que eventualmente se manifiestan en el comportamiento exterior del
sistema.
Una avera es definida por Camejo (2006), como aquella falla o dao,
perjuicio, demora, deterioro de un aparato en particular.(p.98), donde dicho
dao o falla dentro de una empresa de telecomunicaciones corresponde a la
desconexin total entre los distintos componentes de la red que permiten la
transmisin de datos entre los distintos puntos establecidos para la
comunicacin de informacin.

Falla

Se define como una desviacin no aceptable de al menos una


caracterstica del sistema. Hay fallas esenciales que deben ser detectadas y
corregidas, y tambin existen fallas crticas que deben generar un nuevo
ordenamiento de las funciones de proceso.

Servicio tcnico (Help Desk)

Es una capacidad fundamental dentro de la Gestin de Servicios IT. Su


objetivo es proporcionar un punto nico de contacto para satisfacer las
necesidades de comunicacin entre IT y sus clientes, de forma que ambos

35

cumplan con sus objetivos. Muchas organizaciones han implantado un


service desk centralizado para gestionar incidencias, dudas, consultas y
peticiones de usuarios y clientes. El service desk por tanto gestiona
incidencias y peticiones rutinarias de nuevos servicios.
Adems debe mantener Difiere de un Call Center o Help Desk en que
tiene un alcance mayor y ms centrado en el cliente, ya que se encarga de
facilitar la integracin de los procesos de negocio en la infraestructura IT.

CANTV

La Compaa Annima Nacional Telfonos de Venezuela (CANTV), ente


adscrito al Ministerio del Poder Popular para Ciencia, Tecnologa e
Innovacin, junto a sus filiales Movilnet y Caveguas, es la primera empresa
de telecomunicaciones en Venezuela que tiene como objetivo fundamental
fomentar la inclusin social y la disminucin de la brecha al acceso de
tecnologas digitales, facilitando as el alcance de todos a los servicios de
telecomunicaciones.
La gestin de CANTV, tras su nacionalizacin en mayo de 2007, est
definida

por

la

relacin

tica,

productiva,

humanista,

endgena

transparente con las comunidades, los servidores pblicos, los usuarios, el


Estado y el ambiente, al respetar la diversidad y favorecer la reduccin de las
desigualdades sociales.
Como empresa con una visin ms humanista ofrece servicios de
telefona bsica a todo centro poblado con ms de 500 personas, pone a la
disposicin de las venezolanas y de los venezolanos de menores recursos

36

una tarifa social y reinvierte las ganancias en funcin de las necesidades de


telecomunicaciones del pueblo.

Breve resea histrica

La Compaa Annima Nacional Telfonos de Venezuela, fue fundada


en 1930 por el comerciante Flix A. Guerrero, quien luego de haber suscrito
la concesin el 4 de abril de 1930, se asocia con el comerciante Manuel
Prez Abascal y el abogado Alfredo Damirn y constituyen la Compaa
Annima Nacional Telfonos de Venezuela (CANTV) con capital suscrito de
Bs. 500.000, de los cuales Guerrero tena 200 acciones y Damirn y Prez
Abascal 150 acciones cada uno.
En 1953, la nacin adquiere la totalidad de las acciones ordinarias de
CANTV (20.000 en total) por Bs. 29.900.911. El objetivo era crear una nueva
red telefnica independiente y solamente utilizar las partes aprovechables de
la anterior empresa. En este proceso, la compaa Telephone Properties LTD
mantuvo 4.895 acciones que fueron posteriormente adquiridas por el Estado
en 1968.
Desde diciembre de 1991 hasta 2007, la Corporacin CANTV ha
transitado por tres lustros de crecimiento, aprendizaje colectivo y desarrollo
continuo que ha definido sus fortalezas actuales. Para comprender la
transformacin protagonizada por la empresa en este lapso, debemos
subdividir este perodo en cuatro grandes etapas:
1. 1992-1997: Expansin y modernizacin de las redes. Durante los
primeros seis aos como empresa privatizada, se emprende la expansin y
modernizacin de las redes de voz y datos, fijas y mviles; gracias a la mayor
inversin de capital que una empresa privada haya realizado en el pas: ms

37

de 3.000 millones de dlares. Esta novedosa plataforma tecnolgica, que


cubre todo el territorio nacional, permite atender la creciente demanda de
telecomunicaciones de los venezolanos, gracias a su actualizacin
permanente, como ocurri posteriormente con la red de Movilnet.
2. 1998/2000: Transformacin y orientacin comercial. Esta etapa
caracteriza la evolucin de la empresa hacia el mercado ante la inminente
apertura total del sector. Se concreta la transformacin de la estructura
organizacional de CANTV y se crean las unidades de negocio con un nuevo
enfoque estratgico: el cliente.
3. 2001/2003: Integracin en competencia. Luego de la aprobacin de
la Ley Orgnica de Telecomunicaciones y el comienzo de la apertura total del
mercado de las telecomunicaciones, CANTV, como Corporacin, evoluciona
hacia la integracin de las empresas del grupo.
4. 2004/2006: Crecimiento para abrir horizontes mercado de la banda
ancha, de los contenidos y de las transacciones electrnicas a travs de las
redes fijas y mviles. En lo interno, se fortalecen y actualizan los sistemas
tecnolgicos y se establecen procesos flexibles y productivos, basados en la
calidad y la pasin por la ejecucin. De esta forma, se abre un nuevo camino
para convertir a CANTV en una Corporacin sobresaliente.

Visin de CANTV

CANTV y sus filiales, empresa estratgica, rentable y socialista del


Estado venezolano, contribuye en colectivo a garantizar al pas su derecho a
la comunicacin.

38

S.A.C.A.S. (Sistema Automatizado para el Control de Averas de


Servicios)

Proyecto de la empresa CANTV puesto en marcha desde el ao 2011 el


cual es utilizado actualmente mediante mdulos de operaciones, reportes,
utilidades, requerimientos y llamadas para el control de averas de servicios
de voz y datos (almbrico e inalmbrico) y de elementos de red asociados,
para clientes residenciales y no residenciales.

USE (Unidad de Seguimiento Estatal)

La Unidad de Seguimiento Estatal es la responsable de la gestin de


operaciones de la Lnea de Proyectos de Mantenimiento Correctivo y
Preventivo de CANTV, la cual comprende:
1. Control y revisin de la justificacin de los trabajos realizados en la
empresa hacia los departamentos que as lo ameriten.
2. Comprobacin del cumplimiento de la normativa interna de la empresa
en la gestin de operaciones efectivas.
3. Realizacin de los controles de verificacin necesarios para velar por
el buen uso de los recursos, as como tambin el desenvolvimiento de su
talento humano.
4. Autorizacin de modificaciones de las condiciones iniciales de los
proyectos.
5. Informacin permanente a la Gerencia Red, as como tambin a
niveles superiores en relacin a la gestin y justificacin de las
subvenciones.

39

Metodologa implementada
La metodologa es definida desde la visin de Tovar (2005), como una
serie de pasos que se deben seguir, con el fin de llevar a cabo dicho
proyecto, para poder alcanzar el objetivo planteado y garantizar la solucin
del problema(p.89).
En efecto, la metodologa de trabajo se baso en la unin de dos
enfoques: la metodologa de modelado UWE (UML-Based Web Engineering
Ingeniera Web basada en UML) y la metodologa estructural Escalera Top
Down del Ing. Leonel Jimnez Gamboa de la Universidad Nacional
Experimental Rmulo Gallegos.

Metodologa UWE

UWE es un enfoque de ingeniera de software para el dominio Web con


el objetivo de cubrir todo el ciclo de vida de desarrollo de aplicaciones
Web. El aspecto clave que distingue UWE es la dependencia de los
estndares. El foco principal del enfoque UWE es proporcionar un:

Dominio especfico del lenguaje de modelado basado en UML,

Dirigido por modelos metodologa,

Soporte de herramientas para el diseo sistemtico, y

Herramienta de apoyo para la generacin automtica de aplicaciones Web.

Es una herramienta que permite modelar aplicaciones web, prestando


especial

atencin

en

sistematizacion

personalizacin

(sistemas

adaptativos), adems proporciona soporte de herramientas para el diseo de

40

los modelos, las comprobaciones de coherencia de modelos, y la generacin


semiautomtica de sistemas Web.
El enfoque UWE provee una notacin de dominio especfico, un
proceso de desarrollo dirigido por modelos, y soporte de herramientas para la
ingeniera de aplicaciones Web. La caracterstica de la UWE es el hecho de
que un enfoque basado en normas que no se limita al uso de UML, pero
tambin utiliza XMI como un formato modelo de intercambio, MOF para el
meta-modelado, los principios basados en modelos del enfoque MDA, el
modelo de lenguaje de transformacin QVT y XML.
Las principales razones para el uso de los mecanismos de extensin de
UML en lugar de una de las tcnicas de modelado de propiedad es la
aceptacin de la UML en el desarrollo de sistemas de software, flexibilidad
para la definicin de un lenguaje de modelado especfico de dominio Web, y
amplio soporte de modelado visual por las herramientas CASE UML
existentes.
UWE utiliza la notacin UML "pura" y los tipos de diagramas UML
siempre que sea posible para el anlisis y diseo de aplicaciones Web, es
decir, sin las extensiones de cualquier tipo. Por las caractersticas especficas
de la Web, como los nodos y enlaces de la estructura del hipertexto, el perfil
UWE incluye estereotipos, valores etiquetados y restricciones definidas por
los elementos de modelado. La extensin UWE cubre navegacin,
presentacin, procesos de negocio y los aspectos de adaptacin.

Descripcin general de los modelos UWE:

El enfoque de diseo UWE para los procesos de negocio Web consiste


en la introduccin de clases especficas de procesos que forman parte de un

41

modelo de proceso independiente con una interfaz definida para el modelo


de navegacin. Para modelar las caractersticas adaptativas de las
aplicaciones web de una manera no invasiva, UWE utiliza tcnicas de
modelado orientado a aspectos (AOM). Tras la separacin de las
preocupaciones principales UWE propone la construccin de un modelo de
adaptacin de los sistemas personalizados o dependientes del contexto y
tejer los modelos despus.
La notacin de UWE se define como una extensin "ligera" de UML, sin
embargo admite la seleccin y uso de cualquier tipo de diagrama
perteneciente al Lenguaje Unificado de Modelado, ya que la misma es una
extensin de UML.
En requisitos separa las fases de captura, definicin y validacin. Hace
adems una clasificacin y un tratamiento especial dependiendo del carcter
de cada requisito.
En el marco de UWE es necesario la definicin de un perfil UML
(extensin) basado en estereotipos, con este perfil se logra la asociacin de
una semntica distinta a los diagramas del UML puro, con el propsito de
acoplar el UML a un dominio especfico, en este caso, las aplicaciones Web.
UWE define vistas especiales representadas grficamente por
diagramas en UML. Adems, no limita el nmero de vistas posibles de una
aplicacin, UML proporciona mecanismos de extensin basados en
estereotipos. Estos mecanismos de extensin son los que UWE utiliza para
definir estereotipos que son lo que finalmente se utilizarn en las vistas
especiales para el modelado de aplicaciones Web. De esta manera, se
obtiene una notacin UML adecuada aun dominio en especfico a la cual se
le conoce como Perfil UML.

42

Est especializada en la especificacin de aplicaciones adaptativas, y


por tanto hace especial hincapi en caractersticas de personalizacin, como
es la definicin de un modelo de usuario o una etapa de definicin de
caractersticas adaptativas de la navegacin en funcin de las preferencias,
conocimiento o tareas de usuario.

Actividades de modelado de UWE.

Las actividades base de modelado de UWE son el anlisis de


requerimientos, el modelo conceptual, el modelo navegacional y el modelo
de presentacin. A estos modelos se pueden sumar otros modelos como lo
son el modelo de interaccin y la visualizacin de Escenarios Web.
El modelo que propone UWE est compuesto por etapas o submodelos:

Modelo de Casos de Uso

Modelo de Contenido

Modelo de Usuario

Modelo de estructura

Modelo Abstracto

Modelo de Adaptacin

Modelo de flujo de presentacin.

Modelo de ciclo de vida del objeto.

Modelo Lgico-Conceptual.

UWE apunta a construir un modelo conceptual de una aplicacin Web,


procura no hacer caso en la medida de lo posible de cuestiones relacionadas
con la navegacin, y de los aspectos de interaccin de la aplicacin Web. La

43

construccin de este modelo lgico-conceptual se debe llevar a cabo de


acuerdo con los casos de uso que se definen en la especificacin de
requerimientos. El modelo conceptual incluye los objetos implicados en las
actividades tpicas que los usuarios realizarn en la aplicacin Web. Se
tienen:
1)

Modelo de Navegacin: consta de la construccin de dos

modelos de navegacin, el modelo del espacio de navegacin y el


modelo de la estructura de navegacin. El primero especifica que
objetos sern visitados por el navegador a travs de la aplicacin. El
segundo define como se relacionaran.
2)

Modelo de presentacin: describe dnde y cmo los objetos de

navegacin y accesos primitivos sern presentados al usuario, es


decir, una representacin esquemtica de los objetos visibles al
usuario.
3)

Interaccin Temporal: presenta los objetos que participan en la

interaccin y la secuencia de los mensajes enviados entre ellos.


4)

Escenarios Web: permiten detallar la parte dinmica del modelo

de navegacin, especificndoles eventos que disparan las situaciones,


definen condiciones y explcitamente incluyen las acciones que son
realizadas. Junto con el modelo de interaccin temporal, los
escenarios Web proveen la representacin funcional dinmica del
modelo de navegacin.
5)

Diagramas:

son

diagramas

UML puro.

Entre

los

ms

importantes se encuentran: diagramas de caso de uso, diagramas de


estado, de secuencia, de colaboracin y diagramas de actividad.

44

Fases

UWE cubre todo el ciclo de vida de este tipo de aplicaciones


centrando adems su atencin en aplicaciones personalizadas o adaptativas.
Las fases o etapas a utilizar son:
1) Captura, anlisis y especificacin de requisitos: En simple palabras
y bsicamente, durante esta fase, se adquieren, renen y especifican las
caractersticas funcionales y no funcionales que deber cumplir la aplicacin
web.
Trata de diferente forma las necesidades de informacin, las
necesidades de navegacin, las necesidades de adaptacin y las de interfaz
de usuario, as como algunos requisitos adicionales. Centra el trabajo en el
estudio de los casos de uso, la generacin de los glosarios y el prototipo de
la interfaz de usuario.
2) Diseo del sistema: se basa en la especificacin de requisitos
producido por el anlisis de los requerimientos (fase de anlisis), el diseo
define cmo estos requisitos se cumplirn, la estructura que debe darse a la
aplicacin web.
3) Codificacin del software: durante esta etapa se realizan las tareas
que

comnmente

se

conocen

como

programacin;

que

consiste,

esencialmente, en llevar a cdigo fuente, en el lenguaje de programacin


elegido, todo lo diseado en la fase anterior.
4) Pruebas: las pruebas se utilizan para asegurar el correcto
funcionamiento de secciones de cdigo.
5) La Instalacin o Fase de Implementacin: es el proceso por el cual
los programas desarrollados son transferidos apropiadamente al computador

45

destino, inicializados, y, eventualmente, configurados; todo ello con el


propsito de ser ya utilizados por el usuario final.
Esto incluye la implementacin de la arquitectura, de la estructura del
hiperespacio, del modelo de usuario, de la interfaz de usuario, de los
mecanismos adaptativos y las tareas referentes a la integracin de todas
estas implementaciones.
6) El Mantenimiento: es el proceso de control, mejora y optimizacin
del software ya desarrollado e instalado, que tambin incluye depuracin de
errores y defectos que puedan haberse filtrado de la fase de pruebas de
control.

Por otro lado, UWE propone una extensin de UML que se divide en 4
pasos.
1.

Anlisis

de requisitos: su objetivo es encontrar los requisitos

funcionales de la aplicacin web para representarlos como casos de


uso. Da lugar a un diagrama de casos de uso.
2.

Diseo conceptual: su objetivo es construir un modelo

conceptual del dominio de la aplicacin considerando los requisitos reflejados


en los casos de uso. Da como resultado un diagrama de clases de dominio.
3.

Diseo navegaciones: se obtienen el modelo de espacio de

navegacin y modelo de estructura de navegacin, que muestra cmo


navegar a travs del espacio de navegacin. Se obtienen diagramas de
clases que representan estos modelos.
4.

Diseo de presentacin: de este paso se obtienen una serie de

vistas de interfaz de usuario que se presentan mediante diagramas de


interaccin UML.

46

Los aspectos principales de esta metodologa son:

Uso de una notacin estndar, como es la notacin UML.

Definicin precisa del mtodo, una serie de pasos para seguir la

construccin delos modelos.

La especificacin de restricciones, la metodologa recomienda

el uso de restricciones escritas en el Lenguaje de Restricciones de


Objetos (OCL)para aumentar la precisin de los modelos.

Metodologa Escalera Top - Down

La escalera TOP - DOWN es una metodologa para el Desarrollo de


Sistemas de Informacin que contempla las fases de Anlisis, Diseo y
Construccin. A su vez cada fase contempla varias etapas, que a su vez
presentan varios pasos de accin.
La metodologa se basa en el transitar por un camino de accin y
trabajo secuencial y lgico. Un camino que comienza en un primer momento
cuando el desarrollador no tiene conocimiento acerca del sistema que piensa
afrontar. A modo grfico, la metodologa se puede representar como una
escalera por donde debe transitar el desarrollador,
La escalera sta conformada por ocho peldaos que bajan hasta una
especie de sala tipo stano y despus sube otros ocho peldaos hacia
adelante. El tramo de bajada representa la fase de Anlisis del Sistema, y el
tramo de subida representa al Diseo del Sistema, despus del tramo de
subida sigue un camino recto, sin peldaos, que se corresponde con la fase
de Construccin del Sistema.

47

EL ANLISIS: El anlisis es el primer tramo del camino por recorrer, es


en bajada por la escalera, en esta fase se gana un conocimiento profundo
acerca del rea de accin relacionada con el problema planteado. A medida
de que se va bajando por la escalera se va ganando, en las profundidades,
un mayor conocimiento del caso, se va descubriendo todo.
Se comienza en el tope (Top), el peldao 00, a este nivel se entiende
que el analista carece de informacin para poder hacer un diagnstico. Todos
los escalones representan una serie de actividades que el desarrollador debe
acometer para poder realizar un efectivo anlisis.

El producto del peldao 01 es la redaccin del funcionamiento del


sistema actual a manera de procesos, en este escaln es en donde se
levanta la informacin, se clasifica y se organiza. Ya despus de esto se
estudia y se analiza la informacin para poder redactar el caso y as poder
presentar la descripcin del sistema actual (procesos).
En el peldao 02 se procede a diagramar al sistema actual, esto en
base a la descripcin que se realiz en el primer escaln, para esto se
utilizarn tcnicas de modelaje que permitirn mostrar de manera grfica el
modelo y funcionamiento del sistema actual en trminos de informacin y
datos, modelaje del sistema actual.
En el peldao 03 se construye la tabla de campos de datos del sistema
actual. Para construir esta tabla se siguen los parmetros y estipulaciones ya
establecidos en la descripcin del caso y en el modelaje del sistema, en todo
caso la Tabla de Campos de Datos se debe encontrar entrelazada con el
Modelo del Sistema Actual.
En el peldao 04, el determinacin de situaciones problemticas, se
definen cules son los problemas en los que se encuentra inmerso el sistema

48

actual.

Para poder definir estos problemas se debe estudiar con

detenimiento la descripcin del caso, el modelo del sistema y la tabla de


campos.
En el peldao 05 es cuando se presenta la solucin propuesta, la cual
se encuentra muy ligada con lo que es el ttulo del trabajo del proyecto de
grado, pero desde un punto de vista de ingeniera, desde un punto de vista
tcnico.
En el peldao 06 se describe cual es el alcance del sistema. En esta
seccin se define el alcance del sistema, se determina cules son los
aspectos estructuras que abarcar el nuevo sistema, esto a manera general.
Es una primera aproximacin de lo que debera hacer el nuevo sistema, es
una inferencia lgica de operacin, por otro lado, tambin sirve para definir
hasta donde va a llegar el desarrollo del sistema y cules son las fronteras
del mismo.
Si existe alguna limitacin en el emprendimiento del proyecto, entonces
es en el peldao 07, limitaciones del proyecto, en donde se describan tales
limitaciones.
El peldao 08 es el ltimo escaln de bajada en la escalera (Down), y
en ste se describen cules son las necesidades generales del sistema. Todo
sistema cumple con abarcar ciertas necesidades comunes con todos los
sistemas de informacin existentes, acceso, seguridad, configuracin,
respaldo, entre tantos. Adems, tambin se definen a este nivel ciertas
necesidades especficas que se han podido percibir y determinar a lo largo
del anlisis que se ha ido efectuando.
A este nivel del desarrollo del proyecto ya se tiene un slido
conocimiento del sistema actual y tambin se conoce con certeza cul es el

49

rumbo a tomar para emprender el diseo, claro sta, en funcin de la


solucin propuesta planteada.

EL DISEO: En el diseo se sube la escalera desde el peldao 09


(Down) hasta el peldao 16, para llegar de nuevo al tope (Top). En este
recorrido el desarrollador se encontrar armando el paquete de diseo muy
bien elaborado que deber ser tomado en cuenta para el momento de la
construccin del nuevo sistema.
Como se puede observar el peldao 09 se encuentra al mismo nivel del
peldao 08, esto es debido a que la informacin que es producto del peldao
09 contiene a su vez a la informacin ya establecida en el peldao 08, solo
con la diferencia de que esta informacin se encontrar mucho ms detallada
en el nivel 09. En el nivel 09 se arma la tabla de requerimientos del sistema,
la cual es una tabla que contiene todos los requerimientos de informacin
que los usuarios han determinado son necesarios dentro de las operaciones
del nuevo sistema, requerimientos de seguridad, de acceso, de reportes, de
configuracin, de despliegue de informacin, etc.
En base a los nuevos requerimientos planteados en el escaln 09 y al
modelo del sistema actual ya analizado, se procede a realizar el modelo del
nuevo sistema, modelaje del nuevo sistema, escaln 10.
Igualmente y siguiendo los mismos parmetros de la fase de anlisis,
en el escaln 11 se procede a construir la tabla de campos de datos del
nuevo sistema, claro est que para esto hay que tomar en cuenta los nuevos
campos de datos que se han determinado en la tabla de requerimientos, los
posibles campos de datos que se vayan a eliminar de la tabla de campos de
datos del sistema actual y la tambin posible modificacin de algunos de los
campos de datos ya existentes en el sistema actual.

50

En el escaln 12 se generan las entidades de las bases de datos. Estas


entidades con sus respectivos atributos se determinan a partir de la tabla de
campos de datos del nuevo sistema.

Despus de determinadas las

entidades se procede a construir el diagrama Entidad Relacin (E-R).


El diagrama E-R, conjuntamente con el proceso de Normalizacin son
quienes dan origen al esquema lgico de la base de datos, escaln 13, el
cual es el mapa o diseo conceptual de la Base de Datos.
En el escaln 14 se genera la carta de navegacin. Esta carta es un
diagrama que seala entre tantos:
Cules son los mdulos operativos del nuevo sistema.
Como se conectan los mdulos operativos del sistema.
Cules son las rutas de navegacin que pueden tomar los usuarios
para moverse entre los mdulos.
Cules son los enlaces directos e indirectos entre los mdulos.
La relacin entre los mdulos del sistema y los requerimientos
preestablecidos en la Tabla de Requerimientos.

El prototipo grfico, escaln 15, tiene que ver con la diagramacin


grfica,

el estilo de pantallas y los contenidos estructurales y de

posicionamiento de la informacin que regirn la interfaz hombre mquina.


El desarrollador debe presentar los modelos de pantallas prototipos del
nuevo sistema, as como tambin, dentro de estas pantallas, la ubicacin de
los logotipos de la institucin asociada con el sistema, la posicin y
despliegue de mens y dems ventanas emergentes, el posicionamiento de
la identificacin del usuarios, la hora y fecha, el rea operativa y de
presentacin de informacin especfica, entre tantos.

51

Ya en el ltimo escaln de subida en la escalera, escaln 16 (Top), se


presentan las mejoras sobre el sistema anterior. Si se est diseando un
nuevo sistema es porque el sistema actual tiene fallas y problemas. El nuevo
sistema, en teora debera solucionar los problemas y fallas del sistema
actual.
A este nivel se presenta en forma tipo tabla un conjunto de
razonamientos que explican el cmo cada solucin especfica diseada
mejora los aspectos deficientes del sistema actual.
Ya culminado el tramo de subida de la escalera TOP DOWN el
desarrollador contar con el paquete de diseo listo y completo que servir
de gua para la construccin del nuevo sistema.

LA CONSTRUCCIN: Ya con el paquete de diseo en la mano el


desarrollador se encuentra en la capacidad de comenzar la construccin del
nuevo sistema.
En el paso 17, planificacin de la construccin, se debe proceder a
hacer una planificacin real y practica de las tareas de programacin y
construccin en funcin del tiempo. Para esto se puede utilizar la tcnica de
la carta Gantt conjuntamente con cualquier aplicacin informtica para este
fin.
El programador tiene como insumo principal y aspecto fundamental
para realizar la planificacin de la construccin a la carta de navegacin del
sistema, la cual contiene a todos los mdulos operacionales del nuevo
sistema.
El proceso de configuracin, paso 18, tiene que ver la construccin del
cdigo de programacin de los mdulos del nuevo sistema. Esta fase es
netamente operativa ya . el diseo se sube la escalera desde el peldao 09

52

(Down) hasta el peldao 16, para llegar de nuevo al tope (Top). En este
recorrido el desarrollador se encontrar armando el paquete de diseo muy
bien elaborado que deber ser tomado en cuenta para el momento de la
construccin del nuevo sistema.

53

FASE III

ANALISIS DEL SISTEMA

Descripcin del sistema actual (Procesos)

El levantamiento de informacin del sistema actual se basa en la


experiencia personal del tesista como antiguo miembro de la USE. Durante el
tiempo que labor en USE, pudo observar y entender en profundidad todos
los procesos y procedimientos internos de la corporacin que le permitirn
llevar a cabo este sistema.

Con la informacin recolectada se procedi a clasificar y organizar la


data, y despus de realizar los pertinentes anlisis, se pudieron determinar
los siguientes procesos:

54

Figura Nro. 01 Procesos del Sistema Actual


Fuente: Ibarra (2014)
A continuacin se presenta la descripcin de los procesos del sistema
actual de la USE.
55

El departamento de Unidad de Seguimiento Estatal (USE) perteneciente


a la empresa CANTV, ubicada en San Juan de Los Morros, brinda servicios
de vigilancia y monitoreo de las averas del departamento de Acceso I (AX I)
todos los das de manera continua.
A continuacin se puntualizan todos los procesos que se realizan en la
USE:
1. ASIGNACIN MANUAL DE LOS INCIDENTES CRITICOS: Diariamente el
Supervisor del departamento Acceso I (AX I) entrega una lista de las averas
crticas que sern atendidas durante el trascurso del da. La misma se
encuentra identificada con el tcnico, el carnet del tcnico que atender esas
averas durante el transcurso de ese da. El personal de la USE procede a
revisar cada incidente en el sistema SACAS para verificar la asignacin
correcta de los carnets. Una vez realizada la asignacin de cada nmero, se
procede a iniciar el seguimiento.

Los tcnicos encargados de las

reparaciones tambin poseen la lista que se le entrego a la USE, de tal forma


que sirve de gua a la hora de verificar los resultados.
Existen otros tipos de averas que se pueden recibir adems de los
provenientes del departamento de AX I, los cuales son determinados por la
USE de la siguiente manera: clientes de 3era edad, tiempo acumulado
excesivo, clientes premium, averas pendientes, caso CONATEL, caso twitter,
caso INDEPABIS, casos gerenciales, casos muy crticos, para los cuales el
departamento puede cambiar o adjudicarles prioridad segn su conveniencia.
Los miembros de la USE pueden emitir rdenes de darle prioridad a alguno
de esos casos, por encima de los supervisores.
Estos casos muchas veces son recibidos mediante correo electrnico,
visitas de clientes a las oficinas, llamadas directa a la oficina USE, entre

56

otros. Las prioridades son diferenciadas de las dems averas a travs de


distintos elementos, como pueden ser un resaltador (marcatexto) de color,
smbolos varios como asteriscos, guiones, crculos, mediante el uso de block
de notas (que se colocaban en la pantalla del ordenador para evitar su
olvido) o simplemente se agregaba solamente el nmero de dispositivo en
una de las hojas de la lista de incidentes diarios y se le asignaba un tcnico
cualquiera para que la atendiera.
2. ANOTACIN MANUAL DE INFORMACIN: Una vez asignados los
incidentes e iniciado el seguimiento, el personal de la USE recibe informacin
constante, de forma oral, escrita o va telefnica por parte del personal
tcnico y/o abonados referente a: direcciones imprecisas, actualizaciones de
distintos datos que conforman un incidente crtico, ya sea nmero de
contacto errado, datos tcnicos cambiados, mudanzas no actualizadas,
instalaciones

ilegales,

solicitudes

de

enrutamiento;

validaciones

correspondientes, ya sean: averas reparadas, averas reparadas sin


cancelar, averas reparadas y canceladas, averas reparadas que aun
presentan fallas.
Todo este registro se lleva a cabo de manera manuscrita ya sea en la
misma lista entregada por el supervisor (si haba espacio), o al reverso, o en
una hoja blanca, cuaderno, block o lo que estuviese disponible en el
momento.
3. REVISIN CONTINUA DEL SISTEMA SACAS: Durante el transcurso del da
los integrantes de la USE deben revisar constantemente, hasta 3 veces cada
incidente de cada tcnico para verificar el estatus (Abierto - Cerrado). Esto se
hace debido a que no todos los tcnicos informan el cierre de sus averas, no
utilizan las herramientas existentes para el cierre de los incidentes. Muchas
veces no contestan el telfono celular.

57

Al no tener conocimiento sobre el estatus del incidente, el equipo USE


no puede verificar la efectividad del mismo con el cliente y por ende se
acumula el trabajo y se retrasan las cancelaciones, la toma de decisiones y
las labores se ralentizan, provocando el trabajo bajo presin debido a la
necesidad de enviar las averas al Centro de Servicio (CDS) que posee un
horario de trabajo diferente al horario de oficina que tienen las oficinas
regionales de CANTV.
4. VERIFICACIN DE EFECTIVIDAD DEL SERVICIO: Despus de haber
revisado el estatus de sistema SACAS y encontrar el estatus Cerrado, se
procede a la verificacin de la efectividad de la reparacin. Muchas veces
sucede que el tcnico informa la reparacin y no se encuentre cerrado el
incidente, por lo que queda de parte del miembro de USE verificarlo y
enviarlo a cancelar utilizando un formato propio.
Tambin puede suceder que el tcnico lo haya reparado y lo haya
cancelado utilizando alguna de las herramientas disponibles en la empresa
(Open Wave, comunicacin directa con el CDS) sin realizar la verificacin de
la efectividad del incidente, por lo tanto notifica al equipo USE para que
realice dicha verificacin y en caso de persistir, informar al cliente para que
realice nuevamente su reporte, o en su defecto, notificar nuevamente al
tcnico para que se dirija nuevamente a la ubicacin de la falla y proceda a
resolverla de manera concreta, an estando cerrada, puesto que es su
responsabilidad reparar los incidentes de manera efectiva.
5. CONTEO MANUAL DE LA LABOR DIARIA: Una vez realizado el seguimiento
y haber tomado nota de todos los datos suministrados por los tcnicos y los
clientes se procede al conteo de los resultados diarios, ya sean: averas
crticas resueltas (cola), averas sin reparar, averas efectivas sin cancelar,
averas efectivas sin confirmar. Dicho seguimiento debe realizarse por

58

tcnico, por rea, por cola, entre otros.


6. CALCULO MANUAL ESTADSTICO: Una vez realizado el conteo y
finalizando la jornada se procede a realizar un balance de las averas
asignadas segn su hoja diario y las averas solventadas. De esta manera se
busca medir el nivel de eficiencia de los tcnicos mediante el clculo de su
productividad al momento de resolver las averas.

Modelaje del Sistema

Despus de haber analizado la informacin contenida en la descripcin


del sistema actual ya se cuenta con los parmetros, caractersticas y datos
necesarios para proceder a modelar el sistema actual.

A continuacin se presenta el modelo del sistema al nivel macro, en su


primera instancia:

59

Figura Nro. 02 Entrega de reportes diarios de averas y mtodos de


seguimiento.
Fuente: Ibarra (2014)

60

A continuacin se presentan distintos niveles de datos presentes en el


diagrama.

Cuadro Nro. 01
Flujos de Informacin del Sistema Actual
FLUJO DE

DESCRIPCIN

INFORMACIN
Lista de averas

Listado de averas impresas que el Supervisor entrega a USE


para ser seguidas durante el da.

Averas

Gerencia Llamada recibida desde Gerencia General Tecnologa y

Regional

Operaciones para la atencin de averas prioritarias, las


cuales ameritan anotacin manual.

Avera de visitas diarias

Visitas recibidas en oficina, las cuales ameritan anotacin


manual.

Numero de carnet del Cada avera debe asignarse a un carnet de un tcnico de


tcnico de reparacin

reparacin.

Diferenciar asignaciones

Marcacin mediante smbolos de averas asignadas a carnet


correspondiente.

Verificar

direccin

de Llamada recibida de los tcnicos de reparacin solicitando

avera

ubicacin de direccin.

Llamada a cliente con Diferenciacin y anotacin de ubicacin exacta otorgada por


direccin imprecisa.

el cliente.

Solicitud de enrutamiento

Llamada recibida de los tcnicos de reparacin solicitando


enrutar averas.

Motivo de enrutamiento

Diferenciacin y anotacin de cola a enrutar avera y


comentario de enrutamiento.

Solicitud de actualizacin

Llamada recibida de los tcnicos de reparacin solicitando


61

actualizacin de datos.
Motivo de actualizacin

Diferenciacin y anotacin de datos a actualizar de la avera.

Cancelar nmeros

Llamada recibida de los tcnicos de reparacin solicitando


cancelacin de averas.

Motivo de cancelacin

Diferenciacin y anotacin de cdigo de cancelacin para


cancelar avera.

Cancelar nmeros USE

Llamada emitida a los tcnicos de reparacin solicitando


nmeros a cancelar.

Motivo

de

cancelacin Diferenciacin y anotacin de cdigo de cancelacin para

USE

cancelar avera.

Verificacin de nmeros Llamada emitida a clientes que presentan averas para


a cancelar

verificar reparacin efectiva.

Verificacin de nmeros Diferenciacin y anotacin de motivo de verificacin fallida de


fallida

las averas.

Informacin

los Llamada emitida a los tcnicos de reparacin solicitando

tcnicos

nueva revisin a avera informada efectiva no confirmada.

Conteo de labor

Conteo manual de labor diaria.

Creacin

de

archivo Transcripcin de datos obtenidos en el seguimiento.

Excel
Calculo de rendimiento
Verificacin
cancelada

de

Clculo realizado mediante Excel para el rendimiento diario.

avera Se verifica en el sistema si la avera realmente fue


cancelada.

Fuente: Ibarra (2014)

62

A continuacin se presentan los siguientes niveles de abstraccin


dentro del modelo grfico del sistema actual:

63

Figura Nro. 03 Proceso de Recepcin de Averas del Sistema Actual


64

Fuente: Ibarra (2014)

El flujo de informacin RECEPCIN DE AVERAS puede alimentarse


de distintos entes de donde pueden provenir dichas averas, tales como AX I,
Gerencia Regional, Visitas en Oficina e incluso la misma Gerencia. El
departamento de AX I emite una lista impresa con todas las averas a seguir,
la Gerencia Regional realiza llamadas solicitando la atencin de averas lo
que incide en anotaciones manuales, anotacin del motivo de la avera, cola,
fecha y prioridad. En el caso de las averas recibidas mediante visitas en la
oficina tambin requieren de anotacin de los mismos datos para poder ser
investigada y luego procesarlas.

65

Figura Nro. 04 Proceso de Solicitud de Enrutamiento del Sistema Actual

66

Fuente: Ibarra (2014)

El flujo de informacin SOLICITUD DE ENRUTAMIENTO se compone


de la recepcin de llamadas que realiza el tcnico de reparacin, para ello se
debe identificar el nmero a enrutar en las distintas listas, se debe diferenciar
el nmero como enrutamiento y la anotacin de la cola a la que se desea
enrutar. Luego se debe analizar cada caso y evaluar el uso de las
herramientas existentes para poder procesar el requerimiento del tcnico de
reparacin, de lo contrario debe enviarse un informe al Centro de Servicio de
CANTV ubicado en la Ciudad de Maracay.

67

68

Figura Nro. 05 Proceso de Solicitud de Actualizacin del Sistema Actual


Fuente: Ibarra (2014)

El flujo de informacin de SOLICITUD DE ACTUALIZACION se


compone de la recepcin de llamadas del tcnico de reparacin, la
identificacin del nmero a actualizar en las distintas listas, la diferenciacin
como actualizacin usando smbolos y la anotacin de la actualizacin
solicitada. Luego se debe realizar un archivo que deber ser enviado al CDS
para que este lo evalu y procese.

69

70

Figura Nro. 06 Proceso de Direccin Imprecisa del Sistema Actual


Fuente: Ibarra (2014)

El flujo de informacin DIRECCION IMPRECISA se compone de la


recepcin de llamadas del tcnico de reparacin, la identificacin del nmero
en las distintas listas, la realizacin de llamadas al telfono de contacto del
cliente para verificar la direccin, anotacin de la direccin exacta otorgada
por el cliente e informar al tcnico de reparacin la direccin obtenida.

71

72

Figura Nro. 07 Proceso de Cancelar Averas del Sistema Actual


Fuente: Ibarra (2014)

El flujo de informacin CANCELAR AVERAS se compone de la


recepcin de llamadas de los tcnicos de reparacin o la emisin de
llamadas desde USE, en el caso del primero, se realiza la identificacin del
nmero a cancelar en la lista diaria, la diferenciacin del nmero a cancelar
usando smbolos y la anotacin del cdigo de cancelacin; en el caso del
segundo se realiza la solicitud de nmeros listos reparados, la identificacin
de los nmeros dictados a cancelar en la lista diaria, la diferenciacin de los
nmero dictados usando smbolos y la anotacin del cdigo de cancelacin.

73

Figura Nro. 08 Proceso de Verificacin de Averas del Sistema Actual


Fuente: Ibarra (2014)

74

El flujo de informacin VERIFICACIN DE AVERAS se compone de la


emisin de llamadas desde USE a todos aquellos clientes que el tcnico ha
notificado como reparado. Una vez contestada la llamada el cliente deber
avalar como efectiva o no efectiva el estatus de su avera. En caso de no ser
efectiva se realizaran anotaciones del motivo de la falla para luego
informarlas al tcnico de reparacin responsable.
Cada vez que el departamento recibe las diversas solicitudes, toda la
informacin obtenida es anotada manualmente apoyndose de manera
directa con el sistema S.A.C.A.S. para poder ser canalizadas. Debido al flujo
de informacin se hace necesaria la diferenciacin de los distintos tems en
la lista diaria mediante el uso de smbolos varios y/o marcadores,
resaltadores u otras anotaciones. Mediante el uso de la herramienta Excel se
solicita su canalizacin con los entes correspondientes, pero debido a la
cantidad de informacin que se maneja este medio resulta ineficiente.
A continuacin se presenta el diagrama de actividades de la situacin
actual donde se pueden apreciar de mejor manera el desarrollo de estos
procesos:

75

Figura Nro.09 Diagrama de Actividades del Sistema Actual


76

Tabla de Campos de Datos

A continuacin se muestra la tabla de campos de datos del sistema


actual.

Cuadro Nro. 02
Tabla de Campos de Datos del Sistema Actual
#

CAMPO

TIPO

TAMAO/
FORMATO

PROCES
O

CI_CLIENT

VARCHAR

10

3,4,5

NOM_CLIENT

TEXT

30

4,5

APE_CLIENT

TEXT

30

4,5

TLF_CLIENT

VARCHAR

10

3,4,5

DA_ACT

DATE

DD/MM/AA

1,2,3,4,5

COD_CENT

NUM

1,2,3,4,5

NUM_DISP

VARCHAR

11

1,2,3,4,5
77

DESCRIPCIN
Cedula del Cliente, el
cual lo identifica en
algunas solicitudes
Nombre del Cliente, por
lo general compuesto
por dos. Tambin puede
representar
a
una
empresa.
Apellido del Cliente, por
lo general compuesto
por dos. Tambin puede
representar
a
una
empresa.
Telfono de contacto del
cliente,
numero
personal el cual solo es
representado como dato
nico.
Da Actual, el cual
identifica el da de
trabajo.
Cdigo
Central,
identifica
zona
de
trabajo.
Numero de dispositivo,

DIR_REP

TEXT

100

3,4,5

FECH_REP

DATE

DD/MM/AA

1,2,3,4,5

10

HORA_REP

DATE

a.m./p.m.

1,2,3,4,5

11

GRUP_ASIG

VARCHAR

12

1,2,3,4,5

12

CABLE_1

VARCHAR

2,3,4,5

13

PAR_1

VARCHAR

2,3,4,5

14

ARM_TERM_1

VARCHAR

2,3,4,5

15

CABLE_2

VARCHAR

2,3,4,5

16

PAR_2

VARCHAR

2,3,4,5

17

ARM_TERM_2

VARCHAR

2,3,4,5

18

AREA_TRAB

VARCHAR

1,2,3,4,5

19

CI_TEC

VARCHAR

10

2,5

78

representa el nmero de
identificacin del cliente
ante
la
empresa.
Numero averiado.
Direccin del reporte,
indica direccin del
nmero del dispositivo.
Fecha del Reporte,
representa la fecha del
reporte en el sistema.
Hora
del
Reporte,
representa la hora del
reporte en el sistema.
Grupo Asignado, indica
el tcnico asignado a
reparar la avera.
Cable
Central,
representa la ubicacin
en el cable.
Par Central, representa
la ubicacin en el
distribuidor.
Armario
Terminal,
representa la ubicacin
en el distribuidor.
Cable Local, representa
la ubicacin en el cable
local.
Par Local, representa la
ubicacin
en
el
distribucin local.
Armario
Terminal,
representa la ubicacin
en el ADS.
rea Trabajo Nombre,
representa la dificultad
de la avera (cola).
Cedula del Tcnico, la
cual es utilizada en las
solicitudes.

20

CARNET_TEC

VARCHAR

1,2,3,4,5

21

NOM_TEC

TEXT

30

1,2,3,4,5

22

APE_TEC

TEXT

30

1,2,3,4,5

23

CORREO_TEC

VARCHAR

40

24

TLF_TEC

VARCHAR

10

1,2,3,4,5

25

SAP_TEC

NUM

2,3,4,5

26

CLAVE_TEC

NUM

27

COD_CANC

NUM

Fuente: Ibarra (2014)

79

Carnet del Tcnico, la


cual es representado
por nmeros, o dato
alfanumricos.
Nombre del Tcnico,
por
lo
general
compuesto por dos.
Apellido del Tcnico,
por
lo
general
compuesto por dos.
Correo Electrnico del
Tcnico, el cual es
representado por uno
solo.
Telfono de contacto del
tcnico,
numero
personal el cual solo es
representado como dato
nico.
SAP
del
tcnico,
representa al tcnico
ante la empresa.
Clave
del
Tcnico,
compuesta
por
6
caracteres.
Cdigo de cancelacin,
indica el motivo del
cierre de la avera.

Determinacin de Situaciones Problemticas

A continuacin se presentan las situaciones problemticas que se


pudieron determinar a travs del sistema actual:

- El departamento USE de CANTV es una seccin muy nueva que


progresivamente ha ido creciendo tomando la responsabilidad de vigilar,
controlar y supervisar todo lo referente a las averas que se atienden
diariamente provenientes del departamento de AX I. Dado que las
operaciones diarias son constantes, el proceso de vigilancia se hace
obligatorio para mantener la secuencia de las actividades. Sin un monitoreo
constante el cmulo de informacin afectara de manera negativa las
operaciones de dicho departamento.
Dado que la cantidad de averas ha aumentado de manera progresiva,
se estn presentando retardos en la reparacin de los incidentes, generando
descontento por parte de los clientes.
-

A pesar de que la USE utiliza el sistema SACAS, este representa un


problema a la hora de realizar el seguimiento, ya que slo es utilizado para la
asignacin de los carnets de los tcnicos y para la revisin continua durante
todo el da el estatus de los incidentes. El seguimiento de las averas hasta
lograr su cierre se lleva a cabo a mano, no permitiendo que se agilicen la
mayora de sus procesos, sobre todo a la hora de la entrega de resultados a
la gerencia.

Se observan excesivas anotaciones que dificultan y hacen muy lento todo el


seguimiento, haciendo tedioso el trabajo, generando desorganizacin y
prdida de informacin, afectando a los abonados.

80

Al finalizar el conteo de los incidentes por cancelar, verificados y efectivos,


se procede a la transcripcin de los nmeros, cola, carnet del tcnico, clave
de acceso al cierre de averas y responsable USE que realiza el seguimiento,
haciendo de esto una prdida de tiempo, segn sea la cantidad de incidentes
resueltos en el da.

Al finalizar la jornada, la lista diaria de incidentes es almacenada en un


archivero, el cual contiene toda la informacin del seguimiento separado por
meses. La cantidad de informacin acumulada que generalmente no se
vuelve a utilizar, compromete el espacio fsico de la oficina.

La bsqueda de informacin se hace tediosa, afectando la comparacin de


las estadsticas diarias, as como tambin la comparacin del rendimiento del
tcnico.

A nivel de diagnstico se observa como problemtica existente una


notable dependencia del sistema SACAS para la verificacin manual, en
reiteradas ocasiones durante el da, del estatus de los incidentes, as como
tambin la constante prdida de informacin debido a la desorganizacin y
un excesivo registro de informacin en mltiples papeles y formatos. Esto
ocurre debido a la gran cantidad de informacin que se necesita para realizar
un correcto seguimiento y la cantidad de anotaciones que se llevan a cabo y
por la falta de una herramienta automatizada que se dedique nicamente a
realizar seguimiento y agilice las tareas de la Unidad de Seguimiento
permitiendo un mejor control de toda la informacin.

81

Solucin propuesta

De acuerdo con el diagnstico realizado se plantea el diseo y


construccin de un Sistema Web para el Seguimiento de las Reparaciones
de las Averas del Departamento de la Unidad de Seguimiento de CANTV
San Juan de Los Morros.

Este sistema debe satisfacer la problemtica existente, y adems,


tambin debe cumplir con brindar a los usuarios del sistema un conjunto de
nuevas funciones y herramientas que permitan agilizar los procesos, registrar
toda la informacin necesaria, mejorar el tiempo de respuesta y manejar de
manera eficiente toda la informacin recabada.

Todo esto coadyuva al desarrollo de la automatizacin informtica de un


sistema que se lleva casi en su totalidad de forma manual.

Alcances del sistema

El sistema de seguimiento de reparaciones llevar a cabo funciones de


apoyo directo al personal de la Unidad de Seguimiento en los procesos de
registro de datos, conteo de labor diaria y muestreo de datos estadisticos de
resultados.

El sistema se encuentra orientado nicamente a la atencin de las


averas provenientes del departamento de Acceso I (AX I) perteneciente a la

82

regin de San Juan de Los Morros. El nuevo sistema no cancelar averas


de ningn tipo, esto lo seguir haciendo el CDS o en su defecto a travs de
la herramienta Open Wave de CANTV, segn acontezca.

A su vez, el sistema emitir tres tipos de reportes que facilitarn la


gestin diaria a la gerencia red. Entre ellos tenemos: informe de la gestin
diaria, expresado en cantidad de averas en la calle, cantidad de averas
resueltas, averas sin resolver, y tcnico responsables. Esto con la finalidad
de ofrecer a la gerencia una visin general de las actividades diarias, la cual
se puede enviar va correo electrnico o en su defecto imprimirse y
entregarse en fsico. Por otro lado, mostrar un segundo reporte, que estar
conformado por aquellos incidentes por cancelar, que son aquellos que ya se
encuentran confirmados por el tcnico, verificado con el cliente, y poseen
estatus de abierto, los cuales sern enviados al CDS a la maana siguiente
para que proceda con su debida cancelacin. Y evitar su aparicin en lo
indicadores diarios provenientes de la Gerencia de Gestin Tecnologa y
operaciones. Y un ultimo reporte que estar formado por aquellas averas
que aun se mantienen sin reparacin.

El sistema, tambin almacenar toda la informacin introducida en el,


con el fin de evitar la duplicidad de los datos y pudiendo retomar aquellos
incidentes que an se mantienen en estatus abierto y hayan sido atendidos
en das anteriores.

El registro con precisin de la fecha y hora en que se realizan las


operaciones tambin forma parte del sistema, esto con la finalidad de llevar
un buen manejo de la informacin.

83

Limitaciones del proyecto

El desarrollador del sistema observa que existen dos tipos de


limitaciones que entorpeceran considerablemente la funcionalidad del
sistema, a saber: la mltiple asignacin de los incidentes, el cual depende
completamente del funcionamiento del sistema SACAS, as como tambin de
la conexin que exista entre ellas para permitir la asociacin de ambas
herramientas de manera que los cambios efectuados en uno, se reflejen en
el otro.

Otra limitacin sera la revisin del estatus de los incidentes, Abierto o


Cerrado, el cual tambin depende de una conexin exitosa entre el nuevo
sistema y la herramienta SACAS para lograr explotar las funcionalidades del
sistema.

Ambos procesos son de vital importancia para el buen manejo del


seguimiento de reportes de manera diaria, por lo tanto se solicitaran los
permisos necesarios para entrelazar ambas herramientas y lograr un
funcionamiento sincronizado, para que al activarse la primera, la segunda
pueda acoplarse.

A nivel del usuario, cabe destacar mltiples beneficios como producto


de la construccin de un sistema que les permita llevar a cabo sus funciones
de manera rpida y amena. Una mejor respuesta ante los abonados y por
consiguiente el ahorro de tiempo y esfuerzo a la hora de prestar un servicio.

84

En cuanto a la construccin, el desarrollador cuenta con los equipos


necesarios para tal fin, y adems, se tienen los conocimientos necesarios
para la elaboracin de este sistema. Igualmente, se desarrollar de manera
eficiente la fase de codificacin, es decir, la construccin total de la nueva
herramienta.

Necesidades Generales del Sistema

A continuacin se describen las necesidades generales del sistema,


hardware, software y funcionales.

Necesidades de Hardware

Equipo Servidor

Procesador Intel Core i7

Memoria RAM 8GB

Disco Duro con 600GB de capacidad, 80GB libres para datos.

Equipo Cliente

Procesador Core Duo 3 GHz

Memoria RAM 2 GB

Disco Duro 40MB de espacio libres.

Necesidades de Software

Equipo Servidor

85

-Sistemas Operativos

Debian Server

-Gestor de Base de Datos

MySQL

-Paquete de Aplicaciones

FPDFreader

PHPExcel

JPGRAPH

Equipo Cliente

-Sistema Operativo

Debian

-Browser

Google Chrome

Chromium

Iceweasel

86

Necesidades Funcionales:

Las caractersticas principales que va a contemplar el nuevo sistema de


seguimiento de reparaciones de averas telefnicas de CANTV son: la
automatizacin de registro de todos los procesos manuales, la generacin de
archivos PDF y el muestreo de estadsticas de todo lo recabado durante las
jornadas. A continuacin se presenta un listado con las caractersticas
funcionales demandadas por el nuevo sistema:
Inscripcin de usuarios.
Acceso limitado solo a miembros de la USE previamente
evaluados.
Respaldo y mantenimiento de la informacin.
Manual de instrucciones de uso del nuevo sistema.
Disponibilidad para descargar archivos PDF de jornadas
anteriores.
Disponibilidad para visualizar en pantalla estadsticas de
jornadas anteriores.
Registro de toda la informacin. recibida va telefnica, oral,
escrita o digital.
Control de usuarios.
Control de operaciones de los usuarios.
Historial de operaciones de los usuarios.
Posibilidad para imprimir resultados diarios.
Posibilidad para imprimir estadsticas diarias.

87

FASE IV

DISEO DEL SISTEMA

Tabla de Requerimientos
Los requerimientos de un sistema, Rabala (2005) los define como las
necesidades que se derivan con respecto a la funcionalidad de un servicio en
particular (p.45), siendo as, en el caso del sistema propuesto, los
requerimientos se manifiestan en trminos de automatizacin de los
procesos relacionados con el seguimiento de las reparaciones de averas
telefnicas de CANTV, as como tambin se toman en cuenta lo siguiente;
acceso a la informacin., seguridad, reportes, configuracin y despliegue de
informacin.
A continuacin se muestra una lista detallada de los requerimientos
necesarios para garantizar un optimo y adecuado diseo de la propuesta:

Cuadro Nro. 03
Tabla de Requerimientos del Sistema Propuesto
NIVEL

REQUERIMIENTO
1)
Restringir el acceso al sistema, realizada
mediante la validacin de los datos de entrada.
2)
Restringir el acceso a los archivos, comprende la
autorizacin del usuario.

SEGURIDAD
3)
Asegurar que se estn utilizando los datos,
archivos y programas correctos en y por el
procedimiento correcto.

88

4)
Garantizar que la informacin transmitida sea
recibida slo por el destinatario al cual ha sido enviada
y no a otro, mediante el uso de rutas preestablecidas.
5)
Verificar que la informacin recibida sea la
misma que ha sido transmitida, mediante el uso de
parmetros.
6)
Garantizar que existan otras alternativas de
transmisin entre diferentes puntos, realizada mediante
vistas previas.**
SEGURIDAD
7)
Asegurar que se disponga de pasos alternativos
de emergencia para la transmisin de informacin,
utilizando respaldos.
8)
Proteccin
discrecional,
mediante
la
identificacin de usuarios que permitan el acceso a
distinta informacin.
9)
Proteccin de Acceso Controlado, mediante la
auditoria de accesos e intentos fallidos de acceso a
objetos.
10)
Seguridad Etiquetada, se establece que el dueo
del archivo no puede modificar los permisos de un
objeto que est bajo control de acceso obligatorio.

11) Identificacin y Autentificacin, mediante la


prevencin del ingreso de personas no
autorizadas
utilizando
la Identificacin del
usuario registrado, y la verificacin que se
realiza sobre esta identificacin.
12)
Rol del acceso a la informacin, el cual permitir
el control de acceso de acuerdo con el rol de los
usuarios.
ACCESO
13)

Transacciones, las cuales requieren

89

de

una

clave al requerir el procesamiento de una transaccin


determinada, realizada por el administrador.
14)
Limitaciones
a
los
Servicios,
se refieren a las restricciones de la utilizacin de la
aplicacin, preestablecidos por el administrador del
sistema, mediante el uso de licencias para la utilizacin
simultanea del producto del software.
15) Modalidad de Acceso, el cual permite al usuario
el acceso sobre los recursos y a la informacin
(lectura, escritura, ejecucin, borrado, creacin,
bsqueda, modificacin, o todas), diferenciada
por tipo de usuario.
16)
Ubicacin y Horario, permite el acceso a
determinados recursos del sistema ya sea mediante la
ubicacin fsica o lgica de los datos o personas. El
horario permitir limitar el acceso de los usuarios en las
sesiones.
Control de Acceso Interno:
17)
Contraseas, permitir la autenticacin del
usuario y a su vez proporcionando proteccin a los
datos y aplicaciones.

ACCESO

18)
Sincronizacin de contraseas, asegura que el
usuario acceda con una misma contrasea a diferentes
peticiones interrelacionados.
19)
Caducidad y control, controla el cambio de
contraseas de los usuarios, definido por un periodo
mnimo de tiempo, ejecutado por el administrador.
20)
Encriptacin, permitir ocultar, asegurar
proteger la informacin y data del sistema.

21)
Listas de Control de Accesos: se refiere al
registro que contiene a los usuarios que poseen

90

permiso en el sistema, reflejado mediante la BD.


22)
Lmites sobre la Interfaz de Usuario, restringe a
los usuarios funciones especficas, ya sea men, vistas,
accesos.
23)
Etiquetas
de
Seguridad,
consiste
en
designaciones otorgadas a los recursos (archivo) con el
propsito de tener mayor control de accesos y la
especificacin de medidas de proteccin.

Control de Acceso Externo:

24)
Dispositivos de Control de Puertos, se
autoriza el acceso a un puerto determinado.
25)
Firewalls o Puertas de Seguridad,
permiten bloquear o filtrar el acceso a las redes,
previniendo la intromisin de terceros.
26)
Acceso de Personal Contratado o
Consultores, permite el control de acceso
temporal a personas de carcter especial.
27)
Accesos Pblicos, se garantiza el uso del
sistema solo por personas autorizadas, sin
acceso pblico previamente no registrado.
ACCESO

Administracin:

28) Seguridad lgica, involucra la implementacin,


seguimientos, pruebas y modificaciones sobre
los accesos de los usuarios al sistema.
29) Determinacin
de
los
controles
de
modificaciones, a travs de perfiles de usuarios.
30) Nivel

de

91

seguridad,

ejecuta

el

nivel

de

proteccin sobre los datos.


31) Nivel de informacin, depende de los niveles de
seguridad previamente establecidos.
32) Medidas de seguridad, implementada sobre la
informacin ms sensible o las aplicaciones
ms crticas.
33) Medidas de seguridad para cada uno de los
niveles.
34) Administracin de los usuarios, donde se
especifique la responsabilidad de cada uno de
ellos.

Administracin del Personal y Usuarios Organizacin del Personal: este proceso lleva
generalmente cuatro pasos:
35)
Definicin de puestos, contempla la clasificacin
de los roles para el otorgamiento de los permisos.
36)
Determinacin de la sensibilidad del puesto,
determina los permisos a los usuarios.
37)
Eleccin de la persona para cada puesto,
considera la experiencia de los usuarios al momento de
asignarles la permisologa.
38)
Entrenamiento inicial y continuo del empleado,
determina la adecuacin de los nuevos usuarios.

REPORTES

39)
Exportacin de archivo, permite la
seleccin de descarga de archivo diariamente.
40)
Seleccin de da, mes y ao para
descarga de archivos.
41)
Generar Estadsticas explicativas del

92

rendimiento diario.
42)
Generar
Grficos
Estadsticos
del
rendimiento diario.
43)
Seleccionar una comparacin fisica de
rendimiento diario.**
44)
Averas reparadas.
45)
Averas reparadas sin cancelar.
46)
Averas listas para cancelar.
47)
Averas en espera de actualizaciones,
enrutadas y por enrutar.
48)
Exportar reportes a una extensin .pdf con
proteccin de edicin.
Configuracin
predeterminada,
representa
informacin predefinida por el sistema.
49)

CONFIGURACIN

la

Configuracin de Usuario:

a.
Contrasea, otorga una
especificada por el administrador.

clave

b.
Usuario, otorga un nombre
especificado por el administrador.
c.
Rol, asigna
administrador.

un

acceso

de

de

limitado

acceso

usuario

por

50)

Configuracin de Idioma:

a.

Idioma, muestra el idioma espaol por defecto.

51)

Configuracin de Interfaz:

el

a.
Fuente, asigna una tipografa Arial, tamao
nmero 12, estilo normal, sombreado en negrita los
ttulos.
b.
Dimensin de ventana, posee configuracin de
acuerdo a la necesidad o llamados.

93

CONFIGURACIN

c.
Color de pestaas, posee color blanco, bordes
color azul.
52)

Configuracin de Seguridad:

a.

Registro de usuario, depende del administrador.

Configuracin personalizada:
53)

Configuracin de Usuario:

a.
Contrasea, permite la modificacin de la clave
de acceso solo al usuario administrador.
b.
Usuario, permite la modificacin del nombre de
usuario, solo al usuario administrador.
c.

Rol, asignado por el administrador.

54)

Configuracin de Idioma:

a.

Posee idioma espaol por defecto.

Lgico (Software):
55)
Formulario de Registro Usuarios:
a)
Datos Personales:
*Nombres
*Apellidos
DESPLIEGUE DE
INFORMACIN

*Cdula
*Correo Electrnico
*Direccin
*Especialidad

94

*SAP
*Usuario
*Contrasea
*Telfono Oficina
*Telfono Celular
*Rol
1)
Perfil de usuario:
a)
Login de Seguridad:
*Usuario
*Contrasea
Fsica (Hardware):
1)
Componentes Hardware:
a) Pantalla
b) Equipo Cliente:
*Procesador Core Duo 3GHz
DESPLIEGUE DE
INFORMACIN

*Memoria RAM 2 GB
*Disco Duro 40MB de Espacios libres.
c) Dispositivo de Entrada:
*Mouse
*Sensor Tctil.
d) Dispositivo de Salida:
*Documento Digital
*Impresora
e) Equipo Servidor:
*Procesador Intel Core i7
*Memoria RAM 8GB
*Disco Duro con 600GB de Capacidad, 80GB
libres para datos.
1)

Componente Software:

95

a)
Sistema Operativo:
*Linux Debian
*Windows Vista
*Fabricante: GNU/Linux y Microsoft.
b)

Aplicaciones Instaladas

*SACAS
*Gestor de Base de Datos: MySQL
*Paquete de Aplicaciones: FPDF, PHPExcel,
JPGRAPH.
*Browser: Chromium, Google Chrome.
c)
Mecanismo de Conexin:
*Tipo de Conexin: Internet Almbrica.

Fuente: Ibarra (2014)

Modelaje del nuevo sistema

El enfoque UWE proporciona una notacin de dominio especfico, un


proceso de desarrollo dirigido por modelos, y soporte de herramientas para la
ingeniera de aplicaciones web.Por efectos de esta investigacin el diagrama
de casos de uso representa la funcionalidad del sistema propuesto.

96

Cuadro Nro. 04
Descripcin del Modelo UML
SMBOLO

NOMBRE
Actor

Caso de Uso
Flujo de actividad
Include
Extend

97

DESCRIPCIN
Representa los Individuos
que interactan en la
gestin de procesos.
Seala la operacin que
se realiza.
Relacin que existe entre
un proceso y el actor.
Representa
la
dependencia
entre
acciones.
Representa
la
dependencia o no entre
acciones.

Figura Nro. 10 Diagrama de caso de uso General del Sistema Propuesto


Fuente: Ibarra (2014).

98

Figura Nro. 11 Diagrama de Caso de Uso de la Relacin entre Actores del


Sistema Propuesto
Fuente: Ibarra (2014)

99

Figura Nro. 12 Diagrama de Caso de Uso de Usuario Administrador del


Sistema Propuesto
Fuente: Ibarra (2014)

100

Figura Nro. 13 Diagrama de Caso de Uso de Usuario Ejecutivo del Sistema


Propuesto
Fuente: Ibarra (2014)

101

Entre los sujetos que interactuan con el producto tecnolgico propuesto


se tienen:

Figura Nro. 14 Sujetos que interactuan con el producto tecnolgico


propuesto
Fuente: Ibarra (2014)

102

Tabla de Campos de Datos del nuevo sistema

Cuadro Nro. 05
Tabla de Campos de Datos del Sistema Propuesto
CAMPO

TIPO

TAMAO/
FORMATO

CI_CLIENT

VARCHAR

10

NOM_CLIEN
T

TEXT

30

APE_CLIENT

TEXT

30

TLF_CLIENT

VARCHAR

10

DA_ACT

DATE

DD/MM/AA

COD_CENT

NUM

NUM_DISP

VARCHAR

11

DIR_REP

TEXT

100

PROCESO

DESCRIPCIN

Cedula del Cliente, el


cual lo identifica en
algunas solicitudes
Nombre del Cliente, por
lo general compuesto
1,3,5,6
por dos. Tambin puede
representar
a
una
empresa.
Apellido del Cliente, por
lo general compuesto
1,3,5,6
por dos. Tambin puede
representar
a
una
empresa.
Telfono de contacto del
cliente,
numero
1,3,4,5,6,
personal el cual solo es
representado como dato
nico.
Da Actual, el cual
1,2,3,4,5,6,7,8,9 identifica el da de
trabajo.
Cdigo
Central,
1,2,3,4,5,6,7,8,9 identifica
zona
de
trabajo.
Numero de dispositivo,
representa el nmero de
1,2,3,4,5,6,7,8,9 identificacin del cliente
ante
la
empresa.
Numero averiado.
Direccin del reporte,
1,3,4,5,6
indica direccin del
nmero del dispositivo.
1,3,5,6

103

FECH_REP

DATE

DD/MM/AA

10

HORA_REP

DATE

a.m./p.m.

11

GRUP_ASIG

VARCHAR

12

12

CABLE_1

VARCHAR

13

PAR_1

VARCHAR

14

ARM_TERM
_1

VARCHAR

15

CABLE_2

VARCHAR

16

PAR_2

VARCHAR

17

ARM_TERM
_2

VARCHAR

18

AREA_TRAB

VARCHAR

19

CI_TEC

VARCHAR

10

20

CARNET_TE
C

VARCHAR

21

NOM_TEC

TEXT

30

Fecha del Reporte,


representa la fecha del
reporte en el sistema.
Hora
del
Reporte,
1,2,3,4
representa la hora del
reporte en el sistema.
Grupo Asignado, indica
1,2,3,4,6,7,8,9 el tcnico asignado a
reparar la avera.
Cable
Central,
1,3,4,5,7,8,9
representa la ubicacin
en el cable.
Par Central, representa
1,3,4,5,7,8,9
la ubicacin en el
distribuidor.
Armario
Terminal,
1,3,4,5,7,8,9
representa la ubicacin
en el distribuidor.
Cable Local, representa
1,3,4,5,7,8,9
la ubicacin en el cable
local.
Par Local, representa la
1,3,4,5,7,8,9
ubicacin
en
el
distribucin local.
Armario
Terminal,
1,3,4,5,7,8,9
representa la ubicacin
en el ADS.
rea Trabajo Nombre,
1,3,4,5,7,8,9
representa la dificultad
de la avera (cola).
Cedula del Tcnico, la
4,6
cual es utilizada en las
solicitudes.
Carnet del Tcnico, la
cual es representado
1,2,3,4,5,6,7,8,9
por nmeros, o dato
alfanumricos.
Nombre del Tcnico,
2,3,4,8,9
por
lo
general
compuesto por dos.
1,2,3,4

104

22

APE_TEC

TEXT

30

23

CORREO_T
EC

VARCHAR

40

24

TLF_TEC

VARCHAR

10

25

SAP_TEC

NUM

26

CLAVE_TEC

NUM

27

COD_CANC

NUM

28

FECH_ING_
SIS

DATE

DD/MM/AA

29

DIR_IMPRE
CI

TEXT

40

30

CABLE_1_A
CT

VARCHAR

31

PAR_1_ACT

VARCHAR

32

ARM_TERM
_1_ACT

VARCHAR

Apellido del Tcnico,


por
lo
general
compuesto por dos.
Correo Electrnico del
Tcnico, el cual es
6,7,8
representado por uno
solo.
Telfono de contacto del
tcnico,
numero
1,2,4,5,6,7,8
personal el cual solo es
representado como dato
nico.
SAP
del
tcnico,
2,4
representa al tcnico
ante la empresa.
Clave
del
Tcnico,
6,7
compuesta
por
6
caracteres.
Cdigo de cancelacin,
6,7,8
indica el motivo del
cierre de la avera.
Fecha de Ingreso al
Sistema, indica la fecha
1,2,3,4,5,6,7,8,9 en que ingresa la
avera. Al sistema de
seguimiento.
Direccin
Imprecisa,
contiene el registro de la
1,2,5,7,8
direccin inexacta del
cliente.
Cable
Central
Actualizar, representa el
1,3,4,5,7,8,9
registro del cable centra
a actualizar.
Par Central Actualizar,
representa el registro
1,3,4,5,7,8,9
del
par
central
a
actualizar.
Armario
Terminal
1,3,4,5,7,8,9
Actualizar, representa el
2,3,4,8,9

105

33

CABLE_2_A
CT

VARCHAR

34

PAR_2_ACT

VARCHAR

35

ARM_TERM
_2_ACT

VARCHAR

36

INST_ILICTA

TEXT

30

37

ENRUTAMIE
NT

CHAR

38

TEC_INF_RE
P

CHAR

39

CLIENT_CO
NT

CHAR

40

CLIENT_AVA
L_REP

CHAR

41

TEC_INF_CI
ERRE

CHAR

registro del armario,


terminal a actualizar.
Cable Local Actualizar,
representa la ubicacin
1,3,4,5,7,8,9
en el cable local a
actualizar.
Par Local Actualizar,
representa la ubicacin
1,3,4,5,7,8,9
del
par
local
a
actualizar.
Armario
Terminal
Actualizar, representa la
1,3,4,5,7,8,9
ubicacin del armario,
terminal a actualizar.
Instalacin Ilcita, indica
el
registro
de
la
2,4,5,7,8,9
deteccin
de
instalaciones ilcitas.
Enrutamiento,
representa el registro de
2,4,5,7,8
solicitudes
de
enrutamiento.
Tcnico
Informo
Reparacin, indica el
registro
del
tcnico
2,3,4,6,7,8
cuando
reparo
una
avera
y
solicita
verificacin.
Cliente
Contactado,
indica el registro de la
1,2,3,4,5,6,7,8,9
llamada realizada al
cliente por verificacin.
Cliente
Avalo
Reparacin, indica el
1,2,3,4,5,6,7,8,9 registro de la llamada
realizada al cliente por
verificacin. positiva.
Tcnico Informo Cierre,
1,2,3,4,5,6,7,8,9 representa el registro
del
tcnico
cuando
106

42

REG_COD_
CANC

VARCHAR

1,4,6,7,8,

43

NOM_PRIO

CHAR

1,5

44

NOM_TEC_
REEM

VARCHAR

10

1,2

45

APE_TEC_R
EEM

VARCHAR

10

1,2

46

CARNET_TE
C_REEM

VARCHAR

10

1,2,3,5,7,8

47

TLF_TEC_R
EEM

VARCHAR

10

1,2,5,6,7,8

Fuente: Ibarra (2014)

107

informa cierre de la
avera desde su WAP o
CDS.
Registrar Condigo de
Cancelacin, registra el
cdigo de cancelacin
de la avera.
Nombre de la Prioridad,
indica la denominacin
de la prioridad de
algunas averas.
Nombre del Tcnico de
Reemplazo, indica el
nombre del tcnico que
reemplazara a otro.
Apellido del Tcnico de
Reemplazo, indica el
apellido del tcnico que
reemplazara a otro.
Carnet del Tcnico de
Reemplazo, indica el
carnet de trabajo del
tcnico de reemplazo.
Telfono del Tcnico de
Reemplazo, representa
el numero de telfono
de contacto del tcnico
de reemplazo.

Entidades de la Base de Datos (Tabla de Entidades)


A continuacin se presenta el diagrama Entidad Relacin del sistema
propuesto:

Figura Nro. 15 Diagrama Entidad Relacin del Sistema Propuesto


Fuente: Ibarra (2014)

108

Esquema Lgico de la Base de Datos

Figura Nro. 16 Esquema Lgico de la Base de Datos del Sistema Propuesto


Fuente: Ibarra (2014)

109

Carta de Navegacin

Figura Nro. 17 Diagrama de Navegacin del Sistema Propuesto


Fuente: Ibarra (2014)

110

Prototipo Grfico

UWE representa el prototipo grfico mediante el uso de modelos


abstractos, a continuacin se presentan las interfaces abstractas del sistema
propuesto:

Figura Nro. 18 Interfaz abstracta de inicio de sesiones de usuario del


sistema propuesto
Fuente: Ibarra (2014)

111

Figura Nro. 19 Interfaz abstracta de la pagina principal del sistema


propuesto
Fuente: Ibarra (2014)

112

Diagrama de Clases
UWE considera el diagrama de clases como un diagrama fundamental

para el anlisis y diseo de la propuesta.

Figura Nro. 20 Diagrama de clases del sistema propuesto


Fuente: Ibarra (2014)

113

Diagrama de Estados

Figura Nro. 21 Diagrama de Estados del mdulo seguimiento del sistema


propuesto
Fuente: Ibarra (2014)

114

Figura Nro. 22 Diagrama de Estados del mdulo informes del sistema


propuesto
Fuente: Ibarra (2014)

115

Figura Nro. 23 Diagrama de Estados del mdulo estadsticas del sistema


propuesto
Fuente: Ibarra (2014)

116

Figura Nro.24 Diagrama de Estado del mdulos usuarios del sistema


propuesto
Fuente: Ibarra (2014)

117

Figura Nro. 25 Diagrama de Estados del mdulo tcnicos del sistema


propuesto
Fuente: Ibarra (2014)

118

FASE V
DISEO Y DESARROLLO DEL PRODUCTO TECNOLGICO
PROPUESTO

Planificacin (Carta Gantt)


En el proyecto S.R.A. (Sistema de Seguimiento Regional de
Reparaciones de Averas) se realizo una planificacin en funcin de las
actividades involucradas en el desarrollo, obteniendo un total de XX
actividades, organizndose de la siguiente forma: diseo de interfaces,
creacin de base de datos, creacin de archivos de procesos, edicin de
libreras, creacin y prueba de funciones y pruebas al sistema.
Es necesario resaltar que cada tarea se paut en un lapso de tiempo
especifico, sin embargo, existieron actividades que requeran mayor tiempo
de trabajo y por consiguiente fueron retomadas en periodos diferentes pero
de manera continua, entre ellas se encuentran: el diseo de interfaz de
procesamiento de datos, edicin y prueba de las libreras, la adaptacin de
dichas libreras a la interfaz de procesamiento de datos y la concatenacin
de los informes de resultados. El resto de las tareas fueron realizadas de
forma progresiva con modificaciones leves.
Para la realizacin de este esquema se utilizo el software de gestin de
proyectos GanttProject bajo una licencia open source escrita en lenguaje de
programacin Java.
A continuacin se describen de manera detallada las actividades
realizadas durante el desarrollo de la herramienta:

119

Grafico Nro. 01

120

Objetivos
Registrar todos los datos necesarios

Objetivos Especificos
1

121

Estilo de programacin (Rutinas)

El sistema de seguimiento regional de reparaciones de averas (S.R.A.)


est diseado con lenguaje de marcado HTML5 (Hyper Text Markup
Language) con hojas de estilo en cascada CSS (Cascading Style Sheet),
siendo desarrollado con el lenguaje de programacin PHP (Hypertext PreProcessor) del lado del servidor y para la generacin de acciones en el
sistema se utilizo JAVASCRIPT DOM (Document Object Model) como
lenguaje de programacin del lado del cliente, bajo el paradigma de
programacin orientada a objetos (Object Oriented Programming) con una
base de datos realizada en MySQL, utilizando el patrn de diseo MVC
(Modelo Vista Controlador) orientado a la web. De esta manera, mediante la
combinacin de estas tecnologas se logro construir un sistema capaz de
responder a las eventualidades del departamento de seguimiento de CANTV.
A continuacin se tiene el cdigo fuente correspondiente al sistema
propuesto:

122

Grafico Nro. 02 Cdigo fuente para el registro de usuarios en el sistema


Fuente:

Ibarra

123

(2014)

Grafico Nro. 03 Cdigo fuente para modificar tcnicos en el sistema


Fuente:

Ibarra
124

(2014)

125

Grafico Nro. 04 Cdigo fuente para consultar usuarios en el sistema


Fuente:

Ibarra

126

(2014)

Documentacin (Mdulos)

El sistema estar formado por cinco mdulos para el usuario


administrador y tres mdulos para el usuario ejecutivo. Cada uno ejecuta una
accin predeterminada manteniendo una relacin entre si, entre ellos se
tienen:

Para el usuario administrador:


1) Modulo seguimiento

2)

Modulo informes

3)

Modulo estadsticas

4)

Modulo usuarios

5)

Modulo tcnicos

Para el usuario ejecutivo:


1)

Modulo seguimiento

2)

Modulo informes

3)

Modulo estadsticas

Ahora bien, el modulo seguimiento posee mas importancia dentro del


sistema ya que es el encargado de realizar la vigilancia de los incidentes, y
del cual dependen la ejecucin de los acciones del resto de los mdulos.

Modulo Seguimiento:

En este segmento el sistema realizara todas las evaluaciones de los


incidentes a seguir de manera individual, de tal forma se busca vigilar,
127

controlar y supervisar la totalidad de las reparaciones de las averas


telefnicas criticas ingresadas en el sistema. Al mismo tiempo proporcionara
elementos para el registro en tiempo real de toda la informacin recibida en
el departamento, ya sea de forma oral, escrita o va telefnica, proporcionada
por el personal tcnico, supervisor de Acceso I (AX I), Gerente de
Operaciones, Lder del Departamento o el abonado.

Este modulo ser el encargado de almacenar, organizar, analizar y


custodiar cada uno de los incidentes que forman parte del segmento.
Una vez seleccionada la categora de iniciar jornada, el sistema solicita
la importacin de un archivo Microsoft Excel en un formato de archivo binario
pertenecientes a versiones iguales o superiores a 12.0 (2007), 14.0 (2010) y
15.0 (2012) y LibreOffice Calc pertenecientes a versiones 3.6 (2012), 4.0
(2013), 4.1 (2013) y 4.2 (2014), las cuales deben cumplir con requisitos
obligatorios para la aceptacin y almacenamiento en el sistema. Dicho
archivo debe provenir del sistema S.A.C.A.S. y el cual debe ser descargado
y editado por el Supervisor encargado del departamento de Acceso I (AX I) o
en su defecto el lder del departamento de seguimiento o alguno de sus
informantes. Es indispensable que el archivo a importar lleve el siguiente
orden en sus pestaas identificadoras, segn el formato predefinido por
S.A.C.A.S.:
1A. Dispositivo
1B. CodigoCentral
1C. NombreCliente
1D.TlfContacto
128

1E. GrupoAsignado
1F. Da de trabajo
1G. FechaHoraReporte
1H. DireccionReporte
1I. Cable1
1J. Par1
1K. Armario/Term1
1L. Cable2
1M. Par2
1N. Armario/Term2
1O. AreaTrabajoNombre

Ahora bien, las celdas que corresponden al tem 1E (GrupoAsignado)


debe ser llenado en su totalidad , con el objetivo de diferenciar la cantidad de
averas que trabajara cada tcnico por separado. Por otro lado, el tem 1F
(Da de trabajo) representa la fecha de la jornada laboral que se esta
realizando y debe expresarse de la siguiente manera, ejemplo: Jueves 2410-2013. Dentro de las celdas inferiores (el limite sera representado segn la
cantidad de averas que se decidan trabajar durante esa jornada) se debe
incluir la inicial del primer nombre y el primer apellido de cada tcnico de
soporte que se encargara de atender las averas asignadas por el Supervisor
de Acceso I (AX I). El resto de los tems no sern editados, ya que los
mismos son proporcionados directamente por el sistema S.A.C.A.S.

129

Esta validacin se realiza con el fin de lograr equidad en la evaluacin


de los procesos involucrados y evitar posibles errores.

En primera instancia el sistema analizara la hoja cargada para verificar


que el archivo ingresado cumple con todos los elementos obligatorios
necesarios para su aceptacin, y por consiguiente su evaluacin, de lo
contrario emitir un mensaje de alerta indicando que el archivo no cumple
con los requisitos aceptados, por lo cual deber ser nuevamente evaluado.
De resultar correcta, en primer lugar, el sistema mediante el uso de pestaas
utilizara el tem 1B (CodigoCentral) para diferenciar la zona de trabajo de la
jornada y mostrar su nombre al usuario, en segundo lugar, tomara como
referencia el numero de carnet de cada integrante del personal tcnico (tem
IE), con el fin de dividir toda la informacin evitando la mezcla de datos y
separando de forma ordenada los incidentes que corresponden a cada
tcnico, colocando tambin entre parntesis el numero de carnet del
trabajador al que hace referencia.

En la seccin de procesamiento de la informacin cargada se mostrara


un identificador, el cual se encuentra dividido en dos sectores, el primero
permitir visualizar los datos mas relevantes de los incidentes cargados, y el
segundo ofrece una serie de opciones que regirn el seguimiento. El primer
sector estar organizado de la siguiente manera:
1)

Nro

2)

Incidente

3)

Fecha Ingreso
130

4)

Fecha S.R.A.

5)

Cola

6)

Observacin

El primer tem permitir enumerar la cantidad de incidentes que


corresponden a cada tcnico de reparacin, el segundo tem engloba los
nmeros de dispositivos que poseen un reporte de avera, el tercer tem hace
referencia a la fecha de reporte de la avera en el sistema S.A.C.A.S.
(FechaHoraReporte), el cuarto tem especifica la fecha de ingreso en el
sistema S.R.A., el quinto tem evidencia la cola del dispositivo que posee la
avera (AreaTrabajoNombre) y el sexto tem es un espacio que permite
registrar comentarios referentes al incidente.

Hay que destacar que el tem de observaciones (tem numero 6) ser


utilizada para registrar notaciones recibidas de cada incidente con el fin de
mantener la integridad de la informacin evitando perdida de datos; entre la
informacin

que

se

puede

transcribir

en

esta

seccin

se

tiene:

actualizaciones de datos del abonado (nmeros de contacto errados,


direccin mal canalizada, comentarios, registros temporales), mudanzas no
actualizadas, entre otros.), las cuales podrn ser enviadas al CDS para que
puedan ser procesadas de manera mas rpida evitando inconvenientes al
momento de realizar el seguimiento.

En el sector restante se posicionaran las consignas individuales que


funcionaran como agentes principales para realizar el seguimiento y permitir
131

que el sistema tome decisiones y emita las alertas y recomendaciones


correspondientes. Las mismas se identificaran de la siguiente manera:

Opcin 1. Registrar cancelacin: la cual al ser seleccionada

mostrara 4 tem individuales que almacena la informacin otorgada por el


tcnico-abonado y as lograr el cierre de la avera.

Opcin 2. Enrutamiento: permite la seleccin de la cola destino

de la avera a la que se debe solicitar el cambio. En este caso solo se


otorgan al usuario las colas destino de las colas criticas mas comunes, tales
como: ABAE, ABAIR, CABL(XX), DISP(XX), RPTRA y SUPRA.

Opcin 3. Prioridad: muestra un listado de opciones de

prioridad que posee el departamento, tales como: tercera edad, caso Twitter,
caso CONATEL, caso INDEPABIS y caso gerencia.

Opcin 4. Registrar actualizacin: almacena la informacin

referente a la distribucin primaria y secundaria de las averas en las redes


de la empresa.

Opcin 5. Instalacin ilcita: concede un espacio para describir

la deteccin de aquellas instalaciones que no cumplen con los reglamentos


de la compaa.

Opcin 6. Direccin imprecisa: registra la informacin obtenida

por el cliente y el tcnico de reparacin.

Opcin 7. Solicitud de cancelacin: registra el cdigo de

cancelacin otorgado por el tcnico de reparacin.

Cada consigna estar compuesta por registros abiertos (informacin


otorgada por el usuario), cerrados (si y no) y de seleccin (distintas opciones)
132

que podrn ser seleccionados dependiendo del requerimiento, de esta forma


se busca registrar cada proceso que realiza el personal del departamento de
seguimiento evidenciando la constante comunicacin existente entre el
personal del departamento de seguimiento, el abonado y el personal tcnico.

Por otro lado, la seccin de prioridades servir de gua para el sistema


para ordenar los incidentes de tal forma que se le pueda indicar al personal
tcnico la importancia que posee cada uno de ellos. Las prioridades se
ordenan segn el peso que tengan dentro del tiempo de atencin estipulado
en el reglamento de la empresa, ordenndose as: 1. Clientes de tercera
edad, 2. Caso INDEPABIS, 3. Caso CONATEL, 4. Caso Twitter, 8. Caso
gerencia. En caso de existir varios incidentes con el mismo nivel de prioridad,
sern organizados de manera progresiva hasta iniciarse la prioridad que le
sigue.

El sistema debe resguardar la informacin de cada archivo Excel


importado para la emisin de informes descriptivos a la gerencia, realizar
clculos estadsticos correspondientes a las reparaciones de averas
(efectivas, no efectivas, por cancelar, ), rendimiento general del tcnico y
solicitud de la informacin segn sea requerida.

133

134

Grafico Nro. 05 Cdigo fuente de librera PHPExcel que procesa los datos ingresados mediante archivos .xls
Fuente:

Ibarra

135

(2014)

Modulo Informes:

En este modulo el sistema permitir la visualizacin de informes de


resultados de las acciones registradas en el modulo seguimiento. Esta
seccin se muestra a travs de dos secciones diferentes, en primer lugar se
encuentra el filtro informe por resultados, el cual se clasifica en: informes por
resultados e informe individual, y en segundo lugar el informe por averas, el
cual se clasifica en averas efectivas, averas pendientes y averas
canceladas.
El informe por resultados de jornadas comprende un resumen general
de los totales de los registros realizados durante el seguimiento de las
reparaciones de averas. Esta constituido de la siguiente manera:

Seccin superior: contiene la identificacin de la empresa y

jerarqua del departamento responsable. En el lado izquierdo de la hoja se


encuentra el logotipo de la empresa y en el lado derecho, el logotipo del
sistema S.R.A. Por consiguiente se puntualiza el nombre del informe emitido,
y para finalizar se describe la fecha de la jornada de trabajo, la cantidad de
averas emitidas en esa jornada, hora de inicio y hora fin.

Seccin central: contiene una tabla descriptiva que muestra los

resultados provenientes del modulo seguimiento. Se divide de la siguiente


manera:

Columna 1:

tcnico, identifica a los tcnicos que trabajaron

durante la jornada.

Columna 2: Averas asignadas, contiene la descripcin de los

totales correspondiente a cada tcnico.


136

Columna 3: Averas resueltas: contiene la descripcin de los

totales correspondiente a cada tcnico.

Columna 4: Averas pendientes: contiene la descripcin de los

totales correspondiente a cada tcnico.

Columna 5: Averas criticas resueltas: contiene la descripcin

de los totales correspondiente a cada tcnico.

Columna 6: Colas averas criticas resueltas: contiene la

descripcin de los totales correspondiente a cada tcnico acompaadas del


nombre de la cola perteneciente.

Columna 7: Averas criticas rezagadas: contiene la descripcin

de los totales correspondiente a cada tcnico acompaadas del nombre de la


cola perteneciente.

Seccin Inferior: siguiendo el mismo orden, en la

parte

posterior a la tabla se muestra un resumen global de los totales de todas las


acciones realizadas por todos los tcnicos, indicando tambin el rendimiento
en de la jornada segn la cantidad de averas emitidas y averas
solventadas.

Para finalizar, el documento refleja la informacin que determina la


validez del informe, haciendo nfasis en el sustento proveniente de la
gerencia y as canalizar de manera mas rpida la veracidad de la
informacin. A su vez hace referencia al nombre del sistema del cual fue
descargado el reporte, reflejando tambin la hora de la descarga.

137

El informe por resultados individuales comprende los mismo datos que


el informe por resultados de jornadas, teniendo la diferencia de en que sern
filtrados por tcnicos que realizaron dichos trabajos.

El informe por averas efectivas comprende todos aquellos incidentes


que el departamento de seguimiento logro confirmar como reparados siendo
avalados por el usuario. Se encuentra estructurado de la misma forma que el
informe por resultados de jornada. Sin embargo, se diferencia en la
constitucin de la tabla, la cual se estructura as:

Columna 1: tcnico, contiene la identificacin de los tcnicos

que trabajaron durante la jornada, utilizando la inicial de su primer nombre y


el primer apellido, as como tambin el numero de carnet de trabajo.

Columna 2: Dispositivo, contiene los nmeros de telfono

confirmados efectivos que correspondiente a cada tcnico.

Columna 3: Cola: contiene el nombre de la cola que hace

referencia al numero de telfono confirmado efectivo correspondiente a cada


tcnico.

Columna 4: Cdigo de cancelacin: contiene el numero de

cdigo de cancelacin de la avera una vez confirmada y avalada efectiva.

Por su parte, el informe por averas pendientes comprende a todas


aquellos incidentes que no lograron ser atendidos durante la jornada. Se
encuentra estructurado de la misma forma que el informe por averas
efectivas, diferencindose en la columna numero cuatro (4) al contener las
observaciones que validan la no atencin de los mismo.
138

El informe por averas canceladas comprende a todos aquellos


incidentes que fueron cerrados directamente por el tcnico de reparacin,
utilizando otros medios para su fin tales como: la aplicacin OpenWave,
llamada directa al CDS, IVR, entre otros. Se encuentra estructurado de la
misma forma que el informe por averas efectivas y el informe por averas
pendientes, diferencindose en la columna numero cuatro (4) al contener las
observaciones que validan que el tcnico informo el cierre del incidente.

Hay que destacar que dichos informes podrn ser descargados en


formato PDF en hoja tamao carta (8.5 por 11 21.59cm por 27.94cm). Los
mismos sern llenados de manera progresiva mientras se realiza el
seguimiento y se almacenan los registros. Dicha accin permitir visualizar
el informe sin culminar la jornada, lo cual favorece la consulta de resultados
sin afectar el seguimiento activo. Hay que aclarar, que al finalizar la jornada
se mostrara un mensaje de advertencia que solicitara la aprobacin de la
accin, que en caso de ser afirmativa dar por finalizado el seguimiento y no
se podrn reingresar dichas averas, por ende no se seguirn insertando
datos en los informes. En caso de obtener una respuesta negativa, se puede
continuar con el seguimiento.

139

Grafico Nro. 06 Cdigo fuente de librera FPDF que organiza los datos que
se mostraran en el informe de seguimiento
Fuente: Ibarra (2014)

140

Mdulo estadsticas:

En este segmento el sistema permitir la visualizacin de grficos de


resultados de las acciones registradas en el modulo seguimiento. Esta
seccin se muestra segn el rendimiento de trabajo obtenido en las
reparaciones de los incidentes, filtrndose de la siguiente forma, grficos por
jornada y grficos individuales.
En la seccin de grficos por jornada se muestran los resultados totales
obtenidos en el mdulo seguimiento, provenientes del informe de resultados
por jornada. Por otro lado, el grfico por resultados individuales comprende
los mismo datos que el grfico resultados de jornadas, teniendo la diferencia
en que sern filtrados por tcnicos que realizaron dichos trabajos.
Ambos grficos permitirn una mejor visualizacin de los resultados
simplificando toda la informacin que maneja el sistema.

141

Modulo usuarios:

Este segmento solo podr ser visualizado por el usuario administrador,


el cual tendr la facultad de otorgar permisos a aquellos empleados que
posean el perfil adecuado para ejecutar las tareas del sistema. El mismo se
encuentra estructurado de la siguiente forma: Registrar, modificar, consultar y
eliminar.
La seccin registrar hace referencia a los datos requeridos por el
sistema para otorgar privilegios de ingreso a la herramienta, para ello solicita
lo siguiente: nombre, apellido, nombre de usuario, contrasea, confirmar
contrasea, cedula, correo electrnico, telfono de oficina, telfono celular,
sap, tipo de usuario y direccin. La seccin modificar, consultar y eliminar
solicita el numero de cedula del usuario registrado para mostrar el formulario
original y realizar los cambios (modificar), los datos del usuario registrado
(consultar) y el cambio de estatus del usuario, activo o inactivo (eliminar).

142

Grafico Nro. 07 Cdigo fuente de accin de buscar/consultar usuario del mdulo usuarios
Fuente:

Ibarra

143

(2014)

Modulo tcnicos:

Al igual que el mdulo usuarios, este segmento solo podr ser


visualizado por el usuario administrador, el cual tendr la facultad de registrar
a aquellos tcnicos de reparacin que trabajen en la resolucin de los
incidentes. El mismo se encuentra estructurado de la siguiente forma:
Registrar, modificar, consultar y eliminar.
La seccin registrar hace referencia a los datos requeridos por el
sistema para otorgar privilegios de trabajo a los tcnicos que correspondan,
para ello solicita lo siguiente: carnet corporativo, nombre, apellido, cedula,
correo electrnico, telfono celular, sap, especialidad y direccin. La seccin
modificar, consultar y eliminar solicita el numero de carnet del tcnico
registrado para mostrar el formulario original y realizar los cambios
(modificar), los datos del tcnico registrado (consultar) y el cambio de estatus
del tcnico, activo o inactivo (eliminar).

144

Grafico Nro. 08 Cdigo fuente de accin de registrar tcnico del mdulo tcnicos
Fuente:

Ibarra
145

(2014)

Documentacin del sistema

Se presenta a continuacin las pantallas principales del sistema de


seguimiento regional de reparaciones de averas (S.R.A.), aplicado al
departamento USE de CANTV San Juan de Los Morros, Estado Guarico.

Grfico Nro. 9 Pantalla de inicio del sistema propuesto.


Fuente: Ibarra (2014)

146

Grfico Nro. 10 Pantalla de inicio de usuario o contrasea incorrectos del


sistema propuesto.
Fuente: Ibarra (2014)

147

Grfico Nro. 11 Pantalla de inicio de usuario administrador del sistema


propuesto. Incluye mensaje de bienvenida.
Fuente: Ibarra (2014)

148

Grfico Nro. 12 Pantalla de inicio de usuario ejecutivo del sistema


propuesto. Incluye mensaje de bienvenida.
Fuente: Ibarra (2014)

149

Grfico Nro. 13 Modulo Seguimiento de usuario administrador y usuario


ejecutivo del sistema propuesto. Incluye breve descripcin del mdulo.
Fuente: Ibarra (2014)

150

Grfico Nro. 14 Modulo Informes de usuario administrador y usuario


ejecutivo del sistema propuesto. Incluye breve descripcin del mdulo.
Fuente: Ibarra (2014)

151

Grfico Nro. 15 Modulo Estadsticas de usuario administrador y usuario


ejecutivo del sistema propuesto. Incluye breve descripcin del mdulo.
Fuente: Ibarra (2014)

152

Grfico Nro. 16 Modulo Usuarios de usuario administrador del sistema


propuesto. Incluye breve descripcin del mdulo.
Fuente: Ibarra (2014)

153

Grfico Nro. 17 Modulo Tcnicos de usuario administrador del sistema


propuesto. Incluye breve descripcin del mdulo.
Fuente: Ibarra (2014)

154

Grfico Nro. 18 Solicitud iniciar jornada en Modulo Seguimiento de usuario


administrador y usuario ejecutivo del sistema propuesto. Solicitud de
insercin de archivo Excel.
Fuente: Ibarra (2014)

155

Grfico Nro. 19 Ordenamiento de datos insertados en Modulo Seguimiento


de usuario administrador y usuario ejecutivo del sistema propuesto.
Fuente: Ibarra (2014)

156

Grfico Nro. 20 Vista de informes generados en Modulo Infornes de usuario


administrador y usuario ejecutivo del sistema propuesto.
Fuente: Ibarra (2014)

157

Grfico Nro. 21 Vista de grficos generados en Modulo Estadsticas de


usuario administrador y usuario ejecutivo del sistema propuesto.
Fuente: Ibarra (2014)

158

Grfico Nro. 22 Vista de registro de usuarios del Modulo Usuarios de usuario


administrador del sistema propuesto.
Fuente: Ibarra (2014)

159

Grfico Nro. 23

Vista de consulta de usuarios del Modulo Usuarios de

usuario administrador del sistema propuesto.


Fuente: Ibarra (2014)

160

Grfico Nro. 24 Vista de registro de tcnicos del Modulo Tcnicos de usuario


administrador del sistema propuesto.
Fuente: Ibarra (2014)

161

Grfico Nro. 25 Vista de modificar tcnicos del Modulo Tcnicos de usuario


administrador del sistema propuesto.
Fuente: Ibarra (2014)

162

Manual de Usuario e Instalacin

En este apartado se describir la informacin necesaria para utilizar el


Sistema de Seguimiento Regional de Reparaciones de Averas (S.R.A.) para
web y su funcionamiento.
El sistema SRA fue creado con el fin de brindar apoyo a los usuarios al
momento de realizar sus actividades cotidianas. Este manual esta orientado
a los usuarios finales involucrados en el seguimiento de reportes de averas
de USE de CANTV. Los conocimientos mnimos que deben poseer los
operarios del sistema son:
- Conocimientos bsicos acerca de manejo de programas.
- Conocimientos bsicos de navegacin en web.
- Conocimiento bsico de Internet.
- Conocimiento bsico- de Windows.

Especificaciones tcnicas:

Para la la implementacin del sistema SRA se requiere lo siguiente:


-Hardware:
El software soporta Chromium, Iceweasel en sistema operativo Linux,
a su vez soporta Google Chrome y Mozilla Firefox en sistema operativo
Windows.

- Software:

163

Se requiere una base de datos MySQL y para el servidor es requerido


un software Debian Server.

A.- Ingreso al sistema:

Para ingresar al sistema se debe tener en cuenta lo siguiente:


1)

Ubicarse en el icono del navegador web deseado, segn el sistema

operativo utilizado.
2)

Se debe ubicar en la barra de direcciones y se debe escribir la

direccin web del sistema.


3)

A continuacin se mostrara la pagina inicial del sistema S.R.A. Se da

la bienvenida y en caso de poseer un usuario registrado, podr ingresar al


sistema de lo contrario debe solicitar la inscripcin al administrador.
4)

El administrador es el nico individuo autorizado para inscribir

usuarios al sistema. As como tambin es el nico responsable de inscribir a


los tcnicos de reparacin y otorgar los permisos necesarios para su manejo.

B.- Ingresar al sistema con usuario y contrasea:

1)

En los cuadros de texto correspondientes se debe ingresar el nombre

de usuario y contraseas otorgadas por el administrador del sistema, luego


se hace click en Iniciar Sesin.
2)

De ser errneo los datos, el sistema devolver un mensaje indicndole

al usuario que los datos introducidos son incorrectos. Por lo tanto debe

164

reescribir los datos, de lo contrario deber comunicarse con el administrador


del sistema.

C.- Operacin del sistema:

Una vez accedido satisfactoriamente al sistema S.R.A. se cuentan con


las siguientes opciones:
1) Mdulos: el usuario administrador podr visualizar cinco mdulos
mientras que el usuario ejecutivo podr visualizar solo tres. Esto se debe a
que el usuario administrador es el nico capacitado para inscribir usuarios y
tcnicos (mdulos restantes).
1.1) La pestaa seguimiento hace referencia a las operaciones de
registro, anlisis y ordenamiento de los datos a ingresar. Al posicionarse
sobre ella y hacer click se mostrara un mensaje informativo que hace
referencia a las acciones que lleva el mdulo, con el fin de informar al
usuario sobre su utilidad. A su vez se podrn visualizar una lista desplegable
de tres opciones, las cuales son:
1.1.1) Iniciar Jornada: al hacer click en iniciar jornada se
mostraran dos botones en la posicin derecha de la pantalla, el primero
indica la seleccin de archivos, en el cual solo esta permitido formatos .xls y
.ods. Antes de realizar la importacin de un archivo es necesaria la revisin
del mismo con el fin de corregir posibles errores, tales como: espacios en
blancos y pestaa GrupoAsignado vaca o incompleta. Ambos errores son
comunes a la hora de importar, por lo que se considera necesario una
revisin previa del archivo. Al hacer click en Cargar Jornada el sistema abrir
165

una nueva pestaa que sera la encargada de gestionar los datos insertados.
Una vez seleccionado el archivo excel de la jornada se le debe dar click a
Cargar Jornada para que el sistema pueda analizar los datos, procesarlos e
insertarlos en la base de datos. Una vez procesada mostrara un mensaje
informativo al usuario indicndole si la carga fue o no exitosa. De no ser
exitosa, el usuario deber revisar el archivo a importar, y una vez realizada la
revisin puede volver a insertar los datos. De ser exitosa se debe ir al
siguiente paso.
1.1.2)Procesar Jornada: al hacer click se mostraran todos los
datos cargados en la base de datos, dejndose observar un orden
predefinido de datos para un mayor manejo de los mismos, segn la
informacin otorgada por el personal de la USE. Esta seccin se divide en
pestaas superiores y pestaas inferiores; las pestaas superiores hacen
referencia a la jornada que se esta trabajando (Zona de trabajo) y las
pestaas inferiores hacen referencia a los tcnicos de trabajo involucrados
en la jornada, dejndose ver los nmeros de carnet de cada tcnico para
informacin del usuario. Luego, en la parte central a las pestaas inferiores
se muestran en la seccin izquierda los datos principales de las averas, y los
datos a registrarse a cada avera en el rea derecha. Solo se puede guardar
un dato a la vez con una avera a la vez. Esta interfaz se repite por cada
pestaa de cada tcnico, haciendo referencia solo a las averas que posee
cada tcnico. Una vez finalizados todos los registros se deber finalizar la
jornada.
1.1.3)Finalizar Jornada: al hacer click en esta seccin se da por
culminado los registros de la seccin de procesar jornada. Al darle click
166

mostrara un mensaje de advertencia que indicara al usuario si esta seguro


de su operacin, de lo contrario no podr recuperar los registros.
1.2) La pestaa informes hace referencia a los resultados de los
registros realizados en la pestaa seguimiento. Al posicionarse sobre ella y
hacer click se mostrara un mensaje informativo que hace referencia a las
acciones que lleva el mdulo, con el fin de informar al usuario sobre su
utilidad. A su vez se podrn visualizar una lista desplegable con dos
divisiones de dos y tres opciones, las cuales son:
1.2.1) Por Resultados: muestra dos opciones internas que
permite diferenciar los resultados de una jornada. Al hacer click en la primera
se muestra la opcin Jornada, la cual hace referencia a los resultados
generales de todos los registros realizados en Procesar Jornada, al hacer
nuevamente click muestra un mensaje que indica que se debe elegir la fecha
del informe a descargar. El mismo se mostrara en una pestaa nueva del
navegador con la opcin a descarga. La segunda opcin se conoce como
Individual, la cual hace referencia a la opcin Jornada pero con la opcin
para descargar por numero de carnet del tcnico de reparacin. Al hacer
click sobre el numero de carnet del tcnico que se desea se desplegara una
nueva ventana con el informe correspondiente.
1.2.2) Por averas; muestra tres opciones internas que permite diferenciar los
tipos de registros realizados en durante la jornada. La primera opcin se
conoce como Efectivas, la cual hace referencia a aquellos registros con
solicitud de cancelacin y registro de cancelacin. La segunda opcin hace
referencia a las averas pendientes, las cuales engloban a todas aquellas
averas que no lograron obtener registros de cancelacin. La tercera opcin
167

se conoce como canceladas, las cuales hacen referencia a aquellas averas


que fueron canceladas directamente por el tcnico de reparacin. Al hacer
click sobre alguna de estas opciones se desplegara una pestaa nueva
mostrando el informe que indique la jornada.
1.3) La pestaa estadsticas hace referencia a los datos registrados en
la pestaa informes, mostrando los mismos resultados de manera grfica,
con la finalidad de apreciar de mejor manera los resultados diarios de la
jornada. Al posicionarse sobre ella y hacer click se mostrara un mensaje
informativo que hace referencia a las acciones que lleva el mdulo, con el fin
de informar al usuario sobre su utilidad. A su vez se podrn visualizar una
lista desplegable de una divisin de dos opciones, las cuales son:
1.3.1) Por Rendimiento: posee dos opciones internas que
permite diferenciar los grficos de cada registro de la jornada. La primera
opcin refleja de manera grfica los resultados generales de la pestaa
informes de jornada, mientras que la segunda muestra los grficos de
rendimiento de cada tcnico siendo buscados por numero de carnet. Al hacer
click sobre alguna de estas opciones se desplegara una pestaa nueva
mostrando el grfico seleccionado.
1.4) La pestaa usuarios esta destinada al registro de los usuarios de
la herramienta, la cual solo podr ser vista por el usuario administrador. Al
posicionarse sobre ella y hacer click se mostrara un mensaje informativo que
hace referencia a las acciones que lleva el mdulo, con el fin de informar al
usuario sobre su utilidad. Esta seccin se divide en cuatro opciones, las
cuales son:

168

1.4.1)Registrar: esta seccin se compone de 12 tems los


cuales deben ser llenados por el usuario administrador para lograr darle los
permisos necesarios al usuario previamente evaluado. Al hacer click en
aceptar el sistema devolver un mensaje de registro exitoso, de lo contrario
devolver un error en el registro.
1.4.2) Modificar: en esta seccin se debe ingresar el numero de
cedula del usuario final en caso de ser necesaria su modificacin. Al hacer
click en buscar mostrara el formulario con los datos de la cedula buscada,
con opcin a editar, de lo contrario emitir un mensaje de usuario no
encontrado.
1.4.3) Consultar: en esta seccin se debe ingresar el numero de
cedula del usuario final para verificar su inscripcin en el sistema, de lo
contrario deber registrarse. Al hacer click en buscar mostrara el formulario
con los datos del tcnico buscado, de lo contrario emitir un mensaje de
usuario no encontrado.
1.4.4) Eliminar: en esta seccin se debe ingresar el numero de
cedula del usuario a eliminar. Al hacer click en aceptar mostrara un mensaje
de registro exitoso, de lo contrario se debe revisar la informacin
suministrada, ya que el sistema mostrara como no exitoso el registro.
1.5)La pestaa tcnicos esta destinada al registro de los tcnicos de
reparacin que trabajaran durante las jornadas, la cual solo podr ser vista
por el usuario administrador. Al posicionarse sobre ella y hacer click se
mostrara un mensaje informativo que hace referencia a las acciones que
lleva el mdulo, con el fin de informar al usuario sobre su utilidad. Esta
seccin se divide en cuatro opciones, las cuales son:
169

1.5.1)Registrar: esta seccin se compone de 9 items los cuales


deben ser llenados por el usuario administrador para que el tcnico pueda
ser seguido durante la jornada. Al hacer click en aceptar el sistema devolver
un mensaje de registro exitoso, de lo contrario devolver un error en el
registro.
1.5.2) Modificar: en esta seccin se debe ingresar el numero de
carnet del tcnico de reparacion en caso de ser necesaria su modificacin. Al
hacer click en buscar mostrara el formulario con los datos del carnet
buscado, con opcin a editar, de lo contrario emitir un mensaje de tcnico
no encontrado.
1.5.3) Consultar: en esta seccin se debe ingresar el numero de
carnet del tcnico de reparacion para verificar su inscripcin en el sistema, de
lo contrario deber registrarse. Al hacer click en buscar mostrara el formulario
con los datos del carnet buscado, de lo contrario emitir un mensaje de
tcnico no encontrado.
1.5.4)Eliminar: en esta seccin se debe ingresar el numero de
carnet del tcnico de reparacion a eliminar. Al hacer click en aceptar mostrara
un mensaje de registro exitoso, de lo contrario se debe revisar la informacin
suministrada, ya que el sistema mostrara como no exitoso el registro.

D.- Cierre de sesin:

Para el cierre de la aplicacin es necesario ubicarse en la esquina superior


derecha de la aplicacin y hacer click en el enlace Cerrar Sesion, el usuario
cerrara la ventana principal y se ubicara en la pantalla de inicio de sesin
170

CONCLUSIONES

En el desarrollo de esta investigacin se encontr con la problemtica


que presentaba el departamento de Unidad de Seguimiento de CANTV San
Juan de Los Morros, Estado Gurico, con la finalidad de determinar su
dificultad y ofrecer posibles soluciones. Se dictamino que los procesos que
llevaba el departamento eran principalmente manuales, por lo que se planteo
el desarrollo de un sistema bajo ambiente web para el seguimiento de
reparaciones de averas telefnicas que realizan los tcnicos de reparacin
de la compaa, y as lograr agilizar dichos procesos y mejorar los tiempos de
respuesta a las acciones que realiza el departamento.
Ahora bien, para el diseo de la propuesta se realizo un levantamiento
de informacin que permiti la organizacin de toda la informacin que
maneja el departamento, ofreciendo como propuesta una aplicacin
automatizada amigable al usuario, mas rpida y eficiente al ejecutar las
actividades. En tal sentido, se logro el desarrollo de una herramienta que
permite el manejo, optimizacin, resguardo y control de la informacin de
USE, logrando un mejor desempeo en el espacio laboral, ahorrando tiempo,
esfuerzo y control en los resultados.
Finalmente con la implementacin de la propuesta se logro solventar
eficazmente

la

problemtica

presentada,

llenando

esperadas, mejorando la eficiencia del departamento.

las

expectativas

RECOMENDACIONES

En virtud de lo planteado anteriormente y durante el desarrollo de la


aplicacin, en funcin de los objetivos propuestos, con respecto al
departamento de Unidad de Seguimiento de CANTV, se recomienda:

El sistema debe admitir la seleccin mltiple de los incidentes

que integran una pestaa, con la finalidad de realizar asignaciones de


carnets de trabajo correspondientes a cada integrante del personal tcnico,
segn instrucciones emanadas por el supervisor del departamento de Acceso
I (AX I). No esta permitida la seleccin de incidentes entre pestaas. Esto
debe hacerse en comunicacin directa con los servidores de CANTV que
manejan el Sistema SACAS, con el fin de sostener un vinculo que permita
realizar dicha tarea de manera automatizada evitando perjudicar las
asignaciones, manteniendo un entorno amigable entre ambos sistemas.

Permitir el registro de tcnico de reemplazo, con el fin de

controlar todos los eventos que manejo la Unidad de Seguimiento.

Emisin de alertas al usuario. Una vez emprendido el

seguimiento habiendo realizado varios registros, el sistema ejecutara de


manera automatizada una evaluacin continua de cada dato almacenado,
dndole potestad absoluta para emitir alertas y recomendaciones oportunas
cuando un incidente sea ingresado de manera continua.

Las alertas y recomendaciones deben ser mostradas en la

parte inferior de cada incidente (solo si aplica) identificndose con el color


rojo para hacer referencia a la urgencia del caso. La misma estar
estructurada de la siguiente forma: incidente en cuestin (numero de

dispositivo), da y fecha inicial de ingreso al sistema (registro del da y fecha


de primera importacin), cantidad de das acumulados desde la primera
importacin expresados de manera numrica, distintas asignaciones
otorgadas por el Supervisor de Acceso I (AX I) mostrando entre parntesis
las fechas y carnets de trabajo al que fueron asignados los incidentes y por
ultimo debe realizar una recomendacin acorde al caso evaluado. Las alertas
y recomendaciones solo se cerraran despus de 2 das hbiles contndose a
partir del da en que fue mostrada.

Manejo de incidentes remanentes. En caso de ser ignoradas

estas advertencias, el sistema despus de un tiempo estipulado, creara


automticamente una nueva pestaa que lleva el nombre de Remanente, la
cual se mantendr fija sin opcin a cierre para mantener siempre alerta al
usuario sobre esas averas criticas ingresadas que aun se mantienen en
estatus abierto, acumulando tiempo de atencin.

Las

averas

criticas

que

posean

estatus

abierto

son

almacenadas y custodiadas hasta confirmar su operatividad, sin embargo,


despus de haber cumplido un lapso de 72 horas sin solucin, son
cambiadas a estatus pendiente y almacenadas dentro de la pestaa
remanente hasta que las mismas sean resueltas y pasen a estatus cerrado
y por ende desaparecer del orden de seguimiento. Por su parte, los
incidentes que logran el estatus cerrado indican la efectividad del
seguimiento permitiendo su desaparicin del orden de seguimiento. Estos a
su vez son almacenados ya que servirn de sustento para la generacin de
informes y estadsticas as como tambin darn soporte de datos en caso de
reincidencias.

Bsqueda de informes por fecha. La cual permitir una

ubicacin mas rpida de los nmeros que se estn siguiendo.

historial de rendimiento. Permitir el mejor manejo de las

actividades realizadas por los tcnicos de reparacin.

Formato de informe de Bsqueda por mes. Para futuras

evaluaciones de rendimiento de trabajo en la zona regional.

Perfil visto por el usuario. Opcin al usuario a cambiar por si

mismo sus contraseas.

En el caso de registros, especficamente el de los tcnicos, se

debe solicitar el nombre del supervisor directo del tcnico. En caso de que se
trabajen con reas forneas. Numero del telfono del supervisor y cargo.

Revisin de estatus abierto cerrado directamente con SACAS.

El cual deber ser manejado en conexin directa con S.A.C.A.S.

BIBLIOGRAFIA
JIMNEZ, E. (1998) Sistemas de Informacin, Rincn del Vago; [Fecha de
Consulta

15/05/2014]

[Link

de

Consulta

http://html.rincondelvago.com/sistema-de-informacion-administrativa.html ].
RODRGUEZ, A. (Noviembre 2012) Anlisis de Sistema, Blogger; [Fecha de
Consulta

15/05/2014]

[Link

de

Consulta

http://informacion-

sistematica.blogspot.com/2012/11/tecnicas-de-levantamiento-deinformacion.html ].
EDGAR. (Junio 2014) Programacin orientada a objetos WIKIPEDIA La
enciclopedia libre;

[Fecha de consulta 23/05/2014] [Link de Consulta

http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos ].
COPLIEN,J. REESNKAUG, T. (Marzo 2009) Modelo-Vista-Controlador
WIKIPEDIA La enciclopedia libre; [Fecha de consulta 23/05/2014] [Link de
Consulta
http://es.wikipedia.org/wiki/Modelo%E2%80%93vista%E2%80%93controlado
r]. ltima edicin (Julio 2014).

FOWLER, M. SCCOTT, K. (1999). "UML Gota a Gota", WIKIPEDIA La


enciclopedia libre; [Fecha de consulta 05/06/2014] [Link de Consulta
http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado].

GUTIRREZ, D. (Abril 2011) Casos de Uso, Diagramas de Casos de Uso,


Universidad de los Andes. Venezuela.

GUTIRREZ, D.

(Mayo 2011) Diagramas de Estados, Diagrama de

Actividades (UML Ilustrado), Universidad de los Andes. Venezuela.

ESCALONA, M. GUTIRREZ, J. (2007) Diagramas UML de actividades para


la definicin de reglas de negocio y comportamientos de RFs, Universidad de
Sevilla ETS Ingeniera Informtica.

COELLO, M. RUIZ, M. (Octubre 2008) Diagrama de Mdulos, Universidad de


Guayaquil Ingeniera en Sistemas.

HINZ, S. DUBOIS, P. (Noviembre 2009) MySQL Manuales de Referencias,


MySQL Base de datos de cdigo abierto ms popular del mundo, [Fecha de
Consulta 12/06/2014] [Link de Consulta http://dev.mysql.com/doc/ ].
BRAVO, D. (Julio 2014), Diagrama Entidad Relacin, Conocimiento con
todos y para todos EcuRed; [Fecha de Consulta 12/06/2014) [Link de
Consulta
http://www.ecured.cu/index.php/Diagrama_Entidad_Relaci%C3%B3n ].

BERZAL, F. (2014), Diseo Lgico de Bases de Datos Relacionales, DECSAI


Departamento de Ciencias de la Computacin e I.A, Universidad de
Granada.
KON, M. (Marzo 2014) Software Libre, Monografias.com; [Fecha de
Consulta 20/06/2014] [Link de Consulta
http://www.monografias.com/trabajos12/elsoflib/elsoflib.shtml ].
KONNE, OSEPU. (Mayo 2014) XAMPP WIKIPEDIA La enciclopedia libre;
[Fecha

de

consulta

20/06/2014]

[Link

de

Consulta

http://es.wikipedia.org/wiki/XAMPP ].
MAC. (Julio 2014) PHP WIKIPEDIA La enciclopedia libre; [Fecha de
consulta 25/06/2014] [Link de Consulta
http://www.youtube.com/watch?v=rp4UwPZfRis&list=RDJ3UjJ4wKLkg&index
=2 ].
MAC. (Julio 2014) Hoja de Estilos en Cascadas WIKIPEDIA La enciclopedia
libre;

[Fecha

de

consulta

20/06/2014]

[Link

http://es.wikipedia.org/wiki/Hoja_de_estilos_en_cascada ].

de

Consulta

S-ar putea să vă placă și