Infante Kevin

Proyecto de Grado
Presentado ante la ilustre Universidad de Los Andes como requisito parcial para
obtener el Ttulo de Ingeniero de Sistemas
n Web
Desarrollo de un Sistema de Informacio
rida
Centralizado para la CANTV del Estado Me
Por
Br. Kevin J. Infante O.

Tutor: Prof. Pablo Guillen
Asesor Industrial: Ing. Jose Velazquez
Junio 2009
c
2009
Universidad de Los Andes, Merida, Venezuela
Desarrollo de un Sistema de Informaci

on Web Centralizado
para la CANTV del Estado M
erida
Br. Kevin J. Infante O.
Proyecto de Grado Investigacion de Operaciones, 89 paginas
Escuela de Ingeniera de Sistemas, Universidad de Los Andes, 2009
Resumen: En el presente proyecto se realizo el dise
no, desarrollo e implementacion de
un Sistema de Informacion Web para la Red de CANTV Merida, que incluye una base
de datos y los diferentes mapas que describen las redes secundaria, fibra optica, urbana
e interurbana. Se utilizo el UML (Unified Modeling Language) el cual es un lenguaje
grafico para modelar, visualizar, especificar, construir y documentar un sistema de
software, como herramienta para el modelado de la base de datos con la que cuenta el
sistema. Dicho modelado permitio establecer con mayor facilidad las conexiones entre
las diferentes tablas y elementos de la base de datos. Para el desarrollo se utilizo el
manejador de base de datos MySQL.
Palabras claves: Sistema de Informacion Web, Bases de Datos, MySQL, Telefona,
Redes telefonicas.
Este trabajo fue procesado en LATEX.
A mis padres por ser lo mejor

de mi vida y mi mayor ejemplo, gracias.
Indice
Indice de Tablas
vii
Indice de Figuras
viii
Agradecimientos
xi
1 Introducci
on
1.1
Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . .
1.4
Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1
Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2
Objetivos Especficos . . . . . . . . . . . . . . . . . . . . . . . .
Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1
Revision bibliografica . . . . . . . . . . . . . . . . . . . . . . . .
1.6.2
Proceso de desarrollo . . . . . . . . . . . . . . . . . . . . . . . .
1.6
2 Marco te
orico
2.1
11
Sistemas de informacion . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.1.1
Actividades que realiza un sistema de informacion . . . . . . . .
12
2.1.2
Tipos de sistemas de informacion . . . . . . . . . . . . . . . . .
13
2.1.3
Sistemas de informacion Web . . . . . . . . . . . . . . . . . . .
14
2.2
Servidor Web Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3
Bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
iv
2.3.1
Bases de datos relacionales . . . . . . . . . . . . . . . . . . . . .
16
2.3.2
Lenguaje estructurado de consulta (SQL) . . . . . . . . . . . . .
17
2.3.3
El sistema de gestion de bases de datos MySQL . . . . . . . . .
17
2.3.4
Algunas caractersticas de MySQL . . . . . . . . . . . . . . . .
18
2.4
Arquitectura orientada a servicios (SOA) . . . . . . . . . . . . . . . . .
19
2.5
Protocolo SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.6
Lenguaje de modelado unificado (UML) . . . . . . . . . . . . . . . . .
22
2.6.1
Diagramas de clases
23
2.6.2
Diagramas de componentes
. . . . . . . . . . . . . . . . . . . .
23
2.6.3
Diagramas de objetos . . . . . . . . . . . . . . . . . . . . . . . .
24
2.6.4
Diagramas de despliegue . . . . . . . . . . . . . . . . . . . . . .
24
2.6.5
Diagramas de paquetes . . . . . . . . . . . . . . . . . . . . . . .
24
2.6.6
Diagramas de actividades . . . . . . . . . . . . . . . . . . . . .
24
2.6.7
Diagramas de casos de uso . . . . . . . . . . . . . . . . . . . . .
25
2.6.8
Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . .
25
El lenguaje de programacion PHP . . . . . . . . . . . . . . . . . . . . .
25
2.7
. . . . . . . . . . . . . . . . . . . . . . . .
3 Modelado de Negocios del Sistema de Informaci

on Centralizado
(SIC)
27
3.1
Modelado de negocios . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.1.1
Delimitacion del sistema de negocios . . . . . . . . . . . . . . .
28
Ingeniera de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2.1
Definicion de los requisitos de software . . . . . . . . . . . . . .
29
3.2.2
Definicion de requisitos seg

un actores . . . . . . . . . . . . . . .
30
3.2.3
Clasificacion de los requisitos y definicion de prioridades . . . .
34
3.2.4
Definicion de casos de uso . . . . . . . . . . . . . . . . . . . . .
36
3.2.5
Matriz de casos de uso vs. requisitos . . . . . . . . . . . . . . .
42
3.2
4 Dise
no del Sistema de Informaci
on Centralizado (SIC)
44
4.1
Metas de dise
no . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.2
Definicion del estilo arquitectonico
. . . . . . . . . . . . . . . . . . . .
45
4.3
Diagrama de clases del sistema
. . . . . . . . . . . . . . . . . . . . . .
49
4.4
Diagramas de actividades
. . . . . . . . . . . . . . . . . . . . . . . . .
51
4.5
Diagramas de secuencias . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.6
Dise
no de la interfaz del usuario . . . . . . . . . . . . . . . . . . . . . .
54
4.7
Fase de implementacion y pruebas . . . . . . . . . . . . . . . . . . . . .
56
4.7.1
Implementacion del sistema . . . . . . . . . . . . . . . . . . . .
56
4.7.2
Pruebas del sistema . . . . . . . . . . . . . . . . . . . . . . . . .
62
Entrega final del sistema . . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.8
5 Conclusiones y Recomendaciones
71
5.1
Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
5.2
Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
Bibliografa
75
77
83
86
Indice de Tablas
3.1
Especificacion de los requisitos . . . . . . . . . . . . . . . . . . . . . . .
34
3.2
Casos de uso del sistema . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.3
Matriz de casos de uso vs. requisitos . . . . . . . . . . . . . . . . . . .
43
4.1
Pruebas de caja negra . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.2
Pruebas funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
4.3
Fechas de cursos de induccion . . . . . . . . . . . . . . . . . . . . . . .
69
vii
Indice de Figuras
1.1
Estructura de CANTV . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Estructura de CANTV Merida . . . . . . . . . . . . . . . . . . . . . . .
1.3
Etapas del metodo watch . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.1
Arquitectura orientada a servicios . . . . . . . . . . . . . . . . . . . . .
20
3.1
Delimitacion del sistema de negocios . . . . . . . . . . . . . . . . . . .
28
3.2
Diagrama de actores del SIC . . . . . . . . . . . . . . . . . . . . . . . .
31
3.3
Diagrama de caso de uso centralizar informacion . . . . . . . . . . . . .
37
3.4
Diagrama de caso de uso identificacion . . . . . . . . . . . . . . . . . .
37
3.5
Diagrama de caso de uso mostrar informacion . . . . . . . . . . . . . .
38
3.6
Digrama de caso de uso modificar elemento . . . . . . . . . . . . . . . .
38
3.7
Diagrama de caso de uso reporte lista . . . . . . . . . . . . . . . . . . .
39
3.8
Diagrama de caso de uso eliminar elemento . . . . . . . . . . . . . . . .
39
3.9
Diagrama de caso de uso crear usuario . . . . . . . . . . . . . . . . . .
39
3.10 Diagrama de caso de uso modificar usuario . . . . . . . . . . . . . . . .
40
3.11 Diagrama de caso de uso insertar elemento . . . . . . . . . . . . . . . .
40
3.12 Diagrama de caso de uso subir mapa o diagrama . . . . . . . . . . . . .
40
4.1
Diagrama de despliegue del sistema . . . . . . . . . . . . . . . . . . . .
48
4.2
Diagrama de clases del SIC
. . . . . . . . . . . . . . . . . . . . . . . .
50
4.3
Diagrama de actividad de autenticar usuario . . . . . . . . . . . . . . .
51
4.4
Diagrama de actividad de consultar equipo . . . . . . . . . . . . . . . .
51
4.5
Diagrama de actividad de modificar equipo . . . . . . . . . . . . . . . .
52
4.6
Diagrama de secuencia de consultar equipo . . . . . . . . . . . . . . . .
52
viii
4.7
Diagrama de secuencia de modificar equipo . . . . . . . . . . . . . . . .
53
4.8
Diagrama de secuencia de autenticar usuario . . . . . . . . . . . . . . .
53
4.9
Pantalla de inicio del sistema . . . . . . . . . . . . . . . . . . . . . . .
54
4.10 Pantalla principal de usuario . . . . . . . . . . . . . . . . . . . . . . . .
55
4.11 Diagrama de flujo de pantallas . . . . . . . . . . . . . . . . . . . . . . .
56
4.12 Formulario dinamico . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.13 Filtro de consulta dinamico . . . . . . . . . . . . . . . . . . . . . . . .
58
4.14 Formulario dinamico . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.15 Modelo de la base de datos del SIC . . . . . . . . . . . . . . . . . . . .
61
4.16 Mensaje obtenido al ingresar usuario invalido . . . . . . . . . . . . . .
63
4.17 Mensaje obtenido al ingresar contrase

na incorrecta . . . . . . . . . . .
63
4.18 Mensaje obtenido al intentar ingresar equipo con campos faltantes . . .
64
4.19 Lista de centrales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.20 Registro de acciones en SIC . . . . . . . . . . . . . . . . . . . . . . . .
64
4.21 Exportar archivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.22 Informacion exportada a una hoja de calculo . . . . . . . . . . . . . . .
65
4.23 Valores erroneos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.24 Valores correctos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
A.1 Diagrama de estado de equipo . . . . . . . . . . . . . . . . . . . . . . .
77
A.2 Diagrama de estado de mapa o diagrama . . . . . . . . . . . . . . . . .
77
A.3 Diagrama de estado de usuario autenticado . . . . . . . . . . . . . . . .
77
A.4 Diagrama de estado de usuario
. . . . . . . . . . . . . . . . . . . . . .
78
A.5 Diagrama de actividad de crear usuario . . . . . . . . . . . . . . . . . .
78
A.6 Diagrama de actividad de modificar usuario . . . . . . . . . . . . . . .
78
A.7 Diagrama de actividad de cerrar sesion . . . . . . . . . . . . . . . . . .
78
A.8 Diagrama de actividad de insertar equipo . . . . . . . . . . . . . . . . .
79
A.9 Diagrama de actividad de eliminar equipo . . . . . . . . . . . . . . . .
79
A.10 Diagrama de actividad de listar reporte . . . . . . . . . . . . . . . . . .
79
A.11 Diagrama de actividad de subir mapa o diagrama . . . . . . . . . . . .
80
A.12 Diagrama de secuencia de crear usuario . . . . . . . . . . . . . . . . . .
80
A.13 Diagrama de secuencia de cerrar sesion . . . . . . . . . . . . . . . . . .
80
A.14 Diagrama de secuencia de modificar usuario . . . . . . . . . . . . . . .
81
A.15 Diagrama de secuencia de insertar equipo . . . . . . . . . . . . . . . . .
81
A.16 Diagrama de secuencia de eliminar equipo . . . . . . . . . . . . . . . .
82
A.17 Diagrama de secuencia de listar reporte . . . . . . . . . . . . . . . . . .
82
A.18 Diagrama de secuencia de subir mapa o diagrama . . . . . . . . . . . .
82
C.1 Pantalla de crear usuario . . . . . . . . . . . . . . . . . . . . . . . . . .
86
C.2 Pantalla de usuario buscado . . . . . . . . . . . . . . . . . . . . . . . .
86
C.3 Pantalla de buscar equipo . . . . . . . . . . . . . . . . . . . . . . . . .
87
C.4 Pantalla de lista de equipos . . . . . . . . . . . . . . . . . . . . . . . .
87
C.5 Pantalla de lista de enlaces de fibra optica . . . . . . . . . . . . . . . .
87
C.6 Pantalla de lista de mapas o diagramas . . . . . . . . . . . . . . . . . .
88
C.7 Pantalla de insertar enlace de fibra optica
. . . . . . . . . . . . . . . .
88
C.8 Pantalla de historial de acciones . . . . . . . . . . . . . . . . . . . . . .
89
C.9 Pantalla de diagrama de la red de fibra optica . . . . . . . . . . . . . .
89
C.10 Pantalla de salida del sistema . . . . . . . . . . . . . . . . . . . . . . .
89
Agradecimientos
Este documento no hubiera podido realizarse sin el aporte de todas las personas
e instituciones que intervinieron su tiempo y esfuerzo en alg
un momento sobre el
proyecto, y que gracias a su experiencia, interes, dedicacion, apoyo y confianza hicieron
posible su realizacion. Por ello tengo que agradecerles:
A la ilustre Universidad de Los Andes, particularmente a la Escuela de Ingeniera
de Sistemas, por contribuir en mi formacion profesional.
Al profesor Pablo Guillen, por ser un excelente gua y un gran apoyo desde el
comienzo hasta el final del proyecto.
Al ingeniero Jose Velazquez por ser un buen mentor, gua y apoyo dentro de la
empresa, sin su ayuda no hubiera sido posible.
A todos los miembros del departamento de Conmutacion, Transmision y Datos de
CANTV del estado Merida, su consejo y apoyo fueron fundamentales en la realizacion
de este proyecto.
A CANTV Merida, por brindarme esta inigualable oportunidad de iniciar mi
desarrollo profesional.
A mis padres, por brindarme su apoyo incondicional y darme fuerza durante todo
el transcurso de mi carrera.
A todos aquellos amigos y compa
neros, que de alguna forma intervinieron en la
realizacion de este trabajo, Gracias.
xi
Captulo 1
Introducci
on
El 22 de Mayo de 2007, luego de un proceso de compra de acciones, el Estado
Venezolano concreto la nacionalizacion de la Compa
na Anonima Nacional Telefonos
de Venezuela (CANTV).
La CANTV declara como principio irrenunciable, que el acceso a las telecomunicaciones es un derecho humano fundamental. Por ese motivo llevara los servicios de
telecomunicaciones a todos los rincones del territorio nacional.
La CANTV ofrecera servicios de telefona basica a todo centro poblado con mas de
500 personas, pondra a disposicion de los clientes de menores recursos una tarifa social a
comienzos del 2008 y reinvertira el 60% de las ganancias de la empresa en funcion de las
necesidades de telecomunicaciones del pueblo venezolano. Como empresa del Estado,
CANTV impulsara tambien la construccion de una nueva estructura social en Venezuela
en la que priven valores de igualdad, solidaridad, participacion y corresponsabilidad.
La CANTV alineada con la vision de pas, se planteo los siguientes objetivos
estrategicos:
Democratizar el servicio con justicia social: Ampliando la cobertura geografica,
incluyendo a todos los segmentos de la poblacion, ofreciendo tarifas justas y
solidarias para promover una competencia mas equitativa, con atencion particular
para cada segmento de la poblacion para facilitar la integracion al uso de las
telecomunicaciones.
Potenciar la participacion y el Poder Popular: Las comunidades se convierten
n
1 Introduccio
en aliadas en la prestacion del servicio. En esta etapa, CANTV promueve la

