Академический Документы
Профессиональный Документы
Культура Документы
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
Junio 2009
c
2009
Universidad de Los Andes, Merida, Venezuela
Indice
Indice de Tablas
vii
Indice de Figuras
viii
Agradecimientos
xi
1 Introducci
on
1.1
1.2
Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
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
12
2.1.2
13
2.1.3
14
2.2
15
2.3
Bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
iv
2.3.1
16
2.3.2
17
2.3.3
17
2.3.4
18
2.4
19
2.5
Protocolo SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.6
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
25
2.6.8
Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . .
25
25
2.7
. . . . . . . . . . . . . . . . . . . . . . . .
27
3.1
Modelado de negocios . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.1.1
28
Ingeniera de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2.1
29
3.2.2
30
3.2.3
34
3.2.4
36
3.2.5
42
3.2
4 Dise
no del Sistema de Informaci
on Centralizado (SIC)
44
4.1
Metas de dise
no . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.2
. . . . . . . . . . . . . . . . . . . .
45
4.3
. . . . . . . . . . . . . . . . . . . . . .
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
56
4.7.1
56
4.7.2
62
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
34
3.2
41
3.3
43
4.1
63
4.2
Pruebas funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
4.3
69
vii
Indice de Figuras
1.1
Estructura de CANTV . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
1.3
10
2.1
20
3.1
28
3.2
31
3.3
37
3.4
37
3.5
38
3.6
38
3.7
39
3.8
39
3.9
39
40
40
40
4.1
48
4.2
. . . . . . . . . . . . . . . . . . . . . . . .
50
4.3
51
4.4
51
4.5
52
4.6
52
viii
4.7
53
4.8
53
4.9
54
55
56
58
58
59
61
63
63
64
64
64
65
65
66
67
77
77
77
. . . . . . . . . . . . . . . . . . . . . .
78
78
78
78
79
79
79
80
80
80
81
81
82
82
82
86
86
87
87
87
88
. . . . . . . . . . . . . . . .
88
89
89
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
n
1 Introduccio
nacional.
1.1
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.
1.3
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
1.5
1.5.1
Objetivos
Objetivo General
1.5 Objetivos
1.5.2
Objetivos Especficos
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
1.6.1
Revisi
on bibliogr
afica
1.6 Metodologa
1.6.2
Proceso de desarrollo
1.6 Metodologa
10
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
n
2.1 Sistemas de informacio
12
2.1.1
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
2.1 Sistemas de informacio
13
2.1.2
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
n
2.1 Sistemas de informacio
14
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:
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
2.2
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
16
2.3
Bases de datos
2.3.1
2.3.2
17
2.3.3
El sistema de gesti
on de bases de datos MySQL
18
2.3.4
2.4
19
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).
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:
22
2.6
23
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
2.6.5
Diagramas de paquetes
2.6.6
Diagramas de actividades
n PHP
2.7 El lenguaje de programacio
2.6.7
25
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
2.7
El lenguaje de programaci
on PHP
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,
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
28
3.1.1
Delimitaci
on 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
3.2.1
Definici
on de los requisitos de software
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
31
32
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
distribucion.
34
3.2.3
Clasificaci
on de los requisitos y definici
on de prioridades
N de
Clasificaci
on
Prioridad
Requisito
R1
Tipo de
Requisito
Centralizar la informacion
No Funcional
Aseguramiento
de la calidad
Funcional
Funcionalidad
Funcional
Funcionalidad
R4
Funcional
Funcionalidad
R5
Funcional
Funcionalidad
Funcional
Funcionalidad
La informacion eliminada no
debe ser borrada, solo ocultada.
N de
35
Clasificaci
on
Prioridad
Requisito
R7
Tipo de
Requisito
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
R9
R10
R11
R12
R13
R14
R15
R16
R17
N de
36
Clasificaci
on
Prioridad
Requisito
R18
Requisito
La interfaz debe ser amigable y
No Funcional
de facil manejo.
R19
Tipo de
Aseguramiento
de la calidad
No Funcional
Aseguramiento
de la calidad
No Funcional
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
37
38
39
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
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
usuario.
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.
CU6
Consultar Repetidoras.
CU7
Consultar Enlaces de
Fibra Optica.
CU8
Consultar Enlaces de
Radio.
CU9
Consultar TCP-IP
RAS.
CU10
Consultar Elementos
de Datos.
CU11
Consultar 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
Caso
de Uso
de Uso
CU13
CU14
CU15
42
Descripci
on
Modificar Elementos
del sistema.
Eliminar un Elemento
del sistema.
Insertar un Elemento
en el sistema.
CU16
Reporte Lista.
CU17
Crear Usuario.
CU18
Modificar Usuario.
CU19
Cerrar Sesion.
CU20
Registrar Accion.
3.2.5
43
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
45
4.2
Definici
on del estilo arquitect
onico
46
47
48
4.3
49
50
4.4
51
Diagramas de actividades
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.
52
4.5
Diagramas de secuencias
Una vez analizados los diagramas de actividades es importante saber el
53
4.6
54
Dise
no de la interfaz del usuario
55
n y pruebas
4.7 Fase de implementacio
56
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
n y pruebas
4.7 Fase de implementacio
57
n y pruebas
4.7 Fase de implementacio
58
n y pruebas
4.7 Fase de implementacio
59
n y pruebas
4.7 Fase de implementacio
60
n y pruebas
4.7 Fase de implementacio
61
n y pruebas
4.7 Fase de implementacio
4.7.2
62
n y pruebas
4.7 Fase de implementacio
63
Par
ametros de
Salida
Resultado
Entrada
Control de Acceso
Usuario incorrecto
(ingresar.php)
Control de Acceso
Contrase
na incorrecta
(ingresar.php)
Satisfactorio
usuario no es valido.
Satisfactorio
contrase
na es incorrecta.
Insertar Equipos
Campo obligatorio
Satisfactorio
(insertar central.php)
faltante.
Consulta correcta
(lista centrales.php)
Se muestra la lista de
Satisfactorio
centrales deseada.
Listar Bitacora
Rango de fechas
Se muestra la lista de
Satisfactorio
(listar bitacora.php)
valido.
acciones realizadas en el
sistema.
Reportes
Consulta correcta
(exportar archivo.php)
Satisfactorio
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.
n y pruebas
4.7 Fase de implementacio
Figura 4.18: Mensaje obtenido al intentar ingresar equipo con campos faltantes
64
n y pruebas
4.7 Fase de implementacio
65
n y pruebas
4.7 Fase de implementacio
66
n y pruebas
4.7 Fase de implementacio
67
n y pruebas
4.7 Fase de implementacio
Caso de uso
68
Resultado
entrada
Ingresar al sistema
Usuario y contrase
na
Satisfactorio
Identificar perfil de
Usuario y contrase
na
Satisfactorio
usuario.
Consultar equipo
al tipo de usuario.
Equipo que desea
consultar
Consultar mapas o
Estado de el cual
diagramas.
solicitado.
Consultar registro
Rango de fechas o
historico o bitacora
toda la bitacora
el sistema.
Modificar equipo
Editar la informacion
del equipo
correctamente.
Equipo consultado
seleccionar eliminar
Eliminar equipo
Satisfactorio
Satisfactorio
Satisfactorio
Satisfactorio
Satisfactorio
Informacion del
equipo a insertar
correctamente.
Consulta de alg
un
macion
Satisfactorio
Satisfactorio
Satisfactorio
correctamente. Se enva un
correo al nuevo usuario.
Modificar Usuario
Cerrar sesion
Editar la informacion
del usuario
correctamente
El usuario elige
cerrar sesion
Satisfactorio
Satisfactorio
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
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
Miercoles 25/03/2009
Jueves
26/03/2009
Viernes
27/03/2009
Jueves
30/04/2009
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
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
5.1 Conclusiones
72
5.2 Recomendaciones
5.2
73
Recomendaciones
5.2 Recomendaciones
74
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).
Disponible en :
http://www.desarrolloweb.com/articulos/1557.php.
Elmasri, R. and Navathe, S. (2002).
Pearson
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.
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
78
79
80
81
82
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
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
Ap
endice C
Im
agenes de la interfaz Usuario/Sistema
87
88
89