FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA DE SISTEMAS
Módulo de asignación y planificación de empleo de
personal de Telefónica Movistar
Liliana Peña
Tutor: Ing. Héctor Lollett
Caracas, Septiembre 2005
II
DERECHO DE AUTOR
Quien suscribe, en condición de autor del trabajo titulado “Módulo de
asignación y planificación de empleo de personal de Telefónica Movistar”,
declara que: Cedo a título gratuito, y en forma pura y simple, ilimitada e
irrevocable a la Universidad Metropolitana, los derechos de autor de
contenido patrimonial que me corresponde sobre el presente trabajo.
Conforme a lo anterior, esta cesión patrimonial sólo comprenderá el derecho
para la Universidad de comunicar públicamente la obra, divulgarla, publicarla
o reproducirla en la oportunidad que ella así lo estime conveniente, así como,
la de salvaguardar mis intereses y derechos que me corresponden como
autor de la obra antes señalada. La Universidad en todo momento deberá
indicar que la autoría o Elaboración del trabajo corresponden a mi persona,
salvo los créditos que se deban hacer al tutor o a cualquier tercero que haya
colaborado o fuere hecho posible la realización de la presente obra.
Autor:
C.I. 14.351.063
En la ciudad de Caracas, a los 9 días del mes de Septiembre del año 2005.
III
APROBACIÓN
Considero que el Trabajo Final titulado:
MÓDULO DE ASIGNACIÓN Y PLANIFICACIÓN DE EMPLEO DE
PERSONAL DE TELEFÓNICA MOVISTAR
Elaborado por la ciudadana:
Liliana Carolina Peña Borges
Para optar al título de:
Ingeniero de Sistemas
Reúne los requisitos por la Escuela de Ingeniería de Sistemas de la
Universidad Metropolitana, y tiene méritos suficientes como para ser
sometido a la presentación y evaluación exhaustiva por parte del jurado
examinador que se designe.
En la ciudad de Caracas, a los 9 días del mes de septiembre del año 2005.
_____________________
Ing. Héctor Lollett
IV
ACTA DE VEREDICTO
Nosotros, los abajo firmantes, constituidos como jurado examinador y
reunidos en Caracas, el día 19 del mes de Septiembre de 2005, con el
propósito de evaluar el Trabajo Final titulado:
MÓDULO DE ASIGNACIÓN Y PLANIFICACIÓN DE EMPLEO DE
PERSONAL DE TELEFÓNICA MOVISTAR
Presentado por la ciudadana
Liliana Carolina Peña Borges
Para optar al titulo de
Ingeniero de Sistemas
Emitimos el siguiente veredicto:
Reprobado ____ Aprobado ____ Notable ____ Sobresaliente ___
Observaciones:
_____________________________________________________________
_____________________________________________________________.
Prof. Nelly de Abreu Prof. Rafael Matienzo Ing. Hector Lollett
V
DEDICATORIA
En primer lugar, le quiero dar gracias a Dios, por haberme dado la vida.
A mis Padres, que siempre me apoyaron en todo momento y me dieron
ánimo, en los momentos duros, para seguir adelante y sobrellevar todos los
obstáculos, los amo.
A mi Mamá, por ayudarme a salir adelante siempre brindándome una mano
amiga y su apoyo incondicional, eres lo mejor que una hija pueda desear.
A mi Papá, donde quiera que me encuentre siempre sé que estás conmigo.
A mi hermana Oly, por ser mi amiga, mi hermana, mi todo…Gracias por
siempre estar ahí, haciéndome feliz, regañándome cuando hace falta,
dándome los consejos que tanto me han hecho falta y sobre todo, gracias
por darme tu cariño y apoyo.
A mis hermanos Gaby, Adry y Leo, por siempre estar a mi lado en los
momentos buenos y malos, los quiero mucho.
A mis Sobrinitas, porque han sabido llenar mi corazón con su cariño.
A Chucky, por brindarme tu apoyo en todo momento y ser más que un
cuñado.
A Vanessa, ¡Galle!, gracias por estar siempre ahí, por tu amistad con tus
despistes y locuras me has ayudado a salir adelante en todo momento.
A Beny y Kary por ser unos amigos incondicionales.
A todos mis amigos, por siempre estar a mi lado, los quiero mucho.
VI
AGRADECIMIENTOS
Agradezco a Dios por haber puesto en mi camino a todas las personas que
me han brindado su apoyo y que de alguna u otra forma permitieron que este
Trabajo Especial de Grado fuese posible.
A Héctor, por ser el jefe que toda persona quiere tener, por apoyarme en
todo momento y ser un asesor, tutor, guía y amigo. Gracias por tu
comprensión.
A Rubén y a Tomás por estar siempre apoyándome y brindándome ayuda en
todo momento.
A todos mis compañeros de trabajo de Movistar, por dejarme entrar en su
mundo, por su amistad y apoyo incondicional.
Gracias a todas las personas que me ayudaron a hacer realidad este Trabajo
Especial de Grado.
Liliana Peña
VII
TABLA DE CONTENIDO
LISTA DE TABLAS Y FIGURAS…………………………………………………X
RESUMEN………………………………………………………………………...XVI
INTRODUCCION………………………………………………………………..1
CAPITULO I. TEMA DE INVESTIGACION…………………………………...4
I.1 PLANTEAMIENTO DEL PROBLEMA……………………………………..5
I.2 OBJETIVO GENERAL………………………………………………………6
I.3 OBETIVOS ESPECÍFICOS………………………………………………...7
I.4 ALCANCE Y LIMITACIONES………………………………………………8
I.5 JUSTIFICACIÓN DE LA INVESTIGACIÓN……………………………….8
CAPITULO II. MARCO TEORICO……………………………………………..9
II.1 Marco Histórico de Telefónica………………………………………...11
II.1.2 El Grupo Telefónica…………………………………………………12
II.1.2.1 ¿Qué es Movistar?..................................................................13
II.1.2.2 Telefónica impulsa a Movistar………………………..…………14
II.1.2.3 Movistar Venezuela………………………………………………15
II.2 Algoritmos Inteligentes…………………………………………………20
II.2.1 ¿Qué son los Algoritmos Inteligentes?.......................................20
II.2.2 Sistemas expertos…………………………………………………..20
VIII
II.2.2.1 La función de un sistema experto………………………..…….21
II.2.2.2 Los componentes de un sistema experto………………….….21
II.2.3 Redes neuronales o neurales……………………………………..22
II.2.3.1 Características de las redes neurales…………………………22
II.2.4 La lógica difusa…………………………………………………...…25
II.2.5 Los algoritmos genéticos…………………………………………...27
II.2.5.1 Inteligencia artificial y resolutores generales de problemas…….29
II.2.5.2 Métodos de aprendizaje…………………………………………………30
II.2.5.3 Definición de agente……………………………………………………..31
II.2.5.4 Jerarquía de acciones.…………………………………………………..32
II.2.5.5 Jerarquía de variables…………………………………………………....33
II.2.5.6 Lo que se quiere conseguir…………………..……………………….…33
II.3 Variables…………………………………………………………………...35
II.3.1 Definición de variable………………………………………………….35
II.3.1.1 Las variables conceptuales o constitutivamente……………………..35
II.3.1.2 Las variables operacionales…………………………………………….36
II.3.2 La variable lingüística………………………………………………….36
II.4 TÉCNICAS Y MODELOS………………………………………………....36
II.4.1 Semántica………………………………………………………….….…36
II.4.2 RUP (Rational Unified Process)………...…………………………….37
II.4.2.1 Características del RUP………………………………………………....37
II.4.2.2 Enfoque del RUP…………………………………………………….38
II.4.2.3 Fases del RUP……………………………………………….…...38
IX
II.4.2.3.1 Inicio……………………………………….……………………40
II.4.2.3.2 Elaboración………………………….…………………………40
II.4.2.3.3 Construcción…………………………………………………..41
II.4.2.3.4 Transición……………………………………………………...41
II.4.2.4 Actividades del RUP……………………………………….……..42
II.4.3 UML (Unified Modeling Language)…………..………….……..44
II.4.3.1 Diagramas UML……………………………………….……….47
II.4.3.2 Vistas UML…………………………………………….……….51
CAPITULO III. MARCO METODOLOGICO…………………………….………53
III.1 Fase de Inicio…………………………………………………….……….54
III.1.1 Reglas por Departamento……………………………………….…57
III.1.2 Caso de uso, modelo inicial……………………………….……….61
III.1.3 Estudio Inicial de Riesgos………………………………….………63
III.2 Fase de Elaboración………………………………………………….…65
III.2.1 Requerimientos No Funcionales del Sistema…………………...65
III.2.2 Lista Revisada de Riesgos…………………………………….…..65
III.2.3 Caso de uso del módulo, Asig.Auto.Encargado…………….…...68
III.2.4 Caso de uso “Generar resultados”…………………………….….71
III.2.5 Análisis del sistema y limitaciones…………….………………….71
III.2.6 ¿Cómo se podría definir el tipo de estudio metodológico?........72
III.2.7 ¿Qué sucede si se aplica el enfoque de
X
sistemas expertos para el desarrollo del módulo de
Auto.Asig.Encargados?..............................................................73
III.2.8 Adquisición de conocimiento……………………………………....75
III.2.9 Observación como técnica de adquisición de conocimiento…...76
III.3 Fase de Construcción……………………………………………….….77
III.3.1 Descripción de los casos de uso……………………………….….77
III.3.1.1 Establecer estudio………………………………….……………77
III.3.1.2 Administrar el sistema……………………………….…………..79
III.3.1.3 Administrar reglas………………………………………….…….81
III.3.1.4 Generar resultados………………………………………….…...83
III.3.2 Casos de uso expandidos…………………………………….……85
III.3.2.1 Procesar información……………………………………….…...85
III.3.2.2 Almacenar información…………………………………….……86
III.3.2.3 Generar tablas…………………………………………………...87
III.3.2.4 Generar reportes…………………………………………………88
III.3.3 Modelado conceptual………………………………………….……89
III.3.4 Diagrama de clases…………………………………………..……..91
III.3.5 Desarrollo del módulo Asig.Auto.Encargados...………..………..93
III.4 Fase de Transición…………………………………………….………...95
III.4.1 Implantación del módulo Asig.Auto.Encargados……….………..95
III.4.2 Navegación en Asig.Auto.Encargados………………….………..96
III.4.3 Validación del modulo Asig.Auto.Encargados………….………107
XI
CAPITULO IV. CONCLUSIONES Y RECOMENDACIONES……………108
CAPITULO V. REFERENCIAS BIBLIOGRAFÌCAS………….…112
APÉNDICE A. METODOLOGÌA DE LOS SISTEMAS EXPERTOS…….…115
APÉNDICE B. MODELO LÒGICO:
DIAGRAMA ENTIDAD RELACIÒN……………………….…123
APÉNDICE C. DIAGRAMA DE DECISIÒN…………………………………...125
APÉNDICE D. NAVEGACIÒN DEL SISTEMA…………………………….…127
XII
LISTA DE TABLAS Y FIGURAS
TABLAS
Tabla 1. Línea de Negocio (LOB)………………………………………………..19
Tabla 2. Caso de uso “Establecer estudio”……………………………………..78
Tabla 3. Caso de uso “Administrar el sistema”………………………………...80
Tabla 4. Caso de uso “Administrar reglas”……………………………………..82
Tabla 5. Caso de uso “Generar resultados”……………………………………84
Tabla 6. Caso de uso expandido “Procesar información”…………………….85
Tabla 7. Caso de uso expandido “Almacenar información”…………………..86
Tabla 8. Caso de uso expandido “Generar tablas”…………………………….87
Tabla 9. Caso de uso expandido “Generar reportes”………………………….88
XIII
FIGURAS
Figura 1. Logo Telefónica………………………………………………………..13
Figura 2. Logo de Telefónica Movistar…………………………………………14
Figura 3. Servicios de Telefónica Movistar…………………………………….17
Figura 4. Red de neuronas formales……………………………………………25
Figura 5. Tipo de reglas…………………………………………………………..31
Figura 6. Calidad de conocimiento Vs. Tiempo………………………………..34
Figura 7. Vista general de RUP………………………………………………….39
Figura 8. Flujos de trabajo del RUP…………………………………………….44
Figura 9. Caso de uso inicial del módulo Auto.Asig.Encargados…………….62
Figura 10. Caso de uso final del módulo Auto.Asig.Encargados…………….70
Figura 11. Estructura básica de un Sistema Experto………………………....74
Figura 12. Modelo Conceptual…………………………………………………..90
Figura 13. Diagrama de Clases………………………………………………….92
Figura 14. Pantalla de control de acceso al sistema…………………………97
Figura 15. Pantalla de construcción de Algoritmos…………………………..98
Figura 16. Pantalla para agregar Algoritmos………………………………….99
Figura 17. Pantalla para agregar Empleado por Dpto.
a los Algoritmos……………………………………………………100
Figura 18. Pantalla para agregar Reglas a los Algoritmos……………….101
Figura 19. Pantalla para activar el algoritmo………………………………..103
Figura 20. Pantalla para seleccionar el Dpto. del algoritmo……………….104
XIV
Figura 21. Pantalla principal para agregar carga a cada proyecto……….105
Figura 22. Pantalla para agregar carga a cada proyecto………………….106
Figura 23. Diagrama Entidad-Relación………………………………………..124
Figura 24. Diagrama de decisión………………………………………………126
Figura 25. Acceso al SIP+……………………………………………………...128
Figura 26. Pantalla principal de Asig.Auto.Encargados……………..………129
Figura 27. Pantalla de asignación de algoritmo
de Asig.Auto.Encargados……………………………..……………130
Figura 28. Pantalla de asignación de Dpto.
de Asig.Auto.Encargados…………………………………………..131
Figura 29. Pantalla de asignación de encargado por default ………………132
Figura 30. Pantalla para grabar las opciones
de Asig.Auto.Encargados…………………………………………..133
Figura 31. Pantalla para grabar las opciones
de Asig.Auto.Encargados…………………………………………..134
Figura 32. Pantalla de mensaje de error en
el Asig.Auto.Encargados…………….……………………………...135
Figura 33. Pantalla de Workflow……………….……………………………….136
Figura 34. Pantalla de activación de funcionalidades……………………….137
Figura 35. Pantalla de activación de la funcionalidad
Asig.Auto.Encargados……………………………………………...138
Figura 36. Pantalla de éxito de la funcionalidad
Asig.Auto.Encargados……………………………………………...139
XV
Figura 37. Pantalla para guardar el Workflow………………..………………140
Figura 38. Pantalla del Workflow grabado…………………..………………..141
XVI
RESUMEN
Módulo de asignación y planificación de empleo de personal
de Telefónica Movistar
Autor: Liliana Carolina Peña Borges
Tutor: Ing. Héctor Lollett Caracas, septiembre de 2005
Para asignar y planificar el personal requerido para la ejecución de proyectos, la Gerencia de Acceso de Telefónica Movistar se apoya en un sistema de manejo de proyectos (SIP+), el cual adolece de un mecanismo automático e inteligente para asignar y planificar el empleo de personal. La elaboración del módulo del presente Trabajo Especial de Grado, se basó en un enfoque de Sistemas Expertos, (los cuales aportan soluciones a diferentes problemas), y se utilizó para su desarrollo la metodología RUP (Rational Unified Process), el cual se basa en la ejecución de un conjunto de pasos para lograr satisfacer los requerimientos de los usuarios. A partir del uso éstas dos herramientas, se diseñó e implementó el módulo de asignación automática e inteligente de recursos en los proyectos manejados en el SIP+ el cual se llamó “Auto.Asig.Encargados”. Finalmente, se realizaron pruebas para demostrar la validez y alcance del módulo.
INTRODUCCIÓN _____________________________________________________________________________________________
1
INTRODUCCIÓN
En la actualidad, el manejo de personal es parte fundamental de toda
empresa para la ejecución de sus actividades en forma rápida y eficiente.
Con los adelantos de la tecnología, se aprovechan los beneficios que la
misma otorga para mejorar el desempeño de los empleados y ayudar en la
toma de decisiones para la solución de problemas de cualquier índole en las
diferentes áreas.
La innovación de la tecnología, los cambios organizativos y productivos, la
aparición de nuevos competidores en los mercados de la telecomunicación,
los nuevos productos que son ofrecidos, los cambios en los requerimientos
de los clientes y la internalización de los mercados, hacen que hoy en día la
competitividad de las empresas no se base únicamente en la inversión de
tecnología en el mercado, sino en el factor humano, en la calidad, eficiencia
e iniciativa que los empleados de una empresa posean y de su capacidad
para solucionar los problemas que se presenten.
Debido a la importancia que tiene el factor humano y a la ola creciente de
proyectos que actualmente tiene, la empresa Telefónica Movistar se vio en la
necesidad de diseñar una herramienta que le permitiera la distribución de los
INTRODUCCIÓN _____________________________________________________________________________________________
2
mismos de forma equitativa entre sus empleados y de esta manera poder
brindarles una mejor atención a todos sus clientes.
Dicha herramienta debe ser capaz de determinar el momento preciso para
realizar una asignación y por consiguiente una planificación del personal de
la empresa. Para elaborar esta herramienta, se tomó como base los
algoritmos inteligentes, en especial los sistemas expertos, ya que ellos
ayudan a aportar soluciones a problemas, como si de humanos se tratara.
Esto es posible gracias a que al sistema lo crean con expertos (humanos)
que intentan estructurar y formalizar conocimientos poniéndolos a
disposición del sistema, para que éste pueda resolver una función dentro del
ámbito del problema, de igual forma que lo hubiera hecho un experto.
Este Trabajo Especial de grado, ofrece la herramienta que la empresa
Telefónica Movistar necesita para la asignación del personal de Ingeniería,
realizándolo de forma automática y sencilla, para la ejecución de los
proyectos que se presenten en la empresa.
Este Trabajo Especial de Grado se encuentra estructurado en cinco capítulos
principales: El primero, está constituido por la definición del problema de
investigación, objetivos, los alcances y limitaciones del módulo a desarrollar.
Después de haber analizado el tema de investigación en el primer capítulo,
se presenta el segundo, donde se realiza un recorrido sobre la empresa
INTRODUCCIÓN _____________________________________________________________________________________________
3
Telefónica Movistar, las diferentes alternativas que se tienen después del
estudio del problema de investigación y la metodología que se va a emplear
para resolverlo. En el tercer capítulo, se elabora el diseño, desarrollo e
implementación del módulo, mediante el uso del RUP (Rational Unified
Process), un proceso que se utiliza para el desarrollo del mismo. En el
capítulo cuatro, se presentan las conclusiones y recomendaciones sobre el
módulo. Por último, en el capítulo cinco, se encuentran las referencias
bibliográficas y los apéndices.
CAPITULO I
TEMA DE INVESTIGACIÓN
En este capitulo se describe el tema de investigación, los objetivos que se
plantearon y las delimitaciones de los mismos, para el desarrollo de este
Trabajo Especial de Grado.
Por medio de los objetivos generales y específicos se puede concebir cuáles
pueden ser los resultados como consecuencia de la investigación realizada,
así como también los alcances y limitaciones que se obtuvieron durante el
desarrollo del presente Trabajo Especial de Grado.
CAPITULO I ____________________________________________________________________________________________
5
I.1 PLANTEAMIENTO DEL PROBLEMA
El Sistema de Información de Proyectos (SIP+) de Telefónica Movistar tiene
la capacidad de diseñar caminos de trabajo (WorkFlows) para los proyectos
desarrollados de provisión de Servicios de Acceso Fijo para Clientes
Corporativos, y permite el seguimiento (tracking) de la ejecución de los
mismos basados en una interfaz Intranet que habilita accesos remotos a los
diferentes departamentos de Telefónica Movistar que participan en dichos
proyectos.
Actualmente, el SIP+ provee un mecanismo para asignar de forma manual
los recursos humanos requeridos para los diferentes proyectos llevados a
cabo por el Departamento de Ingeniería de Acceso. Igualmente, el SIP+
asigna un período holgado para la realización de las tareas en un proyecto
pero no es capaz de planificar inteligentemente el momento preciso de
ejecución de tarea de acuerdo a la disponibilidad de los diversos recursos
humanos involucrados. Ejecutar ambas labores de manera manual y con
tiempos tan holgados genera retrasos e imprecisiones, que en muchos casos
pueden desembocar en reestructuración de trabajos y empleo ineficiente de
los recursos.
El módulo a desarrollar perfeccionará los métodos en la Asignación y
Planificación de Empleo de Personal para el Sistema de Información de
CAPITULO I ____________________________________________________________________________________________
6
Proyectos (SIP+) de Acceso de la empresa de telecomunicaciones
Telefónica Movistar.
El nuevo Módulo del SIP+ contara con las siguientes funcionalidades:
• Selección automática del Líder de Proyecto que asumirá una actividad de
acuerdo a carga de trabajo, tipo de cliente, línea de negocio y área
geográfica.
• Planificar inteligentemente el momento preciso de ejecución de tarea de
acuerdo a la disponibilidad de los diversos recursos humanos
involucrados.
• Realizar seguimiento al status de un proyecto determinado.
I.2 OBJETIVO GENERAL
Desarrollar un módulo que sea capaz de determinar en cada situación cuál
es la respuesta que le permita al sistema alcanzar sus objetivos, en cuanto a
la asignación y planificación automática de los recursos requeridos para la
ejecución de los proyectos.
CAPITULO I ____________________________________________________________________________________________
7
I.3 OBJETIVOS ESPECÍFICOS
• Levantar los requerimientos de la empresa para la ejecución del
Módulo.
• Estudiar los algoritmos inteligentes que permitan desarrollar el Módulo
de asignación y planificación de empleo de personal de Telefónica
Movistar.
• Sintetizar la información para los participantes de las decisiones y
acciones para al ejecutar la asignación y planificación de empleo de
personal de Telefónica Movistar.
• Determinar variables y restricciones, como:
o Lenguajes de programación necesarios para el desarrollo del
Módulo.
o Base de datos utilizada por la empresa Telefónica Movistar.
Estos factores pudiesen intervenir de forma clave en la elaboración del
Módulo de asignación y planificación de empleo de personal.
• Elaborar un diseño preliminar del Módulo a desarrollar.
• Desarrollar el Módulo de asignación y planificación de empleo de
personal de Telefónica Movistar.
CAPITULO I ____________________________________________________________________________________________
8
I.4 ALCANCE Y LIMITACIONES
• Hacer el diseño conceptual del sistema, según las especificaciones del
usuario.
• Hacer el diseño del software que soporte el sistema.
• Programar todos los módulos que comprenden el sistema.
• Elaborar el manual del usuario. Debido a las políticas de la empresa,
este manual no se puede circular a personas fuera de la misma.
• Probar en los diferentes ambientes de desarrollo de Telefónica
Movistar, para verificar la operabilidad y confiabilidad del sistema.
I.5 JUSTIFICACIÓN DE LA INVESTIGACIÓN
Justificación práctica
De acuerdo con los objetivos anteriormente mencionados, este trabajo
permitirá encontrar soluciones concretas para los problemas de asignación
de recursos humanos para cada uno de los proyectos realizados por el
Departamento de Ingeniería de Acceso.
CAPITULO II
MARCO TEÓRICO
En la actualidad los sistemas de información juegan un papel fundamental
para el éxito de las empresas. Es una gran ventaja para una organización
tener controladas las variables de planificación, organización, control y
dirección de la misma. Para ello, se requiere tomar decisiones acertadas que
se traduzcan en el cumplimiento de los objetivos asumidos en la
organización.
Sin embargo, es importante recordar que es el recurso humano, quien se
encarga de tomar estas decisiones y en oportunidades éste puede incurrir en
errores involuntarios por causas diversas (stress, cansancio físico y mental).
Para evitar estos inconvenientes, el hombre se ha dedicado al estudio de los
seres humanos con la finalidad de comprender mejor su funcionamiento y
tratar de emularlo. Así surgen técnicas como la robótica, encargada de
emular las capacidades motoras de los humanos, y la inteligencia artificial,
encargada de simular el raciocinio, la toma de decisiones, las posibilidades
de representación y el aprendizaje.
CAPITULO II _____________________________________________________________________________________________
10
Con esto, se quiere introducir al lector en lo importante que puede ser la
inteligencia artificial y en como ésta puede ayudar a facilitar el trabajo de las
personas de forma rápida y efectiva.
CAPITULO II _____________________________________________________________________________________________
11
II.1 Marco Histórico de Telefónica
Estos últimos diez años han coincidido con el nacimiento de la sociedad de la
información, cuya principal característica es la confluencia de la informática,
la electrónica y las telecomunicaciones, actividades que se han erigido como
motor de la economía mundial.
El mundo de las telecomunicaciones ha venido experimentando una
completa transformación en los últimos años. De ser un sector
extraordinariamente estable en el cual mercados, empresas y servicios
tendían a perpetuarse y donde las escasas novedades casi siempre
originadas por la tecnología, eran fácilmente controlables, ha pasado a ser
un sector en constante ebullición.
Intranet.telefonica.com.ve es un sitio donde se puede tener acceso a la
historia de La Compañía Telefónica Nacional de España, la cual se
constituye el 19 de abril de 1924 en Madrid como sociedad anónima. Su
capital social asciende a un millón de pesetas representado por 2.000
acciones ordinarias y está integrada por la International Telephone and
Telegraph Corporation (ITT) de Nueva York.
La historia de la Compañía Telefónica Nacional de España se remonta al
último cuarto de siglo XIX. En 1884, un Decreto Real establece en España el
CAPITULO II _____________________________________________________________________________________________
12
monopolio del servicio telefónico a favor del Estado, y en 1886 se autoriza su
explotación a particulares. La falta de coordinación y homogeneidad por
parte de las diversas empresas concesionarias plantea la necesidad de
unificar criterios en la prestación del servicio.
En este marco se crea la Compañía Telefónica Nacional de España; Un Real
Decreto firmado por el rey Alfonso XIII, en agosto de 1924, autoriza al
Gobierno a contratar la Compañía Telefónica Nacional de España (CTNE)
para la organización, reforma y ampliación del servicio telefónico nacional. A
consecuencia de esto, se firma el primer contrato entre el Estado y la CTNE,
según el cual éste cede a la nueva empresa, (mediante la adecuada
valoración) todas las instalaciones y líneas que explotaba directamente,
además de todos los derechos de las concesiones existentes, que pasarían a
formar parte de ella a medida que fuesen acabando sus licencias.
II.1.2 El Grupo Telefónica
El Grupo Telefónica es uno de los líderes mundiales del sector de las
telecomunicaciones. Es el operador de referencia en los mercados de habla
hispana y portuguesa, la segunda compañía integrada de
telecomunicaciones del mundo y la tercera compañía por capitalización
bursátil del sector. Su actividad se centra fundamentalmente en los negocios
de telefonía fija y telefonía móvil, con la banda ancha como herramienta
CAPITULO II _____________________________________________________________________________________________
13
clave para el desarrollo de ambos negocios. Su presencia es significativa en
17 países, si bien realiza operaciones en aproximadamente 40 naciones.
Tiene una fuerte presencia en Latinoamérica, donde actúa en trece países
con una clara estrategia de crecimiento. La base de clientes del Grupo
Telefónica en el mundo supera los 120 millones de clientes.
Telefónica es una empresa totalmente privada. Cuenta con casi 1,7 millones
de accionistas directos. Su capital social está dividido en la actualidad en
4.955.891.361 acciones ordinarias que se cotizan en el mercado continuo de
las bolsas españolas (Madrid, Barcelona, Bilbao y Valencia) y en las bolsas
de Londres, París, Frankfurt, Tokio, Nueva York, Lima, Buenos Aires, São
Paulo y SEAQ Internacional de la Bolsa de Londres.
(http://intranet.telefonica.com)
En la figura 1 se puede observar el Logo del Grupo Telefónica:
Figura 1. Logo Telefónica
Fuente: Telefónica Movistar
CAPITULO II _____________________________________________________________________________________________
14
II.1.2.1 ¿Qué es Movistar?
En la página telefonicamoviles.com nos informa sobre Movistar, la cual es
una de las marcas comerciales de Telefónica. Una empresa líder en el
mercado español de la telefonía móvil y uno de los cinco primeros
operadores en Europa.
Un liderazgo basado en lograr la satisfacción total de sus clientes. Cuenta
con una gama de servicios del mercado y las solucionas más innovadoras.
(http://www.telefonicamoviles.com)
II.1.2.2 Telefónica impulsa a Movistar
La marca Telefónica, como ‘master brand’ del Grupo Telefónica, es una de
las palancas para el impulso de Movistar. La marca Telefónica aporta
solvencia, garantía y respaldo, al tiempo que genera recuerdo inmediato,
integra y agrupa a Movistar junto al resto de las marcas comerciales de
Telefónica bajo un mismo grupo.
Por otro lado, es una fuente de motivación para Movistar, a la que fortalece
en su sector, al tiempo que aporta una dimensión y potencia internacional
para hacer frente a la competencia a nivel mundial. Para ello, aporta valores
como 80 años de historia, solidez, capacidad de innovación, dimensión
CAPITULO II _____________________________________________________________________________________________
15
internacional, capacidad para generar riqueza y ser motor de bienestar En la
siguiente se puede observar el logo de Movistar:
Figura 2 Logo de Telefónica Movistar
Fuente: Telefónica Movistar
II.1.2.3 Movistar Venezuela
En analitica.com se hace referencia al proceso de unificación de la marca
Movistar. Nace Movistar en Venezuela, nace parte de la mayor comunidad de
telefonía móvil de habla hispana, en una operación de lanzamiento sin
precedentes en el mercado de las telecomunicaciones.
Movistar Venezuela es la operadora filial de Telefónica Móviles en el
mercado venezolano. Cuenta con un 48% de participación de mercado. Sus
clientes totales superan los 4,5 millones y posee una posición de vanguardia
en el lanzamiento de los productos y servicios más innovadores en la
telefonía móvil de Venezuela.
CAPITULO II _____________________________________________________________________________________________
16
Brinda cobertura al 98% del territorio poblado en Venezuela y su red de
distribución de tarjetas Telpago es una de las más grandes del país,
superando los 30 mil puntos de venta.
Cuenta con una red completamente digital de más de 3.500 kilómetros,
compuesta por sistemas de microondas, fibra óptica, el cable Panamericano,
con el cual tiene una sociedad y una estación terrena de acceso satelital.
Así mismo, Movistar esta respaldada por la solidez, prestigio y experiencia
internacional del Grupo Telefónica, que se destaca por entregar productos y
soluciones vanguardistas de alta calidad, para facilitar el día a día de sus
usuarios, además de estar comprometidos con el desarrollo económico y
social del país, lo que la ubica en una alta posición competitiva.
(http://www.analitica.com)
Movistar está comprometida con sus clientes para brindarles los mejores
productos y servicios de telecomunicaciones y satisfacer sus necesidades de
comunicación. Atiende un mercado cada vez más exigente, compuesto de
distintos segmentos, desde abonados particulares hasta grandes
corporaciones en telefonía fija inalámbrica, larga distancia nacional e
internacional, conexión a Internet, Redes Privadas, T-Motion y el portal
mipunto.com, por medio de productos como la telefonía celular y fija e
Internet. Además ofrece servicios de valor agregado entre los que destacan
CAPITULO II _____________________________________________________________________________________________
17
la mensajería de texto, interactivo, entre otros. Estos servicios se pueden
apreciar en la Figura 3:
Figura 3. Servicios de Telefónica Movistar
Fuente: Elaboración propia
Leyenda:
CDC: Centro de Conexiones
PBX: Public Branch Exchange
CPA: Central Privada Automática
NMS: Nodos Multiservicio
ADSL: Asymmetric Digital Subscriber Line
ID: Internet Dedicado
FR: Frame Relay
CAPITULO II _____________________________________________________________________________________________
18
TDM: Time Division Multiplexing
ATM: Asynchronous Transfer Mode
La compañía posee un total de 500 mil clientes de telefonía fija residencial y
corporativa, siendo la única alternativa del mercado en ofrecer este tipo de
servicio.
En el ámbito de la telefonía pública, los Centros de Conexiones se han
convertido en un excelente modelo de negocio y una alternativa de
comunicación para la población.
En Telefónica Movistar Venezuela, la unidad encargada de proveer los
servicios corporativos contratados es la Gerencia de Acceso de la unidad de
proyecto de Redes, la cual se basa en la estructura matricial Servicios Vs.
Proyectos, es decir, cada servicio prestado le corresponde uno o más
proyectos como se muestra en la tabla 1:
CAPITULO II _____________________________________________________________________________________________
19
Tabla 1. Línea de Negocio (LOB)
Servicios Vs. Proyectos.
Fuente: Elaboración propia.
LOB CPA PBX CDC DP ID ADSL
Tipo Proyecto
Instalación
Desinstalación
Mudanza
Cambio de Tecnología
Modif. Ancho de
Banda
Los proyectos en Movistar dependen directamente de la línea de negocio
(LOB); el ejecutivo de ventas inicia un proyecto, en el cual se van a ejecutar
varias tareas con un orden lógico dependiendo del departamento que se
encargue de cada etapa, ya que son proyectos que implican la colaboración
de varios departamentos. Para el desarrollo normal de cada tarea, se hace
un recorrido por el workflow donde se utiliza una funcionalidad especial para
detectar en que fase se encuentra el proyecto, a fin de que siga su secuencia
normal y se pueda ejecutar sin inconveniente alguno.
CAPITULO II _____________________________________________________________________________________________
20
II.2 Algoritmos Inteligentes
II.2.1 ¿Qué son los Algoritmos Inteligentes?
Los Algoritmos Inteligentes se plantean como una continuación de la
Inteligencia Artificial y tienen como objetivo el estudio de paradigmas de
resolución de problemas tradicionalmente ligados al reconocimiento de
patrones y, en general, a la percepción computacional.
Los Algoritmos inteligentes, surgen como una necesidad de practicar las
técnicas emergentes de la inteligencia, cada día mas utilizadas en los
ambientes empresariales. Entre las prácticas de los mismos, se puede
nombrar: Los sistemas expertos, las redes neuronales, lógica difusa y los
algoritmos genéticos. (http://www.ing.ula.ve)
II.2.2 Sistemas expertos
Bajo el término de Sistemas Expertos se entiende un nuevo tipo de software
que imita el comportamiento de una persona en la solución de un problema.
Estos sistemas pueden almacenar conocimientos humanos para un campo
determinado y solucionar un problema mediante deducción lógica de
conclusiones.
CAPITULO II _____________________________________________________________________________________________
21
II.2.2.1 La función de un sistema experto
Un Sistema Experto tiene la función de aportar soluciones a problemas, tal
como los pudiese resolver un ser humano, es decir posee la capacidad de
mostrar soluciones inteligentes. Ello es posible gracias a que el sistema es
creado por expertos (humanos), que intentan estructurar y formalizar
conocimientos de manera de ponerlos a disposición del sistema, para que
éste pueda resolver una función dentro del ámbito del problema, de la
misma forma en que lo hubiera hecho un experto.
II.2.2.2 Los componentes de un sistema experto
Los componentes de un sistema experto son:
• Su Base de Conocimientos contiene los hechos y las experiencias de
los humanos en un dominio determinado.
• El Mecanismo de Inferencia puede simular la estrategia de solución de
una persona.
• El Componente Explicativo explica al usuario la estrategia de solución
encontrada y el porqué de las decisiones tomadas.
• La Interfaz de Usuario sirve para que éste pueda realizar una consulta
en un lenguaje lo más natural posible.
CAPITULO II _____________________________________________________________________________________________
22
• El Componente de Adquisición ofrece ayuda a la estructuración e
implementación del conocimiento en la base de conocimientos
(Jackson, 1990).
En el Apéndice A, se puede apreciar la metodología que se utiliza en la
elaboración de Sistemas expertos.
II.2.3 Redes neuronales o neurales
Las redes neuronales son más que otra forma de emular ciertas
características propias de los humanos, como la capacidad de memorizar y
de asociar hechos. Si se examinan aquellos problemas que no pueden
expresarse a través de un algoritmo, se observará que todos ellos tienen una
característica en común: la experiencia. El hombre es capaz de resolver
estas situaciones acudiendo a la experiencia acumulada. Así, una forma de
aproximarse al problema consiste en la construcción de sistemas que sean
capaces de reproducir esta característica humana.
II.2.3.1 Características de las redes neurales
• Tiene capacidad de aprender de la experiencia y adaptarse a su
entorno.
CAPITULO II _____________________________________________________________________________________________
23
• Pueden hacer qué a partir de un conjunto de ejemplos
proporcionados, un ejemplo nunca visto.
• Ofrecen la posibilidad de abstraer características relevantes entre un
conjunto de entradas que incluyen grandes cantidades de datos
irrelevantes y distorsiones. Esto último se refiere a que en la
programación, tal como la practicamos habitualmente, es muy difícil la
discriminación de datos relevantes e irrelevantes.
La página http://www.ilustrados.com es un sitio que informa sobre las
ventajas de las redes neurales, entre la más notoria es su tolerancia a fallos,
basada en su capacidad de auto-ajustarse. Así como estas redes pueden
responder a cambios en el entorno, también pueden responder frente a fallas
internas.
En las redes neurales el conocimiento se representa básicamente mediante
magnitudes llamadas pesos o pesos sinápticos. El tipo de métodos de
resolución de problemas que se usa consiste en algoritmos de búsqueda de
los valores de esas magnitudes. Entre esos métodos de resolver problemas
tiene particular importancia el método de corrección de errores.
¿Pueden las computadoras aprender a resolver problemas a partir de
ejemplos? Esta cuestión, que bordeaba no hace mucho tiempo en la frontera
CAPITULO II _____________________________________________________________________________________________
24
del futuro lejano, es actualmente objeto de profundos estudios. Las redes de
neuronas formales son máquinas que poseen esta capacidad de aprendizaje.
Estas máquinas han sido propuestas como modelos extremadamente
simplificados del funcionamiento del cerebro, puesto que no retienen más
que algunas características esenciales:
Las neuronas no pueden encontrarse más que en dos estados posibles,
activas o en reposo.
• Están interconectadas mediante sinapsis que pueden ser modificadas
por aprendizaje.
• El estado de una neurona a cada instante es determinado por el de
otras neuronas, información que es transmitida por las sinapsis.
Aunque puede parecer muy esquemático, este modelo presenta una riqueza
de estados, de comportamientos y ha sentado las bases de un modelo de
memoria y aprendizaje como un fenómeno emergente colectivo: el sistema
global presenta propiedades complejas que no pueden predecirse a partir del
estudio individual de sus componentes. Así, el todo es mucho más que la
suma de sus partes. Por otro lado, las aplicaciones en diversos dominios no
tardaron en aparecer. Los estudios teóricos de redes de neuronas reflejan
estos dos aspectos: el del modelado de fenómenos cognoscitivos y el del
CAPITULO II _____________________________________________________________________________________________
25
desarrollo de aplicaciones. Aunque las redes de neuronas hayan sido
aplicadas a diversos campos, se hará énfasis en la clasificación de datos:
para los seres humanos ésta es una actividad tan trivial que pasa
desapercibida, pero que presenta dificultades importantes para una máquina
(http://www.ilustrados.com).
En la Figura 4, se puede apreciar una red de neuronas formales:
Figura 4. Red de neuronas formales.
Fuente: Conceptos básicos sobre Redes Neuronales Artificiales
Las neuronas grises pertenecen a las capas de entrada y de salida. Una
neurona particular es indicada en negro. Sus sinápsis de entrada son
representadas en línea gruesa.
II.2.4 La lógica difusa
Russell (1995) y Norvig (1995) dieron a conocer sus fundamentos sobre la
lógica difusa. La Lógica Difusa es un proceso matemático que permite
CAPITULO II _____________________________________________________________________________________________
26
representar y manipular datos que no pueden definirse en forma precisa por
la incertidumbre que poseen. Las aplicaciones de este proceso se extienden
a las diferentes ramas de la ingeniería, lo que le da una gran relevancia. Una
de las áreas de aplicación de la lógica difusa es el área de control y en éste
la estabilidad juega un papel de gran importancia.
La lógica difusa reconoce más que simples valores verdaderos y falsos. Con
ella las proposiciones pueden ser representadas con grados de veracidad o
falsedad. Además, ha sido probada para ser particularmente útil en sistemas
expertos y otras aplicaciones de inteligencia artificial.
En las diferentes aplicaciones, la lógica difusa es utilizada a través de un
conjunto de variables tales como las variables lingüísticas, o los conjuntos de
reglas “SI – ENTONCES”, (“IF-THEN”) y otras. El sistema difuso puede ser
interpretado de manera lingüística, pero el algoritmo en si es un sistema
determinístico que procesa valores exactos de entradas y produce valores
exactos de la salida. Este proceso ofrece un conjunto amplio de posibilidades
de análisis, entre las cuales se pueden citar la notación y las reglas
lingüísticas para transferir de manera consistente el conocimiento heurístico
hacia su conversión en un algoritmo matemático. De esta manera la lógica
difusa esta directamente relacionada con el concepto de redes neuronales, y
el razonamiento probabilístico. Dichas áreas forman parte de lo que se
CAPITULO II _____________________________________________________________________________________________
27
conoce como cómputos suaves, (“soft computing”) y puede afirmarse que
estas metodologías son complementarias y no competitivas.
Otra ventaja de la lógica difusa es que permite formar funciones no lineales
entre las entradas y las salidas de los sistemas. Desde este punto de vista,
puede ser considerada como una ampliación de la lógica booleana
tradicional, lo cual permitiría manejar los conceptos como el de verdad
parcial, que comprende la serie de valores distribuidos entre lo
completamente verdadero, y lo completamente falso. (Zimmerman, Hans J,
1987, p. 1)
II.2.5 Los algoritmos genéticos
Con la información que proporciona Goldberg (1989), en el libro titulado
Genetic Algorithms in Search, Optimization, and Machine Learning, muchos
lectores han aprendido elementos importantes sobre Los algoritmos
genéticos, los cuales son métodos sistemáticos para la resolución de
problemas de búsqueda y optimización que aplican a éstos los mismos
métodos de la evolución biológica.
Una vez estudiadas todas las técnicas fundamentales de la computación
inteligente, hay que tener en cuenta que para desarrollar cualquier
herramienta que pueda hacer el papel de raciocinio de una persona, se debe
CAPITULO II _____________________________________________________________________________________________
28
aplicar la lógica formal, la cual proporciona un medio para representar
argumentos de una manera formal y rigurosa, a través del estudio de los
fundamentos relacionados con su validez y los métodos para inferir
proposiciones a partir de otras consideradas válidas.
Por otra parte, la lógica computacional es una disciplina que estudia la
aplicación de la lógica formal para la representación computacional de
argumentos, las técnicas de deducción automática o asistida por
computadora, los fundamentos relacionados con validez y de forma
completa (completeness) de sistemas de proposiciones y las aplicaciones de
esas técnicas a las diferentes áreas de las ciencias computacionales en
todas las etapas del desarrollo del software, es decir, especificación, diseño,
construcción y verificación formal de programas.
La lógica computacional, sin embargo, no actúa de manera aislada. Para el
establecimiento de fundamentos de las ciencias computacionales concurren
conjuntamente con la lógica computacional, disciplinas como teoría de la
computación y análisis de algoritmos; para el desarrollo de sistemas, la lógica
computacional participa con la ingeniería de software para el establecimiento
de métodos formales de especificación y verificación de programas, los
cuales pueden ser usados para el desarrollo de sistemas críticos y/o
concurrentes.
CAPITULO II _____________________________________________________________________________________________
29
Por otra parte, la lógica computacional en conjunción con otras disciplinas
permite la resolución eficiente de problemas complejos, así como por ejemplo
los métodos de optimización combinatoria y de lógica computacional,
mezclados adecuadamente con métodos heurísticos de la inteligencia
artificial, ofrecen alternativas de solución a problemas computacionales muy
difíciles que se les ha denominado NP completos.
II.2.5.1 Inteligencia artificial y resolutores generales de problemas
Redcientifica.com es un sitio que facilita el acceso a toda la información
sobre los Agentes Autodidactas. En él se puede encontrar material para
solucionar problemas a través de la computadora, así como también se
pueden utilizar conceptos de vida artificial, algoritmos genéticos y sistemas
expertos. En principio, el objetivo es conseguir programar un computador
para que sea capaz de resolver un problema cualquiera. Una vez acabado el
programa, se podría enfrentar problemas sencillos, comprobando hasta que
punto se ha acercado al deseado resolutor general de problemas.
Únicamente se ha de seguir la siguiente norma: estará prohibido introducir
conocimiento específico acerca de cómo resolver los problemas particulares
con los que después se comprobará su validez. Sin embargo, sí estará
permitido introducir conocimiento de nivel superior o metaconocimiento: por
ejemplo, cómo obtener conocimiento, o cómo gestionar los recursos que
obtienen el conocimiento, entre otros.
CAPITULO II _____________________________________________________________________________________________
30
II.2.5.2 Métodos de aprendizaje
En primer lugar, el programa proporcionará una filosofía de trabajo en
paralelo, de forma que, aunque el programa sea único, no actúe como una
única entidad, sino como varias entidades (o programas) que intentan
simultáneamente lograr el objetivo que estamos buscando. Un supervisor
seleccionará las entidades que más se acerquen a la meta, generándose
nuevas entidades a partir de la combinación de las existentes y por puro
azar, como ocurre en los algoritmos genéticos.
Las entidades también podrán reproducirse, comunicarse, cooperar y
competir entre ellas, adquiriendo características propias de los seres vivos.
Además, podrán razonar mediante un sistema de reglas, como en los
sistemas expertos. De esta forma, se tendrán unos agentes que buscarán la
combinación de acciones que les lleve a lograr un objetivo, guiándose por la
información que reciben de unos sentidos.
Un agente podría estar compuesto por un conjunto de agentes de nivel
inferior, y así sucesivamente, de forma que un objetivo, representado
mediante un agente, pueda descomponerse en sub-objetivos, representados
por subagentes.
CAPITULO II _____________________________________________________________________________________________
31
Se supondrá que siempre será posible predecir, con una cierta probabilidad,
el comportamiento del sistema al que nos enfrentamos. Es decir, que existe
una relación entre las acciones que realizamos sobre el entorno, y el estado
siguiente de éste, de forma que es posible asignar una probabilidad a la
relación entre un estado inicial, una acción nuestra sobre él, y el estado
resultado obtenido con esa acción. Así podremos tener reglas del tipo que se
observan en la figura 5:
ESTADO + ACCIÓN = NUEVO ESTADO: PROBABILIDAD
Figura 5. Tipo de reglas
Fuente: Los Algoritmos Genéticos
II.2.5.3 Definición de agente
Los agentes no son más que zonas de memoria con datos-instrucciones, a
los que se les da "vida" cada vez que se les otorga un pequeño tiempo de
ejecución. Ello no es para asombrarse; los seres humanos no son más que
zonas de espacio-tiempo con materia. Los agentes realizan un ciclo continuo
de observación y acción. Un agente siempre posee un objetivo; una misión
que cumplir. Los agentes interpretan la información que reciben de sus
CAPITULO II _____________________________________________________________________________________________
32
sentidos, transformándola en conceptos que definen la situación en la que se
encuentran. Así, entre otras cosas, comprueban hasta qué punto se cumple
el objetivo que los define. En el caso de no cumplirse éste, deciden según
ciertos criterios, cuál es la sucesión de acciones que sería necesario ejecutar
para lograr la meta y a continuación ejecutan dichas acciones.
II.2.5.4 Jerarquía de acciones
Si se realiza una acción y se pasa a un estado desconocido, se almacenará
información que represente ese nuevo estado y se creará una regla que
represente las condiciones necesarias para pasar a ese nuevo estado.
Para poder utilizar este tipo de reglas, las acciones se podrán organizar en
una estructura jerárquica. Así, una sucesión de acciones interesante formará
una acción de nivel superior y esta acción podrá formar parte de una regla.
Si se piensa en el programa como en un conjunto de agentes o entidades,
una acción puede consistir en:
• Crear nuevas entidades.
• Eliminarlas.
• Modificarlas.
CAPITULO II _____________________________________________________________________________________________
33
Es importante recordar que las entidades pueden combinarse y crear nuevas
entidades con características de sus progenitores (reproducción sexual),
pudiendo producirse modificaciones al azar (mutaciones genéticas). También
es posible simular una selección darwiniana haciendo desaparecer aquello
que no consigue sus objetivos o asignándole un tiempo de ejecución menor.
II.2.5.5 Jerarquía de variables
El número de variables que forman un estado normalmente será muy grande,
y muchas veces ocurrirá que varios estados distintos se comportan como uno
sólo. Esta última situación se observa en el caso del tres-en-raya, por
ejemplo, en la simetría que posee el tablero. Por estas razones puede ser
interesante representar algunas combinaciones de valores de variables como
un único valor para una variable de nivel superior.
II.2.5.6 Lo que se quiere conseguir
Para medir el éxito del programa, es más importante observar la tendencia
de éste, que los resultados concretos. Se puede crear una gráfica que
relacione la utilidad o la calidad del conocimiento adquirido por las entidades
en función del tiempo que ha sido necesario para que esto suceda. También
podría hacerse lo mismo en relación con la cantidad de memoria empleada,
en vez del tiempo.
CAPITULO II _____________________________________________________________________________________________
34
En la figura 6 se muestran las diferentes etapas del conocimiento a través
del tiempo.
Figura 6: Calidad de conocimiento Vs. tiempo
Fuente: Programación de sesiones.
La primera de las gráficas corresponde al comportamiento ideal, en el que el
conocimiento aumenta exponencialmente, con lo que se puede esperar
resolver un problema cualquiera y además en un breve tiempo. En la
segunda, el conocimiento aumenta de forma constante. Un sistema así
siempre sería capaz de obtener el conocimiento buscado en un tiempo finito.
CAPITULO II _____________________________________________________________________________________________
35
Sin embargo, la tercera corresponde con un sistema que a pesar de poseer
un gran incremento del conocimiento en el inicio, éste se estabiliza en un
cierto valor, con lo que no se cumplirá el objetivo de disponer de un sistema
capaz de resolver un problema cualquiera, a no ser que el valor de máximo
conocimiento al que se tiende sea tan grande que se pueda considerar
infinito (http://www.redcientifica.com).
II.3 VARIABLES
II.3.1 Definición de variable
Es una propiedad de los objetos o de los sujetos que adquiere distintos
valores. En una investigación, los términos de las variables principales se
definen usualmente en dos formas: conceptual o constitutivamente y
operacionalmente.
II.3.1.1 Las variables conceptuales
Son la expresión conceptual del término. En el presente se utiliza una
definición derivada de la teoría científica. En otros casos se maneja el
diccionario o la lógica del investigador. (Zimmerman, Hans J, 1987, p. 121)
CAPITULO II _____________________________________________________________________________________________
36
II.3.1.2 Las variables operacionales
Por el contrario las variables operacionales son las que se derivan de las
actividades u operaciones necesarias para observar, medir y manipular la
variable. (Zimmerman, Hans J, 1987, p. 121)
II.3.2 La variable lingüística
Se conoce como variable lingüística aquella que tiene por valor palabras o
frases.
II.4 TÉCNICAS Y MODELOS
II.4.1 Semántica
La percepción que tenga cualquier persona lo suficientemente cualificada
(analista, especialista, experto), puede perfectamente tener niveles de
imprecisión o ambigüedades subyacentes en tal percepción. Para modelar
adecuadamente la opinión (juicio de valor) del experto, se trabajará con una
modalidad que permita manipular adecuadamente, los niveles de
ambigüedad e imprecisión que puedan estar presentes en tal percepción.
CAPITULO II _____________________________________________________________________________________________
37
II.4.2 RUP (Rational Unified Process)
Un proceso es un conjunto de pasos ordenados parcialmente para alcanzar
un objetivo. En la ingeniería de software, el objetivo es entregar un producto
software que satisfaga las necesidades del usuario, de forma eficiente y
predecible. (Booch, G., Rumbaugh J. y Jacobson, I., 1999, p. 399)
El objetivo del Rational Unified Process, que en adelante se entenderá como
RUP, es permitir la producción de un software de la mayor calidad que
satisfaga las necesidades de los usuarios finales, dentro de planificaciones y
presupuestos predecibles. El RUP captura algunas de las mejores prácticas
del desarrollo de software, de una forma que es adaptable a un amplio rango
de proyectos y organizaciones. En el aspecto de la gestión, el RUP
proporciona un enfoque disciplinado sobre cómo asignar tareas y
responsabilidades dentro de una organización de desarrollo de software.
(Booch et al., 1999, p. 399)
II.4.2.1 Características del RUP
El RUP es un proceso iterativo. Para los sistemas simples, parece
perfectamente factible definir de forma secuencial el problema completo,
diseñar la solución completa, construir el software y, a continuación, hacer
pruebas con el producto final. Un enfoque iterativo propone una comprensión
CAPITULO II _____________________________________________________________________________________________
38
incremental del problema a través de varios ciclos. Como parte del enfoque
iterativo se encuentra la flexibilidad para acomodarse a nuevos requisitos o a
cambios tácticos en los objetivos del negocio. También permite que el
proyecto identifique y resuelva los riesgos más bien pronto que tarde. (Booch
et al., 1999, p. 399)
II.4.2.2 Enfoque del RUP
El marco metodológico que se ha elaborado es resultado de un estudio para
especializar el uso del RUP orientado al tipo de sistemas que se desarrolla.
Si bien el RUP permite gran flexibilidad para distintos sistemas, requiere de
gran esfuerzo para aplicarlo a otros de menor complejidad, debido a que se
debe comprender en detalle el proceso a fin de discriminar los elementos a
utilizar. El RUP toma en cuenta sólo de manera disgregada el tiempo real.
II.4.2.3 Fases del RUP
Una fase es el intervalo de tiempo entre dos hitos importantes del proceso
durante el cual se cumple un conjunto bien definido de objetivos, se
completan artefactos y se toman las decisiones sobre si pasar a la siguiente
fase. (Booch et al., 1999, p. 400) Como se muestra en la figura 7:
CAPITULO II _____________________________________________________________________________________________
39
Figura 7: Vista general de RUP
Fuente: El Lenguaje Unificado de modelado. Editorial Addison Wesley
RUP define nueve actividades a realizar en cada fase del proyecto
1. Modelado del negocio
2. Análisis de requisitos
3. Análisis y diseño
4. Implementación
5. Test
6. Distribución
7. Gestión de configuración y cambios
8. Gestión del proyecto
9. Gestión del entorno
CAPITULO II _____________________________________________________________________________________________
40
II.4.2.3.1 Inicio
Durante esta fase, se establece la planificación del proyecto y se delimita su
alcance. La planificación del proyecto incluye los criterios de éxito, la
evaluación del riesgo, estimaciones de recursos que se necesitarán y un plan
de fases que muestre la planificación de los hitos principales. Durante la
iniciación, es frecuente crear un prototipo ejecutable que sirva para probar
los conceptos. (Booch et al., 1999, p. 401)
Al final de la fase inicio, se examinan los objetivos del ciclo de vida del
proyecto y se decide si proceder con el desarrollo del sistema. (Booch et al.,
1999, p. 401)
II.4.2.3.2 Elaboración
Los objetivos de esta fase son analizar el dominio del problema, establecer
una base arquitectónica sólida, desarrollar el plan del proyecto y eliminar los
elementos de más alto riesgo del proyecto. Las decisiones arquitectónicas
deben tomarse con una comprensión del sistema global. Esto implica que se
deben describir la mayoría de los requisitos del sistema. Para verificar la
arquitectura, se implementa un sistema que demuestre las distintas
posibilidades de la arquitectura y ejecute los casos de uso significativos.
(Booch et al., 1999, p. 402)
CAPITULO II _____________________________________________________________________________________________
41
Al final de la fase de elaboración se examinan el alcance y los objetivos del
sistema, la elección de la arquitectura y la resolución de los riesgos más
grandes, y se decide si se debe pasar a la construcción. (Booch et al., 1999,
p. 402)
II.4.2.3.3 Construcción
Durante la fase de construcción, se desarrolla de forma iterativa e
incremental un producto completo que está preparado para la transición
hacia la comunidad de usuarios. Esto implica describir los requisitos
restantes y los criterios de captación, refinando el diseño y completando la
implementación y las pruebas del software. (Booch et al., 1999, p. 402)
Al final de esta fase se decide los lugares donde se instalará el software y los
usuarios que podrán empezar a manipularlo. (Booch et al., 1999, p. 402)
II.4.2.3.4 Transición
En esta fase, el software se despliega en la comunidad de usuarios. Una vez
que el sistema ha sido puesto en manos de los usuarios finales, a menudo
aparecen cuestiones que requieren un desarrollo adicional para ajustar el
sistema, corregir algunos problemas no detectados o finalizar algunas
CAPITULO II _____________________________________________________________________________________________
42
características que habían sido propuestas. Esta fase comienza
normalmente con una versión beta del sistema, que luego será reemplazada
con el sistema de producción. (Booch et al., 1999, p. 402)
Al final de la fase de transición se decide si se han satisfecho los objetivos
del ciclo de vida del proyecto, y se determina si se debería empezar otro ciclo
de desarrollo. Éste es también un punto en el que se asimilan las lecciones
aprendidas en el proyecto para mejorar el proceso de desarrollo, que sea
aplicado al próximo proyecto. (Booch et al., 1999, p. 402)
II.4.2.4 Actividades del RUP
El proceso define una serie de roles que se distribuyen entre los miembros
del proyecto y que definen las tareas de cada uno y el resultado que se
espera de ellos.
El Proceso RUP se representa utilizando cuatro elementos básicos de
modelado:
1. Roles: un rol define el comportamiento y las responsabilidades de una
persona trabajando en el proyecto.
2. Actividades: representa una unidad de trabajo desempeñada por un
determinado rol. El propósito de la actividad es crear artefactos.
CAPITULO II _____________________________________________________________________________________________
43
3. Artefactos: son piezas de información que se producen, modifican, o usan
por un proceso; es el producto tangible del proyecto los artefactos pueden
ser:
a) Un modelo o elemento de modelo, tal como Modelo de Casos de
Uso.
b) Un documento, tal como el documento de la Arquitectura del
Sistema.
c) Una Pieza Hardware o de un Programa Ejecutable del Sistema.
4. Flujos de trabajos: un flujo de trabajo es una secuencia de actividades
que produce resultados observables. Se representan dos tipos de flujos de
trabajo:
a) Flujo de Trabajo Principal: es una colección de actividades
relacionadas, que representa un componente del proceso de
desarrollo RUP.
b) Flujo de Trabajo Detallado: representan el desglosamiento de las
actividades que se muestran en el flujo de trabajo principal en otro
grupo de actividades más pequeñas que interactúan con roles y
artefactos.
En la figura 8, se puede apreciar los flujos de trabajo del RUP:
CAPITULO II _____________________________________________________________________________________________
44
Figura 8: Flujos de trabajo del RUP
Fuente: El modelo de McCulloch y Pitts.
II.4.3 UML (Unified Modeling Language)
Un lenguaje proporciona un vocabulario y reglas para combinar palabras de
ese vocabulario con el objetivo de posibilitar la comunicación. Un lenguaje de
modelado es un lenguaje cuyo vocabulario y reglas se centran en la
representación conceptual y física de un sistema. Un lenguaje de modelado
como UML es, por tanto, un lenguaje estándar para los planos del software.
El modelado proporciona una comprensión del sistema. Nunca es suficiente
un único modelo. Más bien, para comprender cualquier sistema, a menudo
CAPITULO II _____________________________________________________________________________________________
45
se necesitan múltiples modelos conectados entre si, excepto en los sistemas
más triviales. Para sistemas con gran cantidad de software, se requiere un
lenguaje que cubra las diferencias vistas de la arquitectura de un sistema
mientras evoluciona a través del ciclo de vida del desarrollo del software.
(Booch et al., 1999, p. 12)
UML cubre las especificaciones de todas las decisiones de análisis, diseño e
implementación que deben realizarse al desarrollar y desplegar un sistema
con gran cantidad de software.
No es un lenguaje de programación visual, pero sus modelos pueden
conectarse de forma directa a una gran variedad de lenguajes de
programación. Esta correspondencia permite ingeniería directa: la
generación de código a partir de un modelo UML en un lenguaje de
programación. (Booch et al., 1999, p. 13)
Lo contrario también es posible: se puede reconstruir un modelo UML a partir
de una implementación. La ingeniería inversa no es magia. A menos que se
codifique esa información en la implementación, la información se pierde
cuando se pasa de los modelos al código. La ingeniería inversa requiere, por
lo tanto, herramientas que la soporten e intervención humana. La
combinación de estas dos vías de generación de código y de ingeniería
inversa produce una ingeniería “de ida y vuelta”, entendiendo por esto la
CAPITULO II _____________________________________________________________________________________________
46
posibilidad de trabajar en una vista gráfica o textual, mientras las
herramientas mantienen la consistencia entre las dos vistas. (Booch et al.,
1999, p. 13)
Además de esta correspondencia directa, UML es lo suficientemente
expresivo y no ambiguo como para permitir la ejecución directa de modelos,
la simulación de sistemas y la instrumentación de sistemas en ejecución.
Con UML habría que apartarse del protagonismo excesivo que se le da al
diagrama de clases, el cual representa una parte importante del sistema pero
sólo representa una vista estática, es decir muestra al sistema detenido. Se
conoce su estructura pero no lo que sucede en sus diferentes partes cuando
el sistema empieza a funcionar. UML introduce nuevos diagramas que
representan una visión dinámica del sistema, es decir, gracias al diseño de la
dinámica del sistema, se puede dar cuenta, durante la fase de diseño el autor
se puede dar cuenta de los problemas de la estructura al propagar errores, o
de las partes que necesitan ser sincronizadas, así como del estado de cada
una de las instancias en cada momento. El diagrama de clases muestra un
conjunto de clases, interfaces y colaboraciones, así como sus relaciones;
cubren la vista de diseño estática de un sistema, pero se debe de tener en
cuenta que su representación es limitada y que ayuda a diseñar un sistema
robusto con partes reutilizables, pero no a la solución de problemas de
propagación de mensajes ni de sincronización o recuperación ante estados
CAPITULO II _____________________________________________________________________________________________
47
de error. En fin, está orientado hacia el hecho de que un sistema debe de
estar bien diseñado y debe funcionar.
UML es ahora un estándar, no existe otra especificación de diseño orientado
a objetos, porque es el resultado de las tres opciones existentes en el
mercado. Su utilización es independiente del lenguaje de programación y de
las características de los proyectos, debido a que UML ha sido diseñado para
modelar cualquier tipo de proyectos, tanto informáticos como de arquitectura
o de cualquier otro ramo.
UML permite la modificación de todos sus miembros mediante estereotipos y
restricciones. Un estereotipo permite indicar especificaciones del lenguaje al
que se refiere el diagrama de UML; una restricción identifica un
comportamiento forzoso de una clase o relación. Es decir mediante la
restricción, estamos forzando el comportamiento que debe tener el objeto al
que se le aplica.
II.4.3.1 Diagramas UML
Un diagrama es la representación grafica de un conjunto de elementos,
visualizado la mayoría de las veces como un grafo conexo de nodos
(elementos) y arcos (relaciones). Los diagramas se dibujan para visualizar un
sistema desde diferentes perspectivas, de forma que un diagrama es una
CAPITULO II _____________________________________________________________________________________________
48
proyección de un sistema. Para todos los sistemas, excepto los más triviales,
un diagrama representa una vista resumida de los elementos que constituyen
un sistema. El mismo elemento puede aparecer en todos los diagramas, solo
en unos pocos en unos pocos diagramas (el caso más común), o en ningún
diagrama (un caso muy raro). En teoría, un diagrama puede contener
cualquier combinación de elementos y relaciones. En la práctica, sin
embargo, sólo surge un pequeño número de combinaciones, las cuales son
consistentes con las cinco vistas más utilizadas que comprenden la
arquitectura de un sistema con gran cantidad de software. (Booch et al.,
1999, p. 20)
UML posee tipos diferentes de diagramas estos son:
Diagrama de clases: son los más comunes en el modelado de sistemas
orientado a objetos. Muestra las clases, interfaces, colaboraciones y sus
relaciones.
Diagrama de objetos: muestra un conjunto de objetos y sus relaciones. Los
diagramas de objetos representan las instancias de los elementos
encontrados en los diagramas de clases y cómo se relacionan entre ellos.
Diagrama de casos de uso: muestra un conjunto de casos de uso y actores
(un tipo especial de clases) y sus relaciones. Estos diagramas son
CAPITULO II _____________________________________________________________________________________________
49
especialmente importantes en el modelado y organización del
comportamiento de un sistema.
El formato para la descripción de los casos de uso es el siguiente:
• Caso de uso: Nombre del caso de uso.
• Actores: Lista de actores (agentes externos), en el cual se indica
quien inicia el caso de uso.
• Propósito: Intención del caso de uso.
• Tipo: Primario, secundario u opcional. Esencial o real.
• Descripción: Descripción del caso de uso.
Los casos primarios de uso representan los procesos comunes más
importantes. Los casos secundarios de uso representan procesos menores o
raros. Finalmente, los casos opcionales de uso representan procesos que
pueden no abordarse.
Diagrama de secuencia, Diagrama de colaboración: son un tipo de
diagrama de interacción. Un Diagrama de interacción muestra una
interacción que consta de un conjunto de objetos y sus relaciones,
incluyendo los mensajes que pueden ser enviados entre ellos. Los diagramas
CAPITULO II _____________________________________________________________________________________________
50
de secuencia y los de colaboración son isomorfos, es decir, que se puede
tomar uno y transformarlo en el otro.
Diagrama de estados: muestra una máquina de estados, que consta de
estados, transiciones, eventos y actividades. Son especialmente importantes
en el modelado del comportamiento de una interfaz, una clase o una
colaboración y resaltan el comportamiento dirigido por eventos de un objeto,
lo cual es especialmente útil en el modelado de sistemas reactivos.
Diagrama de actividades: es un tipo especial de diagramas de estados que
muestra el flujo de actividades dentro de un sistema. Son especialmente
importantes al modelar el funcionamiento de un sistema y resaltan el flujo de
control de objetos.
Diagrama de componentes: muestra la organización y las dependencias
entre un conjunto de componentes. Se relacionan con los diagramas de
clases en que un componente se corresponde, por lo común, con una o más
clases, interfaces o colaboraciones.
Diagrama de despliegue: muestra la configuración de nodos de
procesamiento en tiempo de ejecución y los componentes que se residen en
ellos. Se relacionan con los diagramas de componentes en que el nodo
incluye, por lo común, uno o más componentes.
CAPITULO II _____________________________________________________________________________________________
51
Esta no es una lista cerrada de diagramas. Las herramientas pueden utilizar
UML para proporcionar otros tipos de diagramas, aunque estos nueve son,
los que con mayor frecuencia se utilizan en la práctica.
II.4.3.2 Vistas UML
Las vistas existentes en UML son:
Vista casos de uso: se forma con los diagramas de casos de uso,
colaboración, estados y actividades; cubren la vista estática de casos de uso
de un sistema.
Vista de diseño: se forma con los diagramas de clases, objetos,
colaboración, estados y actividades; cubren la vista de diseño estática de un
sistema.
Vista de procesos: se forma con los diagramas de la vista de diseño,
resaltando las clases y objetos referentes al proceso.
Vista de implementación: se forma con los diagramas de componentes,
colaboración, estados y actividades; cubren la vista de implementación
estática de un sistema.
CAPITULO II _____________________________________________________________________________________________
52
Vista de despliegue: se forma con los diagramas de despliegue,
colaboración, interacción, estados y actividades; cubren la vista estática de
despliegue de una arquitectura.
CAPÍTULO III
MARCO METODOLÓGICO
En este capítulo, se presenta toda la información del desarrollo del Trabajo
Especial de Grado, el cual se basa en la metodología RUP (Rational Unified
Process), para la elaboración del módulo.
El capítulo se encuentra estructurado en varias secciones, en las cuales se
explica la forma en que fue empleada la metodología RUP y se especifica de
acuerdo a la fase que se desarrolle.
CAPITULO III _____________________________________________________________________________________________
54
III.1 Fase de Inicio
El ciclo de vida diaria de la sociedad actual es muy rápido, tanto a nivel
personal como a nivel laboral; debido a esta celeridad, el mundo de los
negocios se ha hecho cada día más competitivo y por ello se espera mucha
mas eficiencia para atraer hacia las empresas nuevos clientes que permitan
el crecimiento de las mismas.
Una de las técnicas más usadas para el crecimiento de las empresas son las
buenas relaciones empleado-cliente. Para esto, es necesario que el
empleado sea rápido a la hora de resolver problemas y que disponga de
tiempo necesario para atender al cliente con un trato personalizado para
satisfacer todas sus exigencias.
Por este motivo, la empresa de Telecomunicaciones Telefónica Movistar se
vió en la necesidad de desarrollar una herramienta que le permitiera diseñar
caminos de trabajo (Workflows) para los proyectos desarrollados de provisión
de Servicios de Acceso Fijo para Clientes Corporativos, y permitir el
seguimiento (tracking) de la ejecución de los mismos, basados en una
interfaz Intranet que habilitara acceso remotos a los diferentes
departamentos de Telefónica Movistar que participaran en los proyectos. Con
CAPITULO III _____________________________________________________________________________________________
55
esto en mente, se creó la herramienta de trabajo llamada SIP + (Sistema de
información de proyectos).
Actualmente, el SIP+ provee un mecanismo para asignar de forma manual
los recursos humanos requeridos para los diferentes proyectos llevados a
cabo por el Departamento de Ingeniería de Acceso. Esta herramienta asigna
un período holgado para la realización de las tareas en un proyecto pero no
es capaz de planificar inteligentemente el momento preciso de ejecución de
tareas de acuerdo a la disponibilidad de los diversos recursos humanos
involucrados. Ejecutar ambas labores de manera manual y con tiempos tan
holgados genera retrasos e imprecisiones, que en muchos casos pueden
desembocar en reestructuración de trabajos y empleo ineficiente de los
recursos.
El módulo a desarrollar perfeccionará los métodos en la Asignación y
Planificación de Empleo de Personal para el Sistema de Información de
Proyectos (SIP+) de Acceso de la empresa de telecomunicaciones
Telefónica Movistar.
El objetivo es desarrollar una extensión del Módulo de Administración de
Recursos de Personal de Ingeniería del SIP+, el cual debe cumplir con
ciertas especificaciones tales como: filtro por región, filtro por departamento,
permitir la modificación de aquellos proyectos que se encuentren en status
CAPITULO III _____________________________________________________________________________________________
56
cerrados y/o cancelados y restringir el acceso a ésta área de manera que
solo lo utilicen las personas autorizadas.
El nuevo módulo del SIP+ contará con las siguientes funcionalidades:
• Selección automática del Líder de Proyecto que asumirá una actividad de
acuerdo a carga de trabajo, tipo de cliente, línea de negocio y área
geográfica.
• Planificación de forma apropiada el momento preciso de ejecución de
tareas, de acuerdo a la disponibilidad de los diversos recursos humanos
involucrados.
Para realizar el levantamiento de información se contó con una serie de
reuniones multilaterales, conocidas por sus siglas en ingles JAD (Joint
Application Development), además de entrevistas personalizadas con
diferentes departamentos, en donde se especifico las pautas con las cuales
se debía realizar la herramienta.
En los JAD, los interesados de cada departamento aportaron sugerencias
sobre las especificaciones del sistema. Entre las cuales se tienen:
CAPITULO III _____________________________________________________________________________________________
57
III.1.1 Reglas por Departamento
Proyecto Vs. Recursos
1) Tipo Proyecto:
- Tipo de Recursos:
- Normal (todos los Lideres) Plus
- Líder Factibilidad
- Líder
- Ventas
- Tipos de Proyectos
- LOB`S
- Región
2) LOB (Línea de negocio).
3) Clientes (Relación de recursos con el cliente).
- Lideres
- Vendedores
4) Status Recursos:
- Activo
- Inactivo
- Vacaciones
CAPITULO III _____________________________________________________________________________________________
58
- Otro
5) Región y sub-región.
6) Carga de trabajo (Módulo de Ranking, dificultades por Dpto.):
- Tipo de Proyecto
- Contratista
- Tiempo de duración del proyecto
- Tipo de Dpto.
- Carga de trabajo.
7) Default: esta se llevará a cabo en caso de que no se encuentre
empleado que cumpla con las especificaciones anteriores.
Una vez levantados los requerimientos generales, la Gerencia de Acceso
(creador del SIP), decidió realizar una selección de los departamentos pilotos
para la ejecución de la nueva herramienta.
En lo referente a las entrevistas, a continuación se hace mención a las más
trascendentes vinculadas con los departamentos involucrados:
Miguel Rahn, Gerencia de Acceso:
Acceso: Gerencia encargada del diseño, dimensionamiento y gestión de los
recursos necesarios que permiten el aprovisionamiento de los servicios de
CAPITULO III _____________________________________________________________________________________________
59
telefonía y datos contratados por los distintos clientes corporativos de
Movistar.
1) El algoritmo, debe reconocer la última fase de acceso que se realice
en el proyecto.
2) Distribución de Proyectos en forma equitativa, es decir, si el líder
estaba en estado inactivo (vacaciones, enfermedad, otro), asignarle
una cantidad adecuada de proyectos sin caer en excesos.
3) Distribución de proyectos por cliente.
4) Asignación de nuevos proyectos a los líderes que se encuentren
atendiendo otros, pero éstos se encuentren parados por motivos
ajenos a la empresa.
Cesar Colina, Gerencia de Redes:
Redes u Operaciones: Gerencia encargada de las labores de mantener la
operatividad de los equipos instalados fuera y dentro de Movistar, además se
encarga de la atención de fallas que puedan ocurrir en los mismos.
1) Los proyectos se asignan por Regiones o sub-regiones.
2) Recurso de cambio de encargado por otro, en caso de haber algún
motivo externo (vacaciones, enfermedad, otro).
3) Se asignan a los técnicos por el número de celdas.
CAPITULO III _____________________________________________________________________________________________
60
4) El responsable de cada proyecto es de donde salga el MTSO (Mobile
Telephone Switching Office) de origen.
5) La cadena que se sigue para asignación de proyectos es:
Estación Cargo (supervisor, Especialista) horario.
Juan Perozo / Neil Ortega, Gerencia de Implementación:
Implementación: Gerencia encargada de la instalación y puesta en
funcionamiento de cualquier equipo de telecomunicaciones a emplearse en
Movistar.
En este Dpto. se lleva un puntaje por cada línea de negocio (LOB).
1) Se asignaran los proyectos de acuerdo a la región (dentro el área de
Caracas) en donde se desarrollen.
2) El empleado que tenga el puntaje mas bajo, será la primera opción
para la asignación del proyecto.
3) Los proyectos se asignan con los puntos que se van acumulando
durante la semana y se le da el proyecto a cada empleado, es decir,
los proyectos se distribuirán todos los viernes.
4) Los puntos de cada empleado se suman a finales de cada mes.
5) En caso de que el empleado no se encuentre disponible, se podrá
asignar a otro que lo sustituya de forma manual (esto seria la parte por
default).
CAPITULO III _____________________________________________________________________________________________
61
III.1.2 Caso de uso, modelo inicial
En esta primera etapa, se planteó un caso de uso inicial, el cual permitió
tener una ideal general del proyecto que se deseaba emprender y todo lo
que éste implicaba.
En la figura 9, se da una idea general de cómo se relaciona el experto
(persona encargada por cada departamento de Movistar) y la administración
(persona que se encarga de sintetizar todas las necesidades por
departamento de Movistar), con cada uno de los procesos que se encuentran
implicados en el sistema, entre ellos se tiene a continuación una pequeña
descripción de los casos de uso que interrelacionan:
CAPITULO III _____________________________________________________________________________________________
62
Figura 9: Caso de uso inicial del módulo Asig.Auto.Encargados
Fuente: Elaboración propia.
1. Establecer estudio: con el fin de determinar los casos de estudio por
departamento, se realizaron algunas preguntas a los expertos y a
partir de las respuestas se generó una idea de lo que se pretende
desarrollar.
2. Administrar el sistema: a partir de la información de los expertos que
participaron en las entrevistas, se puede manipular y sintetizar los
CAPITULO III _____________________________________________________________________________________________
63
objetivos del sistema de forma tal que se generen los resultados
esperados.
3. Administrar reglas: ayuda a determinar que información es
pertinente para cada departamento, con esto elige, modifica y/o
elimina las reglas.
4. Generar resultados: se procesa la información dada por los expertos
en las entrevistas, se guarda y se generan tablas de base de datos y
reportes a fin de extraerla información verdaderamente revelante.
III.1.3 Estudio Inicial de Riesgos
A la hora de elaborar un sistema, es importante estudiar los diferentes
riesgos que acarrea el desarrollo del mismo, dentro de esta fase de análisis
inicial se pueden citar algunos:
1. En todo sistema, se busca siempre que cada vez sea mejor. Estas
ampliaciones para mejorar su funcionamiento, muchas veces pueden ser
demasiado ambiciosas.
2. El alcance de cada reforma al sistema puede variar notablemente durante
el desarrollo.
3. Los requerimientos cambien.
4. Se quieran introducir nuevas funcionalidades al sistema.
CAPITULO III _____________________________________________________________________________________________
64
5. Se quieran realizar cambios sobre las ampliaciones que ya han sido
finalizados.
6. Las ampliaciones lleven consigo errores que no han sido corregidos.
7. El tiempo definido para cada ampliación del sistema no sea suficiente.
8. No se cuente con la documentación necesaria para ejecutar el sistema o
las ampliaciones que se pidan.
9. No se cuente con los equipos necesarios, para la elaboración del sistema.
10. El tiempo de entrega se adelante.
11. No se hayan registrado todas las funcionalidades durante la fase de
análisis.
12. No nos encontremos en la capacidad de entender ciertos conceptos.
13. Confundamos funcionalidades.
14. La metodología no sea la más idónea para diseñar este sistema.
15. Las herramientas utilizadas no sean las más idóneas para desarrollar este
tipo de sistemas.
16. La herramienta de desarrollo no sea amigable.
17. No contemos con el apoyo humano necesario.
18. Se cuente con una mala definición de estándares.
CAPITULO III _____________________________________________________________________________________________
65
III.2 Fase de Elaboración
III.2.1 Requerimientos No Funcionales del Sistema
A continuación se pueden observar algunos de los Requerimientos no
funcionales del Sistema que no restringen la implementación del mismo:
• Amigable: debe proveer al usuario una manera fácil y rápida de uso,
evitando posibles confusiones, que guíe al usuario durante todo su
recorrido, que sea agradable a la vista, fácil de utilizar, etc.
• Costos: el precio de desarrollo e implementación del sistema no debe
ser excesivo y no debe pasar de lo estimado.
• Tiempo: el sistema debe estar completamente listo, instalado y
operante para la fecha prevista.
III.2.2 Lista Revisada de Riesgos
Los riesgos del desarrollo deben ser continuamente revisados y analizados
con la finalidad de mantenerlos, en la medida de lo posible, mitigados.
CAPITULO III _____________________________________________________________________________________________
66
Se puede considerar que hasta ahora los riesgos identificados se han
mantenido latentes en el desarrollo. Estos se muestran con mayor nivel de
detalle a continuación.
1. Las ampliaciones pueden ser demasiado ambiciosas.
Debido a que el alcance de cada una de las ampliaciones no fueron
delimitadas adecuadamente.
2. El alcance de cada ampliación varíe notablemente durante el desarrollo.
Debido a que no se hayan tomado en cuenta factores que influirían
directamente sobre estas.
3. Los requerimientos cambien.
Esto puede ocurrir tanto por parte del usuario como del mismo
desarrollador.
4. Se quieran introducir nuevas funcionalidades al sistema.
Debido a que a corto plazo, lo que se quiere abarque el sistema, cambie.
5. Se quieran realizar cambios sobre las ampliaciones que ya han sido
finalizadas.
Debido a que fueron olvidadas o cambiadas funcionalidades.
6. Las ampliaciones llevan consigo errores que no han sido corregidos.
7. El tiempo definido para cada ampliación no sea suficiente.
Ya que éste es un estimado, y pudiera no ser el más idóneo.
8. No se cuente con la documentación necesaria.
CAPITULO III _____________________________________________________________________________________________
67
Ya que se podría carecer de la documentación necesaria para realizar el
proyecto.
9. No se cuente con los equipos necesarios.
El problema de Hardware siempre está presente.
10. El tiempo de entrega se adelante.
Este riesgo es muy probable, debido a que nos encontramos realizando
proyectos para la vida real.
11. No se hayan registrado todas las funcionalidades durante la fase de
análisis.
Se pueden haber escapado algunas funcionalidades durante la
visualización de las mismas.
12. Falta de capacidad para entender ciertos conceptos de la empresa.
13. Confusión de funcionalidades.
Debido a que muchas de estas son similares.
14. La metodología no sea la más idónea para diseñar este sistema
15. Las herramientas utilizadas no sean las más idóneas para desarrollar este
tipo de sistemas.
Debido al poco conocimiento que tenemos de las mismas, no podemos
evaluarlas con la mayor objetividad.
16. La herramienta de desarrollo no sea amigable.
17. No se cuente con el apoyo humano necesario.
18. Se cuente con una mala definición de estándares.
CAPITULO III _____________________________________________________________________________________________
68
III.2.3 Caso de uso del módulo, Asig.Auto.Encargados
Para la fase de elaboración del Módulo de asignación y planificación de
empleo de personal de Telefónica Movistar, se tomó en cuenta las
entrevistas realizadas a los expertos de cada departamento. Con ello se
pudo determinar ciertas reglas que eran comunes entre las diferentes áreas
de la empresa y así elegir al empleado más apropiado para realizar los
diferentes proyectos. Estas reglas son:
1. Tipo de proyecto: se debe asignar al empleado que esté en la
capacidad de laborar en ciertos proyectos; esto dependerá del
departamento al que pertenece la(s) persona(s) involucradas.
2. Línea de negocio (LOB): se debe elegir al encargado del proyecto,
de acuerdo a la línea de negocio en que se presente el mismo.
3. Región: según esta regla, se elige al empleado que se encuentra en
las zonas donde se desarrollarán los proyectos a los que será
asignado.
4. Carga de trabajo por cliente: se debe elegir al encargado
dependiendo del cliente. Se tomará en cuenta aquel empleado que
haya realizado mayor cantidad de proyectos con un cliente en
particular.
CAPITULO III _____________________________________________________________________________________________
69
5. Carga de trabajo: se elegirá al encargado, dependiendo del número
de proyectos que posea, el puntaje que se tenga según el tipo de
proyecto que se desee asignar y el departamento al que pertenece.
6. Default: en caso de no encontrar empleado alguno que cumpla con
las reglas anteriores, se asignará al personal encargado del proyecto
en forma manual.
En la figura 10, se planteó el caso de uso final de la herramienta a utilizar en
la empresa de telecomunicaciones Telefónica Movistar, lo cual permitió tener
una perspectiva general del proyecto.
CAPITULO III _____________________________________________________________________________________________
70
Figura 10: Caso de uso final del módulo Asig.Auto.Encargados
Fuente: Elaboración propia.
CAPITULO III _____________________________________________________________________________________________
71
En la figura anterior, se puede apreciar de forma detallada el caso de uso
“Generar Resultados”. Este caso es de suma importancia puesto que en él
se van a mostrar todos los procedimientos que el módulo es capaz de
realizar para la empresa. A continuación se explican los procesos que se
encuentran implicados:
III.2.4 Caso de uso “Generar resultados”
1. Procesar información: este caso se refiere a la interpretación de lo
que el experto, persona encargada por departamento, requiere de la
herramienta a utilizar.
2. Almacenar información: consiste en guardar toda la información
proveniente de los expertos para la elaboración de la herramienta, su
alcance y objetivos.
3. Generar tablas: la información se coloca en tablas de base de datos,
donde serán guardadas y consultadas cuando se necesiten.
4. Generar reportes: se pueden observar los resultados obtenidos,
mediante listas o reportes.
III.2.5 Análisis del sistema y limitaciones
La empresa Telefónica Movistar cuenta con una herramienta, el SIP+, que le
ha permitido optimizar el tiempo de sus empleados, de forma tal, que puedan
CAPITULO III _____________________________________________________________________________________________
72
ejecutar sus labores de forma rápida y precisa. No obstante, a la hora de
distribuir los proyectos, muchas veces no lo hace de forma equitativa y en
ciertas ocasiones se ha tenido que redistribuirlos porque no corresponde al
área laboral del empleado.
Por este motivo, algunas veces los clientes se llevaban una percepción poco
favorable de la empresa ya que el empleado es sobrecargado de proyectos y
el cliente no recibe el trato personalizado que se desea.
Por los motivos expuestos anteriormente, Telefónica se vio en la necesidad
de desarrollar una herramienta que lo hiciera de forma equitativa a través de
una serie de pautas, tales como: tipo de proyecto, línea de negocio (LOB),
región, carga de trabajo por cliente y la carga de trabajo del empleado; las
cuales se han estado haciendo mención a lo largo de este trabajo de grado.
III.2.6 ¿Cómo se podría definir el tipo de estudio metodológico?
El estudio de la metodología aplicada sería explorativo, ya que el modulo
Asig.Auto.Encargados, le es posible extender sus funciones, de tal forma que
pueda ser usado por los diferentes departamentos de la empresa Telefónica
Movistar, de acuerdo a las capacidades de cada empleado, los proyectos
que llegan a la empresa y a raíz de esto se ahorra tiempo (horas/hombre), lo
CAPITULO III _____________________________________________________________________________________________
73
que pondría equivaler a un trato mas personalizado con el cliente logrando
así satisfacer sus requerimientos de forma rápida y efectiva.
A lo largo de este trabajo de grado se ha venido hablando de algoritmos
inteligentes para poder realizar la herramienta a utilizar en la empresa
Telefónica Movistar, se pudo observar, que el algoritmo mas propicio para el
desarrollo de la misma son los llamados sistemas expertos; ya que con ellos
se entra en contacto directo con todas las personas involucradas y de esta
forma dar soluciones a los problemas que se puedan presentar.
Con esto en mente, se hace la siguiente pregunta:
III.2.7 ¿Qué sucede si se aplica el enfoque de sistemas expertos para el
desarrollo del módulo de Asig.Auto.Encargados?
Los sistemas expertos son intermediarios entre el experto humano, que
transmite sus conocimientos al sistema, y el usuario de dicho sistema, que lo
emplea para resolver los problemas que se le plantean con la competencia
de un especialista en la materia y que, además, puede adquirir una destreza
semejante a la del experto gracias a la observación del modo de actuar de la
máquina. Los sistemas expertos son, pues, simultáneamente, un sistema de
ejecución y un sistema de transmisión del conocimiento.
CAPITULO III _____________________________________________________________________________________________
74
En la figura 11, se puede apreciar la estructura básica de un sistema experto:
Experto Usuario
Figura 11. Estructura básica de un Sistema Experto
Fuente: Procesos de desarrollo RUP.
El primer paso, antes de desarrollar un sistema experto, es comprender
cómo se recibe la información y cómo se va transformando y utilizando
para llegar a la decisión final. Esta característica hace que el sistema
experto y su proceso de desarrollo sean completamente diferentes de
una empresa a otra. Las personas involucradas en este paso previo son
el ingeniero de desarrollo del sistema y los expertos en el tema que se
desea documentar.
CAPITULO III _____________________________________________________________________________________________
75
III.2.8 Adquisición de conocimiento
Muchas veces no es solamente un experto sino un grupo de ellos que se
encargan de desarrollar el sistema y de “vaciar” su conocimiento en la
base de datos. Existen muchas herramientas y métodos para obtener
este conocimiento entre las cuales está la entrevista, la observación y la
Elaboración de escenarios. A continuación se describe un método
sencillo para la adquisición de conocimiento:
1. Conducir una entrevista con el experto(s) para: sondear el
conocimiento que se va a adquirir, conocer la terminología, el
propósito del conocimiento y el sistema.
2. Crear un diagrama conceptual derivado de los resultados de la
entrevista y utilizarlo para generar preguntas que cumplan con los
propósitos del sistema.
3. Realizar otra entrevista, semi-estructurada, con el experto utilizando
las preguntas del paso 2.
4. Generar los conceptos, reglas, atributos, valores, relaciones que
van surgiendo de las entrevistas.
5. Representar estos elementos de la manera más apropiada (Texto,
diagramas, ilustraciones, hipertexto, anécdotas, etc.)
6. Presentar los resultados al experto y permitirle realizar cambios en
el conocimiento ya capturado.
CAPITULO III _____________________________________________________________________________________________
76
7. Consultar con otros expertos y realizar las modificaciones
apropiadas.
Una recomendación importante es que tanto el experto en el tema como el
encargado de desarrollar el sistema en la organización unan esfuerzos para
realizar esta fase.
III.2.9 Observación como técnica de adquisición de conocimiento
La observación es una técnica muy antigua, cuyos primeros aportes serian
imposible rastrear. A través de sus sentidos, el hombre capta la realidad que
lo rodea, que luego organiza intelectualmente. La observación puede
definirse como el uso sistemático de nuestros sentidos en la búsqueda de los
datos que necesitamos para resolver un problema de investigación. (Carlos
A. Sabino, op. Cit., p. 155)
La ventaja de la técnica de observación, es que coloca a la persona que la
esta ejecutando en contacto directo con los hechos, sin ninguna clase de
intermediarios, de esta forma se percibe la información tal como se da en la
naturaleza.
CAPITULO III _____________________________________________________________________________________________
77
III.3 Fase de Construcción
III.3.1 Descripción de los casos de uso
III.3.1.1 Establecer estudio
Caso de uso: Establecer estudio.
Actores: Experto.
Propósito: Provee la información necesaria para establecer las reglas
importantes de cada departamento.
Tipo: Primario esencial.
Descripción: El experto indica al encargado de administrar el sistema los
requerimientos de cada departamento, estos son “traducidos” y a su vez
colocados en la página donde serán manipulados por los usuarios.
Se puede apreciar el caso de uso “Establecer estudio” en la tabla 2:
CAPITULO III _____________________________________________________________________________________________
78
Curso normal de los eventos:
Tabla 2. Caso de uso “Establecer estudio”
Fuente: Elaboración propia
Acción del Actor Respuesta del Sistema 1) El experto indica los requerimientos de cada departamento.
2) Estos son traducidos en reglas y son visibles para los usuarios.
3) El experto puede pedir al encargado del sistema agregar o modificar las reglas.
4) El sistema valida y guarda en la base de datos.
CAPITULO III _____________________________________________________________________________________________
79
III.3.1.2 Administrar el sistema
Caso de uso: Administrar el sistema.
Actores: Administrador/usuario.
Propósito: Administrar y manipular la información dada por los expertos a
través de las entrevistas realizadas.
Tipo: Real.
Descripción: El administrador con la información dada por los expertos,
puede realizar el sistema. A partir de una serie de pasos, se entra al sistema
y se realiza la selección de reglas que se quiere que el sistema efectué, el
usuario los guarda y sale del sistema.
Se puede apreciar el caso de uso “Administrar el sistema” en la tabla 3:
CAPITULO III _____________________________________________________________________________________________
80
Curso normal de los eventos:
Tabla 3. Caso de uso “Administrar el sistema”
Fuente: Elaboración propia
Acción del Actor Respuesta del Sistema 1) El administrador/usuario ingresa a la página colocando el login y el password de forma correcta.
2) El sistema verifica que los datos estén correctos y que el usuario tenga permisos para entrar en los diferentes módulos del mismo.
3) Una vez realizada la verificación, el usuario podrá realizar las acciones asociadas a los diferentes procesos.
4) El usuario ingresa al Módulo y ejecuta la acción que crea conveniente.
5) El sistema valida, guarda en la base de datos la acción que el usuario haya realizado y ejecuta los cambios que se realizaron.
6) El usuario cierra sesión en el momento que termine su labor.
7) El sistema, en caso de no encontrar actividad, por medidas de seguridad cerrara sesión después de pasado algún tiempo
CAPITULO III _____________________________________________________________________________________________
81
III.3.1.3 Administrar reglas
Caso de uso: Administrar reglas.
Actores: Administrador/usuario, experto.
Propósito: Ingresar las reglas que se quiere que el sistema ejecute.
Tipo: Esencial primario
Descripción: El usuario ingresa al sistema donde encuentra el Módulo que
necesita, en el hay una serie de reglas, dadas por el experto, que el usuario
puede elegir, después de realizar esta acción guarda los cambios y cierra
sesión.
Se puede apreciar el caso de uso “Administrar reglas” en la tabla 4:
CAPITULO III _____________________________________________________________________________________________
82
Curso normal de los eventos:
Tabla 4. Caso de uso “Administrar reglas”
Fuente: Elaboración propia
Acción del Actor Respuesta del Sistema 1) El usuario ingresa su login y password y espera a que el sistema verifique sus datos.
2) El sistema verifica sus datos y permite que el usuario inicie sesión.
3) El usuario se dirige al Módulo donde se encuentran ubicado una serie de reglas, las cuales puede elegir, modificar o eliminar.
4) El sistema valida la acción decidida por el usuario, guarda los cambios que se hayan efectuado y verifica que estos se hayan ingresado de forma correcta
5) El usuario si lo desea cierra sesión.
CAPITULO III _____________________________________________________________________________________________
83
III.3.1.4 Generar resultados
Caso de uso: Generar resultados.
Actores: Administrador/usuario.
Propósito: Ejecuta la corrida de la herramienta para generar resultados.
Tipo: Esencial.
Descripción: Una vez que se le asignó al sistema las reglas determinadas
por los expertos, el usuario puede crear y/o editar los algoritmos
seleccionando las diferentes reglas disponibles y al final estos son guardados
en forma definitiva en la base de datos.
Se puede apreciar el caso de uso “Generar resultados” en la tabla 5:
CAPITULO III _____________________________________________________________________________________________
84
Curso normal de los eventos:
Tabla 5. Caso de uso “Generar resultados”
Fuente: Elaboración propia
Acción del Actor Respuesta del Sistema 1) El usuario pulsa el botón de Asig.Auto.Encargados
2) El sistema despliega la página con un listado de algoritmos por nombre, departamento, encargado y fecha de Elaboración.
3) El usuario puede ejecutar dos opciones en esta pagina: Editar un algoritmo existente o crear uno nuevo 4) El usuario elige la opción de editar un algoritmo existente.
4,1) El sistema despliega todas las opciones editables.
4,2) El usuario realiza los cambios que desee.
4,3) El sistema valida, edita y ejecuta los cambios.
4,4) El sistema muestra un mensaje de éxito en los cambios realizados.
4,5) El usuario vuelve a la pagina Asig.Auto.Encargados. 5) El usuario eligió el botón de nuevo.
5,1) El sistema despliega una serie de opciones que el usuario debe rellenar, en caso contrario el sistema muestra un mensaje de error.
5,2) El usuario rellena todas las opciones y guarda los cambios.
5,3) El sistema valida, guarda y ejecuta todos los cambios. Muestra un mensaje de éxito al realizar la acción de guardar.
5,4) El usuario vuelve al Módulo Asig.Auto.Encargados, donde se encuentra el listado actualizado.
CAPITULO III _____________________________________________________________________________________________
85
III.3.2 Casos de uso expandidos
III.3.2.1 Procesar información
Caso de uso: Procesar información.
Actores: Administrador/usuario.
Propósito: Ingresar información necesaria para la Elaboración de las reglas.
Tipo: Primario, Esencial.
Descripción: El administrador traduce lo que el experto necesita para que el
sistema sea capaz de leerlo.
Se puede apreciar el caso de uso expandido “Procesar información” en la
tabla 6:
Curso normal de los eventos:
Tabla 6. Caso de uso expandido “Procesar información”
Fuente: Elaboración propia
Acción del Actor Respuesta del Sistema 1) El usuario selecciona la información que considera necesaria para la Elaboración de las reglas. 2) El usuario ingresa la información al sistema.
3) El sistema valida que los datos sean ingresados correctamente y cumplan con los requisitos.
CAPITULO III _____________________________________________________________________________________________
86
III.3.2.2 Almacenar información
Caso de uso: Almacenar información.
Actores: Administrador/usuario.
Propósito: Guardar la información de los procesos realizados.
Tipo: Primario, Esencial.
Descripción: El usuario guarda toda la información que le dio el experto en
el sistema.
Se puede apreciar el caso de uso expandido “Almacenar información” en la
tabla 7:
Curso normal de los eventos:
Tabla 7. Caso de uso expandido “Almacenar información”
Fuente: Elaboración propia
Acción del Actor Respuesta del Sistema 1) el usuario decide si desea guardar o editar la información obtenida de los diferentes procesos. 2) El usuario presiona la opción de su gusto.
3) El sistema guarda los resultados en la base de datos.
CAPITULO III _____________________________________________________________________________________________
87
III.3.2.3 Generar tablas
Caso de uso: Generar tablas.
Actores: Administrador/usuario.
Propósito: Generar tablas en la base de datos.
Tipo: Primario, Esencial.
Descripción: La información se coloca en tablas de base de datos donde
serán accesadas por el sistema para mostrar la información.
Se puede apreciar el caso de uso expandido “Generar tablas” en la tabla 8:
Curso normal de los eventos:
Tabla 8. Caso de uso expandido “Generar tablas”
Fuente: Elaboración propia
Acción del Actor Respuesta del Sistema 1) El usuario genera la corrida de la información en la base de datos.
2) Esta corrida genera una secuencia que gracias a ella se lleva a cabo un orden en las claves del sistema.
3) El usuario actualiza las tablas en la base de datos, en caso de requerirse algún cambio.
CAPITULO III _____________________________________________________________________________________________
88
III.3.2.4 Generar reportes
Caso de uso: Generar reportes.
Actores: Administrador/usuario.
Propósito: Genera una lista con todos los datos que se necesitan.
Tipo: Esencial.
Descripción: El usuario una vez guardada la información puede ver los
resultados, por medio de reportes o listas, existentes.
Se puede apreciar el caso de uso expandido “Generar reportes” en la tabla 9:
Curso normal de los eventos:
Tabla 9. Caso de uso expandido “Generar reportes”
Fuente: Elaboración propia
Acción del Actor Respuesta del Sistema 1) El usuario aprieta el botón de nuevo o editar. 2) Realiza los cambios que desee y los guarda.
3) El sistema verifica que todos los datos estén correctos y los guarda en la base de datos.
4) El sistema muestra todos los algoritmos existentes por departamento.
CAPITULO III _____________________________________________________________________________________________
89
III.3.3 Modelado conceptual
Para una representación mas detallada de los requerimientos en el cual se
desarrolla el módulo, se realizo el modelo conceptual donde se capturan los
principales objetos y clases presentes en la aplicación y la forma en la cual
se relacionan.
Antes de definir el modelo de clases, es necesario definir el modelo
conceptual, el cual muestra los conceptos presentes en el dominio del
problema. Un concepto para este caso, en términos de la Programación
Orientada a Objetos, es un objeto del mundo real; es decir, es la
representación de cosas del mundo real y no de componentes del software.
En él no se definen operaciones (o métodos); en este modelo se pueden
mostrar los conceptos, los atributos de los conceptos (opcionalmente) y la
relación o asociación entre ellos. Informalmente podríamos decir, que un
concepto es una idea, cosa u objeto. Para descubrirlos debemos analizar los
sustantivos en las descripciones textuales del dominio del problema, es decir,
la descripción del sistema, de los requerimientos y de los casos de uso (ver
figura 12):
Referirse al apéndice B para observar el Modelo Lógico: Diagrama Entidad-Relación.
CAPITULO III _____________________________________________________________________________________________
90
Figura 12. Modelo Conceptual.
Fuente: Elaboración propia.
CAPITULO III _____________________________________________________________________________________________
91
III.3.4 Diagrama de clases
Nos muestra una vista de la aplicación en un determinado momento, es
decir, en un instante en el que el sistema está detenido. Las clases son la
plantilla de los objetos, y aquí podemos ver representados a estos con sus
atributos o características y su comportamiento o métodos, así como la
relación entre ellas (Ver figura 13)
CAPITULO III _____________________________________________________________________________________________
92
Figura 13. Diagrama de Clases
Fuente: Elaboración propia
Referirse al Apéndice C, para observar el diagrama de decisión.
CAPITULO III _____________________________________________________________________________________________
93
III.3.5 Desarrollo del módulo Asig.Auto.Encargados
Para el desarrollo del módulo se baso en el lenguaje de programación
dirigida a objetos PHP ya que es un potente lenguaje de script del lado del
servidor, que se utiliza principalmente para generar páginas de forma
dinámica, atacando de una forma sencilla y nativa a diferentes bases de
datos, aunque es tan potente que se utiliza para muchísimas cosas más.
PHP se puede conectar, a través de las extensiones, a diversos sistemas de
bases de datos y lenguajes en donde se utilizo Oracle.
Utilizando PHP se pueden realizar los siguientes procedimientos:
• Crear una página HTML con formulario
• Enviar el formulario a una página php, que muestre las variables
enviadas
• Guardar las variables enviadas en una sesión, mostrándolas en una
tercera página
• Crear el formulario con una plantilla HTML.
• Conectar a la base de datos usando cliente de (base de datos)
ORACLE, y presentar los resultados.
El desarrollo de la base de datos esta basada en ORACLE 8i, para la
definición y manipulación de datos, el cual posee una serie de
CAPITULO III _____________________________________________________________________________________________
94
características, tales como: comprobación de errores de forma automática,
así como su actualización y la capacidad para visualizar toa las relaciones
existentes.
La arquitectura del SIP+ cuenta con tres etapas o capas, las cuales se
describe a continuación:
• Capa de Datos: ORACLE 8i
• Capa de Reglas de Negocio: rutinas SQL, PHP, PERL.
• Capa de Interfaz con el Usuario: Servicio Intranet sobre la LAN
Telefónica Movistar desarrollada en PHP y servida por Apache.
La plataforma del Sistema se ubica de la siguiente forma:
• El servicio Apache con las rutinas de PHP y PERL corren en un
servidor SUN Ultra administrado por CCR (Centro de Control de
Red) Desarrollo.
• La instancia ORACLE Producción corre en el Servidor ORACLE de
CCR Remedy Producción. Es importante acotar que la base de
Datos del SIP+ conecta (insert, delete, update) a tablas de CCR
Remedy Producción y la idea de ubicar ambas instancias juntas
fue para evitar el overhead en el performance que supone las
CAPITULO III _____________________________________________________________________________________________
95
conexiones DB Link. Este sistema Remedy Ticket de falla, alberga
tablas de negocio, tales como: clientes, directorio de usuarios,
nodos y rutas usadas por el SIP+.
El desarrollo del módulo se realizó en forma escalar, la cual puede
colocársele nuevas funcionalidades, mediante una interfaz clara, sencilla y
precisa que permite que su desempeño hombre y maquina sea lo mas fácil
posible. La herramienta se presenta en forma de varios módulos que se
relacionan entre si para poder cumplir con los diferentes requerimientos.
III.4 Fase de Transición
III.4.1 Implantación del módulo Asig.Auto.Encargados
El propósito de esta fase es hacer circular del módulo en la comunidad de
usuarios y de esta forma detectar y ajustar todos los posibles errores que
puedan ser encontrados, así como también capacitar a todos los usuarios y
proveerles soporte técnico cuando sea necesario para ajustar el sistema. Se
verifica que la herramienta cumpla con los requerimientos suministrados por
las personas involucradas en el proyecto en el momento de su inicio.
CAPITULO III _____________________________________________________________________________________________
96
A través de las diferentes pruebas realizadas por los usuarios “pilotos” se
comprobó los procesos principales, donde se aceptó las funcionalidades del
sistema. De esta forma, se pudo comprobar que el usuario se sienta cómodo
con el uso de la herramienta, ya que esta permite que se maneje de forma
lógica.
Asig.Auto.Encargados (asignación automática de encargados) es el nombre
que se le dio al módulo capaz de presentar a los usuarios resultados de
forma eficiente los requerimientos que se han presentado a lo largo del
presente trabajo.
Para dar a conocer las ventajas que el módulo ofrece a Telefónica Movistar,
se presenta a continuación la interfaz grafica, explicando en las pantallas
más importantes información como: acceso al sistema, datos suministrados
al sistema por los expertos y los resultados.
III.4.2 Navegación en Asig.Auto.Encargados
Primero que todo, se debe de ingresar al sistema SIP+ por medio de un
nombre y clave; la persona que se encuentra registrada, introduce los datos
correctamente y el sistema verifica que éstos se encuentren bien, una vez
realizado esto el interesado ingresa (Ver figura 14):
CAPITULO III _____________________________________________________________________________________________
97
Figura 14. Pantalla de control de acceso al sistema.
Fuente: Elaborado por Iconos.
La ventana principal del módulo “Asig.Auto.Encargados”, permite agregar y
manipular los algoritmos que se deseen; se encuentra ubicado en el área
denominada por la empresa Adminlite este algoritmo es asociado a un
workflow. Se puede apreciar en la figura 15:
CAPITULO III _____________________________________________________________________________________________
98
Figura 15. Pantalla de construcción de Algoritmos, Asig.Auto.Encargados.
Fuente: Elaboración propia.
CAPITULO III _____________________________________________________________________________________________
99
Si el usuario desea agregar un nuevo algoritmo a la base de datos, en el cual
asigne los proyectos de acuerdo a las reglas expuestas anteriormente, pulsa
el botón de nuevo en donde se desplegó la pantalla que se muestra en la
figura 16:
Figura 16. Pantalla para agregar Algoritmos, Asig.Auto.Encargados.
Fuente: Elaboración propia.
CAPITULO III _____________________________________________________________________________________________
100
Si se desea agregar un nuevo algoritmo, el sistema le pedirá al usuario el
nombre del departamento al cual este será asociado, así como también al
empleado que se asignará por default en caso de no encontrar algún
encargado que concuerde con las reglas seleccionadas, es decir, se
asignará a la persona que se encuentre en esta ventana si no se cumplen las
reglas escogidas (Ver figura17).
Figura 17. Pantalla para agregar Empleado por Dpto. a los Algoritmos.
Fuente: Elaboración propia.
CAPITULO III _____________________________________________________________________________________________
101
Por motivos de seguridad, la pantalla no se despliega completamente hasta
que el usuario no guarde los datos que anteriormente colocó. Una vez
realizado esto, el sistema muestra la pantalla en su totalidad, revelando
varios botones y reglas que ayudarán a la asignación del personal por
departamento (Ver figura 18).
Figura 18. Pantalla para agregar Reglas a los Algoritmos, Asig.Auto.Encargados.
Fuente: Elaboración propia.
CAPITULO III _____________________________________________________________________________________________
102
En caso de no rellenar algún dato, el sistema anunciará un mensaje de error
de lo contrario dará un mensaje de éxito. Una vez realizadas todas las
modificaciones y pulsado el botón de volver, el sistema actualizará
automáticamente la base de datos listando los nuevos cambios que se
efectuaron.
Para poder apreciar lo que Asig.Auto.Encargados es capaz de realizar, el
usuario se dirige a la sección de procesos, donde aparecerá una serie de
pestañas, entre ellas se encuentra la de Workflow donde se podrá activar el
Módulo Asig.Auto.Encargados que contiene el algoritmo que se desee,
siempre y cuando se haya guardado previamente en la base de datos.
Se puede observar, como se realizan los procesos a través de la figura 19:
CAPITULO III _____________________________________________________________________________________________
103
Figura 19. Pantalla para activar el algoritmo.
Fuente: Elaborado por Iconos.
CAPITULO III _____________________________________________________________________________________________
104
La pantalla de la figura 20, muestra lo que sucede al modificar el estado del
Módulo Asig.Auto.Encargados, este puede estar activo, donde funciona, o
inactivo en caso contrario. También se selecciona el departamento al cual se
desea asociar.
Figura 20. Pantalla para seleccionar el Dpto. del algoritmo.
Fuente: Elaborado por Iconos.
CAPITULO III _____________________________________________________________________________________________
105
Se debe de tomar en cuenta que para cada proyecto, se cuenta con un valor
el cual va a formar parte de la carga que se le de al encargado de ejecutar
cada proyecto. En la figura 21, se puede observar una lista de proyectos con
su peso, servicio al cual está relacionado y el tipo de proyecto que se puede
asociar, así como también al departamento al cual pertenece.
Figura 21. Pantalla principal para agregar carga a cada proyecto.
Fuente: Elaboración propia.
CAPITULO III _____________________________________________________________________________________________
106
En la figura 22, se muestra el proceso que se realiza para asignarle un valor
a un tipo determinado de proyecto, departamento y servicio.
Figura 22. Pantalla para agregar carga a cada proyecto.
Fuente: Elaboración propia.
Referirse al Apéndice D, para poder apreciar todas las ventanas de
navegación.
CAPITULO III _____________________________________________________________________________________________
107
III.4.3 Validación del modulo Asig.Auto.Encargados
Por medio de la validación, se puede asegurar al usuario que el módulo
Asig.Auto.Encargados se encuentra en condiciones de operar en los
diferentes ambientes de desarrollo que posee la empresa.
El módulo Asig.Auto.Encargados posee una interfaz o diseño amigable que
permite al usuario entender de forma clara la operacionalidad y lógica del
mismo, gracias a esto se puede decir que se cumplió con uno de los
principales requisitos que propuso el usuario.
Para realizar su instalación, se probó en los tres ambientes de desarrollo que
posee la empresa, (Desarrollo, Demo y Producción), donde el usuario pudo
manejar la nueva funcionalidad y dar su opinión para así poder ajustar el
sistema y corregirlo. De forma tal que el módulo quede en funcionamiento y
no presente eventos negativos en su uso.
CAPITULO IV
CONCLUSIONES Y RECOMENDACIONES
La empresa de telecomunicaciones Telefónica Movistar cuenta con la
Gerencia de Acceso, que se encarga de la gestión de los recursos
necesarios que permiten el aprovisionamiento de los diferentes servicios
para clientes corporativos. Esta gerencia se apoya en una herramienta
llamada SIP+, la cual tiene la capacidad de diseñar caminos de trabajo
(WorkFlows) para los proyectos desarrollados.
A estos proyectos son asignados recursos de personas responsables de
todas las áreas involucradas de forma manual, con lo que en muchos casos
implicaba retrasos e imprecisiones en los mismos. Debido a esto, surgió la
necesidad de desarrollar un nuevo módulo, llamado Asig.Auto.Encargados,
que se encargara de realizar la asignación de proyectos al personal de forma
automática para tener una mejor distribución de los mismos y mejorar la
planificación en el empleo de estos recursos
En base a las necesidades expuestas por la empresa, se realizó un estudio
de las posibles formas de resolverlas; de tal manera, se pudo determinar que
la metodología mas propicia sería la de sistemas expertos, ya que tienen la
CAPITULO IV _____________________________________________________________________________________________
109
función de aportar soluciones a problemas, tal como las pudiese solventar un
ser humano.
Conjuntamente con los sistemas expertos, se utilizó la metodología RUP
(Rational Unified Process), ya que se basa en la elaboración de un conjunto
de pasos, de esta forma alcanzar el objetivo final, que es la producción del
módulo y así satisfacer las necesidades de los usuarios.
Para afrontar el desarrollo del módulo requerido como Trabajo Especial de
Grado, se pudo realizar las siguientes síntesis:
1. Se modificó el contenido de la base de datos para que cumpliera con los
nuevos requerimientos de los usuarios. Entre las modificaciones se pueden
citar las siguientes: se agregaron tablas y campos para satisfacer las nuevas
interacciones entre el nuevo módulo Asig.Auto.Encargados con el sistema de
uso cotidiano de la empresa: SIP+.
2. Se logró sintetizar los requerimientos que solicitaban los expertos de
cada departamento, en reglas para la asignación de proyectos al personal de
ingeniería. De esta forma enfocar las necesidades de gestión al cliente de
manera más rápida y eficiente.
CAPITULO IV _____________________________________________________________________________________________
110
3. Se diseñó el módulo de asignación de encargado de proyectos
(Asig.Auto.Encargado), esta diseñado de tal forma que sea amigable, fácil y
eficiente de usar, a la hora del ingreso de los datos necesarios para la
asignación de los algoritmos de cada departamento. Hay que tomar en
cuenta la importancia de ofrecerle al usuario un módulo que reúna todas las
funcionalidades necesarias para ayudar en el trabajo diario.
4. Se pudo observar que a medida que se desarrollaba el módulo y se
realizaba las pruebas necesarias para lanzarlo a los usuarios finales, al tener
los objetivos bien claros y especificados de forma escalable los resultados
obtenidos fueron muy favorables a la hora de aplicarse dicho módulo, de esta
forma aplicar el producto final (Asig.Auto.Encargados) en el sistema SIP+.
5. Se manejó un diseño orientado a objetos el cual permitió disminuir la
complejidad del problema y facilitó su uso, de esta forma dio una gran
flexibilidad tanto en construcción como en la navegación del mismo.
6. Al terminar el desarrollo del nuevo módulo, se realizo un estudio con el fin
de permitir nuevas aplicaciones al mismo para lograr que cada día sea más
útil y eficiente y de esta forma facilite el trabajo de los usuarios.
A continuación se presentan un conjunto de propuestas que se consideran
como recomendaciones finales, planteadas en base a ideas surgidas a
CAPITULO IV _____________________________________________________________________________________________
111
medida que se fue desarrollando este Trabajo Especial de Grado, que
ayudan a superar las limitaciones y a aumentar su alcance:
1. Se recomienda continuar con la misma metodología de trabajo y la
forma bajo la cual se estructuró el módulo, ya que provee las bases efectivas
para el re-uso a gran escala, esto se refiere a que puede continuar creciendo
dentro del sistema SIP+.
2. Es recomendable continuar con el uso de UML como lenguaje de
especificación, pero se debe seguir estudiando su empleo en los diferentes
desarrollos y mantener la especificación del mismo al día con las últimas
actualizaciones.
3. Se recomienda a la hora de realizar avances en el módulo nuevo,
emplear la metodología que se ha venido utilizando, RUP, para así llevar un
orden en el desarrollo del mismo.
CAPITULO V
REFERENCIAS BIBLIOGRÁFICAS
Alzate, Alfonso. (2004). Aproximación Difusa de Funciones Reales. En:
http://64.233.167.104/search?q=cache:6Sj3-
7KxEm0J:www.utp.edu.co/php/revistas/ScientiaEtTechnica/docsFTP/168582
65-268.pdf+regla+del+IF-THEN&hl=en. (Consultada, Noviembre 2004).
Booch, G., Rumbaugh J. y Jacobson, I. (2003). El Lenguaje Unificado De
Modelado (2* Edición). Editorial Addison Wesley.
Corzo, Yuliana. (2004). La Lógica Difusa. En:
http://personales.ya.com/casanchi/mat/difusa01.htm#04. (Consultada,
Noviembre 2004).
Dr. Andina de la Fuente, Diego. (2004). Tutorial de Redes Neuronales. En:
http://www.gc.ssr.upm.es/inves/neural/ann2/concepts/concepts.htm.
(Consultada, Noviembre 2004).
El desarrollo de sistemas de información empleando el lenguaje de modelado
unificado UML. El proceso Unificado de Modelado (RUP). En:
CAPITULO V _____________________________________________________________________________________________
113
http://www.monografias.com/trabajos16/lenguaje-modelado-
unificado/lenguaje-modelado-unificado.shtml#PROCESO. (Consultada, Julio
2005)
ingenieroseninformatica.org. (2004). Introducción a los Sistemas Expertos.
En: http://ingenieroseninformatica.org/recursos/tutoriales/sist_exp/cap2.php.
(Consultada, Noviembre 2004).
La Nueva Metodología. (2003). ¿Es RUP un método ágil?. En:
http://www.programacionextrema.org/articulos/newMethodology.es.html#tth_s
Ec5.9. (Consultada, Julio 2005).
LOGAN – INTELIGENCIA. El concepto de la inteligencia artificial. En:
http://iartificial.tripod.com.co/ia.html. (Consultada, Junio 2005)
Méndez A. Carlos E. (1995). Metodología: Guía para elaborar diseños de
investigación en ciencias económicas, contables y administrativas (2*
Edición). Editorial McGraw-HILL.
Metodologías De Desarrollo De Software. (2004. Rational Unified Process
(RUP). En: http://64.233.187.104/search?q=cache:-
X51Ojf006kJ:www.willydev.net/descargas/cualmetodologia.pdf+como+utilizar
+RUP&hl=es. (Consultada, Julio 2005).
CAPITULO V _____________________________________________________________________________________________
114
PROCESO UNIFICADO RATIONAL. En:
http://www.vlaredo.galeon.com/index2.htm. (Consultada, Julio 2005).
Programación de Sesiones. (2001). La Lógica Computacional. En:
http://w3.mor.itesm.mx/~logica/log9808/introduccion.html. (Consultada,
Noviembre 2004).
Rivas Echeverria, Francklin. (2004) Algoritmos Inteligentes. En:
http://www.ing.ula.ve/materias/algor_inteligentes/. (Consultada, Noviembre
2004).
Russel, S. y Norvig, P. (1995). Artificial Intelligence A Modern Approach.
Editorial Prentice Hall.
Tutorial de UML. En: http://www.dcc.uchile.cl/~psalinas/uml/introduccion.html.
(Consultada, Enero 2005).
Unified Modeling Language. En: http://www.creangel.com/uml/. (Consultada,
Enero 2005).
Zerpa Morloy, Levis. (2001). Fundamentos lógicos de las redes neurales
artificiales. Editorial Gaudy Venezuela Contreras Gómez.
APÉNDICE A _____________________________________________________________________________________________
117
METOLOGÍA DE LOS SISTEMAS EXPERTOS
Para la elaboración de la nueva herramienta, se basó en los sistemas
expertos donde se propone la siguiente metodología de ejecución:
Metodología para el desarrollo de sistemas expertos
Etapa 1: Análisis y descripción del problema.
Fase a.- Descripción General del Problema:
a.1 - Familiarización con el proceso sobre el cual se desea
realizar el Sistema Experto.
a.2 - Estudio de los ambientes computacionales donde se
encuentran los datos a ser utilizados.
a.3 - Definición detallada del problema que motiva el desarrollo
del Sistema Experto.
Fase b.- Análisis de Factibilidad para el desarrollo del Sistema
Experto:
b.1 - La tarea a desarrollar requiere del conocimiento manejado
por un experto.
b.2 - Disponibilidad del experto o equipo de expertos.
APÉNDICE A _____________________________________________________________________________________________
118
b.3 - La experticia es requerida en varios lugares
simultáneamente.
b.4 - El sistema requiere del manejo de incertidumbre y
aplicación de juicios personales.
b.5 - Existe un grupo potencial de usuarios.
b.6 - Se dispone del tiempo para desarrollar el Sistema
Experto.
Fase c.- Análisis de datos: Verificación de la ubicación y forma de
representación de los datos a ser manejados por el sistema experto,
considerando el tipo de base de datos (industrial, relacional, orientada
a objeto, etc.), plataforma computacional (Windows, DOS, UNIX, VMS,
etc.) entre otras variables
Fase d.- Elección de la fuente de conocimiento: Es necesario contar
con un experto o un grupo de ellos que estén dispuestos a colaborar
con el proyecto. Los expertos deben ser reconocidos como tales por el
grupo de usuarios.
Etapa 2: Especificación de requerimientos.
Fase a.- Determinación de los requerimientos de información. En esta
fase se especifica la información que debe producir el Sistema Experto
APÉNDICE A _____________________________________________________________________________________________
119
y sus atributos tales como: el formato de presentación, la frecuencia
de salida, sus usuarios directos y su interconexión con otros
programas.
Fase b.- Determinación de los requerimientos funcionales: consiste en
la definición de las funciones generales que debe satisfacer el Sistema
Experto.
Fase c.- Determinación de los requerimientos de entrada de datos:
c.1 - Selección de las posibles entradas al Sistema Experto.
c.2 - Identificación de las fuentes de datos.
c.3 - Especificación de los procesos de adquisición de datos.
c.4 - Especificación de los procesos de generación de
parámetros.
c.5 - Caracterización de la interoperabilidad entre las bases de
datos que se requieren en la implantación.
Fase d.- Definición de los requerimientos de hardware y software para
la implantación del Sistema Experto:
d.1 - Especificación de la plataforma de hardware que se
utilizará para el desarrollo y operación del Sistema Experto.
APÉNDICE A _____________________________________________________________________________________________
120
d.2 - Determinación, análisis y selección de las herramientas de
software disponibles en el mercado para el desarrollo de
Sistemas Expertos.
Fase e.- Estimación del perfil de los usuarios finales del Sistema
Experto.
Fase f.- Verificación de los requerimientos con el usuario.
Etapa 3: Análisis de costos, tiempo y recursos.
Fase a.- Elaboración del plan de actividades de desarrollo e
implantación.
Fase b.- Estimación del tiempo requerido para el desarrollo del
Sistema Experto.
Fase c.- Estimación de los recursos computacionales (hardware-
software) requeridos para el desarrollo del Sistema Experto.
Fase d.- Estimación de los costos de desarrollo.
APÉNDICE A _____________________________________________________________________________________________
121
Etapa 4: Ingeniería del conocimiento.
Fase a.- Adquisición del Conocimiento: en esta fase el Ingeniero del
Conocimiento interactúa con el experto para obtener la información
sobre la solución de los problemas, así como las estrategias utilizadas
para la obtención de cada solución.
Fase b.- Estructuración del Conocimiento: al llegar a esta fase, el
Ingeniero del Conocimiento debe llevar a una base de conocimiento la
información proporcionada por el experto. El conocimiento puede ser
de carácter superficial o profundo dependiendo de la estructura interna
y de las interacciones entre sus componentes.
Etapa 5: Diseño preliminar del sistema experto.
Fase a.- Diseño preliminar de la arquitectura del sistema experto.
Fase b.- Selección de la herramienta computacional de acuerdo a los
requerimientos surgidos en la etapa de Ingeniería del Conocimiento.
Fase c.- Diseño preliminar de procesos de adquisición y
almacenamiento de datos.
APÉNDICE A _____________________________________________________________________________________________
122
Fase d.- Diseño preliminar de procesos de interconexión.
d.1 - Integración interna.
d.2 - Integración externa.
d.3 - Selección de software auxiliar.
Fase e.- Verificación del diseño preliminar del sistema experto.
Etapa 6: Desarrollo e implantación del sistema experto.
Fase a.- Construcción del prototipo.
Fase b.- Validación del prototipo.
Fase c.- Construcción de modelo operacional
Fase d.- Prueba y depuración.
Fase e.-Mantenimiento y actualización.
Top Related