participacion protagonica de las comunidades organizadas, al tiempo que potencia
la labor de los Consejos Comunales.
Garantizar autosostenibilidad de la empresa: La CANTV sera eficiente en
sus operaciones, de manera de generar los recursos requeridos para acometer
proyectos con rentabilidad social, pero siempre asegurando la viabilidad
economica de la empresa.
Convertirnos en empresa socialista del Estado: La empresa se ajustara al marco
legal de empresa p
ublica e implantara el modelo laboral socialista, impulsando
la participacion protagonica de los trabajadores como servidores p
ublicos, bajo
un espritu de solidaridad y abriendo espacios para los Esquemas Asociativos
Solidarios con el fin de desarrollar el modelo de economa social.
Avanzar hacia la soberana tecnologica: La CANTV apoyara la implantacion del
software libre cumpliendo con el decreto 3.390 del Ministerio del Poder Popular
para la Ciencia y Tecnologa. Ademas, impulsara la apropiacion tecnologica
por parte de los ciudadanos y ciudadanas, promovera el desarrollo endogeno,
respaldara la formacion de talentos nacionales y promovera la sustitucion de las
importaciones.
Apalancar la transformacion del Estado: La CANTV jugara un papel protagonico
en la transformacion del Estado apalancando con el potencial que ofrecen las
tecnologas de informacion y comunicacion para acercarse al ciudadano y servirlo
de manera mas eficiente, agil y confiable, facilitando a su vez su participacion en
el dise
no de las polticas p
ublicas que guan la accion del Estado.
Apoyar la integracion Nacional e Internacional: CANTV cobra una dimension
internacional, expandiendo las fronteras tecnologicas de la nacion, bajo el
lineamiento del acuerdo ALBA, el proyecto satelital VENESAT-1, que servira
para brindar apoyo a los programas sociales y del Estado y facilitar la
transferencia tecnologica.
Asimismo, se apoyara la seguridad y la defensa
integral del Estado proveyendo una red de comunicaciones segura y de alcance
n
1 Introduccio
nacional.
La CANTV asume el reto de crear la concepcion socialista del
servicio de telecomunicaciones, abrir espacios reales para la participacion de

las comunidades, colocar las innovaciones tecnologicas al servicio del pueblo,
convertirse en un motor de integracion para los pueblos de la region, contribuir
a definir el perfil del Servidor P
ublico Socialista y coadyuvar en el desarrollo del
modelo de economa social sustentable y endogeno.
Misi
on:
Somos la empresa estrategica del Estado venezolano operadora y proveedora
de soluciones integrales de telecomunicaciones e informatica, corresponsable de la
soberana y transformacion de la nacion, que potencia el poder popular y la integracion
de la region, capaz de servir con calidad, eficiencia y eficacia, y con la participacion
protagonica del pueblo, contribuyendo a la suprema felicidad social.
Visi
on:
Ser una empresa socialista operadora y proveedora de soluciones integrales de
telecomunicaciones e informatica, reconocida por su capacidad innovadora, habilitadora
del desarrollo sustentable y de la integracion nacional y regional, comprometida con la
democratizacion del conocimiento, el bienestar colectivo, la eficiencia del estado y la
soberana nacional.
La estructura organizativa de la empresa se muestra en la figura 1.1.
Figura 1.1: Estructura de CANTV
1.1 Estructura del documento
De manera mas especfica se tiene la estructura organizativa del Estado Merida,

que se muestra en la figura 1.2.
Figura 1.2: Estructura de CANTV Merida
1.1
Estructura del documento
El presente proyecto se estructura de la siguiente manera:

El Captulo 1, expone el planteamiento del problema, las metas a cumplir, en que se
justifica el proyecto, ademas de ofrecer los objetivos generales y especficos planteados.
El Captulo 2, muestra la metodologa usada durante el desarrollo, ademas muestra
los procesos y procedimientos necesarios para la elaboracion de este sistema de
informacion Web.
El Captulo 3, ofrece un breve resumen de los conceptos y herramientas ntimamente
vinculados con el proyecto y que es necesario su conocimiento y utilizacion para el
desarrollo del mismo. Se habla acerca de los sistemas de informacion, clasificacion
y se hace mencion del lenguaje de modelado unificado UML, las bases de datos y el
manejador de base de datos MySQL, entre otros.
En el Captulo 4, se desarrolla el sistema enmarcado en el modelo de procesos
Watch, se comienza con la fase de modelado de negocios, pasando por el analisis de
requisitos, hasta llegar a la fase de implementacion y pruebas del sistema.
En el Captulo 5, se incluyen las conclusiones y recomendaciones del proyecto.
1.2 Antecedentes
1.2
Antecedentes
La CANTV cuenta con muchas redes cableadas e inalambricas, que deben ser
gestionadas por diferentes departamentos. La gestion operativa de la compa
na en
las redes debe hacerse de manera rapida, organizada y con la mayor informacion
actualizada a disposicion.
En la gestion operativa de las redes de CANTV cada
departamento tiene informacion correspondiente a la red en su area de accion. La

Gerencia Operativa de Merida cree que la gestion operativa no puede ser algo de
una sola persona o de un solo departamento. Cuando se genera un problema, avera,
chequeo o simplemente una revision de rutina se debe acudir a la persona encargada
del area para que sea el o ella quien solvente el inconveniente. Para resolver problemas
se necesita informacion, informacion que posee el departamento al cual pertenece el
problema o necesidad, por lo tanto, si alg
un otro departamento necesita alg
un tipo de
informacion para resolver un problema, avera o necesidad, debe necesariamente acudir
a ese departamento y solicitar esa informacion, tramite que retarda la efectividad de
la empresa, ademas de resultar engorroso para su personal no tener la informacion a
la mano.
Describiendo un poco mas a fondo este proceso, cada departamento tiene la
informacion de sus equipos y cada miembro de ese departamento tiene a su vez dicha
informacion, pero cuando uno de sus miembros realiza un cambio lo refleja en su base de
datos que no es compartida inmediatamente para el resto de las personas. De manera
que la informacion nunca esta actualizada a tiempo para todos los que la necesitan.
La CANTV cuenta con sistemas de informacion como el TAS (Trouble Administration System, por sus siglas en ingles) y ASAP (Automatizacion de Servicios de Atencion
al P
ublico) que poseen informacion de las capacidades de los elementos, lneas, puertos
ABA (Acceso a Banda Ancha), clientes, averas de los clientes, entre otros. Pero no
posee informacion de los equipos de la red, marcas, ubicacion, tecnologa, coordenadas
y otras propiedades.
Al respecto, CANTV tambien cuenta con el SIR (Sistema Integral de la Red), el cual
es un sistema de inventarios masivo de la red de CANTV a nivel nacional desarrollado
durante los a
nos 1999-2001 por personal de CANTV. El SIR es una herramienta muy
poderosa que nos servira para buscar informacion en este sistema.
1.3 Planteamiento del problema
Motivado por las necesidades del personal de CANTV en La Gerencia Operativa

del Estado Merida nace la intencion de crear este proyecto.
1.3
Planteamiento del problema

La CANTV posee diferentes redes tales como: red secundaria, red de fibra
optica tanto urbana como interurbana, las cuales cuentan con diferentes elementos,
propiedades y caractersticas. Al respecto la informacion se encuentra distribuida entre
los diferentes departamentos de la compa
na de manera separada y manejada por un
supervisor. Debido a lo anterior se pretende dise
nar e implementar un sistema de
informacion Web que centralize toda esa informacion y que pueda ser accedido de igual
manera por cada uno de los departamentos. Este sistema debe poseer los diferentes
mapas y diagramas de las redes secundarias, fibra optica, urbana e interurbana de
Merida y una base de datos. El sistema debe ser accedido desde cualquier punto de la
Intranet de CANTV y desarrollado bajo la filosofa de software libre.
1.4
Justificaci
on
Actualmente, CANTV tiene a su disposicion diversos sistemas de informacion

tanto para gestion como para mantenimiento de sus redes informaticas y telefonicas,
pero desafortunadamente no cuenta con la implementacion de un sistema que permita
visualizar los diferentes mapas de sus instalaciones, red secundaria, red de fibra optica
tanto urbana como interurbana, y que ademas de visualizar los mapas, cuente con una
base de datos de los diferentes elementos de las redes. Por tal motivo la Gerencia
Operativa de Merida se ve en la imperiosa necesidad de solicitar este proyecto.
1.5
1.5.1
Objetivos
Objetivo General
Desarrollar un Sistema de informacion Web para la red de CANTV Merida, de facil

manejo y capaz de agilizar el proceso de almacenamiento, recuperacion, b
usqueda de
1.5 Objetivos
informacion y visualizacion de los mapas de la red.
1.5.2
Objetivos Especficos
1. Definir y analizar el dominio de aplicacion, alcance e informacion.

2. Dise
nar, identificar y especificar los requisitos del sistema que cumplan con
los requerimientos exigidos por CANTV, bajo un ambiente amigable y de facil
manejo.
3. Construir, implementar y realizar pruebas del sistema de informacion que
cumplan con la normativa de la empresa.
4. Presentar una visualizacion de la informacion de la red:
Centrales Fijas
Centrales Moviles
URL
Nodos outdoor
ADS
DLC
As como los datos de los enlaces entre elementos:
Estaciones
Repetidoras
Enlaces de radio
Enlaces de fibra optica
Y las propiedades de los elementos:
Equipos
Marcas
Capacidades
1.6 Metodologa
N
umero de lneas
Frecuencias de transmision y recepcion
Ubicacion
Coordenadas
Direccion
Y ademas de otro tipo de informacion especfica de los diferentes componentes
de la red tales como: IP, bastidores, sub-bastidores, ranuras, puertos, posiciones,
tarjetas entre otros.
1.6
Metodologa
En este captulo de describen los procedimientos, procesos y metodos para realizar

el dise
no e implementacion del Sistema de Informacion Web.
Para el modelado del sistema se hizo uso del Lenguaje Unificado de Modelado
(UML, por sus siglas en ingles, Unified Modeling Language), el cual es un lenguaje
de modelado de sistemas de software mas conocido y utilizado en la actualidad,
esta respaldado por el OMG (Object Management Group) y es un lenguaje grafico
para visualizar, especificar, construir y documentar un sistema de software. El UML
ofrece un estandar para describir un plano del sistema (modelo) incluyendo aspectos
conceptuales tales como: procesos de negocios y funciones del sistema, y aspectos
concretos como expresiones de lenguajes de programacion, esquemas de bases de datos
y componentes de software reutilizables (Schmuller, 1997).
1.6.1
Revisi
on bibliogr
afica
En primer lugar se busca informacion bibliografica de los conceptos y basamentos

teoricos sobre telefona y redes telefonicas, igualmente se recopilara la documentacion
acerca de algunas de las herramientas para el desarrollo de este tipo de proyecto.
Luego, se ofrece la investigacion acerca del manejador de base de datos MySQL, el
cual es herramienta de desarrollo de este sistema.
1.6 Metodologa
Posteriormente, se procede a investigar y recopilar informacion sobre la implantacion de dicho sistema.
1.6.2
Proceso de desarrollo
Para el proceso de desarrollo de este proyecto se siguen las etapas propuestas en

el metodo Watch, el cual se expone muy bien en (Montilva and Barrios, 2003). Este
metodo consta de los siguientes modelos:
Modelo del producto: Describe el tipo de producto que el metodo Watch
ayuda a generar. Se establecen las caractersticas arquitectonicas generales de
una aplicacion empresarial. En este caso las caractersticas del sistema.
Modelo del proceso:
Es una descripcion estructurada del conjunto de
actividades que el desarrollador debe seguir para generar una aplicacion

empresarial y comprende las siguientes fases:
An
alisis del dominio de la aplicaci
on: En esta fase se estudia el sistema
organizacional, es decir, las actividades y los procesos que son llevados por la
organizacion para lograr sus objetivos, se definen los actores que intervienen
en el desarrollo de las actividades del sistema, el dominio de aplicaciones
de dichas actividades y se modela la estructura funcional, describiendo las
funciones, procesos y tareas que se ejecutan.
Definici
on y especificaci
on de requerimientos: Los requerimientos
son las necesidades que deben ser satisfechas por el sistema programado
a partir de la manipulacion y consulta de las bases de datos en el sistema
de informacion Web.
Dise
no del sistema: En esta fase se representa el dise
no de la arquitectura
del sistema, el dise
no del esquema conceptual de la base de datos y el dise
no
de la interfaz Usuario/Sistema.
Implantaci
on del sistema:
Es el proceso de convertir el esquema
modelado a uno que pueda ser directamente implementado con el uso de
1.6 Metodologa
10
un manejador de base de datos, es decir, se lleva el modelo a un lenguaje de

programacion.
Modelo del desarrollador: Este modelo describe como el desarrollador debe
estar organizado cuales son sus roles y tareas.
La figura 1.3 muestra las diferentes etapas comprendidas en el metodo Watch.1
Figura 1.3: Etapas del metodo watch
Fuente (Montilva and Barrios, 2003).
Captulo 2
Marco te
orico
Para el desarrollo de este proyecto se hace necesario conocer un conjunto de
conceptos y herramientas. Al respecto, en este captulo se ofrece un breve resumen de
los conceptos y herramientas ntimamente vinculados con el proyecto. Se comenzara
desarrollando el concepto de sistema de informacion, su clasificacion y se define el tipo
de sistema de informacion que se considera este proyecto. Se hara mencion a algunos
conceptos relacionados y se mencionan brevemente los aspectos mas resaltantes de las
bases de datos relacionales y del manejador de bases de datos MySQL. En cuanto a otras
herramientas utilizadas, se definiran algunos conceptos relacionados con el lenguaje de
modelado unificado (UML) y se explicara la estructura y utilidad de los diagramas
utilizados en el proyecto; por u
ltimo se hara mencion del lenguaje de programacion
PHP (Hypertext Preprocessor).
2.1
Sistemas de informaci
on
Un Sistema de Informacion es un conjunto de componentes interrelacionados
que operan de manera sistematica para capturar, procesar, almacenar y distribuir

informacion que sirva de apoyo a la toma de decisiones, la coordinacion, el control y el
analisis dentro de una organizacion (Schmal and Cisternas, 2000). En ese sentido, de
acuerdo con Mu
noz (2003) algunas de las caractersticas que resultan necesarias para
cualquier Sistema de Informacion son:
n
2.1 Sistemas de informacio
12
Disponibilidad de informacion cuando sea necesario y por los medios adecuados.

Suministro de informacion de manera selectiva.
Variedad en la forma de presentacion de la informacion.
Cierto grado de autonoma para la toma de decisiones
Tiempo de respuesta adecuado a las necesidades del usuario.
Exactitud en la informacion suministrada.
Generalidad en las funciones para atender a las diferentes necesidades.
Flexibilidad y capacidad de adaptacion.
Fiabilidad para que el sistema opere correctamente.
Seguridad para proteccion contra perdidas.
Amigabilidad para que el usuario este a gusto con el sistema.
2.1.1
Actividades que realiza un sistema de informaci

on
De acuerdo con Schmal and Cisternas (2000), las actividades basicas que realiza
cualquier sistema de informacion son: la captura, el procesamiento, el almacenamiento
y la salida o distribucion de la informacion.
Captura de la informaci
on: Mediante este proceso, el sistema toma los datos
que requiere para procesar la informacion. La manera como se ingresan los datos
puede ser manual o automatica. La entrada manual de los datos requiere que estos
sean introducidos directamente por el usuario, mientras que la automatica se produce
cuando el sistema captura los datos de entrada de otro sistema o modulo.
Procesamiento de la informaci
on: Es el proceso mediante el cual el sistema de
informacion realiza transformaciones y calculos sobre los datos basado en una secuencia
de operaciones preestablecida. Las operaciones pueden ser realizadas sobre los datos
recientemente capturados o sobre aquellos ya almacenados. Mediante la transformacion
n
13
de los datos y la informacion generada por el sistema, las personas encargadas de

analizar e interpretar la informacion pueden llevar a cabo la toma de decisiones.
Almacenamiento de la informaci
on: Permite que la informacion generada en
el proceso anterior pueda ser guardada para ser recuperada y utilizada mas adelante.
Por lo general, la informacion es almacenada utilizando archivos y bases de datos que
utilizan como medio de almacenamiento los discos magneticos o discos duros, los discos
compactos, los DVDs, entre otros.
Salida de la informaci
on: Es la capacidad que tiene un sistema de informacion
para mostrar la informacion procesada al exterior. La salida de un sistema puede ser la
entrada de otro sistema de informacion o modulo, o puede ser mostrada directamente
al usuario en el formato que este desee.
2.1.2
Tipos de sistemas de informaci

on
En Barrios (2000) se clasifican los sistemas de informacion basandose en tres

criterios: el grado de cobertura de las actividades organizacionales, el grado de apoyo
a la ejecucion de las actividades en la organizacion y las tecnologas en las que se basa
su desarrollo 1 . En este orden de ideas los sistemas se describen de acuerdo al grado
de cobertura de las actividades organizacionales:
Sistemas independientes (Sind):
Surgen como resultado de
requisitos
individuales de los miembros de una organizacion, apoyando las actividades del usuario
en forma completa y sujetos a las necesidades de estos.
Sistemas integrados (SII): Estan conformados por la conjuncion y colaboracion
de los sistemas de informacion ya existentes en la organizacion.
Sistemas organizacionales (SIO): Proporcionan un grado de cobertura e
integracion total de las actividades y procesos organizacionales, aportando as un grado
de apoyo maximo a la toma de decisiones.
De acuerdo al apoyo brindado a la ejecucion de las actividades organizacionales los
sistemas de informacion pueden ser:
Sistemas operacionales (SIOp): Son sistemas de bajo nivel que apoyan la
automatizacion de tareas y operaciones basicas dentro de una organizacion, tales como
1
No obstante un sistema puede ser clasificado en mas de uno de estos criterios.
n
14
las actividades administrativas y de produccion.

Sistemas gerenciales (SIGe): Estan orientados a brindar apoyo a las actividades
de nivel gerencial y de coordinacion dentro de una organizacion.
Sistemas de apoyo a la toma de decisiones (SATD): Son sistemas que
contribuyen de forma directa y explcita al proceso de toma de decisiones dentro de
una organizacion, permitiendo visualizar el panorama organizacional desde el punto de
vista de los resultados y/o consecuencias de tomar alguna accion en un momento dado.
De acuerdo a las tecnologas en las que se basan, los sistemas de informacion pueden
ser:
Sistemas cliente/servidor
Sistemas basados en tecnologas Web
Sistemas basados en agentes
Sistemas basados orientados a servicios
Existe una cuarta clasificacion de los sistemas de informacion en base al apoyo
de actividades organizacionales muy especializadas.
Dentro de este grupo, se
encuentran los ya mencionados SATD, los Sistemas Expertos (SE) que incorporan
la automatizacion de experticia humana en la realizacion de determinada actividad
y Sistemas de Informacion Geografica (SIG) que estan relacionados con el manejo de
informacion geografica o georeferenciados.
2.1.3
Sistemas de informaci
on Web
En Mu
noz (2003) se define un Sistema de Informacion Web (SIW) como: Un sistema
de informacion que utiliza una arquitectura web para proporcionar informacion (datos)
y funcionalidad (servicios) a usuarios finales, a traves de una interfaz de usuario basada
en presentacion e interaccion sobre dispositivos con capacidad de trabajar en la Web.
En este orden de ideas los SIW varan ampliamente en su ambito, desde sistemas
de informacion, hasta sistemas de transacciones, incluso sistemas de servicios Web
distribuidos. En virtud de la definicion anterior los SIW se clasifican como sigue:
2.2 Servidor Web Apache
15
Las Intranets, (las cuales dan apoyo al trabajo interno dentro de la Empresa)
Los sitios de presencia en la Web, (los cuales son herramientas utilizadas para
alcanzar consumidores fuera de la empresa)
Los sistemas de Comercio Electronico, (los cuales dan apoyo a la interaccion con
el consumidor)
Las Extranets, (las cuales son un conjunto de sistemas internos y externos que
apoyan las comunicaciones entre la empresa y otras empresas)
Por lo general, los SIW manejan un gran volumen de datos que se encuentran en
fuentes heterogeneas, se maneja en distintos formatos, y en un conjunto de componentes
que estan por lo general codificados en diferentes lenguajes de programacion y a su vez
distribuidos en diferentes plataformas. Al igual que los SI tradicionales, mas alla que
una infraestructura para la entrega de informacion (en tiempo de ejecucion), los SIW
deben proporcionar una infraestructura de desarrollo y mantenimiento que permita
manejar e interpretar los datos y que proporcione funcionalidades a los usuarios finales
para capturar, almacenar, procesar y mostrar la informacion dando solucion a sus
requerimientos.
Los SIW son dise
nados, desarrollados y mantenidos con el proposito de alcanzar
objetivos especficos de los usuarios finales. Estos

objetivos deben constituir la base
del proyecto de desarrollo de todo SIW.
2.2
Servidor Web Apache
Apache es el servidor de Web por excelencia. Ha sido uno de los mayores exitos
del software libre y su supremaca entre los servidores de Web no se ve amenazada
y hacen que cada vez millones de servidores reiteren su confianza en este programa
(Linux, 2009).
Una de las principales caractersticas de Apache es su extensibilidad basada en una
gran modularidad de su codigo fuente lo que han facilitado la aparicion de modulos
de extension como PHP el cual evitara el uso de cgi-bins por completo, facilitando
2.3 Bases de datos
16
ampliamente la programacion de aplicaciones en el lado del servidor, especialmente en

el ambito de uso de bases de datos.
2.3
Bases de datos
Una base de datos es una coleccion de datos relacionados, es decir, un conjunto

de hechos que pueden registrarse y que tienen un significado implcito. Por lo general,
las bases de datos representan aspectos del mundo real y son dise
nadas, construidas y
pobladas con datos que tienen un proposito especfico, se caracterizan por la coherencia
de los datos que la integran (Elmasri and Navathe, 2002). Hay cinco modelos principales
de bases de datos: el modelo jerarquico, el modelo en red, el modelo relacional, el
modelo de bases de datos deductivas y el modelo de bases de datos orientado a objetos.
Para el desarrollo del proyecto fue necesario manejar el concepto de bases de datos
relacionales que se menciona a continuacion.
2.3.1
Bases de datos relacionales
Constituye el modelo mas utilizado en la actualidad para el modelado de problemas

reales y la administracion de datos de manera dinamica. Almacena la informacion en
varias tablas (filas y columnas de datos) o ficheros independientes y realiza b
usquedas
que permiten relacionar datos que han sido almacenados en mas de una tabla. Se basa
en el uso de relaciones, donde cada relacion es una tabla compuesta por registros (las
filas de una tabla) y campos (las columnas de una tabla). En el modelo relacional
cada fila representa un hecho que normalmente se corresponde con un vnculo o una
entidad del mundo real. El nombre de la tabla y de las columnas ayuda a interpretar
el significado de los valores que estan en cada fila. En el modelo relacional una fila
se denomina tupla, una cabecera de columnas se denomina atributo y la tabla se
denomina relacion. En este modelo, el lugar y la forma en que se almacenen los datos
no tienen relevancia. Esto tiene la considerable ventaja de que es mas facil de entender
y de utilizar para un usuario esporadico de la base de datos. La informacion puede ser
recuperada o almacenada mediante consultas que ofrecen una amplia flexibilidad y
poder para administrar la informacion (Elmasri and Navathe, 2002).
2.3 Bases de datos
2.3.2
17
Lenguaje estructurado de consulta (SQL)
Es un lenguaje de base de datos normalizado, utilizado por los diferentes manejadores

de bases de datos para realizar determinadas operaciones sobre los datos o sobre
la estructura de los mismos. Esta dise
nado como un lenguaje amplio que incluye
instrucciones para definir, consultar y actualizar las bases de datos. Las funcionalidades
que proporciona el SQL van mas alla de la simple consulta o recuperacion de datos.
Esta a su vez permite definir los tipos de datos y manipular los datos. Ademas, el SQL
permite la concesion y denegacion de permisos, la implementacion de restricciones de
integridad, controles de transaccion y la alteracion de esquemas. El lenguaje SQL esta
compuesto por comandos, clausulas, operadores y funciones agregadas. Estos elementos
se combinan en las instrucciones para crear, actualizar y manipular las bases de datos
(Elmasri and Navathe, 2002).
2.3.3
El sistema de gesti
on de bases de datos MySQL
MySQL es un sistema de gestion de base de datos relacional, multihilo y multiusuario

con mas de seis millones de instalaciones. Desde Enero de 2008 una subsidiaria de
SUN MICROSYSTEMS desarrolla MySQL como software libre en un esquema de
licenciamiento dual.
Por un lado, se ofrece para cualquier uso compatible con la licencia GNU GPL,
pero para aquellas empresas que quieran incorporarlo en productos privativos deben
comprar a la empresa una licencia especfica que les permita este uso. Esta desarrollado
en su mayor parte en ANSI C (Wikipedia, 2008c).
MySQL es una base de datos muy rapida en la lectura cuando utiliza el motor no
transaccional MyISAM, pero puede provocar problemas de integridad en entornos de
alta concurrencia en la modificacion. En aplicaciones Web hay baja concurrencia en la
modificacion de datos, y en cambio el entorno es intensivo en lectura de datos lo que
hace a MySQL ideal para este tipo de aplicaciones.
MySQL fue desarrollado bajo los lenguajes C y C++ y se destaca por su gran
adaptacion a diferentes entornos de desarrollo, permitiendo su interaccion con los
lenguajes de programacion mas utilizados como: PHP, Perl y Java y su integracion
2.3 Bases de datos
18
en distintos sistemas operativos.

Wikipedia (2008c) dice que MySQL es muy utilizado en aplicaciones Web, como
Drupal o phpBB, en diversas plataformas como Unix y por herramientas de seguimiento
de errores como Bugzilla. Su popularidad como aplicacion web esta muy ligada a PHP
que a menudo aparece en combinacion con MySQL lo cual no es una excepcion en este
proyecto.
Inicialmente MySQL careca de elementos considerados esenciales en las bases de
datos relacionales tales como: integridad referencial y transacciones. Estos elementos
atrajeron a los desarrolladores de paginas Web con contenido dinamico, justamente
por su simplicidad; aquellos elementos faltantes fueron llenados a medida que las
aplicaciones lo utilizaban.
Poco a poco los elementos faltantes en MySQL estan siendo incorporados tanto por
desarrollos internos como por desarrolladores de software libre.
2.3.4
Algunas caractersticas de MySQL
Entre las caractersticas disponibles en las u

ltimas versiones de MySQL se pueden
destacar:
Amplio subconjunto del lenguaje SQL. Algunas extensiones son incluidas
igualmente
Disponibilidad en gran cantidad de plataformas y sistemas
Diferentes opciones de almacenamiento seg
un si se desea velocidad en las
operaciones o el mayor n
umero de operaciones disponibles
Transacciones y claves foraneas
Conectividad segura
Replicacion, b
usqueda e indexacion de campos de texto
2.4 Arquitectura orientada a servicios (SOA)
2.4
19
Arquitectura orientada a servicios (SOA)
La SOA es vista como un marco para el desarrollo de productos de software. La

arquitectura orientada a servicios es un paradigma para utilizar y organizar servicios
distribuidos que pueden encontrarse bajo varios dominios y estar implementados
utilizando diferentes tecnologas.
Esta arquitectura se basa en los conceptos de
escalabilidad y reutilizacion del software.

Por lo general, las organizaciones desarrollan funciones y aplicaciones que son u
tiles
para automatizar ciertas tareas dentro de los procesos de negocio. Sin embargo, muchas
veces una solucion puede ser u
til a nivel intermedio para varios procesos o unidades
dentro de la organizacion con fines diferentes.
El concepto de arquitectura orientada a servicios implica que los desarrolladores
creen un conjunto de funciones independientes entre s llamadas servicios, que aceptan
llamadas y generan respuestas mediante interfaces bien definidas y que son puestas
a disposicion de los clientes como utilidades que pueden ser reutilizadas por diversas
aplicaciones dentro de la organizacion.
La implementacion de los servicios es transparente para los usuarios, ya que a estos
no le interesa conocer mas que el tipo y formato de las entradas admitidas y de las
salidas generadas por el servicio (Nickul, 2007).
En un ambiente SOA los nodos de la red hacen disponibles sus recursos a otros
participantes de la red como servicios independientes a los que tienen acceso de un
modo estandarizado. La mayora de las definiciones de SOA identifican la utilizacion
de Servicios Web en su implementacion. No obstante se puede implementar SOA
utilizando cualquier tecnologa basada en servicios (Wikipedia, 2008a).
Las arquitecturas orientadas a servicios difieren de las arquitecturas orientadas a
objetos en que se encuentran formadas por servicios debilmente acoplados y altamente
interoperables. Estos servicios definen una estructura para comunicarse entre s, que
es independiente del lenguaje en que se encuentran implementados y el lenguaje de
programacion. Todo ello buscando maximizar la reutilizacion de los componentes
desarrollados en un sistema (Wikipedia, 2008a).
La arquitectura SOA es muy utilizada por las grandes organizaciones en la
2.4 Arquitectura orientada a servicios (SOA)
20
actualidad, entre tantas cosas, por el hecho de permitir la creacion o cambios en los
procesos de negocios automatizados de forma agil, a traves de una composicion de
nuevos procesos utilizando las funcionalidades del negocio contenidas en las aplicaciones
actuales o futuras consumidas por medio de servicios Web. Una arquitectura de este
tipo es como la que se muestra en la figura 2.1. En esta figura se observa como los
componentes se distribuyen en tres capas:
La capa de presentacion es la que le da el formato a los datos recibidos desde el
bus de integracion con el fin de que el usuario visualice la informacion en una
pagina Web
El bus de integracion, comprende la segunda capa en la que se encuentran los
servicios Web del negocio; as como los objetos manipulados por esos servicios
y todos los servicios comunes para todas las funciones de negocio. Esta capa
implementa la logica de negocios de la aplicacion
La capa de datos es la que mantiene la implementacion de las estructuras que
almacenan los datos de la aplicacion (bases de datos).
Figura 2.1: Arquitectura orientada a servicios
2.5 Protocolo SOAP
2.5
21
Protocolo SOAP
El SOAP es un protocolo de comunicacion definido para el intercambio de
datos mediante el paso de mensajes en formato XML. Define los estandares para la
comunicacion entre dos objetos de diferentes procesos a traves de una conexion de
Internet. Este protocolo es utilizado para el acceso a servicios Web. El mismo permite
la llamada de procedimientos remotos mediante HTTP entre aplicaciones distribuidas
en distintos servidores.
Existen varios protocolos parecidos, como por ejemplo RMI de Java y ORPC de
CORBA. Sin embargo, DesarrolloWeb (2009b) dice que SOAP es uno de los mas
utilizados y aceptados por las grandes compa
nas del mundo y las principales razones
de su exito son:
No esta asociado con ning
un lenguaje: SOAP no especifica una API, por lo que
la implementacion de la API se deja al lenguaje de programacion y la plataforma
No se encuentra fuertemente asociado a ning
un protocolo de transporte: Un
mensaje de SOAP no es mas que un documento XML, por lo que puede
transportarse utilizando cualquier protocolo capaz de transmitir texto
No esta atado a ninguna infraestructura de objeto distribuido: La mayora de
los sistemas de objetos distribuidos se pueden extender, y muchos de ellos ya lo
estan para que admitan SOAP
Aprovecha los estandares existentes en la industria:
Por ejemplo, SOAP
aprovecha XML para la codificacion de mensajes, en lugar de utilizar su propio

sistema de tipo que ya estan definidas en la especificacion esquema de XML,
y como ya se ha mencionado, SOAP no define un medio de transporte para los
mensajes; los mensajes de SOAP se pueden asociar a los protocolos de transporte
existentes como HTTP y SMTP
Permite la interoperabilidad entre m
ultiples entornos: SOAP se desarrollo sobre
los estandares existentes de la industria por lo que las aplicaciones que se ejecuten
en plataformas con dichos estandares, pueden comunicarse mediante mensaje
2.6 Lenguaje de modelado unificado (UML)
22
SOAP, con aplicaciones que se ejecuten en otras plataformas Existen varias

implementaciones de SOAP que proporcionan la estructura para definir servicios
Web bajo un lenguaje particular entre estas implementaciones.
2.6
Lenguaje de modelado unificado (UML)
El UML es un lenguaje grafico para el modelado de sistemas de software que

permite representar graficamente la estructura de un sistema, haciendo posible que
cualquier persona ajena o no al proceso de dise
no lo pueda entender. Mediante UML
se pueden especificar, visualizar y documentar de manera explcita las caractersticas
de un sistema de software antes y durante su construccion. UML es solo un lenguaje
para el modelado por lo que su utilizacion es independiente del proceso de desarrollo,
aunque para su uso optimo debe aplicarse en un proceso centrado en arquitectura,
dirigido a casos de uso, iterativo e incremental (Object Management Group, 2007).
El UML es lo suficientemente expresivo como para modelar pruebas del sistema,
sistemas de hardware, sistemas de negocios, el flujo de trabajo en una empresa, dise
no
de estructura de una organizacion, actividades de planificacion de proyectos y sistemas
no informaticos.
El UML se deriva de la unificacion de tres metodologas de analisis y dise
no
orientada a objeto, tales como: la metodologa de Grady Booch (para la descripcion
de conjuntos de objetos y sus relaciones), la tecnica de modelado orientada a objetos
de James Rumbaugh OMT (Object-Modeling Technique) y la aproximacion de Ivar
Jacobson OOSE (Object Oriented Software Engineering) mediante la metodologa de
casos de uso.
De estas tres metodologas, las de Rumbaugh y Booch se pueden clasificar como
metodologas directamente orientadas a objetos, mientras que la metodologa de
Jacobson esta orientada al usuario, ya que todo su metodo se deriva de los escenarios
de uso del sistema.
El desarrollo de UML comenzo a finales de 1994 cuando Grady Booch y Jim
Rumbaugh de Rational Software Corporation que comenzaron a unificar sus metodos.
A finales de 1995, Ivar Jacobson y su compa
na Objectory se incorporaron,
23
aportando el metodo OOSE.

Los anteproyectos de UML empezaron a circular en la industria de software y
las reacciones resultantes trajeron modificaciones considerables. Conforme diversas
organizaciones vieron que el UML les resultaba u
til a sus propositos, estas fueron
agregando nuevos aportes.
En 1997 se produjo la version 1.0 del UML y se puso a consideracion del OMG
(Object Management Group), propuesto como un lenguaje de modelado estandar.
Desde entonces, UML ha atravesado una serie de revisiones y refinamientos hasta llegar
a su version actual: UML 2.3 (Wikipedia, 2008b). Al respecto el UML esta compuesto
por diversos elementos graficos que se combinan para conformar diagramas. Como
se trata de un lenguaje, UML aporta las reglas para combinar tales elementos. Los
diagramas de UML permiten representar diversas perspectivas de un sistema, indicando
lo que supuestamente hara, pero no la forma como se implementara. En la version 2.0
del UML, se define un total de 13 diagramas para representar la estructura y dinamica
del sistema. Sin embargo, para efectos del proyecto solo se utilizaron ciertos diagramas.
2.6.1
Diagramas de clases
Son estructuras estaticas que dan una vision general del conjunto de clases existentes
en el sistema modelado y las relaciones existentes entre cada una de ellas.
Los
diagramas de clases constan de diagramas estaticos pues muestran las relaciones entre
las clases pero no especifican sus interacciones de manera dinamica. Los diagramas de
clases colaboran en lo referente al analisis y permiten al analista hablarle en su propia
terminologa, lo cual hace posible que los clientes indiquen importantes detalles de los
problemas que deben ser resueltos.
2.6.2
Diagramas de componentes
Los diagramas de componentes son utilizados para modelar la estructura del software
y las dependencias entre sus componentes. Estos diagramas modelan y agrupan los
componentes del sistema en forma de paquetes, y a su vez muestran las interfaces de
los componentes, sus dependencias, relaciones e interacciones.
2.6.3
24
Diagramas de objetos
Un objeto es una instancia de clase (una entidad que tiene valores especficos de
los atributos y acciones). Son parte de la vista estatica del sistema. Los diagramas
de objetos permiten modelar las instancias de las clases que fueron representadas en
el diagrama de clases. Estos diagramas muestran en un momento concreto del sistema
los objetos y sus relaciones. Pueden incorporar clases para mostrar la clase a la que
pertenece un objeto representado.
2.6.4
Diagramas de despliegue
Los diagramas de despliegue muestran la distribucion fsica de los distintos nodos

que componen el sistema, la comunicacion entre los nodos y la disposicion de los
componentes sobre ellos. Un nodo es un recurso de ejecucion tal como un computador,
un dispositivo o memoria. Permiten precisar la naturaleza del equipo. Los elementos
utilizados en la representacion grafica de estos diagramas son los mismos que son
utilizados en los diagramas de componentes.
2.6.5
Diagramas de paquetes
Los diagramas de paquetes permiten visualizar la distribucion de los componentes

del sistema en paquetes y las dependencias entre los mismos.
2.6.6
Un diagrama de actividades ha sido dise

nado para mostrar una vision simplificada
de lo que ocurre durante una operacion o un proceso. Los diagramas de actividades
son utilizados para modelar el flujo de control de las actividades que tienen lugar a lo
largo del tiempo junto a las tareas concurrentes que pueden realizarse a la vez. Estos
diagramas muestra las interacciones entre las clases mediante el flujo de control de
actividades ordenadas cronologicamente con el fin de lograr la ejecucion de un proceso
mas complejo.
n PHP
2.7 El lenguaje de programacio
2.6.7
25
Diagramas de casos de uso
Los diagramas de casos de uso representan la forma como un usuario opera con el
sistema en desarrollo y la forma, tipo y orden en la que interact
uan sus elementos. Los
elementos implicados en un diagrama de casos de uso son:
Actores: Son entidades con un comportamiento definido y que realizan alguna
interaccion con el sistema. Pueden representar usuarios, organizaciones u otros sistemas
informaticos.
Casos de uso: Son descripciones de las secuencias de acciones que se producen de
la interaccion entre un actor y el sistema.
Relaciones entre casos de uso: Las relaciones entre los casos de uso pueden
ser de inclusion y extension. Un caso de uso puede incluir a otro caso de uso como
parte de su procesamiento. Generalmente se asume que los casos de uso incluidos se
llamaran cada vez que se ejecute el camino base. Un caso de uso puede ser incluido
por uno o mas casos de uso, ayudando as a reducir la duplicacion de funcionalidad al
factorizar el comportamiento com
un en los casos de uso que se reutilizan. Un caso de
uso puede extender el comportamiento de otro caso de uso tpicamente cuando ocurren
situaciones excepcionales o cuando depende de ciertos criterios. Entonces el caso de uso
que extiende extend describe un comportamiento opcional del sistema a diferencia
de la relacion incluye include que se da siempre que se realiza la interaccion descrita.
2.6.8
Diagramas de secuencia
Representan la interaccion ordenada entre los objetos de un sistema de acuerdo a

una secuencia temporal de eventos. En particular muestran los objetos que participan
en la interaccion y los mensajes que intercambian en orden temporal (Schmuller, 1997).
2.7
El lenguaje de programaci
on PHP
PHP: Hypertext Preprocessor es un lenguaje de programacion del lado del servidor

dise
nado originalmente para la generacion de paginas Web dinamicas. Es un lenguaje
de programacion interpretado o de script que permite insertar fragmentos de codigo
n PHP
2.7 El lenguaje de programacio
26
dentro de una pagina HTML y realizar determinadas acciones de una forma facil y
eficiente sin tener que generar programas en un lenguaje distinto al HTML.
Por otra parte, PHP ofrece un sinfn de funciones para el aprovechamiento de las
potencialidades de bases de datos de una manera llana y sin complicaciones. PHP
generalmente se ejecuta en un servidor Web, tomando el codigo en PHP como su
entrada y creando paginas Web como salida.
PHP puede ser desplegado en la mayora de los servidores web y en casi todos los
sistemas operativos y plataformas sin costo alguno. PHP se encuentra instalado en
mas de 20 millones de sitios web y en un millon de servidores (Wikipedia, 2008d).
Una de sus mayores ventajas es el parecido que posee con otros lenguajes
de programacion estructurada como Perl y C que permiten a la mayora de los
programadores crear aplicaciones complejas de manera muy sencilla, pues no se requiere
mucho tiempo para su aprendizaje.
Cuando un cliente hace una peticion al servidor para que le enve una pagina Web,
el servidor ejecuta el interprete de PHP. Este

procesa el script solicitado y genera de
manera dinamica un contenido. El resultado es enviado por el interprete al servidor,
quien a su vez enva la pagina HTML al cliente. Mediante extensiones es tambien
posible la generacion de archivos de tipo PDF, Flash; as como imagenes en diferentes
formatos (Wikipedia, 2008d).
Si bien, PHP no es un lenguaje completamente orientado a objetos, en su u
ltima
version (version 5.0) se incorporan varios constructores de programacion orientada a
objetos. Su creacion y desarrollo se da en el ambito de los sistemas libres, bajo la
licencia GNU. Existen muchos editores y entornos integrados de desarrollo disponibles
en el mercado para desarrollar aplicaciones en PHP. Para el desarrollo del sistema se
utilizo el editor Quanta Plus en su version 3.5.
Captulo 3
Modelado de Negocios del Sistema
de Informaci
on Centralizado (SIC)
El presente captulo describe las fases de modelado del SIC. Como se menciono
en los captulos anteriores para el desarrollo del sistema se utiliza el metodo watch en
su version 2004. A continuacion se describe cada una de las fases contempladas en
este metodo y que son aplicadas para obtener el sistema. Se comenzara explicando el
modelado de negocios realizado para la unidad organizativa de la CANTV en estudio
especficamente la gerencia operativa del estado Merida. As mismo se presentan los
requisitos de la aplicacion y los casos de uso modelados.
3.1
Modelado de negocios
En la fase de modelado de negocios resulta de vital importancia dentro del proceso

de desarrollo de un sistema de software, pues permite obtener un conocimiento mas
a fondo del sistema de negocios u organizacion bajo la cual se enmarca el proyecto.
Para determinar de la mejor manera posible los requisitos del sistema es necesario y
esencial un conocimiento a profundidad del dominio de la aplicacion. En el contexto
de aplicaciones empresariales, el dominio de aplicacion se refiere a la organizacion o
sistema de negocios que sera apoyada por la aplicacion o SI, obteniendo como producto
final el modelo de negocios de la organizacion.
3.2 Ingeniera de requisitos
28
Un modelo de negocios es una representacion que captura la estructura y dinamica

de la organizacion objetivo bajo la cual se incorporara el SI. Mediante el modelo de
negocios es posible obtener un conocimiento a profundidad de la organizacion, sus
problemas de informacion y los requisitos funcionales que deben ser satisfechos por el
SI (Montilva et al., 2000).
3.1.1
Delimitaci
on del sistema de negocios
Dentro de la CANTV, la gerencia operativa del estado Merida se encarga de

coordinar los diferentes departamentos que hacen posible el buen funcionamiento y
mantenimiento de su plataforma tecnologica. La ejecucion de una buena coordinacion
tiene como objetivo maximizar la productividad de sus trabajadores, minimizar el
tiempo de respuesta de las averas y de mejorar el servicio a los usuarios. Los diferentes
departamentos involucrados en el SIW poseen informacion importante referente a cada
una de sus areas y la cual sera manejada por el SIW. Los departamentos involucrados
en la gerencia operativa del estado Merida se muestran en la figura 3.1.
Figura 3.1: Delimitacion del sistema de negocios
3.2
Ingeniera de requisitos
Dentro del metodo Watch, la fase de ingeniera de requisitos comprende dos fases
primordiales: una de ellas es la definicion y la otra es la especificacion del conjunto de
requisitos funcionales y no funcionales del producto de software. En la fase de definicion
29
se clasifican los requisitos y se les asigna prioridades de acuerdo con las necesidades del
cliente. Tambien se lleva a cabo la negociacion de los requisitos, siendo posible que el
equipo encargado del desarrollo proponga nuevos requisitos y modifique algunos de los
previamente establecidos, a fin de que exista compatibilidad entre los mismos.
La fase de especificacion de requisitos deriva un conjunto de modelos en los que
se obtiene lo que sera la arquitectura del sistema. Para la ingeniera de requisitos del
SIC se comenzara realizando una descripcion en lenguaje natural de los necesidades
expresadas por el cliente durante las reuniones y entrevistas.
A partir de esta
descripcion se realiza una clasificacion de los requisitos en funcionales y no funcionales,

y a partir de los funcionales se generan los casos de uso del sistema.
3.2.1
Definici
on de los requisitos de software
Durante las diferentes reuniones y entrevistas realizadas a lo largo del desarrollo

del SIC y especficamente en la fase del modelado de negocios para el entendimiento
de la organizacion surgieron diferentes actores. En esta fase se enuncian los principales
actores dentro del proceso de desarrollo:
Cliente: Es el que tiene una necesidad y desea que esta sea satisfecha. El cliente
solicita el desarrollo de un determinado sistema de software de acuerdo a sus problemas
aporta sus ideas y requerimientos al proceso de dise
y necesidades. El
no del sistema.
En el caso del SIW a implementar, el cliente es la gerencia operativa de Merida de
CANTV, particularmente el departamento de Conmutacion, Transmision y Datos.
Desarrolladores/Analistas: Los miembros del equipo de desarrolladores desempe
nan diferentes roles como por ejemplo: coordinador, analista de sistemas, promotor de software, instructor y consejero o gua informatico. Para satisfacer las necesidades del cliente y la resolucion de su problema, los desarrolladores intentaran cumplir
con sus requerimientos en caractersticas especficas de calidad.
Usuarios finales del sistema: La experiencia y aportes brindados por las
personas a las cuales esta dirigido el SIW son esenciales para el proceso de dise
no y
desarrollo. En este caso, el grupo de usuarios finales del SIW hasta los momentos, esta
constituido por el area de conmutacion, transmision, datos, operaciones centralizadas
que comprende los diferentes distribuidores y el personal que trabaja en las diferentes
30
centrales foraneas; ademas de personal de otras areas como las de planta externa,
que necesita de la informacion contenida en el SIC. Sin embargo, se deben permitir
diferentes niveles de acceso a los usuarios del sistema con miras a que este pueda ser
utilizado por miembros de otras unidades o gerencias. Por lo tanto, el sistema debe
manejar al menos los siguientes perfiles de usuario:
Visitante: El visitante podra realizar consultas a la base de datos del sistema.
Usuario: Ademas de las acciones de visitante, el usuario podra realizar consultas
sobre la base de datos del sistema y realizar modificaciones de registros sin poder
eliminar ning
un tipo de informacion.
Administrador: El perfil de administrador debe permitir tanto la consulta
sobre la base de datos del sistema como la modificacion y eliminacion de registros
erroneos o que carezcan de interes para el sistema de negocios y para los cuales
no tengan permiso los usuarios de perfil inferior.
Super administrador: El super administrador debe ser capaz de acceder al
sistema para la correccion de fallas, la insercion de datos, consultas a la base de
datos, restablecer datos borrados erroneamente, crear nuevos usuarios, modificar
y eliminar usuarios, ingresar y eliminar graficos (mapas o diagramas). Ademas
de realizar todas las acciones sobre la bitacora o historial de uso del sistema.
En la figura 3.2 se muestra el diagrama de actores de SIC.
3.2.2
Definici
on de requisitos seg
un actores
Requisitos del cliente

1. El sistema debe contener la informacion mas importante para cada
departamento, mostrar la informacion de las propiedades de los elementos
para la gestion operativa, as como, el igual acceso por parte de cada uno
de ellos.
2. El sistema debe contener los diferentes mapas y diagramas de la red de
CANTV del estado Merida.
31
Figura 3.2: Diagrama de actores del SIC

3. El sistema debe permitir el manejo de usuarios (creacion, modificacion y
eliminacion), ademas de manejar los perfiles de actores ya mencionados.
(Ver Figura 3.2).
4. El manejo de informacion debe permitir la insercion, modificacion y
eliminacion seg
un los perfiles de actores ya mencionados. (Ver Figura 3.2).
5. La informacion eliminada no debe ser borrada de manera definitiva, sino
pasar a un estado de inactivo y permanecer oculta para los usuarios a
excepcion del Super Administrador.
6. El sistema debe contar con un manejo de historico (bitacora) donde se
32
registren todas las acciones realizadas, bien sea de insercion, modificacion

y/o eliminacion de informacion.
7. Los estilos de letras de las paginas Web y los colores deben ser los
establecidos por CANTV.
8. Poseer una interfaz amigable, entendible y de facil manejo para el usuario.
9. Todas las respuestas a las consultas al servidor de base de datos deben
ser lo mas rapidas y eficientes posible, es por esto, que se ha definido el
tiempo maximo a 60 seg. Este tiempo solo se podra exceder con una clara
justificacion.
Requisitos de los usuarios
1. El sistema debe permitir la insercion, modificacion y eliminacion individual
de los elementos y ademas debe contener la siguiente informacion basica:
a. N
umero del elemento o equipo.
b. Codigo del inventario.
c. Nombre del equipo.
d. Ubicacion geografica con coordenadas.
e.
Capacidades de sus diferentes propiedades.
Ademas de otros
mucho atributos especficos de cada uno de los equipos tales como: IP,
bastidores, sub-bastidores, ranuras, puertos, marcas entre otros.
2. El sistema debe mostrar al usuario la informacion para la gestion de
los registros, tales como: campos de observaciones, u
ltima modificacion
realizada al registro, usuario que realizo la modificacion y cuando lo hizo.
3. Para la b
usqueda de informacion en areas como operaciones centralizadas, el
sistema debe contar con campos de consulta directa, por ejemplo el n
umero
telefonico.
4. El sistema debera poseer un buzon de actualizaciones pendientes, el cual
tiene como funcion notificar a los administradores que deben realizar
modificaciones o actualizaciones para las cuales los usuarios de bajo nivel
no poseen permiso.
33
5. El sistema debe permitir cerrar la sesion al usuario actual.

6. La sesion se cerrara automaticamente luego de determinado tiempo. Al
respecto la sesion de PHP es de 24 minutos, por tal motivo este sera el
tiempo de sesion del SIC.
7. Los errores en la insercion de informacion por parte del usuario deben ser
notificados.
8. Los usuarios se crearan con una contrase
na por defecto y esta puede y debe
ser cambiada por cada usuario.
9. El sistema debe incorporar filtros de b
usqueda, es decir, consultas a la base
de datos por todos los campos.
10. El sistema debe permitir la extraccion de informacion en hojas de calculo
para que puedan servir de apoyo en la toma de decisiones.
Requisitos del desarrollador
1. El software se debera implantar con el lenguaje de programacion PHP en el
lado del servidor y contenidos en HTML y Javascript en el lado del cliente.
2. El sistema gestor de bases de datos debe ser MySQL.
3. El equipo donde se ejecute el sistema debe tener las siguientes caractersticas:
a. Memoria principal de al menos 512 MB.
b. Procesador mayor a 1.0 Ghz.
c. Disco duro de al menos 40 GB.
d. Un monitor.
e. Un raton.
f. Un Teclado.
g. Una tarjeta de video de 32 MB.
h. Una tarjeta de red con capacidad de conexion a la intranet de
CANTV.
i.
El sistema operativo Windows XP, Vista o Linux en cualquier
distribucion.
34
j. Navegador Mozilla Firefox 3.0.
3.2.3
Clasificaci
on de los requisitos y definici
on de prioridades
Requisitos funcionales: Describen las funciones y servicios que el sistema debe

hacer. Estan dirigidos a como el sistema hace las cosas.
Requisitos no funcionales: Describen las diferentes respuestas que debe dar el
sistema ante los distintos tipos de errores los cuales imponen restricciones y atributos.
Ademas de clasificarse, los requisitos son priorizados dependiendo de su importancia
para el desarrollo del producto de software y el resultado que se desea obtener. Es por
esto que los requisitos se clasifican con n
umeros del 1 al 10, siendo el 1 la prioridad mas
alta (requisito obligatorio) y el 10 la prioridad mas baja (requisito casi prescindible).
La Tabla 3.1 muestra la clasificacion de los requisitos.
Tabla 3.1: Especificacion de los requisitos
N de
Nombre del Requisito
Clasificaci
on
Prioridad
Requisito
R1
Tipo de
Requisito
Centralizar la informacion
No Funcional
importante para cada
Aseguramiento
de la calidad
departamento (Igual acceso).

R2
Mostrar la informacion de las
Funcional
Funcionalidad
Funcional
Funcionalidad
propiedades de los elementos

para la gestion operativa.
R3
Contener los diferentes mapas

de Merida, red secundaria,
fibra optica y diagramas.
R4
Permitir la gestion de usuarios
Funcional
Funcionalidad
R5
Capacidad para insertar,
Funcional
Funcionalidad
Funcional
Funcionalidad
modificar y eliminar informacion

seg
un los niveles de seguridad.
R6
La informacion eliminada no
debe ser borrada, solo ocultada.
N de
35
Clasificaci
on
Prioridad
Requisito
R7
Tipo de
Requisito
Registrar cuando se inserta,
Funcional
Funcionalidad
Funcional
Funcionalidad
Funcional
Seguridad
Funcional
Funcionalidad
No Funcional
Restriccion
Funcional
Seguridad
Funcional
Funcionalidad
No Funcional
Restriccion
No Funcional
Restriccion
No Funcional
Restriccion
No Funcional
Restriccion
modifica y/o elimina un elemento

existente en el sistema, quien y
cuando.
R8
Generar reportes o listados de

los elementos almacenados en
el sistema.
R9
Identificar los diferentes

usuarios con sus diferentes
perfiles.
R10
Permitir insertar o eliminar un

mapa o diagrama en el sistema.
R11
Desarrollado bajo la plataforma

de software libre.
R12
Varios niveles de usuario. 1

super administrador, varios
administradores, varios usuarios.
Con sus diferentes niveles de
acceso.
R13
Permitir cerrar sesion
R14
El software se debe implantar

con el lenguaje de programacion
PHP en el lado del servidor y
contenidos en HTML y
Javascript en el lado del cliente.
R15
El gestor manejador de base de

datos debe ser MySQL.
R16
El equipo donde se ejecute el

sistema debe tener ciertas
caractersticas.
R17
El acceso al sistema debe ser a

traves de la intranet de CANTV.
N de
36
Clasificaci
on
Prioridad
Requisito
R18
Requisito
La interfaz debe ser amigable y
No Funcional
de facil manejo.
R19
Tipo de
La respuesta a las consultas al
Aseguramiento
de la calidad
No Funcional
servidor de base de datos deben
Aseguramiento
de la calidad
ser lo mas rapidas y eficientes

posible.
R20
El estilo de letra y colores
No Funcional
deben ser los usados por CANTV.

R21
El sistema debe manejar un
Aseguramiento
de la calidad
Funcional
Funcionalidad
historico o bitacora.
Vale la pena mencionar que a pesar de que el producto aqu mostrado es resultado
de un proceso de refinamiento y validacion junto al cliente, en la medida que se sigue
avanzando en el desarrollo del sistema los requisitos de los actores involucrados y sus
expectativas respecto al sistema cambian constantemente. Por ello se trata de mantener
la recopilacion inicial de requisitos, negociando con el cliente aquellos que surgieran
sobre la marcha. De ese modo se trata de abarcar todos los requisitos enunciados.
3.2.4
Definici
on de casos de uso
La elaboracion de los casos de uso se realiza clasificando las funciones seg

un los
diferentes actores del sistema. La jerarqua de actores se mostro en la figura 3.2.
En la figura 3.3 se muestra el caso de uso para ejemplificar la centralizacion de
informacion, es decir, la implementacion de un servidor para almacenar la informacion.
Por su parte la figura 3.4 explica el caso de uso para la identificacion de un usuario
cualquiera y dar acceso al sistema.
Figura 3.3: Diagrama de caso de uso centralizar informacion
Figura 3.4: Diagrama de caso de uso identificacion
37
38
A continuacion se muestran los diagramas de casos de uso mas importantes del

sistema:
Figura 3.5: Diagrama de caso de uso mostrar informacion
Figura 3.6: Digrama de caso de uso modificar elemento
Figura 3.7: Diagrama de caso de uso reporte lista
Figura 3.8: Diagrama de caso de uso eliminar elemento
Figura 3.9: Diagrama de caso de uso crear usuario
39
Figura 3.10: Diagrama de caso de uso modificar usuario
Figura 3.11: Diagrama de caso de uso insertar elemento
Figura 3.12: Diagrama de caso de uso subir mapa o diagrama
40
41
Descripci
on de los casos de uso:
Para una mayor comprension de la secuencia de tareas asociadas a los casos de uso,
se hace una breve descripcion de cada uno de ellos en la tabla 3.2.
Tabla 3.2: Casos de uso del sistema
Caso
Nombre del Caso
de Uso
de Uso
CU1
Ingresar al sistema.
Descripci
on
El usuario introduce su indicador (nombre de usuario de la red
de CANTV) y su contrase
na en la ventana de inicio del sistema.
CU2
CU3
Identificar perfil de
El sistema verifica el nombre del usuario y la contrase

na, dandole
usuario.
acceso a un conjunto de funcionalidades de acuerdo a su perfil.
Consultar Centrales.
El usuario introduce el estado, municipio y tipo de central. El sistema generara una lista de las centrales.
CU4
Consultar ADS.
El usuario introduce el estado, municipio y central a la que pertenece el ADS. El sistema generara una lista de los ADS.
CU5
Consultar Estaciones.
El usuario introduce el estado y el municipio de la estacion. El

sistema generara una lista de las estaciones.
CU6
Consultar Repetidoras.
El usuario introduce el estado y el municipio de la repetidora. El

sistema generara una lista de las repetidoras.
CU7
Consultar Enlaces de
Fibra Optica.
El usuario introduce el estado, municipio y central o la estacion,

repetidora tanto del origen como del destino. El sistema generara
una lista de enlaces entre estos dos puntos.
CU8
Consultar Enlaces de
El usuario introduce el estado, municipio y central o la estacion,
Radio.
repetidora tanto del origen como del destino. El sistema generara

una lista de los enlaces entre estos dos puntos.
CU9
Consultar TCP-IP
El usuario introduce el estado, municipio y central en donde se
RAS.
encuentra el bastidor TCP-IP. El sistema generara una lista con

la informacion de cada ranura del bastidor.
CU10
Consultar Elementos
El usuario introduce el estado, municipio, central y tipo de
de Datos.
elemento de datos. El sistema generara una lista de los elementos

de datos.
CU11
Consultar Mapas o
El usuario introduce el estado de donde quiera ver los mapas o
Diagramas.
diagramas. El sistema generara una lista de los mapas o diagramas para que el usuario posteriormente los visualice.
CU12
Consultar historico o
El usuario introduce la fecha o rango de fechas y el sistema
bitacora del sistema.
generara una lista de acciones realizadas.
Caso
Nombre del Caso
de Uso
de Uso
CU13
CU14
CU15
42
Descripci
on
Modificar Elementos
Una vez consultado el equipo o elemento del sistema se edita o
del sistema.
actualiza la informacion. El sistema notificara de la modificacion.
Eliminar un Elemento
Luego de la consulta del elemento de elimina (marcar como
del sistema.
eliminado). El sistema notificara de la eliminacion.
Insertar un Elemento
El usuario elige el tipo de elemento para introducir la informacion
en el sistema.
correspondiente e inserta el elemento. El sistema notificara de

la insercion.
CU16
Reporte Lista.
Luego de la consulta del elemento en el sistema el usuario

selecciona exportar lista. El sistema generara una hoja de calculo
con la lista de elementos buscados anteriormente.
CU17
Crear Usuario.
El usuario con el perfil para crearlo introduce los datos y crea el

usuario. El sistema notificara la creacion.
CU18
Modificar Usuario.
El usuario consulta el usuario deseado, edita o actualiza la

informacion. El sistema notificara de la modificacion.
CU19
Cerrar Sesion.
El usuario cierra la sesion actual en el sistema.
CU20
Registrar Accion.
La accion realizada por el usuario es almacenada en la base de datos.
3.2.5
Matriz de casos de uso vs. requisitos
Parte fundamental y esencial del proceso de ingeniera de requisitos es la validacion

y verificacion de los requisitos del sistema. Mediante la matriz de Casos de Uso vs.
Requisitos es posible determinar si los requisitos del cliente fueron satisfechos con los
casos de uso especificados. En la matriz de la tabla 3.3 se observa como cada requisito
se ve incluido en por lo menos un caso de uso, por lo que se han cubierto todos los
requisitos funcionales del SIC.
43
Tabla 3.3: Matriz de casos de uso vs. requisitos

HH
HH CU
CU1 CU2 CU3 CU4 CU5 CU6 CU7 CU8 CU9 CU10 CU11 CU12 CU13 CU14 CU15 CU16 CU17 CU18 CU19 CU20
H
HH
R
H
R2
ok
R3
ok
ok
ok
ok
ok
ok
ok
ok
R4
ok
R5
ok
R6
ok
ok
ok
ok
R7
ok
R8
R9
ok
ok
ok
R10
ok
R13
R21
ok
ok
Captulo 4
Dise
no del Sistema de Informaci
on
Centralizado (SIC)
Una vez terminada la tarea de especificacion y definicion de los requisitos, se
procede a dise
nar el sistema. La fase de dise
no pretende determinar la estructura de
la aplicacion a fin de satisfacer los requisitos obtenidos en el procedimiento anterior,
estableciendo la interconexion de los distintos subsistemas que la conforman, junto
con los parametros que regulan que el sistema apoye los procesos de la organizacion
y cumpla con los objetivos que fueron prefijados. Dentro de esta fase se establece
el conjunto de metas con las que debe cumplir el dise
no, se determina cuales de los
requerimientos se encuentran relacionados con la arquitectura del sistema, se describe
la arquitectura, se dise
na la interfaz usuario/sistema y se dise
na la base de datos.
4.1
Metas de dise
no
Buscando que el desarrollo de la aplicacion realmente satisfaga las necesidades de

los actores involucrados en el y que ademas cumpla con los estandares de rendimiento
esperados, se hace necesario fijar ciertas metas en esta fase de dise
no. Las metas
propuestas para el dise
no se enuncian a continuacion:
La arquitectura del sistema estara basada en el uso de servicios Web que estaran
claramente especificados y que podran ser reutilizados por cualquier componente
n del estilo arquitecto

nico
4.2 Definicio
45
que los necesite.

Los componentes dise
nados van a buscar cumplir los requisitos de los actores
involucrados de la manera mas eficiente posible.
La arquitectura estara basada en la utilizacion de componentes modulares bien
estructurados y con entradas y salidas claramente definidas.
El dise
no sera facil de entender, manejar y modificar, permitiendo probar y
detectar fallas rapidamente.
El dise
no se caracterizara por una alta cohesion de los componentes dentro
de cada subsistema y un bajo acoplamiento, es decir, poca dependencia de
componentes de otros subsistemas.
4.2
Definici
on del estilo arquitect
onico
Para el desarrollo del SIW se sigue un patron de dise

no basado en una arquitectura
de 3 capas. La principal ventaja de la utilizacion de este patron esta en la capacidad
de lograr un sistema altamente flexible, pues al separar al maximo los tres grupos de
componentes dentro de la aplicacion, se puede modificar alguno de los componentes de
una capa sin que ello implique hacer modificaciones sobre los componentes de las otras
capas. Al mismo tiempo se obtiene un codigo mas limpio y entendible, garantizando
la mantenibilidad y facilidad de prueba.
La distribucion fsica del sistema es otra de las razones que motivan el uso de este
patron arquitectonico, pues el SIW se encuentra alojado en 3 servidores distintos: un
servidor Web (en el cual se puede alojar todos los componentes relacionados con la
presentacion visual del sistema y su interaccion con los usuarios [este servidor no posee
acceso a la base de datos]), un servidor de aplicaciones (en el cual se puede ejecutar
toda la logica de negocios de la aplicacion y todo lo relacionado al acceso a las bases
de datos) y finalmente un servidor de bases de datos (en el que se alojan los elementos
persistentes del sistema).
Debido a la naturaleza de los servidores, toda la logica asociada con la manipulacion
de los datos obtenidos mediante consultas con la base de datos es implementada en

nico
4.2 Definicio
46
el servidor de aplicaciones, mientras que toda la validacion de los datos de entrada

y la presentacion a los usuarios es manejada por el servidor Web. La comunicacion
entre el servidor de aplicaciones y el servidor Web esta basada en la implementacion
de servicios Web. La arquitectura del sistema se describe como sigue:
1. Primera capa: Presentaci
on
Funcionalidades:
Acceso al sistema.
Distribucion de la informacion seg
un el usuario.
Visualizacion de los mapas de la red.
Visualizacion de la informacion que se solicite.
Escogencia de funciones y funcionalidades.
Validacion de los formatos de los datos.
Activacion de las funcionalidades del sistema.
Visualizacion de errores.
(a) Distribucion de la informacion seg
un el usuario.
(b) Validacion de formatos.
(c) Visualizacion de la informacion.
(d) Acciona funcionalidades del sistema.
2. Segunda capa: Negocios
Funcionalidades:
Hacer y descargar los reportes.
Validacion de datos antes de insertar en el sistema.
Validar la existencia de elementos en el sistema.
Manejo de control de acceso.
Procesamiento de las funcionalidades del sistema.

nico
4.2 Definicio
47
Manejo de bitacora del sistema.

(a) Control de acceso.
(b) Procesamiento de las funcionalidades administrativas.
(c) Validacion de datos.
(d) Manejo de bitacora del sistema.
3. Tercera capa: Base de datos
Funcionalidades:
Conexion con el sistema manejador de base de datos (SMBD). Contempla
la construccion y ejecucion de las consultas a la base de datos.
Registrar las operaciones en el sistema, insertar, modificar, eliminar, etc.
Gestion de historico del sistema.
(a) Gestion de operaciones en la base de datos.
(b) Manejo de historico.
La interaccion entre las tres capas de este sistema se muestra en la Figura 4.1.

nico
4.2 Definicio
Figura 4.1: Diagrama de despliegue del sistema
48
4.3 Diagrama de clases del sistema
4.3
49
Diagrama de clases del sistema
Las clases son abstracciones del conjunto de detalles comunes de la estructura de

los objetos que buscan reducir la complejidad de los mismos para de esta forma tener
una mejor comprension del mundo que los envuelve: estan formados por atributos y
metodos que representan las caractersticas y el comportamiento de las mismas; as
como las relaciones comunes, permitiendo de esta forma definir y limitar el dominio de
los objetos que forman parte del sistema.
Los atributos y operaciones (metodos) as como las relaciones de agregacion,
asociacion o jerarqua que existan entre las clases pueden ser representados graficamente
a traves de los diagramas de clases definidos en el UML. Estos poseen una importancia
esencial en el proceso de dise
no, ya que permiten mostrar la estructura de la
informacion, as como la estructura estatica que tendra el sistema lo que contribuye a
su vez a tener un dise
no conceptual de la base de datos en la que se soportaran todas
las funciones del sistema.
En este orden de ideas el diagrama de clases del sistema que se muestra en la figura
4.2.
4.3 Diagrama de clases del sistema
Figura 4.2: Diagrama de clases del SIC
50
4.4 Diagramas de actividades
4.4
51
Parte importante del modelado del sistema son los diagramas de actividades, estos
son utilizados para modelar el flujo de control de las actividades que tienen lugar a lo
largo del tiempo junto a las tareas concurrentes que pueden realizarse a la vez. Algunos
de los diagramas de actividades mas importantes en el desarrollo de SIC se muestran
a continuacion.
Figura 4.3: Diagrama de actividad de autenticar usuario
Figura 4.4: Diagrama de actividad de consultar equipo
4.5 Diagramas de secuencias
52
Figura 4.5: Diagrama de actividad de modificar equipo
4.5
Diagramas de secuencias
Una vez analizados los diagramas de actividades es importante saber el
comportamiento del sistema en cuanto a la ejecucion de sus procesos en el tiempo.

Para ver esta interaccion ordenada entre los objetos del sistema de acuerdo a una
secuencia temporal de eventos tenemos los diagramas de secuencias. Algunos de ellos
se mostraran a continuacion.
Figura 4.6: Diagrama de secuencia de consultar equipo
4.5 Diagramas de secuencias
Figura 4.7: Diagrama de secuencia de modificar equipo
Figura 4.8: Diagrama de secuencia de autenticar usuario
53
o de la interfaz del usuario

4.6 Disen
4.6
54
Dise
no de la interfaz del usuario
Cuando un usuario cualquiera accede al sistema a traves de la Intranet de CANTV,

se muestra la misma pantalla de acceso al SIC en la que se pide a la persona que ingrese
su usuario y contrase
na. La pantalla inicial del sistema se muestra en la figura
4.9. Una vez dentro del sistema, la estructura de la interfaz sigue los estandares de
presentacion de CANTV para las aplicaciones disponibles a traves de la Intranet tales
como: colores, tama
nos, tipos de letras, entre otros.
La mayora de las aplicaciones de la empresa cuentan con un men
u de navegacion,
un area de trabajo en la cual se realizan las acciones del sistema y un encabezado. La
figura 4.10 muestra la estructura general de estas pantallas. Por otra parte el flujo entre
las pantallas del sistema se muestra en la figura 4.11 en el se incluyen las principales
pantallas de los modulos del SIC.
Figura 4.9: Pantalla de inicio del sistema
o de la interfaz del usuario

4.6 Disen
Figura 4.10: Pantalla principal de usuario
55
n y pruebas
4.7 Fase de implementacio
56
Figura 4.11: Diagrama de flujo de pantallas
4.7
Fase de implementaci
on y pruebas
Esta fase comprende la implementacion de las tres capas de la arquitectura que fueron
dise
nadas en la parte anterior. En dicha fase se construyen e integran los componentes
de la capa de presentacion, los componentes de la capa de logica de negocios y los
componentes de la capa de datos. Estos componentes son probados individualmente
durante su implementacion y, una vez integrados, se realiza un conjunto de pruebas
que permiten determinar si la aplicacion cumple con los requisitos funcionales y no
funcionales del sistema. El producto final que se obtiene es la primera version del
sistema probada y corregida.
4.7.1
Implementaci
on del sistema
El sistema es implementado en tres servidores (tal y como se tena previsto durante la

fase de dise
no). La capa de presentacion es implementada en un servidor Web, el cual
solo debe ejecutar las funciones de captura de datos por parte del usuario y generacion
de paginas Web, ya que solo se puede comunicar con el servidor de aplicaciones y con
el cliente. Los componentes de la capa de logica de negocios se implementan en un
servidor de aplicaciones que se encarga de la captura y procesamiento de los datos del
n y pruebas
57
servidor de bases de datos, en el que se encuentra implementada la capa de datos del

sistema.
Con esto se busca garantizar la mantenibilidad del sistema, para ello, se trata de
separar al maximo el codigo escrito en PHP con el codigo HTML, y se le da particular
importancia a la documentacion de los componentes as como se hace enfasis en lograr
un sistema altamente modular. En complemento a esta estructura modular se crean
los archivos de funciones globales de PHP y validaciones en javascript que pueden ser
invocados desde cualquier punto del sistema.
Para la codificacion del sistema se realizaron y analizaron los diagramas de
actividades y diagramas de secuencias, estos ayudaron a construir la estructura de
los archivos. Los diagramas de actividades y secuencias se muestran en el Apendice A
de este documento.
La nomenclatura utilizada es muy sencilla, al respecto los nombres de las variables
y funciones se escriben en letras min
usculas. Algunos de los lineamientos de listan a
continuacion:
Las palabras se separan por un guion bajo .
Las tablas de la base de datos llevan el mismo nombre del objeto con la primera
letra en may
uscula. Por ejemplo Centrales.
Las funciones de validacion van precedidas por la palabra validar. Por ejemplo
validar central.
Los nombres de las funciones tienen el formato accion objeto donde accion es
lo que se esta realizando sobre el objeto. Por ejemplo modificar central.
1. Implementaci
on de la capa de presentaci
on
Durante el desarrollo del SIC se comenzo ensamblando los componentes de
la capa de presentacion. La interfaz Usuario/Sistema comprende la codificacion
e integracion de componentes del lado del servidor Web y componentes del lado
del cliente:
El codigo del lado del cliente, contiene los elementos visuales (HTML,
controles de servidor y texto estatico) y el codigo que se debe ejecutar en el
n y pruebas
58
navegador del cliente en la forma de funciones javascript utilizandose como

una primera etapa de validacion.
El codigo del lado del servidor Web contiene la logica de programacion de las
paginas y es implementado mediante segmentos de codigo PHP embebidos
dentro de las paginas HTML y mediante funciones contenidas en scripts
externos a las paginas.
Para el tama
no de letras, colores, estilo de men
u y otras caractersticas de la
interfaz se creo un archivo de estilos CSS.
Una de las partes mas complejas de la interfaz, fue el caracter dinamico que
deban llevar las consultas en el sistema. Se deba filtrar la b
usqueda en casi todo
el sistema, ademas de activar y desactivar campos en algunos formularios. Las
figuras siguientes muestra algunos casos en los que se aprecia el caracter dinamico
de la interfaz.
Figura 4.12: Formulario dinamico
Figura 4.13: Filtro de consulta dinamico
n y pruebas
59
Figura 4.14: Formulario dinamico

Por otra parte el SIC cuenta con un repositorio de funciones comunes utilizadas
por todos los componentes de la capa de presentacion. Entre las funcionalidades
se pueden mencionar: metodos que generan la estructura de las paginas y del
men
u dinamicamente de acuerdo al perfil del usuario, funciones de validacion,
funciones que llaman servicios Web, entre otras.
2. Implementaci
on de la capa de l
ogica de negocios
En esta capa se desarrollan el conjunto de funciones y metodos que obtienen
informacion de los objetos del modelo de negocios. Esta capa es la encargada de
las operaciones de modificacion, edicion e insercion de los datos.
Se desarrollan scripts para agrupar servicios que manipulen las mismas tablas
en la base de datos y el acceso a estos servicios desde el servidor Web
es implementado en scripts externos a las paginas, de modo que para los
componentes de la capa de presentacion la llamada a los servicios Web resulta
transparente. Los script mencionados anteriormente se guardan en un repositorio
de funciones comunes a esta capa utilizadas por todos los componentes de dicha
capa.
3. Implementaci
on de la capa de datos
La implementacion de la capa de datos del sistema contempla el dise
no que se
hizo en el apartado anterior. La naturaleza de las transacciones y la sencillez
n y pruebas
60
de las relaciones hacen que no resulte necesario definir vistas ni restricciones

complejas para la recuperacion de los datos. Para la administracion de la base
de datos se utiliza la herramienta phpMyAdmin que facilita la ejecucion de las
consultas antes de ser implementadas en la logica de negocios, y hace posible
al desarrollador visualizar y manipular directamente el contenido de la base de
datos.
Del modelo de clases obtenido en el captulo 4, se realiza un analisis de
las clases y entidades que se identificaron junto con sus atributos y relaciones,
construyendo as el modelo relacional. En la figura 4.15 se muestra el modelo
relacional del SIC.
n y pruebas
Figura 4.15: Modelo de la base de datos del SIC
61
n y pruebas
4.7.2
62
Pruebas del sistema
Las pruebas del sistema buscan detectar y corregir el mayor n

umero de errores
posibles y con una cantidad razonable de tiempo y esfuerzo. En el caso del SIC, las
pruebas permiten verificar que la aplicacion funciona correctamente en condiciones
tpicas de operacion y que satisface los requisitos funcionales y no funcionales
determinados previamente. Para el desarrollo de las pruebas se siguio la siguiente
estrategia:
Se comienza probando individualmente cada uno de los componentes utilizando
pruebas de caja negra. En este tipo de prueba se toman datos de entrada
considerados sin tomar en cuenta el funcionamiento interno del componente,
utilizando valores ubicados justo en los lmites permitidos y fuera de ellos donde
probablemente ocurran excepciones.
En caso de detectarse un resultado inesperado durante la ejecucion de las pruebas
de caja negra, se realizan pruebas de caja blanca en las que se rastrea el
comportamiento interno del componente, verificando la ejecucion de cada una de
las instrucciones involucradas en el caso de prueba, esto con el fin de detectar y
corregir la instruccion en la que se produce el error.
La integracion de los componentes es probada utilizando pruebas funcionales
orientadas a cada caso de uso. En estas pruebas se verifica que los componentes
que intervienen en cada caso de uso funcionan correctamente, cumpliendo as con
los requisitos funcionales del sistema.
Finalmente se hace una verificacion y validacion de los requisitos de los actores.
Esto con el fin de detectar el grado de cumplimiento de los requisitos en el
desarrollo del sistema.
1) Pruebas de caja negra del sistema
El enfoque funcional o de caja negra consiste en estudiar la especificacion de las
funciones, la entrada y la salida con el fin de verificar que los componentes se comportan
de la manera esperada. Aqu, la prueba ideal del software, consistira en probar todas
n y pruebas
63
Tabla 4.1: Pruebas de caja negra

M
odulo
Par
ametros de
Salida
Resultado
Entrada
Control de Acceso
Usuario incorrecto
(ingresar.php)
Control de Acceso
Contrase
na incorrecta
(ingresar.php)
Mensaje indicando que el
Satisfactorio
usuario no es valido.
(Ver figura 4.16).
Mensaje indicando que la
Satisfactorio
contrase
na es incorrecta.
(Ver Figura 4.17).
Insertar Equipos
Campo obligatorio
Mensaje indicando que se
Satisfactorio
(insertar central.php)
faltante.
deben completar todos los
(Ver Figura 4.18).
campos del formulario.

Consultar Equipos
Consulta correcta
(lista centrales.php)
Se muestra la lista de
Satisfactorio
centrales deseada.
(Ver Figura 4.19).
Listar Bitacora
Rango de fechas
Se muestra la lista de
Satisfactorio
(listar bitacora.php)
valido.
acciones realizadas en el
(Ver Figura 4.20).
sistema.
Reportes
Consulta correcta
(exportar archivo.php)
Se exporta una hoja de
Satisfactorio
calculo con la informacion
(Ver Figuras 4.21, 4.22).
las posibles entradas y salidas del programa. Sin embargo, se puede generalizar un
conjunto de valores que abarque el mayor n
umero de casos de entrada posibles y de ese
modo cubrir varios escenarios a la vez. La tabla 4.1 muestra algunas de las pruebas de
caja negra realizadas.
Figura 4.16: Mensaje obtenido al ingresar usuario invalido
Figura 4.17: Mensaje obtenido al ingresar contrase

na incorrecta
n y pruebas
Figura 4.18: Mensaje obtenido al intentar ingresar equipo con campos faltantes
Figura 4.19: Lista de centrales.
Figura 4.20: Registro de acciones en SIC
64
n y pruebas
Figura 4.21: Exportar archivo
Figura 4.22: Informacion exportada a una hoja de calculo
65
n y pruebas
66
2) Pruebas de caja blanca

El enfoque estructural o de caja blanca consiste en centrarse en la estructura interna
(implementacion) del programa para elegir los casos de prueba. En este caso, la prueba
ideal del software consistira en probar todos los posibles caminos de ejecucion a traves
de las instrucciones del codigo que puedan trazarse. Las pruebas de caja blanca son
mas exhaustivas que las pruebas de caja negra por lo que son realizadas solo en aquellos
casos de prueba en los que los resultados obtenidos difieren de los resultados esperados.
Todo esto con el fin de poder rastrear y corregir los errores.
El dominio que se tiene del conjunto de instrucciones asociadas a cada modulo,
hace que no sea necesario revisar exhaustivamente el codigo ni recurrir a analisis de
complejidad ciclomatica para el dise
no de las pruebas.
Uno de los casos en el que fue necesario verificar el funcionamiento interno
del componente fue para el modulo de registrar en bitacora cuando se realizaban
modificaciones de equipos algunos registros se guardaban de manera erronea, con
valores vacos como se muestra en la figura 4.23.
Figura 4.23: Valores erroneos

De la Figura 4.23 se aprecia que el n
umero 8361000 es un registro con campos
vacos puesto que el formato correcto es de la forma 123-1234567. En este orden de
ideas el error se generaba cuando se llamaba a la funcion de registro, la manera en que
se llamaba enviaba variables vacas insertando un registro vaco. Luego de corregir la
llamada la funcion se aprecia el correcto registro de acciones. (Ver Figura 4.24).
n y pruebas
67
Figura 4.24: Valores correctos

3) Pruebas funcionales
Para verificar que el sistema satisface los requisitos funcionales definidos en la fase de
ingeniera de requisitos, se desarrolla un conjunto de pruebas en las que los componentes
que intervienen en cada caso de uso son probados de manera general, en condiciones
que simulan las condiciones normales de operacion del sistema.
En estas pruebas tambien se revisa que los componentes se integran de manera
adecuada, cumpliendo con las especificaciones hechas en la fase de dise
no. Las pruebas
realizadas se muestran en la tabla 4.2.
4) Verificaci
on y validaci
on de los requisitos
En esta actividad, se determina que el sistema cumple con los requisitos establecidos
en el analisis y que estos satisfacen las necesidades de los usuarios. La verificacion
consiste en comprobar que el sistema cumple con la especificacion de requisitos; parte
de este proceso fue llevada a cabo durante la ejecucion de las pruebas funcionales
orientadas a caso de uso y se encontro que todos los casos de uso incluidos en el
analisis fueron construidos en el sistema.
La validacion nos da como resultado que el sistema satisface las necesidades de los
usuarios. Para la entrega final de este sistema se hizo una presentacion al cliente y a
los usuarios principales, en la que se ejecutan los procesos apoyados por el sistema y se
comprobo que el comportamiento en condiciones tpicas de operacion es el esperado,
midiendose el grado de aceptacion y de satisfaccion de las necesidades de informacion
de los usuarios finales.
En estas pruebas el cliente sugiere correcciones que se le deben hacer al sistema
para que apoye de manera mas efectiva sus funciones.
n y pruebas
Caso de uso
68
Tabla 4.2: Pruebas funcionales

Par
ametros de
Salida
Resultado
entrada
Ingresar al sistema
Usuario y contrase
na
Pantalla principal de sistema
Satisfactorio
Identificar perfil de
Usuario y contrase
na
Opciones del menu de acuerdo
Satisfactorio
usuario.
Consultar equipo
al tipo de usuario.
Equipo que desea
Lista de equipo que ha consul-
consultar
tado (centrales,ads, etc.)
Consultar mapas o
Estado de el cual
Lista de mapas del estado
diagramas.
desea ver los mapas
solicitado.
Consultar registro
Rango de fechas o
Lista de acciones realizadas en
historico o bitacora
toda la bitacora
el sistema.
Modificar equipo
Editar la informacion
Mensaje de equipo modificado
del equipo
correctamente.
Equipo consultado
Mensaje de equipo eliminado
seleccionar eliminar
correctamente. El super admi-
Eliminar equipo
Satisfactorio
Satisfactorio
Satisfactorio
Satisfactorio
Satisfactorio
nistrador visualiza estatus de

borrado.
Insertar equipo
Reporte lista
Crear Usuario
Informacion del
Mensaje de equipo insertado
equipo a insertar
correctamente.
Consulta de alg
un
Hoja de calculo con la infor-
elemento del sistema
macion
Datos del usuario
Mensaje de Usuario creado
Satisfactorio
Satisfactorio
Satisfactorio
correctamente. Se enva un
correo al nuevo usuario.
Modificar Usuario
Cerrar sesion
Editar la informacion
Mensaje de usuario modificado
del usuario
correctamente
El usuario elige
Pantalla de salida del sistema
cerrar sesion
Satisfactorio
Satisfactorio
4.8 Entrega final del sistema
69
Vale la pena resaltar que durante todo el proceso de desarrollo, la participacion del
cliente y los usuarios fue activa y se realizaron correcciones al sistema en base a las
observaciones que iban surgiendo. Sin embargo, estas u
ltimas pruebas permitieron la
validacion final de todos los requisitos.
4.8
Entrega final del sistema
Para la puesta en marcha de SIC fue necesario que todas las restricciones y controles
establecidos fueran cumplidos durante las fases del desarrollo y las condiciones del
ambiente en el que fue implementado el sistema simulan completamente a las del
ambiente de operacion definitivo, lo que hace que la puesta en produccion del sistema
no presente mayores complicaciones.
La documentacion entregada al cliente junto con el sistema comprende: manuales
de usuario para los perfiles definidos, manual de mantenimiento para el Super
Administrador del sistema, y algunos videos de uso. Ademas, se hizo una presentacion
orientada a los usuarios en la que se mostraron las funcionalidades del sistema y se dio
una induccion a las personas responsables de su uso y mantenimiento. La tabla 4.3
muestra las fechas para las cuales se realizaron las inducciones de SIC al personal de
CANTV.
Tabla 4.3: Fechas de cursos de induccion
Fecha
Lunes
23/03/2009
Personal de CANTV
Lugar
Alta Gerencia del Estado Merida
Sala de reuniones de la central La Pedregosa
Miercoles 25/03/2009
Supervisores de Area y Lideres de Grupo
Jueves
26/03/2009
Personal de los distribuidores
Viernes
27/03/2009
Personal de la Zona baja
Sala de reuniones de la central El Viga
Jueves
30/04/2009
Otro personal de CANTV
Sala de reuniones de la central Merida Centro
En este orden de ideas durante la entrega final del sistema se verifico que todos
los requisitos de los actores fueron satisfechos. Sin embargo, surgen observaciones
y recomendaciones acerca de aspectos que se pueden incorporar para mejorar las
funcionalidades del sistema. Estas sugerencias hacen posible pensar en el desarrollo de
una segunda version mas adelante, que sea dinamica en el sentido de tomar informacion
4.8 Entrega final del sistema
70
dinamicamente de otros sistemas y que sea capaz de aprovechar los mapas y diagramas
para realizar monitoreo en tiempo real de los equipos de la red.
Hasta la fecha al desarrollador le es gratificante decir que el sistema se encuentra
operativo y en produccion en el estado Merida, ademas de acuerdo a la perspectiva
del desarrollador las miras a futuro indican que el sistema sera utilizado por CANTV
en otros estados del pas, dando as un apoyo total al desarrollo del proyecto y su
crecimiento como herramienta para la gestion operativa.
En diferentes reuniones se ha estudiado la incorporacion de informacion del Estado
Barinas, as como los diferentes mapas y diagramas de sus redes, lo cual ya es un
crecimiento en el desarrollo de este sistema.
Captulo 5
Conclusiones y Recomendaciones
5.1
Conclusiones
El desarrollo de software es un proceso complejo que requiere la aplicacion de

metodologas y procedimientos bien estructurados para obtener productos de alta
calidad a un mnimo costo. Las metodologas imponen un proceso disciplinado
sobre el desarrollo de software con el proposito de hacerlo mas predecible y
eficiente.
El desarrollo del SIC de CANTV fue satisfactorio y sin mayores inconvenientes,
los objetivos planteados inicialmente se han cumplido en su totalidad. CANTV
cuenta ahora con un sistema nuevo en apoyo a la gestion operativa de facil
manejo capaz de agilizar los procesos de recuperacion, almacenaje y b
usqueda de
informacion.
La consolidacion de este sistema, representa una herramienta fundamental en la
toma de decisiones oportunas y efectivas, ya que es posible para los usuarios tener
acceso a la informacion de una manera mas facil y desde cualquier punto de red
de la empresa.
La manera en que fue dise
nado y desarrollado el SIC permite la incorporacion
de nuevos modulos de manera facil y rapida, sin tener que recurrir a una
reestructuracion del mismo lo que facilita la continuidad de su desarrollo.
5.1 Conclusiones
72
El manejador de base de datos MySQL, en el que fue realizado el SIC, es un

sistema de manejador de base de datos que permite crear y manipular de manera
facil e intuitiva una base de datos relacional, por lo que la implementacion y
pruebas fueron realizadas sin mayores inconvenientes.
En el caso del SIC, la aplicacion del metodo Watch jugo un papel protagonico para
poder cumplir con los objetivos planteados. Este metodo permitio la aplicacion
estructurada de un conjunto de procedimientos en los que fue posible para el
cliente conocer en todo momento el nivel de avance del proyecto y participar
de manera activa sobre el proceso de dise
no y desarrollo, colaborando en el
refinamiento de los productos y sub-productos intermedios que se iban obteniendo
en cada fase.
La filosofa de software libre desempe
no un papel de suma y vital importancia
para el desarrollo de este proyecto. Al respecto el SIC cumple con el decreto
3.390 y se convierte en una aplicacion piloto para la CANTV del Estado Merida
bajo dicha filosofa por lo tanto, en el marco de las nuevas tecnologas libres el
SIC es ahora una de ellas.
Las pruebas del sistema se realizaron de manera satisfactoria, se ejecutaron cada
una de ellas conjuntamente con los usuarios del sistema, brindando resultados
positivos que le permitieron a los involucrados concluir que el sistema se comporta
de la manera esperada y de forma confiable. Ademas, la realizacion de estas
pruebas facilito al grupo de desarrollo el proceso de adiestramiento de los usuarios,
ya que permitio que este fuera conocido, despertando el interes por el uso del
sistema.
Finalmente, cabe destacar que el exito del desarrollo de la aplicacion fue un
trabajo colectivo y colaborativo, gracias al uso e integracion de la metodologa
utilizada, que apoya los diferentes procesos relacionados al proceso de desarrollo
de una aplicacion de software; unido con el buen desempe
no de todos los entes
que intervinieron en el proyecto de una forma directa o indirecta.
5.2 Recomendaciones
5.2
73
Recomendaciones
En virtud de las conclusiones y a la luz de los resultados obtenidos, es conveniente

brindar algunas recomendaciones que pudieran extender los resultados del desarrollo
del proyecto, y a su vez que podran ser consideradas por los futuros trabajos que se
realicen en el area. En este sentido se recomienda:
Integrar el Sistema de Informacion Centralizado (SIC) con otros sistemas dentro
de la plataforma de CANTV con el fin de ayudar en la gestion operativa.
Esto ayudara a disminuir la divergencia de informacion entre los sistemas de
informacion de la empresa, es decir, que la informacion de un equipo almacenada
en un sistema sea la misma que en otro sistema.
Incorporar mecanismos que generen estadsticas y graficos de los niveles de
actualizacion de las bases de datos de sus equipos, es decir, graficos que muestren
mensualmente que tantas modificaciones fueron realizadas en el sistema para ser
comparadas con la data fsica y observar la periodicidad con que los usuarios
realizan dichas modificaciones..
Incorporar funcionalidades que permitan relacionar de manera dinamica la
informacion almacenada en las bases de datos con los mapas o diagramas de
la red.
Aplicar este proyecto a niveles mas profundos en los diferentes departamentos, es
decir, profundizar el nivel de detalle de la informacion almacenada en el sistema.
Promover el uso de la filosofa de software libre como pilar fundamental para
el desarrollo de la empresa en el ambito de las tecnologas informaticas. Las
innumerables ventajas de esta filosofa motivaran al personal en el uso de
herramientas desarrolladas bajo dicha filosofa.
Profundizar el desarrollo de esta aplicacion, darle continuidad, soporte y
mantenimiento para su correcto desempe
no, es decir, crear nuevos modulos
y nuevas funcionalidades de interes para el sistema de negocios, realizar
periodicamente limpiezas a la base de datos con la finalidad de eliminar registros
5.2 Recomendaciones
74
que carezcan de interes para el sistema de negocios. Enfatizar en el uso de este

sistema es la mejor manera de garantizar sus desarrollos a futuro.
Bibliografa
Achour, M. and Betz, F. (2008). Manual de PHP. 1997-2008 the PHP Documentation
Group. Disponible en : http://ve2.php.net/manual/es/index.php.
Barrios, J. (2000). Sistemas de informacion. Technical report, Universidad de Los
Andes, Merida, Venezuela.
CANTV (2009). Pagina de la empresa. http://www.cantv.com.ve.
DesarrolloWeb (2009a). Comenzando a utilizar NuSOAP. Disponible en : http:
//www.desarrolloweb.com/articulos/1884.php.
DesarrolloWeb (2009b).
Simple acces object protocol (SOAP).
Disponible en :
http://www.desarrolloweb.com/articulos/1557.php.
Elmasri, R. and Navathe, S. (2002).
Fundamentos de bases de datos.
Pearson
Educacion, Madrid, tercera edicion edition.

Gerencia de Educacion y Desarrollo (1998). Generalidades de Transmisi
on. CANTV,
version 1 edition.
Linux, C. (2009).
Una introduccion a apache.
Disponible en : http://linux.
ciberaula.com/articulo/linux_apache_intro/.
Montilva, J. A. and Barrios, J. (2003). A component-based method for developing web
applications. Technical report, Universidad de Los Andes, Merida, Venezuela.
Montilva, J. A., Hamzan, K., and Gharawi, M. (2000). The watch model for developing
business software in small and midsize organizations. Technical report, Universidad
de Los Andes, Merida, Venezuela.
BIBLIOGRAFIA
76
Mu
noz, A. (2003). Sistemas de informacion en las empresas. Disponible en: http:
//www.hipertext.net/web/pag251.htm.
Nickul, D. (2007). Service oriented architecture (SOA) and specialized messaging
patterns. Adobe Systems Incorporated. Disponible en: http://www.adobe.com/
enterprise/pdfs/Services_Oriented_Architecture.pdf.
Object Management Group (2007).
OMG UML Available Specifications.
OMG.
Disponible en: http://www.omg.org/docs/formal/07-11-04.pdf.

DEL SOFTWARE UN ENFOQUE
Pressman, R. S. (2002).
INGENIERIA
PRACTICO.
McGRAW-HILL/INTERAMERICANA DE ESPANA, S . A. U., 28023
Aravaca (Madrid), quinta edition.
Schmal, R. and Cisternas, E. (2000). Sistemas de informacion: Una metodologa para
su estructuracion. actas de la XXVI conferencia latinoamericana de informatica.
Technical report, Instituto Tecnologico y de Estudios Superiores de Monterrey,
Mexico.
Schmuller, J. (1997). Aprendiendo UML. Prentice Hall, Naucalpan de Juarez, Edo de
Mexico.
Valade, J. (2007). PHP and MySQL For Dummies. Wiley Publishing, Inc, 111 River
Street Hoboken, NJ 07030-5774 Indianapolis, Indiana, 3rd edition.
Wikipedia (2008a). Arquitectura orientada a servicios (SOA). Wikipedia. Disponible
en: http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios.
Wikipedia (2008b). Lenguaje unificado de modelado (UML). Disponible en : http:
//es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado.
Wikipedia (2008c). MySQL. Disponible en : http://es.wikipedia.org/wiki/MySQL.
Wikipedia (2008d). PHP. Disponible en : http://es.wikipedia.org/wiki/.php.
Ap
endice A
Diagramas de estado
Figura A.1: Diagrama de estado de equipo
Figura A.2: Diagrama de estado de mapa o diagrama
Figura A.3: Diagrama de estado de usuario autenticado
78
Figura A.4: Diagrama de estado de usuario

Figura A.5: Diagrama de actividad de crear usuario
Figura A.6: Diagrama de actividad de modificar usuario
Figura A.7: Diagrama de actividad de cerrar sesion
79
Figura A.8: Diagrama de actividad de insertar equipo
Figura A.9: Diagrama de actividad de eliminar equipo
Figura A.10: Diagrama de actividad de listar reporte
80
Figura A.11: Diagrama de actividad de subir mapa o diagrama

Diagramas de secuencias
Figura A.12: Diagrama de secuencia de crear usuario
Figura A.13: Diagrama de secuencia de cerrar sesion
81
Figura A.14: Diagrama de secuencia de modificar usuario
Figura A.15: Diagrama de secuencia de insertar equipo
82
Figura A.16: Diagrama de secuencia de eliminar equipo
Figura A.17: Diagrama de secuencia de listar reporte
Figura A.18: Diagrama de secuencia de subir mapa o diagrama
Ap
endice B
Glosario de t
erminos
Central telef
onica: Es el conjunto de equipos (mecanicos, electromecanica y/o
electronicos) que intervienen o hacen posible la conexion entre dos lneas de
abonados que pertenecen a la red, cuando un abonado origina comunicacion con
otro.
ADP: Armario Digital Primario (Distribuidor).
ADS: Armario Digital Secundario.
DLC: Concentrador de Lneas Digitales.
URL: Unidad Remota de Lnea.
Central m
ovil: Central telefonica foranea que puede ser movilizada de un lugar a
otro de acuerdo a las necesidades de la empresa.
Nodo outdoor: Central telefonica foranea de nueva generacion.
Enlace de fibra
optica: Conexion existente entre dos centrales telefonicas mediante
Red de Fibra Optica.

Enlace de radio: Conexion existente entre dos estaciones, repetidoras y/o centrales
mediante radio frecuencia.
Red de telecomunicaciones: Se designa con el termino de Red de Telecomunicaciones, al conjunto de medios dispuestos, para permitir a los usuarios distantes,
intercambiar informacion entre ellos con un retardo lo mas peque
no posible.
84
Red telef
onica: Se define Como, Red telefonica, al conjunto de enlaces y equipos que
permiten conectar un abonado A con un abonado B. Desde el punto de vista de
localizacion y trafico. La red telefonica comprende tres grandes renglones: Red
Local, Interurbana, Red Internacional.
Red local: Para las llamadas que se originan y terminan en una misma area local
(area definida por los limites de municipios en latitud y en longitud) se emplean
los siguientes centros de comunicacion:
Centrales locales principales (Matriz): Son centrales que atienden
directamente a los clientes o abonados y con la incorporacion de las centrales
digitales, permite dar aplicaciones de centros telefonicos de comunicacion
remota conocidas como: Unidad de remota de linea (URL), en este caso
los clientes son atendidos por la URL y esta a su vez, cuelga o depende de
una central matriz, la cual puede atender directamente a otros clientes de
abonado.
Centrales tandem (Tr
ansito): Son centrales que concentran y distribuyen trafico de otras centrales, las cuales son empleadas en ciudades
grandes como Caracas, Maracaibo, Valencia, optimizando los enlaces entre
las centrales locales y que sirven como desborde o alternativa de trafico.
Centrales sat
elite: Centrales locales que necesitan una segunda central
local para distribuir y recibir trafico local. (Empleadas en el interior del
pas).
Centrales mixtas: Centrales que se emplean como locales y o tandem,
o cualquier combinacion de las anteriores. Es una de las ventajas que
presentan las centrales digitales.
Red interurbana: Para las llamadas que se originan y terminan en otra Area
de
Numeracion Cerrada (ANC) se emplean los siguientes centros de conmutacion,
las cuales pueden hacer funcion de tandem o transito entre ANC. Las cuales de
clasifican en:
Centrales de larga distancia nacional cabecera de region.
85
Centrales de larga distancia nacional de zona.

Red internacional: Para las llamadas que se originan y terminan en Venezuela, se
emplean las siguientes centrales de conmutacion internacional son:
AXE ubicada en CNT.
AT&T ubicada en el Rosal.
Ap
endice C
Im
agenes de la interfaz Usuario/Sistema
Figura C.1: Pantalla de crear usuario
Figura C.2: Pantalla de usuario buscado
87
Figura C.3: Pantalla de buscar equipo
Figura C.4: Pantalla de lista de equipos
Figura C.5: Pantalla de lista de enlaces de fibra optica
88
Figura C.6: Pantalla de lista de mapas o diagramas
Figura C.7: Pantalla de insertar enlace de fibra optica
89
Figura C.8: Pantalla de historial de acciones
Figura C.9: Pantalla de diagrama de la red de fibra optica
Figura C.10: Pantalla de salida del sistema

Infante Kevin

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Infante Kevin

Uploaded by

Copyright:

Available Formats

Proyecto de Grado

Br. Kevin J. Infante O.

Desarrollo de un Sistema de Informaci

A mis padres por ser lo mejor

Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . .

Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . .

Actividades que realiza un sistema de informacion . . . . . . . .

Tipos de sistemas de informacion . . . . . . . . . . . . . . . . .

Sistemas de informacion Web . . . . . . . . . . . . . . . . . . .

Servidor Web Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Bases de datos relacionales . . . . . . . . . . . . . . . . . . . . .

Lenguaje estructurado de consulta (SQL) . . . . . . . . . . . . .

El sistema de gestion de bases de datos MySQL . . . . . . . . .

Algunas caractersticas de MySQL . . . . . . . . . . . . . . . .

Arquitectura orientada a servicios (SOA) . . . . . . . . . . . . . . . . .

Lenguaje de modelado unificado (UML) . . . . . . . . . . . . . . . . .

Diagramas de casos de uso . . . . . . . . . . . . . . . . . . . . .

El lenguaje de programacion PHP . . . . . . . . . . . . . . . . . . . . .

3 Modelado de Negocios del Sistema de Informaci

Delimitacion del sistema de negocios . . . . . . . . . . . . . . .

Definicion de los requisitos de software . . . . . . . . . . . . . .

Definicion de requisitos seg

Clasificacion de los requisitos y definicion de prioridades . . . .

Definicion de casos de uso . . . . . . . . . . . . . . . . . . . . .

Matriz de casos de uso vs. requisitos . . . . . . . . . . . . . . .

Definicion del estilo arquitectonico

Diagrama de clases del sistema

Fase de implementacion y pruebas . . . . . . . . . . . . . . . . . . . . .

Implementacion del sistema . . . . . . . . . . . . . . . . . . . .

Pruebas del sistema . . . . . . . . . . . . . . . . . . . . . . . . .

Entrega final del sistema . . . . . . . . . . . . . . . . . . . . . . . . . .

Especificacion de los requisitos . . . . . . . . . . . . . . . . . . . . . . .

Casos de uso del sistema . . . . . . . . . . . . . . . . . . . . . . . . . .

Matriz de casos de uso vs. requisitos . . . . . . . . . . . . . . . . . . .

Pruebas de caja negra . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fechas de cursos de induccion . . . . . . . . . . . . . . . . . . . . . . .

Estructura de CANTV Merida . . . . . . . . . . . . . . . . . . . . . . .

Etapas del metodo watch . . . . . . . . . . . . . . . . . . . . . . . . . .

Arquitectura orientada a servicios . . . . . . . . . . . . . . . . . . . . .

Delimitacion del sistema de negocios . . . . . . . . . . . . . . . . . . .

Diagrama de actores del SIC . . . . . . . . . . . . . . . . . . . . . . . .

Diagrama de caso de uso centralizar informacion . . . . . . . . . . . . .

Diagrama de caso de uso identificacion . . . . . . . . . . . . . . . . . .

Diagrama de caso de uso mostrar informacion . . . . . . . . . . . . . .

Digrama de caso de uso modificar elemento . . . . . . . . . . . . . . . .

Diagrama de caso de uso reporte lista . . . . . . . . . . . . . . . . . . .

Diagrama de caso de uso eliminar elemento . . . . . . . . . . . . . . . .

Diagrama de caso de uso crear usuario . . . . . . . . . . . . . . . . . .

3.10 Diagrama de caso de uso modificar usuario . . . . . . . . . . . . . . . .

3.11 Diagrama de caso de uso insertar elemento . . . . . . . . . . . . . . . .

3.12 Diagrama de caso de uso subir mapa o diagrama . . . . . . . . . . . . .

Diagrama de despliegue del sistema . . . . . . . . . . . . . . . . . . . .

Diagrama de clases del SIC

Diagrama de actividad de autenticar usuario . . . . . . . . . . . . . . .

Diagrama de actividad de consultar equipo . . . . . . . . . . . . . . . .

Diagrama de actividad de modificar equipo . . . . . . . . . . . . . . . .

Diagrama de secuencia de consultar equipo . . . . . . . . . . . . . . . .

Diagrama de secuencia de modificar equipo . . . . . . . . . . . . . . . .

Diagrama de secuencia de autenticar usuario . . . . . . . . . . . . . . .

Pantalla de inicio del sistema . . . . . . . . . . . . . . . . . . . . . . .

4.10 Pantalla principal de usuario . . . . . . . . . . . . . . . . . . . . . . . .

4.11 Diagrama de flujo de pantallas . . . . . . . . . . . . . . . . . . . . . . .

4.12 Formulario dinamico . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.13 Filtro de consulta dinamico . . . . . . . . . . . . . . . . . . . . . . . .