Ruiz Oscar 004 R924

UNIVERSIDAD DE ORIENTE
NCLEO DE MONAGAS
INGENIERA DE SISTEMAS
COMISIN DE TRABAJOS DE GRADO
MATURN / MONAGAS / VENEZUELA
INGENIERA DE REQUISITOS APLICADO A LOS PROCESOS DE

INSTALACIN Y REPARACIN DE AVERAS, REALIZADOS POR
PLANTA EXTERNA PARA LA UNIDAD DE CONMUTACIN (CX) DE LA
CENTRAL DIGITAL MATURN-CENTRO, C.A.N.T.V. ESTADO MONAGAS.
Propuesta de Trabajo de Grado, Modalidad Pasanta, presentado como requisito

parcial para optar al ttulo de Ingeniero de Sistemas.
Br. Oscar Josu Ruiz

C.I.:18.754.110
Asesor Acadmico: Ing. Yhuanailys Nez
C.I.: 16.699.296
Asesor Laboral: Ing. Wendy J. Rondn R.
C.I.: 13.767.220
Maturn, Octubre de 2012
ACTA DE APROBACIN
DEDICATORIA
Con cario dedico este logro a mi Madre,
principal merecedora de tal triunfo,
sin ella hubiese sido ms arduo el camino y ms inseguro mi andar.
A mis hermanos, por ser un apoyo incondicional.
A todos mis familiares que me han tendido la mano,
especialmente a mi abuela Cristina.
Y por supuesto a mis amigos, que hicieron, entre risas y bromas,
ms llevaderas las cargas.
AGRADECIMIENTOS
Quiero agradecer en primer lugar, entre la certeza y la duda, capaces de corroer
hasta la ms firme de las convicciones del corazn del hombre, a esa fuerza superior
que no vemos, pero que nos da el aliento que necesitamos justo en el momento que
creemos todo perdido, Dios.
A mi madre, que ha dado ms de lo que ha tenido por ver a sus hijos transitar
por el camino correcto. Ella que ha sabido ensearme que significa ser madre y padre
para un hijo sin dejar de ser ninguno de los dos en ningn momento. Quien me ha
acompaado siempre y a quien le debo mi vida y muchsimas noches en vela
cuidando mi sueo. Muchsimas gracias.
A mis hermanos por ser parte de mi vida y de todo este logro, gracias por
acompaarme siempre y ayudarme en todo.
A mi abuela Cristina, un ser excepcional y grandioso, sinnimo de lucha y
perseverancia, una mujer virtuosa, ejemplo de constancia y amor. Quien cri a sus
hijos y nietos con un esfuerzo que se alz entre valores, principios y humildad. Me
siento dichoso de haber sido parte de eso. Siempre dijiste que estudiara y le ehara
pichn, y aqu estoy. Esto tambin es para ti. Y aunque no ya no te encuentres
fsicamente con nosotros, jams sers olvidada. De igual manera le agradezco de
forma especial a mis tios: Rmulo, Moraima, Zulay, Arlex, gracias por su ayuda
oportuna y por estar siempre atentos y pendientes de m.
A mi prima y ta Yubi, tengo muchsimas cosas que agradecerte, de vedad
muchas gracias por estar ah ayudndome cuando lo necesit y por saber que puedo
contar contigo.
A la Universidad de Oriente, gracias por darles la oportunidad a todos aquellos
jvenes que, como yo, una vez tocaron tus puertas en busca de nuevos caminos
rumbo al xito. Por siempre udista de corazn. Gracias a todos los profesores que a
lo largo de todo este tiempo me han impartido conocimientos, ayudndome a crecer
acadmica y personalmente, grandes seres humanos, excelentes todos.
Se hace oportuno entonces mencionar al profesor Jess Chaparro, quien

siempre est dispuesto a atender y a dar respuestas, con esmero y dedicacin, a las
dudas e interrogantes de los estudiantes, aun cuando no sea l su asesor acadmico,
un gesto que sin duda alguna merece ser reconocido.
De igual manera quiero agradecerle a mis amigos de la universidad: Liza, Joha
y Mechita, que ms que un grupo de estudio, fuimos y somos un grupo de amigos que
se forjo en el camino de una carrera universitaria pero que estoy seguro que perdurara
ms que eso. Gracias a mi amiga Gladys por estar conmigo todo este tiempo desde el
primer semestre, gracias por tu amistad, eres como una hermana para m, te quiero
mucho y te deseo todo lo mejor. Pues me alegra ver como cada uno de nosotros
vamos obteniendo los frutos de tanto esfuerzo.
A ti rosita, eres de las personas a quien ms tengo que agradecer. Gracias por tu
amistad y por tu ayuda. Gracias por los buenos momentos. No puedo ms que
desearte el xito que mereces porque solo los dos somos los testigos del esfuerzo y la
constancia del otro para llegar hasta aqu. Te deseo xito, porque suerte es azar.
Gracias por todo.
A la empresa telefnica C.A.N.T.V. por brindarnos la oportunidad de realizar mi
trabajo de grado en modalidad pasanta dentro de sus puertas junto a mis compaeros
Maholi y Jos, grandes experiencias vividas en ese transcurso de tiempo.
Quiero agradecer a Yolis Torrealba y a todo el personal tcnico, de limpieza y
de vigilancia que labora en la central digital, excelentes personas todos. As mismo
tengo que aprovechar la oportunidad de extender mis agradecimientos de forma muy
especial al seor Parra, tcnico de C.A.N.T.V., por aportar ideas que proponen
soluciones, gracias por darme el punto de partida para desarrollar este tema y por ser
tan atento con nosotros los pasantes, esmerndose en transmitir sus conocimientos, y
por dedicar su tiempo a nosotros a pesar de sus ocupaciones y responsabilidades.
Al supervisor de la central digital Maturn-centro, Pedro Rodrguez, por su
ayuda y cooperacin en todo lo que pudiese necesitar.
A mi asesora laboral Ing. Wendy Rondn por sus constantes instrucciones y
enseanzas. Por su incondicional disposicin a ayudarme y aconsejarme, sin duda
alguna: un ejemplo a seguir. Gracias por todo su apoyo.
Igualmente quiero agradecer a mi profesora y asesora acadmica Ing.
Yhuanailys Nez por toda su paciencia y dedicacin, gracias por guiarme en la
elaboracin de este proyecto tan importante, por su apoyo constante y su atencin.
Aprecio mucho todo sus consejos, su orientacin y los conocimientos impartidos.
Finalmente quiero agradecerles a todas aquellas personas que de una forma u
otra me apoyaron y colaboraron conmigo. Aunque no pueda colocar los nombres de
todos, les agradezco enormemente su ayuda.
Muchas Gracias!
Oscar Josu Ruiz
UNIVERSIDAD DE ORIENTE
NCLEO DE MONAGAS
INGENIERA DE SISTEMAS
COMISIN DE TRABAJOS DE GRADO

MATURN / MONAGAS / VENEZUELA
INGENIERA DE REQUISITOS APLICADO A LOS PROCESOS DE
INSTALACIN Y REPARACIN DE AVERAS, REALIZADOS POR
PLANTA EXTERNA PARA LA UNIDAD DE CONMUTACIN (CX) DE LA
CENTRAL DIGITAL MATURN-CENTRO, C.A.N.T.V. ESTADO MONAGAS.
Lnea de investigacin: Sistemas de Informacin Transaccionales y Datawarehouse.
Autor: Oscar Josu Ruiz C.I: 19.078.215
Tutor: Ing. Yhuanailys Nez C.I.: 16.699.296
Fecha: Octubre de 2012
RESUMEN
El objetivo de este trabajo de grado consiste en el desarrollo de los procesos tcnicos
de anlisis propuestos por la metodologa Gray Watch, los cuales comprenden el
modelado del negocio y el de ingeniera de requisitos. Este ltimo, orientado a la
especificacin de los requisitos que debe satisfacer el sistema empresarial propuesto
para la gestin de informacin en los procesos de instalacin y reparacin de averas,
realizado por planta externa para la unidad de conmutacin (CX) de la central digital
Maturn-Centro. Esta aplicacin se plantea para ser incorporada a uno de los
procesos vitales de la compaa, permitiendo gestionar el acceso y manipulacin de
datos mediante tecnologas de informacin, garantizando elevados ndices de
rendimiento a nivel de personal y de procesos. La investigacin es de tipo proyectiva,
de nivel comprensivo y de diseo de fuentes mixtas. Fueron utilizadas para la
recoleccin de datos la revisin documental, la entrevista y la observacin, siendo
estudiadas mediante la tcnica de anlisis de contenido. El patrn de trabajo fue el
propuesto por el mtodo Watch en conjunto con el Lenguaje Unificado de Modelado
(UML). En general, esta investigacin plasma la solucin basada en la construccin
de un sistema desarrollado bajo ambiente web al que los empleados de planta externa
puedan acceder desde zonas forneas, y como base a esta necesidad, todo el
fundamento de ingeniera que sustenta dicha propuesta.
Palabras claves: Ingeniera de requisitos, Gray Watch, Aplicacin Empresarial, Cantv.
INDICE GENERAL
ACTA DE APROBACIN............................................................................................ii
DEDICATORIA...........................................................................................................iii
AGRADECIMIENTOS................................................................................................iv
RESUMEN..................................................................................................................vii
INDICE GENERAL...................................................................................................viii
LISTA DE FIGURAS...................................................................................................xi
LISTA DE CUADROS...............................................................................................xiii
LISTA DE DIAGRAMAS.........................................................................................xvii
INTRODUCCIN.........................................................................................................1
CAPTULO I.................................................................................................................5
CONTEXTO ORGANIZACIONAL.............................................................................5
1.1 C.A.N.T.V..........................................................................................................5
1.2 Resea Histrica................................................................................................6
1.2.1
El inicio de la era del cobre (1930-1952)................................................7
1.2.2
La primera nacionalizacin (1953-1991)................................................9
1.2.3
De Compaa de Telfonos a Corporacin de Telecomunicaciones
(1991-2007)..........................................................................................................13
1.2.4
C.A.N.T.V. hoy......................................................................................16
1.3 Visin...............................................................................................................18
1.4 Misin..............................................................................................................18
1.5 Objetivos de la Organizacin...........................................................................18
1.6 Valores.............................................................................................................20
1.7 Estructura Organizativa...................................................................................25
1.8 Estructura del Departamento...........................................................................26
1.9 Unidad de Conmutacin (CX).........................................................................27
1.9.1
Objetivos del Departamento de Conmutacin.......................................28
1.9.2
Funciones del Departamento de Conmutacin......................................28
CAPTULO II..............................................................................................................29
EL PROBLEMA Y SUS GENERALIDADES............................................................29
2.1 Planteamiento del Problema............................................................................29
2.2 Objetivos de la Investigacin...........................................................................34
2.2.1
Objetivo General....................................................................................34
2.2.2
Objetivos Especficos............................................................................34
2.3 Justificacin de la Investigacin......................................................................35
2.4 Alcance de la Investigacin.............................................................................37
CAPTULO III............................................................................................................38
MARCO REFERENCIAL..........................................................................................38
3.1 Antecedentes de la Investigacin.....................................................................38
3.2 Bases Tericas..................................................................................................40
3.2.1
El Software............................................................................................40
3.2.2
Importancia del Software.......................................................................41
3.2.3
Sistemas de Informacin.......................................................................42
3.2.4
Sistemas de Procesamiento de Transacciones.......................................45
3.2.5
Metodologa Gray Watch.......................................................................46
3.2.5.1 Objetivos del Mtodo Watch..............................................................47
3.2.5.2 Caractersticas del Mtodo Watch......................................................47
3.2.5.3 Estructura del Mtodo Watch.............................................................51
3.2.5.4 Modelo del Dominio de la Aplicacin...............................................59
3.2.5.5 Ingeniera de Requisitos.....................................................................67
10
3.2.6
Cadena de Valor de Porter......................................................................74
3.2.7
Lenguaje de Modelado Unificado (UML).............................................75
3.2.7.1 Diagramas de UML............................................................................76
3.2.7.1.1 Diagramas Estructurales...............................................................77
3.2.7.1.2 Diagramas de Comportamiento....................................................80
3.2.8
Internet...................................................................................................88
3.2.9
Web........................................................................................................89
3.2.10 Aplicaciones Web..................................................................................89
3.2.11 Herramientas Utilizadas........................................................................90
3.2.11.1 Adobe Dreamweaver CS6..............................................................90
3.2.11.2 Adobe Fireworks............................................................................92
3.2.11.3 Microsoft Office Project 2007........................................................92
3.2.11.4 SmartDraw......................................................................................93
3.3 Bases Legales...................................................................................................94
3.3.1
Constitucin de la Repblica Bolivariana de Venezuela (1999):..........94
3.3.2
Decreto 3.390: publicado en la gaceta oficial N 38.095 de fecha
28/12/2004............................................................................................................94
3.3.3
Decreto N 825: publicado en Gaceta Oficial de la Repblica
Bolivariana de Venezuela de fecha 22/05/2000...................................................95
3.4 Definicin de Trminos...................................................................................96
CAPTULO IV..........................................................................................................101
MARCO METODOLGICO...................................................................................101
4.1 Tipo y Nivel de la Investigacin....................................................................101
4.2 Diseo de la Investigacin.............................................................................102
4.3 Poblacin y Muestra......................................................................................103
4.4 Tcnicas e Instrumentos de Recoleccin de Datos........................................104
4.5 Tcnicas de Anlisis de Datos.......................................................................105
4.6 Diseo Operativo...........................................................................................106
4.7 Cuadro Operativo...........................................................................................110
CAPTULO V............................................................................................................113
RESULTADOS..........................................................................................................113
5.1 Etapa I: Estudio de la Situacin Actual..........................................................113
5.2 Etapa II: Modelado de Negocio.....................................................................156
5.3 Etapa III: Ingeniera de Requisitos................................................................222
5.4 Prototipo de la Aplicacin.............................................................................305
5.5 Anlisis Costo-Beneficio...............................................................................314
5.5.1
Costos..................................................................................................314
5.5.2
Beneficios............................................................................................317
CONCLUSIONES.....................................................................................................320
RECOMENDACIONES...........................................................................................322
BIBLIOGRAFA.......................................................................................................323
ANEXOS...................................................................................................................328
HOJAS METADATOS..............................................................................................333
11
LISTA DE FIGURAS
Figura 1. Organigrama general de C.A.N.T.V.............................................................25
Figura 2. Organigrama de Gerencia Gral. Tecnologa y Operaciones.........................26
Figura 3. Componentes del Mtodo Watch.................................................................51
Figura 4. Principales tipos de productos del Mtodo Gray Watch..............................52
Figura 5. Clasificacin de los Actores.........................................................................53
Figura 6. Procesos del Mtodo Watch. Fuente: Jons Montilva C. y Judith Barrios A.
(2008)..........................................................................................................54
12
Figura 7. Productos del Mtodo Watch. Fuente: Jons Montilva C. y Judith Barrios A.
(2008)..........................................................................................................55
Figura 8. Estructura del Modelo de Procesos..............................................................58
Figura 9. Productos asociados al Modelo de Negocios...............................................60
Figura 10. Productos asociados la Ingeniera de Requisitos.......................................69
Figura 11. Representacin de la Cadena de Valor de Porter........................................75
Figura 12. Representacin UML de una Clase............................................................77
Figura 13. Modelo de Procesos. Fuente: Jons Montilva C. y Judith Barrios A. (2008)
...................................................................................................................130
Figura 14. Tipos de productos principales del mtodo Watch...................................132
Figura 15. Caractersticas de la Calidad segn la ISO/IEC 9126..............................137
Figura 16. Plan de Gestin de Tiempos del Proyecto................................................143
Figura 17. Modelo de Jerarqua de Sistema de la Gerencia Red Estado Monagas.. .159
Figura 18. Cadena de Valor de la Unidad de Conmutacin (CX).............................163
Figura 19. Modelo de Reglas del Negocio................................................................201
Figura 20. Integracin de los Sub Modelos...............................................................221
Figura 21. Subprocesos del proceso Ingeniera de Requisitos..................................225
Figura 22. Jerarqua de Procesos del Descubrimiento de Requisitos........................226
Figura 23. Jerarqua de procesos del Anlisis de Requisitos.....................................262
Figura 24. Calidad y Medicin de ISO. Fuente: Coral Calero, Ismael Caballero, M
ngeles Moraga, Manuel Serrano (2008/2009).....................................276
Figura 25. Interfaz Validar Usuario...........................................................................306
Figura 26. Interfaz Men Usuario Administrador.....................................................306
Figura 27. Interfaz Men Usuario Estndar...............................................................307
Figura 28. Interfaz Consultar Abonado.....................................................................307
Figura 29. Interfaz Consultar Abonado. Respuesta de Bsqueda ........................308
Figura 30. Interfaz Sub-men Administrar Usuario..................................................308
Figura 31. Interfaz Registro de Nuevo Usuario.........................................................309
Figura 32. Interfaz Seleccin de Usuario a Modificar/Inhabilitar.............................309
Figura 33. Interfaz Modificar Datos de Usuario........................................................310
Figura 34. Interfaz Datos de Usuario Modificado.....................................................310
Figura 35. Interfaz Seleccin de Usuario a Eliminar.................................................311
Figura 36. Interfaz Bsqueda de Abonado a Actualizar............................................311
Figura 37. Interfaz de Actualizacin de Informacin Tcnica del Abonado.............312
Figura 38. Interfaz Informacin Tcnica de Abonado Actualizada...........................312
Figura 39. Interfaz Consulta de Registros.................................................................313
Figura 40. Interfaz Bsqueda de Registros Filtrados................................................313
13
LISTA DE CUADROS
Cuadro 1. Descripcin de los Subprocesos del Proceso Modelo de Objetivos...........62
Cuadro 2. Descripcin de los Subprocesos del Proceso Modelado de Procesos del
Negocio.......................................................................................................63
Cuadro 3. Descripcin de los Subprocesos del Proceso Modelado de Objetos del
Negocio.......................................................................................................64
Cuadro 4. Descripcin de los Subprocesos del Proceso Modelado de Reglas del
Negocio.......................................................................................................65
Cuadro 5. Descripcin de los Subprocesos del Proceso Modelado de Actores del
Negocio.......................................................................................................65
14
Cuadro 6. Descripcin de los Subprocesos del Proceso Modelado de Eventos del

Negocio.......................................................................................................66
Cuadro 7. Descripcin del Subproceso Descubrimiento de Requisitos......................70
Cuadro 8. Descripcin del Subproceso Anlisis de Requisitos...................................71
Cuadro 9. Descripcin del Subproceso Especificacin de Requisitos........................72
Cuadro 10. Descripcin del Subproceso Validacin de Requisitos.............................72
Cuadro 11. Descripcin del Subproceso Gestin de Requisitos..................................73
Cuadro 12. Relaciones entre Clases............................................................................78
Cuadro 13. Elementos de Diagrama de Despliegue....................................................80
Cuadro 14. Elementos de Diagrama de Actividades...................................................81
Cuadro 15. Elementos de Diagrama de Casos de Uso................................................82
Cuadro 16. Elementos de Diagrama de Secuencia......................................................83
Cuadro 17. Simbologa de Diagrama de Estados........................................................85
Cuadro 18. Representacin de Diagrama de Estados en base a las Actividades.........87
Cuadro 19. Cuadro Operativo....................................................................................110
Cuadro 20. Interesados del Proyecto.........................................................................125
Cuadro 21. Relacin Proceso-Productos...................................................................131
Cuadro 22. Matriz de Evaluacin de Riesgo.............................................................145
Cuadro 23. Riesgo N 1.............................................................................................147
Cuadro 24. Riesgo N 2.............................................................................................147
Cuadro 25. Riesgo N 3.............................................................................................148
Cuadro 26. Riesgo N 4.............................................................................................148
Cuadro 27. Riesgo N 5.............................................................................................149
Cuadro 28. Riesgo N 6.............................................................................................149
Cuadro 29. Riesgo N 7.............................................................................................150
Cuadro 30. Riesgo N 8.............................................................................................150
Cuadro 31. Riesgo N 9.............................................................................................151
Cuadro 32. Riesgo N 10...........................................................................................151
Cuadro 33. Riesgo N 11...........................................................................................152
Cuadro 34. Riesgo N 12...........................................................................................152
Cuadro 35. Riesgo N 13...........................................................................................153
Cuadro 36. Riesgo N 14...........................................................................................153
Cuadro 37. Riesgo N 15...........................................................................................154
Cuadro 38. Matriz Procesos vs Objetos.....................................................................198
Cuadro 39. Matriz Proceso/Actividad/Actor.............................................................203
Cuadro 40. Matriz Procesos vs Eventos....................................................................219
Cuadro 41. Reglas de Negocio..................................................................................229
Cuadro 42. Actores del Sistema.................................................................................231
Cuadro 43. Tipo de Usuarios del Sistema..................................................................233
Cuadro 44. Recoleccin de Requerimientos Iniciales...............................................233
Cuadro 45. Planilla Volere.........................................................................................237
Cuadro 46. Requisito Funcional N 1........................................................................238
15

Cuadro 55. Requisito Funcional N 10......................................................................241
Cuadro 84. Requisito No Funcional N 1..................................................................251
16

Cuadro 93. Requisito No Funcional N 10................................................................254
Cuadro 100. Requisito No Funcional N 17..............................................................256
Cuadro 108. Clasificacin de Requisitos Funcionales..............................................263
Cuadro 109. Clasificacin de Requisitos No Funcionales........................................264
Cuadro 110. Requisitos Funcionales del Sistema......................................................265
Cuadro 111. Requisitos No Funcionales....................................................................271
Cuadro 112. Medicin de la Adecuidad....................................................................278
Cuadro 113. Medicin de la Seguridad.....................................................................278
Cuadro 114. Medicin de la Entendibilidad..............................................................280
Cuadro 115. Medicin de la Operabilidad.................................................................280
Cuadro 116. Medicin de la Madurez.......................................................................281
Cuadro 117. Medicin de la Tolerancia a Fallos.......................................................281
Cuadro 118. Medicin de la Recuperacin................................................................282
Cuadro 119. Medicin del Comportamiento en el Tiempo.......................................283
Cuadro 120. Medicin de la Analizibilidad...............................................................284
Cuadro 121. Medicin de la Cambiabilidad..............................................................284
Cuadro 122. Medicin de la Estabilidad...................................................................284
Cuadro 123. Medicin de la Conformidad de Transportabilidad..............................285
Cuadro 124. Costos de Materiales. Fuente: autor 2012.............................................316
17
LISTA DE DIAGRAMAS
Diagrama 1. Diagrama de Objetivos.........................................................................161
Diagrama 2. Diagrama de Jerarqua de Procesos de la Unidad de Conmutacin.....165
Diagrama 3. Diagrama de Proceso: Instalacin ABA...............................................166
Diagrama 4. Diagrama de Actividades: Instalacin ABA.........................................167
Diagrama 5. Diagrama de Proceso: Instalaciones Comerciales................................168
Diagrama 6. Diagrama de Actividades: Instalaciones Comerciales..........................169
Diagrama 7. Diagrama de Proceso: Instalaciones Residenciales..............................170
Diagrama 8. Diagrama de Actividades: Instalaciones Residenciales........................171
Diagrama 9. Diagrama de Proceso: Instalaciones Voz y Dato..................................172
Diagrama 10. Diagrama de Actividades: Instalaciones Voz y Dato..........................173
18
Diagrama 11. Diagrama de Proceso: Reinstalacin del Servicio..............................174

Diagrama 12. Diagrama de Actividades: Reinstalacin del Servicio........................175
Diagrama 13. Diagrama de Proceso: Instalacin de Servicios Especiales................176
Diagrama 14. Diagrama de Actividades: Instalacin de Servicios Especiales..........177
Diagrama 15. Diagrama de Proceso: Instalacin Telfonos Pblicos.......................178
Diagrama 16. Diagrama de Actividades: Instalacin Telfonos Pblicos.................179
Diagrama 17. Diagrama de Proceso: Retiro de Lazo................................................180
Diagrama 18. Diagrama de Actividades: Retiro de Lazo..........................................181
Diagrama 19. Diagrama de Proceso: Retiro por Pago...............................................182
Diagrama 20. Diagrama de Actividades: Retiro por Pago.........................................183
Diagrama 21. Diagrama de Proceso: Retiro ABA por Solicitud del Cliente.............184
Diagrama 22. Diagrama de Actividades: Retiro ABA...............................................185
Diagrama 23. Diagrama de Proceso: Averas Telefnicas.........................................186
Diagrama 24. Diagrama de Actividades: Averas Telefnicas...................................187
Diagrama 25. Diagrama de Proceso: Averas ABA...................................................188
Diagrama 26. Diagrama de Actividades: Averas Aba...............................................189
Diagrama 27. Diagrama de Objetos para el proceso Instalacin ABA.....................191
Diagrama 28. Diagrama de Objetos para el proceso Instalaciones Comerciales......191
Diagrama 29. Diagrama de Objetos para el proceso Instalaciones Residenciales.. . .192
Diagrama 30. Diagrama de Objetos para el proceso Instalacin Voz y Dato............192
Diagrama 31. Diagrama de Objetos para el proceso Reinstalacin del Servicio......193
Diagrama 32. Diagrama de Objetos para el proceso Instalacin de Servicios
Especiales...........................................................................................193
Diagrama 33. Diagrama de Objetos para el proceso Instalacin Telfonos Pblicos.
............................................................................................................194
Diagrama 34. Diagrama de Objetos para el proceso Retiro de Lazo........................194
Diagrama 35. Diagrama de Objetos para el proceso Retiro por Pago.......................195
Diagrama 36. Diagrama de Objetos para el proceso Retiro ABA por Solicitud del
Cliente................................................................................................195
Diagrama 37. Diagrama de Objetos para el proceso Averas Telefnicas.................196
Diagrama 38. Diagrama de Objetos para el proceso Averas ABA...........................196
Diagrama 39. Diagrama de Clases para la Unidad de Conmutacin (CX)...............197
Diagrama 40. Diagrama de Eventos para la Unidad de Conmutacin (CX).............215
Diagrama 41. Diagrama de Procesos del Descubrimiento de Requisitos..................226
Diagrama 42. Diagrama de Procesos del Anlisis de Requisitos..............................261
Diagrama 43. Diagrama de Caso de Uso General del Sistema.................................288
Diagrama 44. Diagrama de Caso de Uso Validar Usuario.........................................289
Diagrama 45. Diagrama de Clase Validar Usuario....................................................290
Diagrama 46. Diagrama de Secuencia Validar Usuario.............................................291
Diagrama 47. Diagrama de Caso de Uso Consultar Abonado...................................292
Diagrama 48. Diagrama de Clase Consultar Abonado..............................................293
Diagrama 49. Diagrama de Secuencia Consultar Abonado.......................................294
Diagrama 50. Diagrama de Caso de Uso Administrar Usuario.................................295
19
Diagrama 51. Diagrama de Clase Administrar Usuario............................................297

Diagrama 52. Diagrama de Secuencia Administrar Usuario.....................................298
Diagrama 53. Diagrama de Caso de Uso Actualizar Inf. Tcnica del Abonado........299
Diagrama 54. Diagrama de Clase Actualizar Inf. Tcnica del Abonado...................300
Diagrama 55. Diagrama de Secuencia Actualizar Informacin Tcnica del Abonado.
............................................................................................................301
Diagrama 56. Diagrama de Caso de Uso Consultar Registros..................................302
Diagrama 57. Diagrama de Clase Consultar Registros.............................................303
Diagrama 58. Diagrama de Secuencia Consultar Registros.....................................304
INTRODUCCIN
Con el paso del tiempo y de la inminente continuidad evolutiva que obliga la
supervivencia de un ente organizacional que lucha por mantenerse operativo dentro
de un mercado altamente competitivo, surge la necesidad de cambios, la necesidad de
una administracin responsable de los recursos, de una restructuracin de procesos y
de la obtencin de herramientas tecnolgicas que den soporte a dichos procesos. Y es
que en esta nueva era ya no funcionan las formas antiguas de hacer negocio. Los
procesos de administracin, produccin y distribucin de productos y servicios, se
han vuelto ms dinmicos y complicados.
Sin embargo, hoy en da, los variados campos de estudios brindan
oportunidades para comprender y optimizar considerablemente estos complejos
procesos. La industria de la informacin, capaz de ofrecer un manejo eficiente, rpido
y seguro de datos, es uno de los mercados ms atractivos. Procurando agilizar el
intercambio de la informacin, an sin importar la forma en que sta se presente.
Ahora bien, es indispensable entonces saber identificar la estrecha relacin que
guardan la forma de hacer negocios con la administracin de la informacin y la

importancia que lleva inmerso este vnculo.
Los sistemas de informacin en las ltimas dcadas han inundado hogares y
empresas debido a los grandes aportes que estos generan. De esta manera, se han
incorporado innumerables herramientas tecnolgicas a procesos empresariales,
capaces de facilitar tareas manuales y rutinarias, disminuir la probabilidad de errores,
controlar actividades de negocio, mejorar el rendimiento de los empleados e
incrementar la calidad del producto o del servicio ofrecido. Hay que tener en cuenta
que la adopcin de estos sistemas de informacin es el resultado de una preocupacin
incesante por parte de lderes empresariales que orientan sus esfuerzos y estrategias
de negocios en generar mejoras administrativas y de produccin que contribuyan al
cumplimiento de las metas organizacionales.
Desde luego, la produccin de estos sistemas de informacin conlleva una serie
etapas propias del desarrollo y del sistema como tal, esto es el ciclo de vida del
sistema. Dentro de este ciclo se van cumpliendo una serie de etapas o fases enfocadas
a la construccin de un software operativo y de calidad. Muchos autores utilizan
diversas denominaciones para estas fases, pero bsicamente se pueden resumir en tres
etapas. Una primera etapa de anlisis, en la cual se estudia de manera detalla el
sistema de negocio, sus funciones principales, objetivos a alcanzar, procesos de
negocio y deteccin de posibles necesidades, todo esto representado mediante un
modelado de negocio. La etapa de diseo, en la cual se construye un modelo de la
arquitectura del software en su nivel ms detallado. Y como etapa final se tiene la
implementacin del sistema, donde se crea el cdigo, se realizan pruebas y se procede
a ejecutar los diseos previos que generarn el producto final.
La Compaa Annima Nacional Telfonos de Venezuela (C.A.N.T.V.) no est
ajena al inters presente en las empresas actuales por mejorar sus procesos mediante
la adopcin de tecnologa que den soporte a sus procesos e impulsen sus operaciones
hacia el logro de sus objetivos. Por esta razn, se propone para esta importante
empresa que contina desenvolvindose y abriendo caminos en el ramo de las
telecomunicaciones, una ingeniera de requisitos orientada al desarrollo de un sistema
empresarial para la gestin de informacin en los procesos de instalacin y reparacin
de averas. Especficamente en la unidad de conmutacin (CX) de la central digital
Maturn-centro perteneciente a la empresa telefnica C.A.N.T.V.
Esta ingeniera de requisitos supondr, como parte del proceso tcnico de
anlisis, la documentacin de todos los procesos de los cuales la unidad de
conmutacin es responsable, su correcta ejecucin y los actores que desempean rol
dentro de los mismos. Todo esto, junto con el levantamiento e identificacin de los
requisitos para la futura construccin de una aplicacin empresarial que pueda ser
incorporada a los procesos de instalacin y reparacin de averas, realizado por el
personal de planta externa para la unidad de conmutacin.
De forma general, el proyecto que se presenta a continuacin ha sido
estructurado a travs de los siguientes captulos:
Captulo I: Contexto Organizacional, resume toda la informacin concerniente a
la empresa donde fue realizado este estudio, incluye aspectos como resea histrica,
misin, visin, valores, objetivos, entre otros.
Captulo II: El Problema y sus Generalidades, este captulo se define y plantea
de forma detallada el problema bajo estudio, los fundamentos que justifican esta
investigacin as como los objetivos que plantea alcanzar la misma.
Captulo III: Marco Referencial, comprende el conjunto de fundamentos que
sustentan el proyecto tericamente, de igual manera se hace referencia a los
antecedentes de la investigacin que sirvieron de referencia a este estudio junto con la

definicin de trminos.
Captulo IV: Marco Metodolgico, este captulo presenta una descripcin
detallada de la metodologa utilizada para el desarrollo de la investigacin,
describiendo el tipo y nivel de la misma, la poblacin y muestra manejada y la
presentacin del diseo operativo.
Captulo V: Resultados, presenta los resultados obtenidos al utilizar la
metodologa establecida previamente y mediante el cumplimiento de las actividades
programadas, as mismo, se presenta el prototipo de la aplicacin y el anlisis costobeneficio en relacin a este proyecto.
Adicionalmente a lo anterior, se incluyen las conclusiones, recomendaciones y
anexos que complementan esta investigacin.
CAPTULO I
CONTEXTO ORGANIZACIONAL
1.1 C.A.N.T.V.
La Compaa Annima Nacional Telfonos de Venezuela (C.A.N.T.V.), ente
adscrito al Ministerio de Ciencia, Tecnologa e Industrias Intermedias, y junto a sus
filiales Movilnet y Caveguas, es la primera empresa de telecomunicaciones en
Venezuela que tiene como objetivo fundamental fomentar la inclusin social y la
disminucin de la brecha al acceso de tecnologas digitales, facilitando as el alcance
de todos a los servicios de telecomunicaciones. La gestin de C.A.N.T.V, tras su
nacionalizacin en mayo de 2007, est definida por la relacin tica, productiva,
humanista, endgena y transparente con las comunidades, los servidores pblicos, los
usuarios, el Estado y el ambiente, al respetar la diversidad y favorecer la reduccin de
las desigualdades sociales, desde el compromiso asumido hacia la construccin del
socialismo del siglo XXI.
Es considerada la principal empresa de telecomunicaciones venezolana, y tiene
como objetivo fundamental fomentar la inclusin social y la disminucin de la brecha
al acceso de tecnologas digitales, facilitando as el alcance de todos a los servicios de
telecomunicaciones. Como empresa con una visin ms humanista ofrece servicios de
telefona bsica a todo centro poblado con ms de 500 personas, pone a la disposicin
de las venezolanas y de los venezolanos de menores recursos una tarifa social y
reinvierte las ganancias en funcin de las necesidades de telecomunicaciones del
pueblo. Es as como con las polticas de inclusin y democratizacin de las
telecomunicaciones, la C.A.N.T.V. ha logrado impulsar el buen vivir de todas y

todos llevando los servicios de telefona fija, almbrica e inalmbrica, telefona
mvil, internet, plan internet equipado, a las poblaciones ms remotas del pas.
(C.A.N.T.V., 2007).
1.2 RESEA HISTRICA
La Compaa Annima Nacional Telfonos de Venezuela, conocida como
C.A.N.T.V., fue fundada en 1930, y hoy en da es el proveedor lder de servicios de
telefona fija, mvil, internet y servicios de informacin del pas. C.A.N.T.V. posee
una estructura de propiedad mixta, en la que participan tanto pequeos ahorristas,
como trabajadores y jubilados, capitales nacionales y extranjeros y bloques de
inversin institucionales y estratgicos, como por ejemplo, el Estado venezolano y
experimentadas empresas de la industria mundial de las telecomunicaciones.
La corporacin C.A.N.T.V. dispone de las tecnologas ms avanzadas, lo cual,
aunado al desarrollo de mejores prcticas gerenciales, ha permitido llevar adelante
una importante transformacin en cobertura y calidad de servicios. Hoy, luego de 15
aos de administracin privada, C.A.N.T.V asume una nueva etapa que representar
importantes retos en sus 77 aos de servicio a los venezolanos. Y no es algo nuevo, a
travs de los siglos XX y XXI, C.A.N.T.V. ha pasado por diferentes facetas que
comenzaron en 1930, con una concesin otorgada al venezolano Flix A. Guerrero,
pasando por ser empresa pblica entre 1953 y 1991, para luego volver a manos
privadas por un lapso de 15 aos, entre 1992 y 2007, ao en que pasa, una vez ms, al
control del Estado venezolano.
1.2.1 El inicio de la era del cobre (1930-1952)
En los ltimos aos del gobierno del General Juan Vicente Gmez, el entonces
Ministro de Fomento, Gumersindo Torres, otorga una concesin para construir y
explotar una red telefnica en el Distrito Federal y los llamados Estados de la Unin.
El beneficiario de esta concesin es el comerciante Flix A. Guerrero, quien
luego de haber suscrito la concesin el 4 de abril de 1930, se asocia con el
comerciante Manuel Prez Abascal y el abogado Alfredo Damirn y constituyen la
Compaa Annima Nacional Telfonos de Venezuela (C.A.N.T.V.) con capital
suscrito de Bs. 500.000, de los cuales Guerrero tena 200 acciones y Damirn y
Prez Abascal 150 acciones cada uno.
C.A.N.T.V. fue inscrita formalmente en el Registro de Comercio el 20 de junio
de 1930 y, diez das despus, compra la Compaa de Telfonos de Maracaibo. Ese
mismo ao, en octubre, adquiere la Venezuelan Telephone and Electrical Appliances
Company Limited, empresa de origen ingls que provea servicios de telfonos desde
Caracas hasta las poblaciones de Puerto Cabello, San Juan de Los Morros, Ocumare
del Tuy y Macuto.
Ese ao se inaugura la primera central Strowge, que utiliza el sistema paso a
paso, con lo cual se inicia la automatizacin del servicio telefnico y la
multiplicacin de centrales debido al incremento de suscriptores. En 1931,
C.A.N.T.V. sigue creciendo aceleradamente y adquiere las instalaciones telefnicas
que funcionaban en Ciudad Bolvar.
En septiembre de ese mismo ao, el Ministerio de Fomento declara abierto el
servicio Radiotelefnico Internacional que operaba en ese mismo ministerio. La
empresa alemana Telefunken era la responsable del funcionamiento de la estacin
radio-elctrica, con la cual se establece comunicacin directa entre Maracay, ciudad
de residencia del General Gmez, Miami, en Estados Unidos, y Europa.
En 1936, el general Eleazar Lpez Contreras crea el Ministerio de
Comunicaciones,
que
incluye,
entre
sus
unidades,
la
Direccin
de
Telecomunicaciones, y se promulga la Ley de Telecomunicaciones que deroga la Ley

de Telfonos y Telgrafos Federales vigente desde 1918.
El 29 de julio de 1940 se promulga la nueva Ley de Telecomunicaciones que
asigna al Estado la administracin de estos servicios. Pero es en 1946, con la llegada
de la Junta de Gobierno que derroca al Presidente Isaas Medina Angarita, que se
produce un cambio en el criterio imperante hasta entonces en materia de servicios
telefnicos, como el hecho de otorgar concesiones de dichos servicios para que fueran
explotados por particulares. A partir de ese momento, el Estado comienza a contratar
y administrar directamente redes de telecomunicaciones.
En 1947, a travs de la Direccin de Telecomunicaciones, contrata con la
empresa Ericsson la instalacin de un sistema telefnico de 1.150 lneas automticas
y 420 manuales para las poblaciones del estado Tchira. Al asumir la explotacin
directa de los servicios de telefona, el Estado comienza a desplazar a C.A.N.T.V.
como principal prestatario privado de los servicios telefnicos en Venezuela.
Para 1950, existan en el pas, 48.529 lneas de telfonos. En 1951, C.A.N.T.V.
desarrolla un plan de expansin y modernizacin de sus lneas que le permitiran, en
un lapso de cinco aos, corregir las deficiencias del servicio y ampliar su red, la cual
resultaba insuficiente para el crecimiento y demanda del pas. El plan tena un costo
de Bs. 59 millones.
1.2.2 La primera nacionalizacin (1953-1991)
En 1953, la nacin adquiere la totalidad de las acciones ordinarias de
C.A.N.T.V. (20.000 en total) por Bs. 29.900.911. El objetivo era crear una nueva red
telefnica independiente y solamente utilizar las partes aprovechables de la anterior
empresa. En este proceso, la compaa Telephone Properties LTD mantuvo 4.895
acciones que fueron posteriormente adquiridas por el Estado en 1968.
De esta
manera, el Estado venezolano inicia un proceso de adquisiciones de empresas
telefnicas que culmina con la compra de la Compaa de Telfonos de San Fernando

de Apure en 1973.
El 26 de enero de 1955, ya bajo el control de la nacin, se celebra una
Asamblea Extraordinaria en donde se incrementa el capital social de la empresa a Bs.
29,5 millones, mediante la emisin de 29.550 acciones ordinarias; se aumenta el valor
nominal de las acciones comunes; se reforman los Estatutos Sociales y se modifica el
contrato de concesin suscrito con el Ejecutivo Nacional. En este ltimo punto, se
revisa el Contrato de Concesin otorgado a Flix A. Guerrero, vigente hasta entonces
por casi 25 aos, a objeto de dotar a C.A.N.T.V. de las atribuciones y facultades que
requera para afrontar la modernizacin del servicio telefnico, la extensin de sus
redes a localidades no servidas, la inversin de sus utilidades en el fomento y mejora
del servicio en general y otras finalidades acordes con la envergadura de los planes
que tena en ejecucin el Estado.
Despus de 1958, con la cada del rgimen del General Marcos Prez Jimnez,
la planificacin se visualiza como el agente rector de desarrollo econmico y se
comienzan a elaborar los Planes Quinquenales de la nacin, en los cuales las
telecomunicaciones tienen una importancia capital. Y es entonces cuando el Estado
comienza a visualizar la necesidad de crear una instancia de planificacin, separada
de
C.A.N.T.V., que,
en principio, se denomin
Comisin
Nacional
de
Telecomunicaciones, y luego se convirti en la Direccin de Telecomunicaciones del

Ministerio de Comunicaciones.
En junio de 1962, el Ejecutivo Nacional le asigna a C.A.N.T.V. la operacin,
administracin y desarrollo de los servicios de telefona local, larga distancia, tlex,
radio, facsmil, telfonos, transmisin de datos y otras facilidades para la transmisin
de radiodifusin y televisin. Posteriormente, para el ao de 1962, el Gobierno
Nacional solicita al Fondo Especial de las Naciones Unidas una ayuda para la
10
creacin del Centro de Estudios para Tcnicos de Telecomunicaciones (CETT),

aporte que se concreta en 1964 con la firma del Plan de Operaciones suscrito por el
Ministerio de Comunicaciones, el Subsecretario General de la Unin Internacional de
Telecomunicaciones (UIT) y representantes del Programa de las Naciones Unidas
para el Desarrollo (PNUD). Las actividades del CETT comenzaron con la formacin
de 400 tcnicos preparados para mantener los equipos instalados. El Jefe de la misin
del PNUD fue Jan Deketh, uno de los asesores ms interesados en el desarrollo del
CETT, del cual fue profesor y cuyo nombre lleva uno de los edificios del centro
educativo.
El 12 de junio de 1964, C.A.N.T.V. suscribe un contrato con la American
Telephone and Telegraph, (AT&T) y la Transoceanic Communications Incorporated
para la construccin de un cable submarino, con capacidad de 83 canales, que
enlazara a Venezuela con las Islas Vrgenes para establecer comunicaciones
confiables y de calidad con Estados Unidos. Este cable submarino entr en servicio
en agosto de 1966. En ese perodo se introduce el Discado Directo Nacional y la
instalacin de las primeras centrales tlex.
En 1965 Venezuela firma, como uno de los primeros pases asociados, los
acuerdos interinos del Consorcio Internacional de Comunicaciones Va Satlite
(Intelsat). El 29 de noviembre de 1970 se inaugura la Estacin Rastreadora
Camatagua I, con la cual Venezuela se interconecta con el mundo a travs del satlite
Intelsat IVA. Ms tarde, en enero de 1973, se crea la empresa Manufacturas Plsticas
y Telefnicas MPT (Maplatex), con el propsito de producir 750 mil telfonos
anuales para la industria nacional. En 1974, C.A.N.T.V. adquiere 45% de las acciones
de Maplatex. Posteriormente la empresa se separa del grupo.
En 1975 la tasa interanual de instalacin de suscriptores telefnicos alcanza un
nivel inusual: 17%, cifra que ir disminuyendo progresivamente en aos posteriores.
11
En octubre de ese mismo ao, se constituye la filial C.A. Venezolana de Guas

(Caveguas). En esta empresa C.A.N.T.V. participa con 40% de las acciones para ese
momento.
El 12 de octubre de 1977 se inaugura el Cable Columbus, con una longitud de
6.012 kilmetros, 503 repetidoras y 1.840 canales. Es propiedad de Venezuela en un
70%, mientras que el restante 30% es de Espaa y enlaza a Venezuela con las Islas
Canarias y en el ao 1979, C.A.N.T.V. arriba al primer milln de lneas fijas
instaladas.
Para el perodo 1979-1983, C.A.N.T.V. contempla la diversificacin de los
servicios: telefona rural con acceso mltiple, construccin de redes de transmisin de
datos, radio y TV; planes que no pudieron cumplirse porque comienzan a ocurrir
desajustes en el panorama econmico nacional y se restringe el apoyo financiero del
Estado. Mientras tanto, a nivel internacional, hay un desarrollo intensivo de
innovacin en microelectrnica e informtica que invade el mercado mundial de
suministros. Este hecho afecta la adquisicin de insumos para C.A.N.T.V., cuya red se
va quedando obsoleta frente a estos cambios tecnolgicos.
Es en 1988 cuando se concretan algunos de los planes previstos con
anterioridad: telefona rural en zonas fronterizas y agropecuarias y la red pblica
conmutada de transmisin de datos. Se instalan telfonos monederos bidireccionales,
de tarjeta magntica, teletasa y se adquieren 152.000 lneas digitales de contado y
848.000 en una negociacin a tres aos.
El programa de modernizacin previsto por C.A.N.T.V. ese ao tambin
contempla la fabricacin nacional de un milln de aparatos telefnicos; 2 millones de
kilmetros/par de planta externa; la construccin de 82 edificios y el desarrollo de 7
proyectos de transmisin digital a travs de fibra ptica a fin de instalar 678.000
12
nuevos clientes en 1989 y elevar la densidad telefnica de 6 a 12 telfonos por cada

100 habitantes. Estos proyectos no pueden concretarse por no haberse previsto la
infraestructura necesaria. Sin embargo, se instalan 300.000 nuevas lneas.
En 1990 se vence el Contrato de Concesin que C.A.N.T.V. tiene con el Estado
por 25 aos. En esos tiempos, el Estado atraviesa por una comprometida situacin
financiera para afrontar los requerimientos de los servicios de telecomunicaciones. Y
de acuerdo con las proyecciones de aquella poca, se requeran 300.000 nuevas lneas
anuales durante 10 aos para satisfacer la demanda en un 80%, lo cual significaba una
inversin anual de mil millones de dlares hasta el ao 2000.
El Estado prorroga por seis meses el contrato de concesin vencido mientras
decide cul ser la frmula para afrontar la situacin. Se nombra una comisin
integrada por el Ministerio de Transporte y Comunicaciones, el Fondo de Inversiones
de Venezuela y la oficina de Coordinacin de Planificacin de la Presidencia de la
Repblica (Cordiplan) que se pronuncia a favor de la privatizacin de la empresa. En
tal sentido, se abre una licitacin internacional para la venta de 40% de las acciones
de C.A.N.T.V., con lo cual se otorgaron derechos para instalar, desarrollar, mantener y
comercializar el servicio de telecomunicaciones del pas.
A las compaas interesadas se les exigieron ingresos superiores a los 5.000
millones de dlares y la instalacin de ms de 6 millones de lneas de acceso,
digitalizacin de centrales, menos de un mes para instalar una lnea telefnica y ms
de 65% de llamadas internacionales completadas.
Para finales de 1991, C.A.N.T.V. tiene:
1.500.000 telfonos instalados.
13
Una demanda satisfecha de 47%.

Una densidad telefnica de 7,5 lneas por cada 100 habitantes.
80 lneas por cada trabajador.
32.000 telfonos monederos.
12.000 tlex abonados.
Promedio de 101 horas de suscriptor fuera de servicio.
19% de llamadas internacionales efectivas.
Un dficit de Bs. 4 millardos.
1.2.3 De compaa de telfonos a corporacin de telecomunicaciones

(1991-2007)
Desde diciembre de 1991 hasta 2007, la Corporacin C.A.N.T.V. ha transitado
por tres lustros de crecimiento, aprendizaje colectivo y desarrollo continuo que ha
definido sus fortalezas actuales. Para comprender la transformacin protagonizada
por la empresa en este lapso, es preciso subdividir este perodo en cuatro grandes
etapas:
1992-1997: Expansin y modernizacin de las redes.
Durante los primeros seis aos como empresa privatizada, se emprende la
expansin y modernizacin de las redes de voz y datos, fijas y mviles; gracias a la
mayor inversin de capital que una empresa privada haya realizado en el pas. Esta
novedosa plataforma tecnolgica, que cubre todo el territorio nacional, permite
atender la creciente demanda de telecomunicaciones de los venezolanos, gracias a su
actualizacin permanente, como ocurri posteriormente con la red de Movilnet.
14
En efecto, se construyen 1.981 kilmetros del ms importante proyecto de

C.A.N.T.V. para este perodo: el sistema de fibra ptica interurbana, el cual permitira
la interconexin de las principales ciudades del pas a la plataforma de
telecomunicaciones ms avanzada y confiable existente en Latinoamrica. Asimismo,
se avanz en la instalacin del cable costero de fibra ptica y entran en servicio los
cables submarinos de fibra ptica Amricas I, Columbus II y Panamericano, lo cual
garantiza a C.A.N.T.V. la comunicacin simultnea digital de voz, datos y video entre
Venezuela y Norteamrica, el Caribe, Suramrica y Europa.
Otro de los hitos de este perodo es la constitucin de Movilnet el 19 de mayo
de 1992, que en su primer ao alcanz 21.000 clientes, y pronto se convertira en la
primera operadora celular del pas en digitalizar su red. Bajo la tecnologa TDMA
(Time Division Multiple Access) y se fortalece la privatizacin de la empresa en el
pas.
1998-2000: Transformacin y orientacin comercial.
Esta etapa caracteriza la evolucin de la empresa hacia el mercado ante la
inminente apertura total del sector. Se concreta la transformacin de la estructura
organizacional de C.A.N.T.V. y se crean las unidades de negocio con un nuevo
enfoque estratgico: el cliente. Durante esta etapa, C.A.N.T.V. consolida el proceso
de transformacin anunciado en 1997, a raz de la formulacin de un nuevo plan
estratgico. Se inicia as una nueva ruta, luego de la etapa de evolucin tecnolgica,
orientada hacia el cliente como razn de ser de la empresa, con lo cual la cultura
corporativa da un giro donde el mercado pasa a dominar la dinmica de la gestin de
la organizacin; aprendizaje que se vena gestando con el mpetu competitivo que ya
protagonizaba Movilnet, compaa que siempre estuvo en competencia.
15
Paralelamente, se introducen novedosos puntos de contacto con el cliente, como

los Centros de Comunicaciones y las Taquillas de Paso, que adems de recaudar
comienzan a ofrecer tambin productos y servicios de la empresa. De igual manera,
se produce la explosin del segmento prepago en el mercado celular venezolano,
hecho que capitaliza Movilnet para incrementar su cartera de clientes, que pasa de
228.000 en 1998 a casi 1.500.000 para el ao 2000.
En este perodo, se inicia tambin el avance de Internet a travs de cantv.net. De
la mano de esta filial, nace el producto Acceso a Banda Ancha (ABA) que aos ms
tarde pasa al portafolio de C.A.N.T.V., el cual revoluciona el servicio de conexin a
internet en el mercado venezolano.
2001-2003: Integracin en competencia.
Luego de la aprobacin de la Ley Orgnica de Telecomunicaciones y el
comienzo de la apertura total del mercado de las telecomunicaciones, C.A.N.T.V.,
como Corporacin, evoluciona hacia la integracin de las empresas del grupo. Este
proceso permite ofrecer, en un mercado totalmente en competencia, productos y
servicios integrales, unificar los medios de prepago y fortalecer la cartera de clientes
a travs de una fuerza de ventas comn.
A partir de 2001, C.A.N.T.V. presenta una identidad de marca corporativa
uniforme, smbolo de la comunicacin abierta a travs de un amplio abanico de
productos y servicios. Una muestra emblemtica de este proceso es la tarjeta de
servicios prepagados n1ca, verdadero pasaporte de comunicaciones. Tambin se
inici un proceso de integracin de las redes fijas y mviles, lo que ha permitido
ofrecer, por ejemplo, servicios de telefona fija inalmbrica.
2004-2006: Crecimiento para abrir horizontes.
16
En esta etapa se trabaja en el mercado de la banda ancha, de los contenidos y de

las transacciones electrnicas a travs de las redes fijas y mviles. En lo interno, se
fortalecen y actualizan los sistemas tecnolgicos y se establecen procesos flexibles y
productivos, basados en la calidad y la pasin por la ejecucin. De esta forma, se abre
un nuevo camino para convertir a C.A.N.T.V. en una Corporacin sobresaliente. En
este sentido, la Corporacin incrementa agresivamente su base de clientes y
C.A.N.T.V. y Movilnet consolidan un liderazgo absoluto en el mercado de banda
ancha e Internet.
1.2.4 C.A.N.T.V. hoy
La Compaa Annima Nacional de Telfonos de Venezuela (C.A.N.T.V.) como
Empresa del Estado venezolano tiene como objetivo fundamental proveer del acceso
a las telecomunicaciones a todas y todos los ciudadanos, para contribuir as a
impulsar su buen vivir y consolidarse como una sociedad tecnolgicamente incluida.
Instalacin de nuevas lneas telefnicas, inclusin del Poder Popular a travs de
Mesas Tcnicas de Telecomunicaciones, incorporacin a las telecomunicaciones de
poblaciones desasistidas, impulso a los servicios de Internet, conexin de poblaciones
remotas a travs del Satlite Simn Bolvar, entre otros, han sido y seguirn siendo la
punta de lanza de C.A.N.T.V. para el fortalecimiento del proceso revolucionario y el
desarrollo de la Venezuela socialista.
Hasta el primer trimestre del ao 2011, C.A.N.T.V. ha llevado a ms de 6
millones de personas los servicios de telefona fija, ms de 15 millones de
venezolanas y venezolanos tienen lnea mvil y 1 milln 700 mil usuarios con el
servicio de Interne. Como Empresa de telecomunicaciones tambin se ha abocado a
mejorar su plataforma tecnolgica, y para ello, la inversin asignada super los 700
millones de dlares, en el primer trimestre del ao 2011.
17
Con la construccin de ms de 6.609 kilmetros de Fibra ptica y la

interconexin con los 12 mil 214 kilmetros de fibra de las redes del Estado de la Red
Nacional de Transporte, C.A.N.T.V. lleva de manera ms rpida y eficiente sus
servicios. Desde el punto de vista de conexin internacional, C.A.N.T.V. interconecta
a Venezuela con los pases de Amrica Latina y El Caribe, a travs de proyectos como
el Cable Submarino de fibra ptica que nos enlaza con Cuba y Jamaica; la
interconexin con Brasil, representando la integracin del Continente; y el convenio
entre Venezuela y Uruguay que permite que ste utilice hasta 10 MHz del espectro
posicionado en su rbita, para mejorar las comunicaciones en todo el territorio
rioplatense.
Con la finalidad de impulsar el Poder Popular, la compaa lder en
telecomunicaciones, cuenta en la actualidad con ms de 1.200 Mesas Tcnicas de
Telecomunicaciones donde participan activamente ms de 4 mil comunidades
organizadas; ms de 300 Esquemas Asociativos Solidarios conformados por ms de 6
mil cooperativistas. C.A.N.T.V., es hoy, la empresa del Estado venezolano que busca
el bienestar de todas las venezolanas y todos los venezolanos al brindarles los
servicios de voz, datos e internet con calidad, demostrando as ser una Empresa
rentable para la consolidacin del Socialismo Bolivariano.
1.3 VISIN
Ser una empresa socialista operadora y proveedora de soluciones integrales de
telecomunicaciones e informtica, reconocida por su capacidad innovadora,
habilitadora del desarrollo sustentable y de la integracin nacional y regional,
comprometida con la democratizacin del conocimiento, el bienestar colectivo, la
eficiencia del estado y la soberana nacional.
1.4 MISIN
18
Somos la empresa estratgica del estado venezolano operadora y proveedora de

soluciones integrales de telecomunicaciones e informtica, corresponsable de la
soberana y transformacin de la nacin, que potencia el poder popular y la
integracin de la regin, capaz de servir con calidad, eficiencia y eficacia, y con la
participacin protagnica del pueblo, contribuyendo a la suprema felicidad social.
1.5 OBJETIVOS DE LA ORGANIZACIN
1. Democratizar el servicio con justicia social: ampliando la cobertura geogrfica,

incluyendo a todos los segmentos de la poblacin, ofreciendo tarifas justas y
solidarias para promover una competencia ms equitativa, con atencin
particular para cada segmento de la poblacin para facilitar la integracin al uso
de las telecomunicaciones.
2. Potenciar la participacin y el poder popular: las comunidades se convierten en
aliadas en la prestacin del servicio. En esta etapa C.A.N.T.V. promueve la
participacin protagnica de las comunidades organizadas, al tiempo que
potencia la labor de los consejos comunales.
3. Garantizar auto sustentabilidad de la empresa: la nueva C.A.N.T.V. ser
eficiente en sus operaciones, de manera de generar los recursos requeridos para
acometer proyectos en rentabilidad social, pero siempre asegurando la
viabilidad econmica de la empresa.
4. Convertirnos en una empresa socialista del Estado: la empresa se ajustar al
marco legal de empresa pblica e implantar el modelo laboral socialista,
impulsando la participacin protagnica de los trabajadores como servidores
pblicos, bajo un espritu de solidaridad y abriendo espacios para los esquemas
asociativos solidarios con el fin de desarrollar el modelo de economa social.
19
5. Avanzar hacia la soberana tecnolgica: la nueva C.A.N.T.V. apoyar la

implantacin del software libre cumpliendo con el decreto 3390 del Ministerio
de Ciencia y Tecnologa. Adems, impulsar la apropiacin tecnolgica por
parte de los ciudadanos y ciudadanas, promover el desarrollo endgeno,
respaldara la formacin de talentos nacionales y promover la sustitucin de
importaciones.
6. Apalancar la transformacin del Estado: C.A.N.T.V. jugar un papel
protagnico en la transformacin del Estado apalancando con el potencial que
ofrecen las tecnologas para acercarse al ciudadano y servirlo de manera ms
eficiente, gil y confiable; facilitando a su vez su participacin en el diseo de
las polticas pblicas que guan la accin del Estado.
7. Apoyar la integracin nacional e internacional: C.A.N.T.V. cobra una
dimensin internacional, expandiendo las fronteras tecnolgicas de la nacin,
bajo el lineamiento del acuerdo ALBA, el proyecto satelital VENESAT-1, que
servir para brindar apoyo a los programa sociales y del Estado y facilitar la
transferencia tecnolgica. Asimismo, se apoyar la seguridad y la defensa
integral del Estado proveyendo una red de comunicaciones segura y de alcance
nacional.
8. La nueva C.A.N.T.V. asume el reto de crear la concepcin socialista del servicio
de telecomunicaciones, abrir espacios reales para la participacin de las
comunidades, colocar las innovaciones tecnolgicas al servicio del pueblo,
convertirse en un motor de integracin para los pueblos de la regin, contribuir
a definir el perfil del servidor pblico socialista y coadyuvar en el desarrollo
del modelo de economa social sustentable y endgeno.
1.6 VALORES
20
Eficiencia
Orientar el cumplimiento oportuno de los objetivos y metas, enfocados en la
obtencin de resultados basados en la rentabilidad social y asegurando la viabilidad
econmica de la Corporacin.
Cumplir con los compromisos establecidos y responder profesionalmente por
las acciones llevadas a cabo, realizando las actividades con altos niveles de
excelencia, calidad y productividad.
Impulsar la optimizacin de los procesos, haciendo uso adecuado de los
recursos y mejorando continuamente lo qu se hace y se hace.
Profundizar en el conocimiento y el autodesarrollo que permita brindar un
soporte adecuado a las propuestas que se realizan.
Propiciar la innovacin, la aplicacin de nuevas ideas, la generacin de
servicios y prcticas que contribuyan al cumplimiento de la Misin y Visin.
Honestidad
Comportarse con probidad y actuar de manera congruente entre lo que es la
compaa, y lo que se dice y se hace.
Actuar con transparencia, facilitando el acceso a informacin veraz y oportuna
del ejercicio de la funcin pblica, a todos los relacionados con las actividades que se
realizan.
21
Promover el uso responsable, claro y racional de los recursos pblicos que se

disponen para realizar las debidas funciones.
Igualdad
Promover la inclusin de todas y todos, sin distinciones de etnia, edad,
orientacin sexual, salud, gnero, credo, condicin social o poltica, jerarqua o
cualquier otra que menoscabe la dignidad humana.
Establecer relaciones basadas en la justicia social con usuarias, usuarios,
trabajadoras, trabajadores, jubiladas, jubilados, comunidades, proveedores y aliados
de la corporacin.
Propiciar la igualdad en el disfrute de los beneficios a los trabajadoras y
trabajadores e impulsar el acceso a las telecomunicaciones de todas y todos como un
derecho fundamental.
Solidaridad
Ser parte de la nueva sociedad en construccin y contribuir activamente con su
desarrollo, esforzados en ayudar a otros y actuar en funcin del bienestar colectivo.
Valorar
la contribucin como trabajadoras y trabajadores al desarrollo y
transformacin de la sociedad.
Participacin Protagnica
22
Comprometerse en el diseo, desarrollo, ejecucin, evaluacin y control de las

iniciativas y actividades de la corporacin, de manera sistemtica y sostenida en el
tiempo.
Mantener una actitud optimista, creativa, positiva y emprendedora, enfocada en
la generacin de acciones y/o propuestas que demuestren compromiso y contribuyan
con la gestin eficiente de la corporacin.
Ser agentes de transformacin, influyendo e inspirando a otros y orientndolos
a compartir experiencias y aprendizajes con el entorno laboral y con la sociedad.
Crear y compartir espacios directos de comunicacin e intercambio para
fortalecer la participacin popular.
Ser corresponsables de la seguridad, defensa y soberana de la nacin, y de la
preservacin y resguardo de la corporacin.
Vocacin de Servicio
Sentir satisfaccin y pasin por brindar la mejor atencin y calidad de servicio,
teniendo claro el rol como servidores pblicos.
Comprometerse a entender, atender y resolver las necesidades de aquellos a
los que se sirve, orientados permanentemente a su satisfaccin y a superar sus
expectativas.
23
Atender con cordialidad, humanidad, rapidez y sentido de oportunidad los

planteamientos de las usuarias y usuarios.
Estar en constante desarrollo, mejoramiento de las capacidades y abiertos al
aprendizaje de nuevos conocimientos, con la finalidad de prestar un mejor servicio.
Esfuerzo Colectivo
Compartir la Misin, Visin, Principios, Valores, Objetivos y sentirse parte de
la corporacin y de la Nacin.
Practicar la cooperacin y la complementariedad, propiciando el esfuerzo
colectivo, como medio fundamental para alcanzar y superar, con pasin, los objetivos
y las metas comunes con altos niveles de excelencia.
Valorar y promover el espritu colectivo, los resultados integrales y el
intercambio de saberes, cumpliendo los compromisos y apoyando a otros en el logro
de los objetivos y metas comunes.
tica Socialista
Ser humanistas, orientando las acciones en el amor y el respeto por los
semejantes, la justicia social, el desprendimiento, la solidaridad humana y la
importancia de lo colectivo.
Desarrollar relaciones armnicas con el ambiente, mitigando el impacto de las
operaciones en la transformacin del entorno.
24
Propiciar el intercambio de saberes con la sociedad, contribuyendo en el

proceso de formacin y modelaje de conductas, facilitando la transferencia de poder
y conocimiento para la toma de decisiones por el pueblo.
Ser tolerantes manejando las diferencias, basados en la capacidad de
comprensin y escuchar, identificando y valorando todas las opiniones y creencias.
Responsabilidad
Estar enfocamos en el cumplimiento de los objetivos y actividades alineados
con la orientaciones estratgicas y planes operativos.
Honrar con el cumplimiento los compromisos adquiridos de manera oportuna y
con altos estndares de calidad.
Ser responsables en la capacidad de dar respuesta a todas las solicitudes que se
tengan de los clientes, compaeros, proveedores.
1.7 ESTRUCTURA ORGANIZATIVA
25
Presidencia
Vice-Presidencia
Ejecutiva
Gerencia Gral.
Mercados
Masivos
Gerencia de
Auditora Interna
Gerencia Gral.
Tecnologa y
Operaciones
Gerencia Gral.
Transicin al
Socialismo
Gerencia Gral.
Aseguramiento
de Ingresos
Gerencia Gral.
Recursos
Humanos
Gerencia Gral.
Finanzas
Gerencia Gral.
Empresas e
Instituciones
Gerencia Gral.
Centro de
Servicios
Gerencia Gral.
Asuntos
Regulados
Gerencia Gral.
Consultora
Jurdica
Gerencia Gral.
Instrucciones
Pblicas
Gerencia Gral.
Operaciones de
Telecomunicacion
es
Gerencia Gral.
Mercadeo
Corporativo
Gerencia Gral.
Comunicaciones
y Asuntos
Pblicos
Gerencia Gral.
Planificacin y
Asuntos
Corporativos
Figura 1. Organigrama general de C.A.N.T.V.

Fuente: Milano Carlos (2010).
1.8 ESTRUCTURA DEL DEPARTAMENTO
26
Gerencia
Gral.
Tecnologa
y
Operacione
s
Gerencia de
Operaciones
Regionales
Gerencia
Regin
Central
Gerencia
Regin
CentroOccidental
Gerencia
Regin
Occidental
Gerencia
Regin
Capital
Gerencia
Regin
Oriental
Gerencia Red
Estado
Nueva
Esparta
Gerencia Red
Estado
Anzoategui
Gerencia Red
Estado Sucre
Gerencia Red
Estado
Bolvar
Gerencia
Red Estado
Monagas
Unidad de
Transmisin
(TXDX)
Unidad de
Conmutacio
n (CX)
Unidad Red
de Acceso
Figura 2. Organigrama de Gerencia Gral. Tecnologa y Operaciones.

Fuente: Milano Carlos (2010).
1.9 UNIDAD DE CONMUTACIN (CX)
27
Dentro de la Gerencia Red Estado Monagas, se encuentra
la unidad de
conmutacin, que para efectos de este proyecto, es considerada el objeto de estudio.

sta unidad constituye uno de los departamentos fundamentales dentro de la
compaa telefnica C.A.N.T.V., debido a que la correcta ejecucin de sus procesos y
actividades garantiza que cada venezolano, en cualquier rincn del pas, pueda tener
acceso a los servicios que en materia de telecomunicaciones ofrece esta importante y
reconocida organizacin.
La unidad de conmutacin es un subsistema de la Compaa Annima Nacional
Telfonos de Venezuela, y se compone de diferentes procesos que determinan la
operatividad del mismo. Tambin conocido como el corazn de la C.A.N.T.V.,
conmutacin es la base de cualquier conexin entre los usuarios suscritos a los
servicios que ofrece la compaa, puesto que es en ella donde se llevan a cabo todas
las conexiones fsicas a travs de la red central que permiten que los usuarios puedan
realizar tareas tan sencillas desde su hogar como levantar su telfono fijo para
realizar una llamada o conectarse a internet.
De forma general, este departamento es responsable de realizar, eficientemente,
diferentes tareas enmarcadas en el procesamiento de todas las ordenes de trabajo que
requieran la realizacin de cruzadas en distribuidor para instalacin del servicio de
voz, aba, retiro de aba, retiros por pagos, reinstalacin del servicio, atencin de
solicitudes y reparacin de averas de clientes, pruebas de conexin servicio aba,
instalaciones comerciales y residenciales, entre otros. De igual manera se ocupa del
levantamiento de nmeros no asociados a pares, instalacin de corridas de puertos
aba, recuperacin de puertos aba, revisin de averas, revisin general de fallas en
pares, actualizacin de nmeros a la red central y mantenimiento general del
distribuidor.
1.9.1 Objetivos del departamento de conmutacin
28
a. Coordinar y controlar los programas de operacin y mantenimiento de las

centrales de la regin a fin de garantizar la continuidad, disponibilidad y calidad
del servicio telefnico
b. Mantener las lneas telefnicas e instalar nuevos clientes de ABA.
1.9.2 Funciones del departamento de conmutacin
a. Reducir el tiempo en las reparaciones e instalaciones y reparar las averas de las

centrales y distribuidores del Estado, mantenindolos en perfectas condiciones
para su ptimo funcionamiento u operatividad.
b. Participar en el mapeo de las centrales Next Generation Network (NGN).
c. Revisar diariamente los reportes de averas de clientes a travs del sistema de
administracin de averas (TAS).
d. CAPTULO II
e. EL PROBLEMA Y SUS GENERALIDADES
f.
2.1 PLANTEAMIENTO DEL PROBLEMA

g.
h. La gestin de procesos es parte fundamental en la administracin

funcional de una empresa, buscando siempre la satisfaccin del cliente, a los
cuales les son asignados diferentes actores para controlar y garantizar el
correcto funcionamiento de los mismos. En muchas oportunidades son estos
actores o responsables quienes determinarn cuales de los procesos
funcionales debe ser mejorado o rediseado. La posibilidad de documentar,
mejorar y optimizar los procesos, con la aplicacin de herramientas
metodolgicas y tecnolgicas, es un enfoque que maneja cualquier empresa
que quiera sobrevivir en un mercado tan competitivo como el actual.
i.
j.
Hoy en da las organizaciones empresariales orientan la mayora de sus
esfuerzos en optimizar su desempeo, con la finalidad de mantener un nivel

competitivo deseado. Sin duda alguna, uno de los factores ms importantes para
lograr esto hace referencia a los procesos que se manejan en la empresa. Las
herramientas y metodologas de modelado de procesos empresariales son las que
contribuyen a que la gestin de los mismos se lleve a cabo correctamente, para de
esta manera generar los productos que puedan garantizar un mejor desempeo del
personal involucrado en el mismo.
k.
l.
En Venezuela son muchas las empresas que han decidido darle a sus
procesos y a las aplicaciones que le dan soporte a los mismos la importancia que estos
precisan, para de esta manera dar una respuesta ptima a las necesidades y
29
30
m.
deficiencias que stas presentan. Es por ello que constantemente en las
organizaciones se aplican mtodos de modelado, como el modelo de objetivos, el cual

marca la trayectoria de la organizacin, el modelo de actores para identificar los
responsables en cada proceso, o las reglas de negocio que comprende las normas que
regulan dichos procesos, de igual manera se llevan a cabo tareas de anlisis para
proponer mejoras y se implementan
innumerables aplicaciones desarrolladas en
funcin a requerimientos estrictamente identificados con el objetivo de contribuir con

la productividad de la empresa.
n.
o.
La Compaa Annima Nacional Telfonos de Venezuela (C.A.N.T.V.),
principal empresa pblica en el ramo de las telecomunicaciones, no se encuentra
alejada de esta realidad, y pretende, al igual que cualquier empresa que tenga por
finalidad mantener la continuidad de sus operaciones ofreciendo un servicio de
calidad, hacer de las tecnologas de informacin que se manejan en la actualidad una
base fundamental que de soporte a muchos de los procesos que, por alguna razn u
otra, necesiten ser rediseados u optimizados.
p.
q.
Como es bien sabido, C.A.N.T.V. es una compaa telefnica que se
encuentra disgregada a lo largo y ancho del territorio nacional y que, gracias a su
correcta administracin y constante crecimiento, ofrece hoy en da a los venezolanos
ms que un servicio de lneas telefnicas, la oportunidad de comunicarse con sus
amigos, familiares y seres queridos en Venezuela o en cualquier parte del mundo.
Este constante crecimiento y avance es atribuido tanto a la adopcin de nuevas
tecnologas que han fortalecido el servicio que ofrece, como a la estructura interna de
la corporacin, la cual ha definido el rumbo de la organizacin a lo largo de este
nuevo perodo como empresa pblica.
r.
s.
C.A.N.T.V posee una estructura jerrquica basada en cuatro gerencias
principales, las cuales se encuentran por debajo de la presidencia y vicepresidencia
ejecutiva, estas son la gerencia de auditora interna, la gerencia general tecnologa y
operaciones, la gerencia general transicin al socialismo y la gerencia general
31
mercados masivos. Haciendo un enfoque en el departamento gerencia general,

tecnologas y operaciones, se tiene que sta unidad se encuentra distribuido a lo
largo del territorio nacional por regiones (central, centro-occidental, occidental,
capital, oriental). La gerencia red estado Monagas, forma parte de la regin oriental, y
se conforma por tres unidades fundamentales, la unidad red de acceso, la unidad de
transmisin TXDX y la unidad de conmutacin (CX).
t.
u. Un aspecto importante que debe ser tomado en cuenta es que el
sistema de negocio a estudiar es la unidad de conmutacin, la cual se encarga
de realizar diferentes actividades, enmarcadas en el procesamiento de todas
las ordenes de trabajo que requieran la realizacin de cruzadas en
distribuidores para instalacin del servicio de tono, aba, retiro de aba, retiros
por pagos, reinstalacin del servicio, atencin y reparacin de averas de
clientes, pruebas de conexin servicio aba, instalaciones comerciales y
residenciales, entre otros, de igual manera se ocupa del levantamiento de
nmeros no asociados a pares, instalacin de corridas de puertos aba,
recuperacin de puertos aba, revisin de averas del reporte Tas, revisin
general de fallas en pares, actualizacin de nmeros a la red central y
mantenimiento general del distribuidor.
v.
w.
De igual manera hay que sealar que la unidad de conmutacin forma
parte de dos departamentos adicionales, que delimitan la ubicacin de los equipos y

del empleado, estos son: planta interna y planta externa. Los empleados que realizan
su trabajo dentro de las instalaciones de la compaa, independientemente de la
unidad a la cual pertenezcan, forman parte del departamento de planta interna. Por
otra parte, los empleados de la compaa que llevan a cabo sus actividades laborales
en reas forneas o zonas externas a la empresa, forman parte del departamento de
planta externa. Generalmente pertenecen a este departamento los trabajadores que se
32
ocupan de la revisin de pares en armarios ubicados en puntos estratgicos de la

ciudad y los tcnicos que supervisan otras centrales externas.
x.
y.
En los diferentes distribuidores, en este caso el distribuidor Maturncentro, se procesan las solicitudes suministradas por los sistemas de gestin de
rdenes de trabajo junto con las solicitudes provenientes de los trabajadores adscritos
al departamento de planta externa, lo que conlleva a un problema para los empleados
que se encuentran dentro del distribuidor realizando sus labores cotidianas en la
compaa, debido a que estos realizan el trabajo que se les ha asignado, pero a la
misma vez, deben atender cualquier tipo de solicitud realizada por algn empleado de
planta externa, lo que sin duda alguna, interrumpe y retrasa el trabajo de los
empleados de planta interna, especficamente en el distribuidor.
z.
aa.
La causa principal de todo esto es que los empleados adscritos al
departamento de planta externa, los cuales intervienen en los procesos de instalacin

y reparacin de averas, dependen de los empleados de planta interna, ubicados en la
unidad de conmutacin, para que stos le suministran informacin tcnica de los
abonados. De esta manera, cuando se va a llevar a cabo una instalacin o algn tipo
de reparacin de averas, los empleados que se encuentran en las calles requieren de
informacin alojada en el sistema de base de datos a la cual solo puede accederse
desde planta interna, por lo tanto se ven en la obligacin de contactar telefnicamente
a algn trabajador que se encuentre dentro de las instalaciones y que tenga acceso al
sistema para que le facilite la informacin requerida.
ab.
ac. Hay que tener presente que en muchas ocasiones no es slo el
trabajo que se lleva a cabo dentro de las puertas del distribuidor el que tiene
que paralizarse para atender a los compaeros ubicados en zonas forneas,
sino que tambin muchas veces el trabajo en las calles se paraliza cuando no
se encuentra ningn personal dentro de la unidad de conmutacin que pueda
33
acceder a la base de datos y suministrar la informacin necesaria para dar

continuidad al proceso.
ad.
ae. As mismo, existen diversas situaciones que pudiesen presentarse y
que impiden que el trabajador de planta externa pueda obtener los datos
tcnicos de los abonados que requiera en un determinado momento, por
ejemplo, cuando hay personal en conmutacin pero ste no tiene acceso al
sistema, cuando el personal que tiene acceso al sistema se encuentra muy
ocupado y no puede atender las solicitudes de planta externa, cuando las
lneas telefnicas estn ocupadas, cuando el personal est de descanso,
generalmente en horas del medioda o cuando ocurre alguna avera eventual
como fallas en electricidad o problemas con el sistema de acceso al
distribuidor.
af.
ag.
Ahora bien, otro problema que se presenta en la unidad de conmutacin
(CX) es que no posee una documentacin de los procesos que sustente la secuencia
de las actividades y los actores que intervienen en ellas. Esto trae como consecuencia
una escasa organizacin dentro del departamento. Muchos de los nuevos empleados
que han pasado a formar parte de la empresa realizando labores dentro del
departamento no tuvieron acceso a informacin documentada de los procesos que
deban llevarse a cabo ni de la manera como estos deban ejecutarse, sencillamente
porque no se cuenta con la informacin representativa de esos procesos. En vista de
esto, los empleados son capacitados y entrenados de forma prctica pero sin ningn
tipo de material instructivo que plasme los procesos y la secuencia de los mismos.
ah.
ai.
De acuerdo con los razonamientos que se han venido realizando, se puede
afirmar que la carencia de un manual para comprender el contexto y los detalles de

los procesos hace que estos se vuelvan un tanto confusos para los actores que
intervienen en estos, aun cuando lleven a cabo sus responsabilidades. Por otra parte,
los procesos no estn identificados o delimitados, y es all donde la ausencia de una
34
documentacin de procesos se convierte en un problema. Puesto que los procesos

fluyen a travs de diferentes departamentos de la organizacin funcional y estos no
siempre son percibidos y diferenciados en su totalidad. Es por ello que se hace
preciso atender estos focos problemticos de forma oportuna y eficiente, a fin de
generar soluciones determinantes que contribuyan a establecer las bases
fundamentales del crecimiento y la supervivencia organizacional.
aj.
2.2 OBJETIVOS DE LA INVESTIGACIN
ak.
2.2.1 Objetivo General

al.
am. Desarrollar la ingeniera de requisitos aplicado a los procesos de

instalacin y reparacin de averas, realizados por planta externa para la
unidad de conmutacin (CX) de la central digital Maturn-centro, C.A.N.T.V.
estado Monagas.
an.
2.2.2 Objetivos Especficos
ao.
1. Diagnosticar la situacin actual de los procesos de la unidad de conmutacin

perteneciente a planta interna del distribuidor Maturn-centro para detectar las
fallas de la misma.
2. Disear el modelo de negocio de la unidad de conmutacin (CX) de la central
digital Maturn-centro a fin de obtener una visin del sistema a nivel
conceptual.
3. Determinar los requisitos funcionales y no funcionales que deber contener la
aplicacin a incorporar en los procesos de instalacin y reparacin de averas.
ap.
aq.
35
4. Evaluar los requerimientos de compatibilidad de software y hardware en

funcin a soporte y costos.
5. Desarrollar la ingeniera de requisitos de la aplicacin de consulta de
informacin para los procesos de instalacin y reparacin de averas, realizados
por planta externa para la unidad de conmutacin (CX) de la central digital
Maturn-centro, C.A.N.T.V. estado Monagas.
ar.
2.3 JUSTIFICACIN DE LA INVESTIGACIN

as.
at. A nivel empresarial los procesos constituyen el motor que mantiene

constante la operatividad de una organizacin. Es por ello que muchas de las
acciones emprendidas por la mayora de las empresas ms importantes y
decisivas a lo largo de la historia han otorgado la importancia que merece la
implementacin de la gestin, control y documentacin de sus procesos. Es
evidente entonces, que la relevancia que posee una definida estructuracin,
identificacin y delimitacin de los procesos conlleva a una coordinacin que
contribuye en el logro de los objetivos de la organizacin funcional.
au.
av. En este sentido, debido a la escases de una documentacin que
defina de manera adecuada los procesos que se llevan a cabo dentro de la
unidad de conmutacin, de la central digital Maturn-centro perteneciente a la
compaa telefnica C.A.N.T.V, ha originado con el pasar del tiempo una
notoria deficiencia en el desarrollo de las funciones y tareas de las que la
unidad es responsable. Aunado a esto, se debe adicionar el constante
crecimiento que ha presentado la corporacin en los ltimos aos,
incrementando de forma proporcional su nmero de clientes y, por
consiguiente, el nmero de solicitudes que deben ser procesadas de manera
eficiente en periodos de tiempos relativamente cortos. Son considerados estos
sntomas entonces como el indicio de que se hace oportuna una definicin
36
clara y precisa de los procesos de la unidad de conmutacin, debido a que

estos se han venido realizando de tal forma que su ejecucin ha generado
problemas y retrasos en la realizacin del resto de los procesos.
aw.
ax. Sin embargo, la fase de anlisis propuesta, la cual se compone
bsicamente del modelado de negocio y la ingeniera de requisitos, busca
convertirse en el primer paso para la elaboracin de un proyecto de software
que contribuya con la mejora de los procesos organizacionales. Teniendo en
cuenta que estos procesos pueden ser diagramados y representados a travs de
un modelado de procesos que permita su documentacin con el objetivo de
delimitar, identificar y almacenar la informacin relacionada con los mismos
para usarse cuando sea requerido por la empresa.
ay.
az. En base a lo planteado anteriormente, esta investigacin permitir
desarrollar una propuesta que sea capaz de solventar el problema que origina
la falta de documentacin y la dependencia interdepartamental que presenta la
unidad de conmutacin (planta interna) con planta externa durante el proceso
de instalacin y reparacin de averas, sintetizando las relaciones dinmicas
que existen en cada proceso, probando sus premisas y prediciendo sus efectos.
ba.
bb. En relacin a la documentacin de los procesos, se realizar un
modelado de los mismos en la unidad de conmutacin con el objetivo de
lograr una mayor comprensin a las actividades que en l se efectan,
brindando la oportunidad de organizar y documentar la informacin sobre el
sistema de negocio, la cual servir para aportar una representacin de los
procesos. De esta manera se contribuye con la implementacin de alguna
mejora, rediseo futuro de los procesos o al desarrollo de una aplicacin en
base a estos modelos, teniendo en cuenta que un modelo es una representacin
grfica y visual de una realidad compleja.
bc.
37
bd. Finalmente, la ingeniera de requisitos ser el fundamento que

sustentar la propuesta de una aplicacin empresarial, desarrollada bajo un
ambiente web, capaz de ofrecer a los usuarios un entorno amigable y
accesible, que le permita acceder a los servidores de la empresa, de modo que
puedan consultar la informacin relacionada con los pares centrales, pares
locales, armarios, terminales y dems informacin relacionada con los
abonados, de una manera sencilla, segura y eficiente, sirviendo como soporte
al proceso de instalacin y reparacin de averas, de modo que ste pueda
realizarse de forma ms eficiente, y sin afectar el buen funcionamiento del
resto de los procesos de la unidad de conmutacin, garantizando la atencin
eficaz de las solicitudes y ordenes de trabajos asignadas.
be.
2.4 ALCANCE DE LA INVESTIGACIN

bf.
bg. El alcance de esta investigacin abarca el desarrollo de los procesos

tcnicos de anlisis, el cual cubre los procesos de modelado de negocio o
dominio de la aplicacin y el desarrollo de la ingeniera de requisitos junto
con el prototipo de una aplicacin empresarial, en este caso, aplicado a los
procesos de instalacin y reparacin de averas, de los cuales la unidad de
conmutacin es responsable, con el objetivo fundamental de desarrollar las
bases de ingeniera que den paso a la construccin final del producto de
software propuesto que de soporte tecnolgico a dichos procesos.
bh.CAPTULO III
bi. MARCO REFERENCIAL
bj.
3.1 ANTECEDENTES DE LA INVESTIGACIN
bk.
bl.
Salazar, C (2006). Especificacin y Evaluacin de alternativas de
software para el departamento de repuestos de ALMARCA. La finalidad de esta tesis

de grado presentada antes la Universidad de los Andes Mrida para optar por el ttulo
de ingeniero de sistemas, fue definir mediante la recoleccin y el levantamiento de
requisitos, las caractersticas de una herramienta de software que satisfaga las
necesidades del departamento de repuestos de ALMARCA, para luego evaluar
alternativas de software existentes en el mercado y recomendar la que mejor se adapte
a las necesidades de dicho departamento. Este trabajo aport los conocimientos
necesarios para lograr una correcta comprensin de la ingeniera de requisitos del
mtodo GRAY WATCH, as como los productos que se obtienen como el resultado de
sta.
bm.
bn.
Abreu, M. (2007). Modelo de Negocios del Departamento Tcnico de la
Direccin de Servicios Generales de la Universidad de los Andes, el cual fue una

Tesis de Grado de la Universidad de los Andes. Bsicamente este trabajo consisti en
desarrollar el Modelo de Negocios del Departamento Tcnico de la Direccin de
Servicios Generales de la universidad ante la cual fue presentado dicho trabajo, con la
finalidad de documentar la situacin actual y llevar a cabo una planificacin de la
infraestructura informtica. La metodologa que sustent este importante estudio fue
BMM (Business Modeling Method) de Montilva y Barrios (2003), el cual permite la
representacin grfica a travs del lenguaje UML Business. Esta tesis sirvi de ayuda
38
39
bo. para entender de una manera ms clara el uso del mtodo WATCH y de
los diferentes diagramas representativos que ofrece el lenguaje UML
Bussines.
bp.
bq.
Mata, V (2010). Modelado de Negocios y procesos operacionales de la
gerencia de plantas de gas y agua del distrito norte de Pdvsa Exploracin y

Produccin Oriente. Trabajo especial de grado, el cual fue presentado ante la
Universidad de Oriente, ncleo de Monagas, en la especialidad Ingeniera de
Sistemas. Esta investigacin se bas en construir el Modelo de Negocios de la
Gerencia de Plantas de Gas y Agua, haciendo uso de la Metodologa Business
Modeling Method (BMM). Dicho estudio sirvi para obtener conocimientos amplios
acerca de la aplicacin del lenguaje de modelado BMM a los diferentes procesos
organizacionales.
br.
bs.
Cedeo, L (2010). Implementacin de un sistema automatizado que
optimice la gestin de los procesos administrativos del rea servicios mdicos de la

Universidad de Oriente Ncleo Monagas. El objetivo principal de este informe de
pasantas de grado presentado ante la Comisin de Trabajos de Grado, como requisito
para optar al ttulo de Ingeniero en Sistemas, consisti en el desarrollo e
implementacin de un sistema automatizado que permitiera optimizar la gestin de
los procesos administrativos del rea servicios mdicos de la Universidad de Oriente
Ncleo Monagas, controlando cada uno de los procesos administrativos que all se
realizan. Debido a que para la elaboracin del mismo se hizo uso del mtodo Gray
Watch, este trabajo sirvi como referencia para consolidar los conocimientos en el
uso adecuado de dicha metodologa y de los diferentes modelos basados en el
lenguaje unificado UML Business.
bt.
bu.
Sarabia, K (2011). Ingeniera de requisitos para procesos de ejecucin
de estrategias de mercadeo (Impulsos y Fachadas), coordinacin de desarrollo en el
40
punto de venta Cervecera Polar C.A territorio comercial oriente sur. Tesis de
grado de la especialidad Ingeniera de Sistemas de la Universidad de Oriente, ncleo
de Monagas. Dicho trabajo tuvo como objetivo fundamental desarrollar la ingeniera
de requisitos de aplicacin empresarial para la gestin, control y seguimiento de los
procesos de ejecucin de estrategias de mercadeo (Impulsos y Fachadas) en la
Coordinacin de Desarrollo en el Punto de Venta en Cervecera Polar Comercial
Oriente Sur.
El estudio comprende un anlisis profundo de procesos tcnicos:
Modelo de Negocio e Ingeniera de Requisitos propuestos por la metodologa GRAY

WATCH. La ingeniera de requisitos formulada propone una que atienda las
necesidades planteadas en la coordinacin con la finalidad de automatizar los
procesos Impulsos y Fachadas. Este trabajo de grado sirvi para conocer de forma
detallada la aplicacin del mtodo GRAY WATCH, y el desarrollo del proceso de
anlisis, tanto en el modelado de negocio como la ingeniera de requisitos.
bv.
3.2 BASES TERICAS
bw.
3.2.1 El software
bx.
by.
El software es una palabra que proviene del idioma ingls, pero que
gracias a la masificacin de uso, ha sido aceptada por la Real Academia Espaola. As

pues, segn la RAE, el software es un conjunto de programas, instrucciones y reglas
informticas para ejecutar ciertas tareas en una computadora. En otras palabras, el
software no es ms que el equipamiento lgico e intangible de un ordenador,
abarcando todas las aplicaciones informticas, como los procesadores de textos, las
planillas de clculo, aplicaciones de consulta de datos y los editores de imgenes.
bz.
ca.
El software es desarrollado mediante distintos lenguajes de programacin,
que permiten controlar el comportamiento de una mquina. Estos lenguajes consisten

en un conjunto de smbolos y reglas sintcticas y semnticas, que definen el
41
significado de sus elementos y expresiones. Un lenguaje de programacin permite a

los programadores del software especificar, en forma precisa, sobre qu datos debe
operar una computadora.
cb.
cc.
Sin embargo, en base a esto y en relacin a la definicin del software,
Sommerville sostiene que El software no son solo programas, sino todos los
documentos asociados y la configuracin de datos que se necesitan para hacer que
estos programas operen de manera correcta. (Sommerville 2005, p. 05).
cd.
3.2.2 Importancia del software
ce.
cf.
El software es considerado como un elemento fundamental generador de
servicios, capaz de dar soporte a procesos organizacionales y respuestas a

innumerables situaciones problemticas. Tanto as, que muchas organizaciones
dependen de complejos sistemas informticos que contribuyen con la optimizacin de
los procesos administrativos que se desarrollan en las mismas. Cada uno de estos
productos de software son diseados y desarrollados bajo delimitadas condiciones
para que puedan dar respuesta a alguna necesidad presente en la organizacin.
cg.
ch.
Con referencia a lo anterior, se puede decir que la intervencin del
software a nivel empresarial tiene como finalidad maximizar variables como tiempo,
capital, eficiencia y minimizar otras ms como lo son los costos. Solo basta con mirar
a nuestro alrededor para ver cmo estos sistemas de informacin estn teniendo una
importancia creciente, responsabilizndose de los xitos y fracasos de muchos
sistemas basados en ellos y siendo tambin responsables de los xitos y fracasos de
las empresas que los construyen o utilizan.
ci.
cj.
ck.
42
3.2.3 Sistemas de informacin

cl.
cm. Un sistema de informacin (SI) es un conjunto de elementos orientados al
tratamiento y administracin de datos e informacin, con el objetivo fundamental de
brindar soporte a los procesos de la organizacin orientados hacia la satisfaccin de
alguna necesidad y para el logro de algn objetivo.
cn.
co.
Kenneth E. Kendall y Julie E. Kendall (2005), en la sexta edicin de su
libro Anlisis y Diseo de Sistemas presentan la siguiente definicin de Sistemas de

Informacin:
cp.
cq.
Son sistemas de informacin computarizados cuyo propsito es
contribuir a la correcta interaccin entre los usuarios y las
computadoras. Debido a que requieren que los usuarios, el software
[los programas de cmputo] y el hardware (las computadoras,
impresoras, etc.), funcionen de manera coordinada, los sistemas de
informacin gerencial dan apoyo a un espectro de tareas
organizacionales, como el anlisis y la toma de decisiones (p. 03).
cr.
cs.
Por otra parte, los profesores de administracin de empresas, Laudon y
Laudon (1995),
en el libro de su autora Administracin de los Sistemas de
Informacin, definen los Sistemas de Informacin de la siguiente manera:

ct.
cu. Un Sistema de Informacin puede definirse tcnicamente como
un conjunto de componentes interrelacionados que permiten capturar,
procesar, almacenar y distribuir la informacin para apoyar toma de
decisiones y el control en una institucin. Adems, para apoyar la
toma de decisiones, la coordinacin y el control, los Sistemas de
Informacin pueden tambin ayudar a los administradores y al
43
personal a analizar problemas, visualizar cuestiones complejas y crear

nuevos productos (p. 08).
cv.
cw. Haciendo referencia a los sistemas de informacin y su estructura, los
autores Jons Montilva C. y Judith Barrios A. (2007) establecen que:
cx.
cy. La estructura de un SI est fundamentada en una arquitectura
distribuida en la que los datos de uso corporativo se mantienen en un
ambiente de servidor centralizado y son accesibles desde cualquier
dispositivo/computador-cliente conectado a la Intranet de la empresa.
Los datos centrales del sistema son accedidos a travs de un conjunto
de aplicaciones informticas, muchas de las cuales pueden, tambin,
mantener sus propios datos locales (p. 05).
cz.
da.
Un SIE est, generalmente, formado por los siguientes componentes
arquitectnicos:
db.
a) Una base de datos corporativa (BDC-SIE) que organiza y gestiona los datos de
uso comn a toda la empresa.
b) Una plataforma infraestructura de operacin compuesta, generalmente, por
un servidor central y un conjunto de computadores clientes conectados a travs
de la red de datos de la empresa (no ilustrados en la Figura 1), un conjunto de
paquetes de software para el desarrollo, administracin y operacin de las bases
de datos y una coleccin de herramientas CASE para el desarrollo de
aplicaciones.
c) Un conjunto de aplicaciones informticas orientadas a apoyar los procesos de
negocio de la empresa en diferentes unidades organizacionales. Estas
aplicaciones se clasifican en cuatro tipos:
dc.
44
1. Sistemas de informacin funcional.- Son sistemas de informacin de

menor alcance que un SIE y que estn dirigidos a satisfacer las
necesidades especficas o particulares de una o ms Gerencias o
Direcciones. Estos sistemas, adems de acceder a los datos de la BDCSIE, pueden poseer sus propias bases de datos locales. Estn divididos
en tres tipos: Sistemas de informacin fsico-natural, sistemas de
informacin socio-econmico y sistemas de apoyo a procesos
especficos de la empresa.
2. Aplicaciones de propsito especfico.- Son todas aquellas aplicaciones menores
o programas dedicados a satisfacer necesidades de informacin empresarial de
carcter departamental, grupal o individual. Estas aplicaciones emplean, para
manipular datos, los productos de software de escritorio que integran la suite
del software.
3. Programas de Mantenimiento de un SIE.- Son programas dedicados a facilitar
la administracin y mantenimiento de un SIE. Uno de estos programas es el que
facilita la actualizacin de los datos de la BDC-SIE, denominado Programa de
Mantenimiento de la BDC-SIE.
4. Aplicaciones web.- Son aplicaciones que facilitan el acceso a los datos
centrales o locales de un SIE mediante el uso de la tecnologa web. El objetivo
principal de estas aplicaciones es facilitarle a los usuarios de un SIE el acceso a
los datos usando interfaces grficas basadas en la tecnologa web. Una de estas
aplicaciones es el Portal de Informacin empresarial que proporcionar, va
Intranet e Internet, informacin empresarial de uso tanto interno como externo.
d) El Personal Tcnico encargado de instalar, desarrollar y/o mantener los
diferentes componentes de la arquitectura de un SIE. Este personal se encarga,
tambin, de dar apoyo tcnico a los usuarios de un SIE.
45
e) El conjunto de Usuarios que emplean los recursos o facilidades que

proporciona Un SIE para acceder, a travs de las aplicaciones informticas, a
los datos centrales o locales del sistema. Estn divididos en dos grupos:
dd.
1. Usuarios internos. Son todos aquellos actores (personal de la empresa) que
requieren bien el acceso a la informacin que produce Un SIE o utilizar este
sistema para realizar sus actividades o procesos de negocio. Estn divididos en
los siguientes grupos: Personal Directivo, Personal Ejecutivo, Personal Tcnico,
Personal Administrativo y Especialistas Ambientales.
2. Usuarios externos. Este grupo lo integran todas aquellas empresas,
instituciones o personas externas a la empresa que requieren los servicios de un
SIE.
df.
de.
Todo esto para poder llevar a cabo las tareas bsicas de entrada,
almacenamiento, procesamiento y salida de informacin requerida por el usuario en

un momento determinado.
dg.
3.2.4 Sistemas de procesamiento de transacciones
dh.
di.
Kenneth E. Kendall y Julie E. Kendall (2005), haciendo referencia a los
sistemas de informacin transaccionales, sealan lo siguiente:

dj.
dk. Los sistemas de procesamiento de transacciones (TPS,
Transaction Processing Systems) son sistemas de informacin
computarizada creados para procesar grandes cantidades de datos
relacionadas con transacciones rutinarias de negocios, como las
nminas y los inventarios. Un TPS elimina el fastidio que representa
la realizacin de transacciones operativas necesarias y reduce el
tiempo que una vez fue requerido para llevarlas a cabo de manera
46
manual, aunque los usuarios an tienen que capturar datos en los

sistemas computarizados (p. 02).
dl.
dm.
dn.
do. A nivel empresarial, el uso de los sistemas de informacin transaccionales
permite expandir los lmites de la organizacin, ya que stos harn posible una
interaccin ms dinmica con ambientes y entornos externos. S importante para las
operaciones cotidianas de un negocio, que estos sistemas funcionen sin ningn tipo de
interrupcin, puesto que los administradores recurren a los datos producidos por los
TPS con el propsito de obtener informacin actualizada sobre el funcionamiento de
sus empresas.
dp.
3.2.5 Metodologa Gray Watch
dq.
dr.
La metodologa Gray Watch o Mtodo del Reloj, es una herramienta para
la construccin y el desarrollo del software empresarial basndose principalmente en

los procesos gerenciales, tcnicos y de soporte, los cuales son de gran importancia en
una organizacin.
ds.
dt.
En este sentido, con la finalidad de producir una aplicacin de
software capaz de atender las necesidades de una empresa, se hace necesario disponer
de una metodologa robusta, definida y bien estructurada que permita contribuir en el
desarrollo de dicho proyecto de software. Los profesores de la Universidad de los
Andes y principales promotores de ste nuevo mtodo de trabajo, Jons Montilva C.
y Judith Barrios A. (2007) definen el mtodo Watch como: un marco metodolgico
que describe los procesos tcnicos, gerenciales y de soporte que deben emplear los
equipos y grupos que tendrn a su cargo el desarrollo de las aplicaciones informticas
de un SIE. (p.08).
du.
47
dv.
dw.
dx.
3.2.5.1 Objetivos del mtodo Watch
dy.
dz.
Gray Watch es un mtodo de desarrollo de software que ha sido elaborado
expresamente para ser utilizado durante el desarrollo de sistemas de aplicaciones

empresariales, con la finalidad de:
ea.
a) Orientar a los equipos de desarrollo acerca de qu deben hacer y cmo deben
desarrollar una aplicacin informtica de un SIE.
b)
Garantizar la uniformidad, consistencia, facilidad de integracin y calidad de

las distintas aplicaciones que integrarn Un SIE.
c) Gestionar el desarrollo de las aplicaciones de un SIE como proyectos de

ingeniera, siguiendo los estndares de gestin de proyectos establecidos en la
empresa.
d) Asegurar que en el desarrollo de cada aplicacin de un SIE se empleen las
mejores prcticas, tcnicas, herramientas, estndares y lenguajes aceptados
internacionalmente para desarrollar software de alta calidad.
eb.
3.2.5.2 Caractersticas del mtodo Watch
ec.
ed.
Este modelo de procesos describe cmo desarrollar aplicaciones de alta
calidad, en el tiempo establecido y bajo el costo presupuestado en el Plan del

Proyecto de cada aplicacin. Las caractersticas ms relevantes del mtodo WATCH
son las siguientes:
48
a) Est slidamente fundamentado. Posee una base conceptual y metodolgica

muy bien sustentada. El mtodo descansa en conceptos bien establecidos que se
derivan de la Ingeniera de Software, los Sistemas de Informacin Geogrfica
(SIG) y los Sistemas de Informacin Empresarial (SIE). En concreto, el mtodo
emplea una arquitectura de dominio de tres capas que define los elementos
principales de los SIG/SIE modernos.Metodolgicamente, el modelo ha sido
elaborado tomando como referencia modelos de procesos bien conocidos o bien
fundamentados, tales como el modelo RUP-Rational Unified Process
(Krutchen, 2000) y el mtodo WATCH (Montilva y Barrios, 2004b).
b) Es estructurado y modular. Posee una clara estructura que facilita su
comprensin y utilizacin. Esta estructura separa los tres elementos
primordiales de un mtodo: el producto que se quiere elaborar, los actores que
lo elaboran y el proceso que siguen los actores para elaborar el producto. Estos
tres elementos definen los tres componentes del mtodo WATCH: modelo de
productos, modelo de actores y modelo de procesos. Cada uno de ellos posee, a
su vez, una estructura modular claramente visible y acorde al elemento que
representa. As, por ejemplo, el modelo de procesos tiene una estructura
jerrquica de cinco (5) niveles compuesta de: grupo de procesos, procesos, subprocesos, actividades y tareas.
c)
Es de propsito especfico. El mtodo est dirigido al desarrollo de

aplicaciones geogrficas en entornos empresariales; es decir, al desarrollo de
sistemas de informacin de carcter corporativo que estn orientados al manejo
de datos e informacin geogrfica. Esta orientacin concreta y especfica
resuelve los problemas que tienen la mayora de los mtodos comerciales y
acadmicos existentes, cuya generalidad va en detrimento de su aplicabilidad en
sistemas muy especializados, tales como los SIG y SIE.
d)
Es flexible y adaptable. Si bien el mtodo est dirigido al desarrollo de

aplicaciones
especializadas
(aplicaciones
geogrficas
en
entornos
49
empresariales), sus tres componentes pueden ser adaptados, con relativa

facilidad, a otros tipos de productos de software. Esta labor, sin embargo, debe
ser hecha por expertos en Ingeniera de Mtodos, para asegurar la correcta y
efectiva adaptacin a otros tipos de aplicaciones.
e) Emplea las mejores prcticas del desarrollo de software. Al igual que otros
mtodos bien establecidos, tales como RUP (Krutchen, 2000) y OOSE
(Jacobson, 1994), el mtodo WATCH emplea prcticas metodolgicas
internacionalmente aceptadas y utilizadas en la industria del software, las
cuales, al ser aplicadas apropiadamente, contribuyen a resolver muchos de los
problemas que, comnmente, se le atribuyen a los proyectos de software. Entre
estas prcticas, se destacan las siguientes:
ee.
a. Desarrollo de software iterativo e incremental. WATCH considera el
proceso de desarrollo de aplicaciones como un proceso iterativo. Cada
iteracin produce un componente o una nueva versin operativa de la
aplicacin.
b. Manejo eficiente de los requisitos. Una mala gestin de los requisitos de
una aplicacin es una de las principales causas de problemas en
proyectos de desarrollo de software. Para evitar estos problemas,
WATCH emplea las mejores prcticas, tcnicas y procesos de la
Ingeniera de Requisitos, las cuales facilitan las actividades de
identificacin, anlisis, especificacin, validacin y gestin de
requisitos.
c. Reutilizacin de activos de software. El mtodo promueve la
reutilizacin de activos de software. Ello reduce costos y aumenta la
calidad de los productos de software elaborados usando el mtodo. Entre
estos activos estn los siguientes: arquitecturas de dominio, patrones de
50
diseo, componentes de software reutilizables y plantillas de

documentos (Ej., plantillas para planes de proyecto, pruebas de
software, manuales de uso, etc.).
ef.
d. Modelado visual de la aplicacin. Para desarrollar una aplicacin
informtica es indispensable modelar distintos aspectos de ella, en
cada una de las etapas o fases de su desarrollo. WATCH emplea
lenguajes de modelado grfico o visual ampliamente conocidos, tales
como UML (Booch, Rumbaugh and Jacobson, 1999) y BPMN (BPMI,
2005). Estos lenguajes facilitan la representacin de la aplicacin
desde
diferentes
perspectivas
reducen
los
problemas
de
comunicacin que normalmente surgen entre los expertos en

Informtica y los usuarios.
eg.
eh.
e. Verificacin continua de la calidad de los productos. WATCH asegura
la calidad de la aplicacin, a travs del uso de un proceso bien definido
de Verificacin y Validacin (V&V). Este proceso es aplicado a todos
los productos intermedios y finales que se elaboran a lo largo del
desarrollo de cada aplicacin.
ei.
f. Apropiada gestin de cambios. Los cambios en los requisitos es una
constante en el desarrollo de aplicaciones empresariales. Estos
cambios pueden surgir en cualquier fase del desarrollo de una
aplicacin, por lo que es necesario controlarlos apropiadamente, a fin
de evitar que el proyecto se postergue continua o indefinidamente.
WATCH emplea un proceso bien definido de Gestin de la
Configuracin de Software (SCM) que se encarga de controlar estos
cambios.
51
f) Emplea las mejores prcticas y procesos de gestin de proyectos. El

mtodoWATCH emplea procesos y prcticas establecidas en el cuerpo de
conocimientos de gestin de proyectos propuesto por el PMI (Project
Management Institute).
g) Integra los procesos de gestin con los procesos tcnicos y de soporte. WATCH
define tres grupos de procesos: tcnicos, gerenciales y de soporte. Los procesos
tcnicos se relacionan con las actividades de anlisis, diseo, implementacin y
pruebas de las aplicaciones. Los procesos gerenciales se encargan de gestionar el
desarrollo de cada aplicacin como un proyecto de ingeniera; involucran, por lo
tanto, actividades de planificacin, organizacin, administracin, direccin y
control del proyecto. Por su parte, los procesos de soporte complementan los
procesos tcnicos y gerenciales con actividades, tales como: el aseguramiento de la
calidad, la gestin de la configuracin, la capacitacin de los actores y la gestin
de riesgos del proyecto.
ej.
3.2.5.3 Estructura del mtodo Watch
ek.
el.
El mtodo WATCH est compuesto por tres modelos que describen los
tres elementos claves de todo mtodo: el producto que se quiere elaborar, los actores
que lo elaboran y el proceso que los actores deben seguir para elaborar el producto
(ver Figura 3).
em.
52
en.
Mtodo
Watch
Modelo de
Productos
Modelo de
Actores
Modelo
deProcesos
eo. Figura 3. Componentes del Mtodo Watch.

a) Modelo de Productos: este modelo identifica y describe los tipos de productos
que se deben generar durante el desarrollo de una aplicacin SIE. Estos tipos de
productos se elaboran durante la ejecucin de los procesos tcnicos, gerenciales
o de soporte, que estn contenidos en el Modelo de Procesos del mtodo.
ep.
eq.
La Figura 4 refleja los principales tipos de productos que se deben
producir a lo largo del desarrollo de una aplicacin empresarial.

er.
53
es.
Producto
Watch
Producto
Intermedio
Producto
Tcnico
Producto
Entregable
Producto Aplicacin
Producto
de Gestin de Soporte Entregable
et. Figura 4. Principales tipos de productos del Mtodo Gray Watch.

eu. Fuente: Jons Montilva C. y Judith Barrios A. (2008)
ev.
ew. Los productos intermedios son todos aquellos documentos, modelos,
listas, libreras de software, matrices, etc., que se elaboran durante la ejecucin de los
procesos tcnicos, de soporte y de gestin y que son necesarios para desarrollar la
aplicacin. No son considerados productos finales o entregables, por cuanto no
constituyen parte integrante de la aplicacin.
ex.
ey.
Los productos entregables o finales del proyecto son todos aquellos que
conforman la aplicacin empresarial propiamente dicha y que son entregados al

cliente al final de un ciclo de desarrollo o de todo el proyecto. En este grupo se
incluyen todas las versiones de la aplicacin que se elaboran durante la vida del
proyecto. Cada versin entregable est compuesta de programas, bases de datos y
manuales.
ez.
b) Modelo de Actores: el Modelo de Actores tiene como objetivos:
54
1. Identificar los actores o interesados (stakeholders) que estn

involucrados en el desarrollo de aplicaciones empresarial.
2. Describir las modalidades de organizacin del equipo de trabajo que
desarrollar los diferentes componentes arquitectnicos de una
aplicacin empresarial.
3. Definir los roles y responsabilidades de aquellos actores que integrarn
el equipo de trabajo.
fa.
fb.
Actor
(Stakeholder)
Cliente
fd.
ff.
Promotor
Desarrollador
Usuarios
fc. Figura 5. Clasificacin de los Actores.

Fuente: Jons Montilva C. y Judith Barrios A. (2008)
fe.
La Figura 5 clasifica en cuatro grupos distintos los actores que deben
involucrarse en el desarrollo de aplicaciones empresariales. Los clientes son aquellas

personas o unidades organizacionales que contratan el desarrollo de la aplicacin y
aportan los recursos financieros necesarios para su desarrollo. Los promotores son
aquellas personas o unidades organizacionales que tienen inters en que la aplicacin
55
se desarrolle y, por consiguiente, promueven y apoyan su desarrollo. Los

desarrolladores son personas o grupos que participan en la ejecucin de los procesos
tcnicos, de gestin y/o soporte del desarrollo de la aplicacin. Los usuarios son todas
aquellas personas, unidades organizacionales u organizaciones externas que hacen
uso de los servicios que ofrece la aplicacin.
c) Modelo de Procesos: el objetivo de este modelo es describir los procesos tcnicos,
gerenciales y de soporte que los equipos de trabajo deben emplear para desarrollar
las aplicaciones a nivel empresarial. Cada uno de estos procesos se indican en la
Figura 6.
fg.
Ingeniera de Requisitos
Diseo
Diseo de Componentes
ProgramacinPruebas de laEntrega de la
Modelo de
fh.
Arquitectnico
Aplicacin
e Integracin Aplicacin
Negocio
fi.
fj.
Gestin de Proyectos, Alcance, Tiempo, Recursos y Contratos
fk.
fl.
fm.
Gestin de Riesgos
fn.
fo.
Gestin de la Configuracin
fp.
Gestin de lafq.Calidad
fr.
ft.
fs. Figura 6. Procesos del Mtodo Watch.

Fuente: Jons Montilva C. y Judith Barrios A. (2008).
Estos procesos se clasifican, segn su naturaleza con respecto al proceso
de desarrollo de software, en tres grupos: procesos tcnicos, procesos de gestin y

procesos de soporte (ver Figura 7).
fu.
56
fv.
Producto de
Procesos
Producto
Tcnico
Producto de
Gestin
Producto de
Soporte
fw. Figura 7. Productos del Mtodo Watch.

Fuente: Jons Montilva C. y Judith Barrios A. (2008).
fx.
fy.
El grupo de procesos tcnicos se encarga de organizar las actividades
tecnolgicas que caracterizan el desarrollo de una aplicacin empresarial cualquiera e

incluye los siguientes procesos:
a) Modelo del negocio: agrupa a las actividades encargas de caracterizar y
entender el dominio de la aplicacin, es decir, el sistema de negocios para el
cual se desarrolla la aplicacin.
b) Ingeniera de requisitos: incluye todas las actividades necesarias para
identificar, analizar, especificar, validar y gestionar los requisitos que se le
imponen a la aplicacin.
57
c) Diseo
arquitectnico:
congrega
las
actividades
necesarias
para
especificar, disear y documentar la arquitectura de software que debe tener

la aplicacin.
d) Diseo de componentes: Organiza todas actividades de diseo detallado de los
componentes arquitectnicos relacionados con la interfaz grfica de la
aplicacin, sus componentes de software, su base de datos y su interaccin con
otras aplicaciones.
e) Programacin e integracin: Agrupa las actividades de diseo detallado,
codificacin y prueba unitaria de cada uno de los componentes de software que
integran la arquitectura de la aplicacin, as como las actividades de integracin
y prueba de la integracin de estos componentes.
f) Pruebas de la aplicacin: Ordena las actividades de pruebas de la aplicacin
como un todo, incluyendo las pruebas funcionales, no-funcionales y de
aceptacin de la aplicacin.
g) Entrega de la aplicacin: Estructura el conjunto de actividades que preceden a
la puesta en produccin de la aplicacin. Incluye la capacitacin de usuarios, la
instalacin de la aplicacin en su plataforma de produccin u operacin, las
pruebas de instalacin y la entrega final del producto.
fz.
ga.
El grupo de procesos de gestin apoya la ejecucin de todos los procesos
tcnicos y est relacionado con la gestin del proyecto. Se encarga de administrar el

alcance, los tiempos, los costos, los recursos humanos y dems recursos que se
requieran para desarrollar la aplicacin. Este grupo incluye los siguientes procesos:
gb.
1. Constitucin del proyecto. Establece las actividades necesarias para promover,
justificar, aprobar e iniciar el proyecto.
58
2. Planificacin del proyecto. Incluye las actividades encargadas de la

planificacin del alcance, tiempos, recursos humanos, otros recursos y servicios
que requiera el desarrollo de la aplicacin.
3. Direccin del proyecto. Agrupa las actividades de conformacin del equipo de
trabajo, capacitacin del personal, administracin de contratos con terceros,
coordinacin de la ejecucin de las actividades y administracin de los
recursos.
4. Control del proyecto. Contiene las actividades necesarias para supervisar y
controlar el alcance, tiempos, costos, recursos humanos y dems recursos que
han sido asignados al proyecto.
5. Cierre del proyecto. Organiza las actividades que se requieren para cerrar
administrativa y tcnicamente el proyecto, una vez que concluya el desarrollo
completo de la aplicacin.
gc.
gd.
El grupo de procesos de soporte complementan los procesos de gestin y,
al igual que estos ltimos, apoyan la ejecucin de todos los procesos tcnicos. Este
grupo se relaciona con la calidad, los riesgos y la configuracin de la aplicacin.
Incluye los siguientes procesos:
ge.
a) Gestin de riesgos: Agrupa las actividades necesarias para identificar, analizar,
planificar respuestas, monitorear y controlar todos aquellos riesgos o eventos
que puedan afectar negativamente el proyecto.
b) Gestin de la configuracin: Organiza las actividades encargadas del control
de los cambios que puedan surgir en la configuracin de la aplicacin.
59
c) Gestin de la calidad: Contempla las actividades necesarias para garantizar la

calidad de la aplicacin y todos los productos que la integran, as como la
calidad del proceso usado para producir estos productos.
gf.
gg.
gh.
El orden en que los procesos del mtodo se ejecutan metfora del reloj;
metfora en la cual el proceso de desarrollo de software es visto como un reloj, cuyo

motor son los procesos de gestin y soporte y cuyos diales constituyen los procesos
tcnicos. (Ver Figura 8).
gi.
gj.
gk.
gl.
gm.
gn.
go.
gp.
gq.
gr.
gs.
gt.
gu.
gv. Figura 8. Estructura del Modelo de Procesos.
gw. Fuente: Jons Montilva C. y Judith Barrios A. (2007)
gx.
En la Figura 8, se puede apreciar que el modo de trabajo que ofrece el
mtodo Watch es presentado en un orden de ejecucin cclico, en otras palabras, para

el desarrollo final de la aplicacin se llevan a cabo un trabajo previo versionado que
anteceden a la ltima versin operativa del proyecto de software. El resultado de cada
ciclo no es ms que una versin ejecutable del producto pero que posiblemente aun
60
carezca de ciertas funcionalidades que sern agregadas en versiones futuras. Los

ciclos de desarrollo se repiten hasta completar al conjunto total de servicios o
funciones que demandan sus usuarios y que estn indicados en la arquitectura de la
aplicacin. El proyecto culmina cuando se entrega la ltima versin prevista de la
aplicacin.
gy.
gz.
Una vez planificado el proyecto, se da inicio a sus procesos tcnicos
mediante la ejecucin del Modelado del Dominio de la Aplicacin. Se continua,

luego, con los procesos de Ingeniera de Requisitos, Diseo Arquitectnico, Diseo
Detallado, Construccin, Integracin y Pruebas, en el orden indicado por las agujas
del reloj; finalizando con la entrega de la aplicacin completa ( de un subsistema de
ella).
ha.
3.2.5.4 Modelo del dominio de la aplicacin.
hb.
hc.
El modelado del dominio permite tener un conocimiento global y
detallado del dominio de la aplicacin empresarial; esto es, del sistema de negocios
para el cual se desarrolla la aplicacin. Este conocimiento se logra a travs de un
proceso de modelado empresarial que determina los objetivos, procesos, actores,
objetos, reglas, eventos y unidades organizacionales del Sistema de Negocios (SN).
hd.
he.
Entre sus principales objetivos estn:

hf.
a) Entender el dominio de la aplicacin empresarial que se va a desarrollar.

b) Comprender los problemas que motivan el desarrollo de la aplicacin
empresarial.
c) Facilitar la identificacin de las necesidades de informacin que tienen los
usuarios futuros de esta aplicacin.
61
d) Identificar los sistemas de negocios pares con lo que interacta (recibe y/o
entrega recursos, informacin, datos, coordina la ejecucin de actividades y
tareas) el sistema objeto del modelado.
e) Facilitar la integracin de la aplicacin empresarial, una vez desarrollada, en el
Sistema de Negocios o dominio organizacional donde operar.
hg.
hh.
El producto final del modelado del negocio se denomina Modelo del
Negocio de la Aplicacin o Modelo Empresarial. Sin embargo durante la elaboracin

del modelo del negocio se generan a su vez un conjunto de productos que son
representados en la Figura 9.
62
hi.
<<documento>>
<<documento>>
Deascripcin Sistema
Sistema
Deascripcin
de
Negocio
de Negocio
<<diagrama
>>
<<diagrama >>
<<documento>>
<<documento>>
Modelo de
de Objetivos
Objetivos
Modelo
Descripcin
de
Descripcin de
Objetivos
Objetivos
<<diagrama>>
<<diagrama>>
Cadena de
de Valor
Cadena
Valor
<<modelo>>
<<modelo>>
Modelo de
de Procesos
Procesos de
de
Modelo
Negocio
Negocio
<<modelo>
<<modelo>
Modelo
Modelo del
del Negocio
Negocio
<<modelo>>
<<modelo>>
Modelo
de Objetos
Objetos de
Modelo de
de
Negocio
Negocio
<<modelo>>
<<modelo>>
Modelo
Modelo Reglas
Reglas de
de
Negocio
Negocio
<<modelo>>
<<modelo>>
Modelo
Actores
Modelo de
de Actores
<<modelo>>
<<modelo>>
Modelo de
de Eventos
Modelo
Eventos
<<documento>>
<<documento>>
Glosario de
de Trminos
Trminos
Glosario
hj. Figura 9. Productos asociados al Modelo de Negocios.

hk.
<<diagrama>>
<<diagrama>>
Descripcin
Descripcin de
de Procesos
Procesos
<<diagrama>>
<<diagrama>>
Diagrama de
de Actividades
Diagrama
Actividades
<<diagrama>>
<<diagrama>>
Diagrama de
de Clases
Diagrama
Clases de
de
Negocio
Negocio
<<documento>>
<<documento>>
Matriz
Matriz Roles
Roles yy
Responsabilidades
Responsabilidades
<<diagrama>>
<<diagrama>>
Estructura Organizativa
Organizativa
Estructura
63
hl. Breve descripcin de los productos generados a partir del Modelo del
Negocio:
a) Definicin del sistema de negocios: en este documento se identificacin los
objetivos, alcance, componentes o subsistemas y las interacciones con otros
sistemas, del sistema o contexto dentro del cual operar la aplicacin.
b) Modelo de objetivos: es un modelo que contiene el conjunto de objetivos de la
organizacin representados como una jerarqua de objetivos.
c) Modelo de procesos del negocio: en este modelo se describen todos los
procesos que se realizan en el sistema de negocio y que contribuyen al logro de
los objetivos organizacionales.
d) Modelo de reglas del negocio: es un modelo que representa las normas que
rigen y regulan la correcta ejecucin de las tareas y actividades en los procesos
de la empresa.
e) Modelo de eventos: este modelo captura el conjunto de eventos tanto internos
como externos al Sistema de Negocios que causan, disparan y condicionan la
ejecucin de las diferentes actividades y procesos del negocio.
f) Modelo de actores y roles: en este modelo se ven reflejados los actores
responsables de los procesos de la organizacin.
g) Modelo de objetos del negocio: es una representacin, del conjunto de objetos
de negocios, que se crean, modifican, participan y/o fungen como recursos
fundamentales en la ejecucin de las actividades asociadas a cada uno de los
procesos del negocio.
hm.
hn.
Los cuadros que se presentan a continuacin reflejan una descripcin
cada subproceso del proceso de MN junto con sus respectivos productos.

ho.
64
hp.
hq.
hr.
hs.
ht.
hu.
hv. Cuadro 1. Descripcin de los Subprocesos del Proceso Modelo de
Objetivos.
hw. Proce hx. Subproce
hy. Actividades
hz. Productos
sos
sos
ia.
ib.
vos
Objeti
ic.
id.
D
efi
ni
ci
n
de
l
ie. Si
st
e
m
a
de
ne
go
ci
os
.
iq.
if. 1. Definir
il.
objetivos
im.
generales
4. Descripcin
del sistema
del
de negocios.
in. Sistema
ig. 2. Establecer
de
alcance del
io. Negocios.
sistema.
ih. 3. Definir
subsistemas
que
ii. componen el
Sistema de
ij. Negocios
si complejo.
ik. 4. Definir
interaccione
s con otros
sistemas de
negocios.
5. Definir la visin
del sistema de
ir. Negocios.
is. 2. Definir su
ix.
iy.
iz.
ja.
65
C
on
str
uc
ci
n
de
la
Je
ra
rq
u
a
de
O
bj
eti
vo
s.
jf.
Va
lid
ac
i
n
de
Je
ra
rq
u
a
jj.
de
O
bj
eti
vo
misin.
it. 3. Definir
sus
objetivos de
alto nivel.
iu. 4.
Descompon
er objetivos
de alto nivel
en subobjetivos.
iv. 5. Construir
jerarqua de
objetivos.
iw. 6. Revisar la
coherencia
entre
objetivos.
6. Modelo de
jb. Objetivo
s:
jc.
a)
Jerarqua
de
jd. Objetivos.
jg. 1. Analizar
jk.
la jerarqua
jl.
de objetivos.
7. Modelo de
jm.
Objetivos.
jh. 2. Enmendar
inconsistenc
ias en la
representaci
n de
objetivos.
ji. 3.
Documentar
Modelo de
Objetivos.
66
s.
jn.
jo.
jp.
jq.
jr.
jt.
js. Cuadro 2. Descripcin de los Subprocesos del Proceso Modelado de

Procesos del Negocio.
Proces ju. Subproce
jv. Actividades
jw. Productos
os
jx.
jy.
jz.
ka.
M
kb.
Pr
kc.
Negoci
kr.
ks.
sos
kd.
ke.
kf.
kg. Co
nst
ruc
ci
n
de
la
Ca
de
na
de
Va
lor.
la.
lb.
lc. De
sc
kh. 1. Identificar
los procesos
fundamental
es.
ki. 2. Identificar
los procesos
de apoyo.
kj. 3. Describir
cada proceso
usando
diagramas de
procesos
(fundamental
y de apoyo).
ld. 1. Construir
jerarqua de
Procesos
fundamental
kk.
8. Cadena de
kl. Valor.
9. Modelo de
km.
Pro
cesos
del
kn. Negoci
o
ko. (Diagra
mas de
proceso
sy
subproc
esos).
10. Diagramas de
kp. Activid
ad por
subproc
eso de
bajo
nivel.
kq.
lg.
11. Cadena de
lh. Valor.
12. Modelo de
67
kt.
ku.
kv.
kw.
kx.
M
ky.
Pr
kz.
o
ly.
lz.
ma.
Negoci
om
po
sic
in
de
Pr
oc
es
os
en
Su
bp
roc
es
os.
es y de
apoyo.
le. 2. Describir
cada proceso
del negocio
de bajo nivel
(sub
procesos).
lf. 3. Elaborar
diagramas de
actividades
para
procesos
bajo nivel.
lp.
lq.
lr.
ls. Va
lid
aci
n
del
M
od
elo
de
Pr
oc
es
os.
lt. 1. Verificar
coherencia
en
descomposic
in de
procesos.
lu. 2. Validar
descripcione
s de procesos
y diagramas
de actividad.
lv. 3. Validar
con el
usuario/clien
te.
lw. 4. Actualizar
diagramas y
modelos.
li. Proceso
s del
lj. Negoci
o
lk. (Diagra
mas de
proceso
sy
subproc
esos).
13. Diagramas de
ll. Activid
ad por
lm. subproc
eso de
ln. bajo nivel
68
mb.
mc.
Pro
c
e
s
o
s
mg.
M
o
d
e
l
a
d
o
d
e
mh.
Ob
j
Cuadro 3. Descripcin de los Subprocesos del Proceso

Modelado de Objetos del Negocio.
md.
me.
Actividad
mf.Prod
Subpr
es
uctos
oce
sos
mj.
Ide
ntif
ica
ci
n
de
mk.
Objeto
s
del
ml. Ne
go
cio
.
mu.
Or
ga
niz
aci
n
de
los
mv.Ob
jet
os
del
mm. 1.
Identificar las
clases de
objetos del
negocio.
mn.
2.
Establecer
tipos de
relaciones
entre clases de
negocio.
mo.
3. Validar
relaciones y
clasificacin
de clases de
objetos.
mx.
1. Definir
propiedades
de las clases
de objetos.
my.2. Definir
comportamien
to de clases de
objetos.
mz.3. Representar
las relaciones
entre clases de
objetos.
mp.
1.
Lista
y
mq.
c
atego
ras
de
mr. Objet
os del
ms.Nego
cio.
na.
1.
Diagr
amas
de
nb. Clase
s de
nc. Objet
os.
69
e
t
o
s
d
e
l
mi. N
e
g
o
c
i
o
mw.
Negoci
o.
ne.
Ela
bor
aci
n
de
nf. Di
agr
am
as
de
ng. Cla
ses
de
Ob
jet
os
de
Ne
go
cio
.
nq.
Val
ida
ci
n
del
nr. Mo
del
o
de
Ob
jet
nh. 1. Integracin
del modelo de
objetos.
ni. 2. Revisar
diagramas de
clases.
nj. 3. Corroborar
objetos
representados
por procesos
del negocio.
nk. 4. Documentar
modelo de
objetos.
nl.
ns. 1. Analizar los

diagramas de
procesos del
negocio.
nt. 2. Analizar
diagramas de
actividades.
nu. 3. Analizar
diagramas de
clases
nv. 4. Identificar
fuentes de
nw.
1.
Mode
lo de
nm.
O
bjetos
del
nn. Nego
cio.
no. 2.
Matri
z
proce
sos/o
bjetos
.
1.
Listas
de
Regla
s del
Nego
cio.
70
os
del
Ne
go
cio
.
reglas del
negocio.
nx.
ny.
nz.
oa.
ob.
oc.
od. Cuadro 4. Descripcin de los Subprocesos del Proceso Modelado de
Reglas del Negocio.
oe. P
of. Su
og. Actividades
oh. Prod
r
bp
uctos
o
roc
c
eso
e
s
s
o
s
oi.
ol.
oq. 1. Analizar los
ou.
om.
diagramas de
ov. 1.
procesos del
Listas
on. Ide
negocio.
de
nti
or. 2. Analizar
Regla
fic
diagramas de
s del
aci
actividades.
Nego
n
os. 3. Analizar
cio.
de
diagramas de
oo. las
clases
M
Re
ot. 4. Identificar
o
gla
fuentes de
d
s
reglas del
e
del
negocio.
l
op. Ne
a
go
71
d
o
d
e
oj. R
e
g
l
a
s
d
e
l
ok. N
e
g
o
c
i
o
cio
.
ox.
oy.
oz. Re
pre
sen
tac
in
de
las
Re
gla
s
del
pa. Ne
go
cio
.
pn.
po. Val
ida
ci
n
del
pp. M
od
elo
de
Re
gla
s
del
Ne
go
cio
pb. 1. Clasificar
las reglas.
1.
pc. 2. Seleccionar
notacin de
representacin
.
pd. 3. Representar
reglas en
lenguaje
natural y/o
seudocdigo.
pe. 4. Incluir en
glosario de
trminos.
pf. 5. Incluir
reglas en
diagramas de
clases.
pq. 1. Revisar
reglas de
representacin
segn
notacin.
pr. 2. Validar
consistencia
con los
modelos de
procesos y
objetos del
negocio.
ps. 3. Actualizar
modelo de
reglas y
glosario.
pg.
Descripcin de
reglas en
pseudocdigo y/o
lenguaje natural.
ph.
2. Modelo de
pi.
pj.
pk. Regla
s del
pl. Nego
cio.
pt.
pu.
1. Glosario de
pv. Trmi
nos.
72
.
pw.
px.
py. Cuadro 5. Descripcin de los Subprocesos del Proceso Modelado de
Actores del Negocio.
pz. P
qa. Su
qb. Actividades
qc. Prod
r
bp
uctos
o
roc
c
eso
e
s
o
s
qd.
qg.
qk. 1. Retomar los
qn. 1.
M
qh.
diagramas de
Diagr
o
qi. Ide
actividades.
amas
d
ntif
ql. 2. Identificar
de
e
ica
los actores y
qo. Activ
l
ci
su tipo de
idade
a
n
participacin
s.
d
de
(roles).
o
qj. Ac
qm.
3.
tor
Modificar los
d
es.
diagramas de
e
actividades.
qe. A
c
t
o
r
e
s
d
e
l
qf. N
e
73
g
o
c
i
o
.
qq.
Pr
qu.
qv.
qw.
qx.
M
qy.
Ac
qz.
Ne
ro.
qr. Su
bp
ro
ce
so
s
ra.
rb.
rc.
rd. Es
pe
cif
ica
ci
n
de
Ac
tor
es
y
su
s
re. Ro
les
.
ru.
rv.
qp. Cuadro 5. (Cont.).

qs. Actividades
rf. 1.
Representar
la
distribucin
de
responsabilid
ades de los
diferentes
actores.
rg. 2. Modelar
los actores,
sus roles y
sus
responsabilid
ades.
rh. 3. Validar
modelo de
actores.
ri. 4. Construir
matriz
proceso/activi
dad/actor.
rz. 1. Determinar
la estructura
qt. Produc
tos
rj.
rk.
rl. 1.
Matriz
proceso
/actor/
activid
ad.
rm. 2.
Modelo
de
rn. Actores
.
se.
sf.
74
rp.
rq.
rr.
M
rs.
Ac
rt.
Ne
rw.
rx. Ca
rac
ter
iza
ci
n
de
la
Es
tru
ctu
ra
ry. Or
ga
niz
ati
va.
sa.
sb.
sc.
sd.
actual de la
organizacin
o del sistema
de negocios.
2. Validar
estructura
con los
objetivos
modelados
del sistema
de negocios.
a) Proponer
modificacion
es a la
estructura
actual.
b) Disear
nueva
estructura
organizativa.
3.
Representar
estructura en
notacin
UML.
sg.
2. Estructura
sh. Organi
zativa.
si.
sj. Cuadro 6. Descripcin de los Subprocesos del Proceso Modelado de
Eventos del Negocio.
sk. P
sl. Su
sm.Actividades
sn. Prod
r
bp
uctos
o
roc
c
eso
e
s
s
o
s
so.
st. Ide
sv. 1. Detectar
sx. 1.
sp.
ntif
eventos.
Descr
75
sq. M
o
d
e
l
a
d
o
d
e
sr. E
v
e
n
t
o
s
d
e
l
ss. N
e
g
o
c
i
o
ica
ci
n
de
su. Ev
ent
os.
ta. Re
pre
sen
tac
in
de
tb. Efe
cto
s
Ca
usa
dos
.
sw. 2. Identificar
tipo de evento
y sus efectos.
tc. 1. Describir 1.
efectos en
objetos del
negocio.
td. 2. Describir
efectos en
flujo de
2.
acciones.
te. 3. Validar
representacin
de los eventos.
tf. 4. Construir
matriz
tg. Procesos/Even3.
tos.
ipci
n de
sy. Event
os.
Modelo de
th. Proce
sos
del
ti. Nego
cio.
Modelo de
tj. Clase
s de
Objet
os del
Nego
cio.
Matriz Procesos/
Eventos
3.2.5.5 Ingeniera de requisitos

tk.
tl.
Una vez que el modelo del dominio de la aplicacin ha sido finalizado es
posible tener una mayor comprensin del problema que se presenta y del ambiente
organizacional donde se encontrar inmersa la aplicacin. Ahora bien, el siguiente
76
proceso es denominado Ingeniera de Requisitos (IR). Dentro del margen de este

contexto, Montilva y Barrios (2007) sostienen que la ingeniera de requisitos
consiste en determinar y documentar los requisitos funcionales y no-funcionales que
los actores del sistema de negocios tienen con respecto a la aplicacin que se desea
desarrollar.(p. 74).
tm.
tn.
Los requisitos expresan lo que la aplicacin SIE debe hacer para
satisfacer las necesidades de sus usuarios. Los requisitos expresan lo qu se supone

debe hacer una aplicacin, no intentan expresar cmo lograr estas funciones (Braude,
2003). Este proceso utiliza tcnicas, notaciones y herramientas orientadas por objetos
para producir una documentacin completa y precisa de los requisitos que se le
impondrn a la aplicacin empresarial. La entrada al proceso es el Modelo de
Negocios producido por el proceso que lo antecede en la cadena de valor: el
Modelado de Negocios.
to.
tp.
Los requisitos definen:

tq.
a) Lo que la aplicacin debe hacer: Las funciones que debe ejecutar, los datos
que debe capturar y almacenar y la informacin que debe producir.
b) La interaccin entre los usuarios y la aplicacin: La interfaz grfica usuario
sistema.
c) Las restricciones bajo las cuales la aplicacin debe operar: La plataforma de
operacin de la aplicacin (Hardware/Software), la tecnologa de informacin
que debe usar, las reglas y normas bajo las cuales debe operar y las interfaces
con otros sistemas o aplicaciones.
d) Los atributos de calidad que la aplicacin debe satisfacer: Seguridad,
facilidad de uso, documentacin, utilidad, confiabilidad, etc.
77
e) Se clasifican en dos tipos: funcionales y no funcionales. Los requisitos

funcionales establecen los servicios que debe proporcionar la aplicacin,
determinan la funcionalidad de la aplicacin. Describen lo que la aplicacin
empresarial deber hacer, esto es: su comportamiento; su interaccin con los
usuarios y con su dominio de aplicacin (o sistema de negocios); y sus
respuestas a eventos internos (mismo sistema) y externos (interaccin con otros
sistemas). Los requisitos no-funcionales definen las limitaciones que se le
impondrn al diseo de la aplicacin. Describen: las restricciones que se le
aplican al desarrollo y operacin de la aplicacin, tales como el ambiente de
desarrollo, los recursos disponibles para desarrollo y el ambiente de operacin
de la aplicacin.
f) Las cualidades o atributos que el sistema debe satisfacer: tales como su
confiabilidad, utilidad, documentacin, rendimiento, interfaces con otros
sistemas o aplicaciones.
g) Reglas y normas internas o externas al Sistema de Negocios: estas son las
que restringen o condicionan la operacin.
tr.
ts.
El producto final de la Ingeniera de Requisitos es el Documento de
Requisitos, el cual describe cada uno de los requisitos que establecen los usuarios de
la aplicacin. A pesar de ello durante la elaboracin de la IR se generan su vez un
conjunto de productos que son representados en la Figura 10.
tt.
tu.
78
tv.
<<documento>>
<<documento>>
Lista de
Lista
de Requisitos
Requisitos
<<documento>>
<<documento>>
Definicin
Definicin de
de
Requisitos
Requisitos
<<documento>>
<<documento>>
Matriz de
de Requisitos
Requisitos
Matriz
<<documento>>
<<documento>>
Requisitos
Requisitos
Clasificados
Clasificados
<<documento>>
<<documento>>
DEscripciones Textuales
DEscripciones
Textuales
<<modelo>>
<<modelo>>
Casos de
Uso
Casos
de Uso
<<documento>>
<<documento>>
Requisitos
Requisitos de
de la
la
Aplicacin
Aplicacin
<<documento>>
<<documento>>
Especificacin
de
Especificacin de
Requisitos
Requisitos
<<modelo>>
<<modelo>>
Preliminar
Preliminar de
de Clases
Clases
<<documento>>
<<documento>>
Casos de
Prueba de
de
Casos
de Prueba
Aceptacion
Aceptacion
<<producto
<<producto
tcnico>>
tcnico>>
Prototipo
de la
Prototipo de
la
Aplicacin
Aplicacin
<<documento>>
<<documento>>
Plan
Plan Gestin
Gestin de
de
REquisitos
REquisitos
<<documento>>
<<documento>>
Matriz
de Rastreo
Rastreo de
Matriz de
de
Requisitos
Requisitos
tw. Figura 10. Productos asociados la Ingeniera de Requisitos.
<<diagrama
<<diagrama UML>>
UML>>
Diagramas de
Diagramas
de Casos
Casos de
de
uso
uso
<<diagrama
<<diagrama UML>>
UML>>
Diagramas
Diagramas Preliminares
Preliminares
de
Clases
de
Objetos
de Clases de Objetos
79
tx.
ty.
Con el fin de capturar y especificar los requisitos de una aplicacin
empresaria, la Ingeniera de Requisitos requiere de la ejecucin de diversos

subprocesos que lo constituyen, estos son: Descubrimiento de Requisitos, Anlisis
de Requisitos, Especificacin de Requisitos, Validacin de Requisitos y Gestin de
Requisitos.
tz.
ua.
Los siguientes cuadros reflejan una descripcin de las actividades y tareas
necesarias en cada subproceso del proceso de IR junto con sus respectivos productos.
ub. Cuadro 7. Descripcin del Subproceso Descubrimiento de
Requisitos.
uc. Activi
ud. Tarea
ue. Produ
dad
cto
uf.
uh. 1. Identificar objetivos
3. Objetivos y
ug. Determ
de la aplicacin.
um.
Al
inar
ui. 2. Definir alcance de la
cance
Objetiv
aplicacin.
de la
os de
uj. 3. Determinar el
un. Aplica
la
problema a resolver.
cin
Aplica
uk. 4. Establecer
claram
cin.
restricciones.
ente
ul.
definid
os.
uo.
ut. 1. Analizar el modelo de
uy. 1.
up.
negocios y determinar el
Lista
uq.
dominio de la aplicacin.
de
ur.
uu. 2. Revisar
actores
us. Estable
documentacin
clasific
cer
relacionada con
ados.
domini
aplicaciones dentro del
oa
dominio identificado re
partir
uso de requisitos.
del
uv. 3. Estudiar
Model
documentacin sobre
80
o del
Negoci
o.
uz.
va.
vb.
vc.
vd.
ve. Recole
ctar
requisit
os de
la
Aplica
cin.
vq. Consol
idacin
de
Requis
itos.
aplicaciones en dominio.
uw.4. Identificar los actores
o interesados de la
aplicacin y que
participarn directamente
en la definicin de
requisitos.
ux.
vf. 1. Contactar interesados
o actores miembros del
sistema de negocios.
vg. 2. Recabar los requisitos
(funcionales, no
funcionales) de la
aplicacin.
vh. 3. Definir requisitos
(funcionales, no
funcionales y de interfaz)
a partir del modelo de
negocios.
vi. 4. Definir requisitos
(funcionales, no
funcionales y de interfaz)
a partir de aplicaciones
del dominio.
vj. 5. Definir requisitos de
interaccin de la
aplicacin con otros
sistemas dentro o fuera
del mismo sistema de
negocios.
vr. 1. Verificar consistencia
entre los requisitos
recolectados.
vs. 2. Unificar requisitos
recolectados.
vk.
vl. 1.
Planill
as
(Volre
) de
recolec
cin de
requisi
tos.
vm.
2.
Model
os de
casos
vn. de uso
con sus
vo. respect
ivos
vp. escena
rios
vt. 1.
Lista
de
requisi
tos
vu. de la
81
aplicac
in
vv.
vw.
vx.
vy.
vz. Cuadro 8. Descripcin del Subproceso Anlisis de Requisitos.
wa.Activi
wb.
Tarea
wc.Produ
dad
wd.
we.
wf. Clasifi
car
Requis
itos
wg.Recole
ctados.
wm.
wn.
wo.Definir
interac
ciones
entre
requisit
os.
wv.
ww.
wx.Depura
r lista
de
wh.1. Revisar los requisitos

recolectados.
wi. 2. Determinar criterios
de agrupamiento,
generalmente va
asociado al tipo de
requisitos: funcionales y
no-funcionales.
wj. 3. Agrupar requisitos en
las categoras
establecidas.
wp.1. Establecer
contradicciones entre
requisitos.
wq.2. Determinar grado de
completitud de
requisitos.
wr. 3. Determinar
solapamientos y
dependencia entre
requisitos.
ws. 4. Elaborar matriz de
requisitos vs. Requisitos.
wz.1. Eliminar
incompatibilidades y
contradicciones entre
requisitos.
xa. 2. Redefinir requisitos.
cto
wk.
wl. 1.
Requis
itos
clasific
ados.
wt. 1.
Matriz
de
requisi
tos .vs.
wu.Requis
itos.
xd. 1.
Lista
de
xe. Requis
itos
82
wy.Requis
itos.
xf.
xg.
xh.
xi.
xj. Refinar
Requis
itos
xk. Clasifi
cados.
xv.
xw.Validar
Requis
xb. 3. Determinar viabilidad

de los requisitos.
xc. 4. Establecer prioridades
de los requisitos junto
con el usuario.
factibl
es con
priorid
ades
acorda
das
con
usuari
oo
interes
ado.
4. Describir en mayor nivel de

detalle los
xl. requisitos recolectados:
xm.
a) Elaborar
diagramas de caso de
uso.
xn. b) Definir escenarios de
utilizacin y describiros
textualmente.
xo. c) Elaborar diagramas de
clases de objetos para
representar objetos
persistentes y requeridos
para la funcionalidad.
xp. d) Describir atributos y
restricciones de la
aplicacin.
xq.
xr. 1.
Diagra
mas de
casos
de uso.
xs. a)
Descri
pcione
s
textual
es.
xt. 2.
Diagra
mas
prelimi
nar de
clases.
xu. 3.
Diagra
mas de
estado
s.
xz. 1.
Docu
mento
xx. 1. Revisar requisitos con

los actores o interesados.
xy. 2. Ajustar y corregir los
83
itos.
diagramas de casos de
uso, clases y la
definicin de
restricciones y atributos.
de
ya. definic
in de
yb. requisi
tos
yc. Cuadro 9. Descripcin del Subproceso Especificacin de Requisitos.
yd. Activi
ye. Tarea
yf. Produ
dad
yg.
yh.
yi. Definic
in del
docum
ento de
especif
icacin
.
yn.
yo. Especif
icar
requisit
os
desde
el
punto
de
vista
del
interes
ado
(stakeh
yj. 1. Establecer la
estructura y contenido de
la especificacin de
requisitos.
yk. a) Especificar requisitos
desde el punto de vista
del actor o interesado:
funcionales y no
funcionales.
yl. b) Especificar requisitos
desde el punto de vista
del desarrollador:
Modelos del sistema
funcional, esttico o
estructural y dinmico.
yp. 1. Documentar
tcnicamente los
requisitos de la
aplicacin (punto de
vista del grupo de
desarrollo):
yq. a) Refinar los diagramas
y modelos preliminares
de casos de uso, clases
de objetos, estados y
transiciones, objetos y
secuencia.
yr. 2. Documentar atributos,
restricciones y otras
cto
ym.
1.
Estruct
ura y
conten
ido de
docum
ento.
ys. 1.
Docu
mento
de
especif
icacin
de
requisi
tos de
la
aplicac
in.
84
older)
especificaciones segn la
estructura y contenido
definidos para el
documento.
yt.
yu. Cuadro 10. Descripcin del Subproceso Validacin de Requisitos.
yv. Activi
yw.Tarea
yx. Produ
dad
yy. Revisa
r
docum
ento de
especif
icacin
de
requisit
os.
zc. Constr
uir un
prototi
po para
validar
los
requisit
os.
zg. Ajustar
los
modelo
sy
descrip
ciones
de la
especif
icacin
de
requisit
cto
yz. 1. Validar la estructura y
el contenido del
documento.
za. 2. Validar especificacin
tcnica de los requisitos.
zb. 1.
Docu
mento
valida
do.
zd. 1. Desarrollar un
prototipo que emule la
funcionalidad (segn los
casos de uso) y la
interfaz que tendra la
aplicacin.
ze. 2. Validar funcionalidad
e interfaz de la
aplicacin.
zh. 1. Modificar los modelos
y descripciones de
especificacin tcnica.
zi. 2. Verificar consistencia
e integridad de la
especificacin tcnica.
zf. 1.
Prototi
po de
la
aplicac
in.
zj. 1.
Model
os
actuali
zados
y
valida
dos.
85
os.
zk.
zm.
Ac
tividad
zp. Definir
prueba
sy
parme
tros de
aceptac
in de
la
aplicac
in.
zl. Cuadro 10. (Cont.).

zn. Tarea
zo. Produ
cto
zq. 1. Determinar parmetros

de aceptacin de la
aplicacin.
zr. 2. Definir casos de
prueba de aceptacin.
zs. 3. Verificar, con los
interesados, los
parmetros de aceptacin
y los casos de prueba de
aceptacin de la
aplicacin.
zt. 1.
Conju
nto de
casos
de
prueba
de
acepta
cin de
la
aplicac
in.
zu.
zv. Cuadro 11. Descripcin del Subproceso Gestin de Requisitos.
zw. Activi
zx. Tarea
zy. Product
dad
zz. Planifi
car el
proces
o de
gesti
n de
modifi
cacion
es en
los
requisi
tos.
aad.
R
ealizar
aaa.
1. Definicin de los
medios y modos de
almacenamiento de los
requisitos de la
aplicacin Base de
Datos de apoyo a la
gestin.
aab.
2. Establecer
procedimientos y
mecanismos de
actualizacin,
mantenimiento y
control de requisitos.
aae.
1. Seguir los
procedimientos y
o
aac.
1.
Plan de
gestin
de
Requisit
os.
5. Documento de
aaj.Especifi
86
cambi
os en
los
requisi
tos.
mecanismos
establecidos para la
gestin de cambios en
los requisitos.
aaf.2. Realizar los cambios
en los requisitos.
aag.
3. Modificar
documento de
especificacin de
requisitos.
aah.
4. Asegurar
consistencia e
integridad de la base de
aai.datos una vez
realizados los cambios

aal.Rastre
aam. 1. Definir mbito
o de
de influencia del
cambi
cambio sobre los
os en
requisitos de la
los
aplicacin.
requisi
aan.
2. Elaborar matriz
tos.
de rastreo de requisitos.
aao.
3. Asegurar
actualizacin de
documentos y modelos
de la aplicacin.
3.2.6 Cadena de valor de Porter
cacin
actualiza
do.
aak.
2.
Base de
datos de
Requisit
os
actualiza
da.
aap.
1.
Matriz
de
rastreo
de
requisito
s.
aaq.
aar. El economista estadounidense y especialista en gestin y administracin
de empresas, Michael E. Porter populariz en su obra Competitive Advantage:
Creating and Sustaining Superior Performance (1985) un modelo teorico que
permite describir el desarrollo de las actividades de una organizacin empresarial
generando valor al cliente final, en otras palabras, la cadena de valor es una
87
herramienta que permite analizar el contexto interno de una empresa, a travs de su

desagregacin en sus principales actividades generadoras de valor.
aas.
aat. La cadena de valor de Porter considera a las actividades ms importantes
de la empresa u organizacin como fases de una cadena de actividades, las cuales van
agregando valor al producto a medida que ste pasa por cada una de las fases de esta
cadena. La cadena de valor posee una estructura modelo de referencia y organiza
productoras de valor en: actividades primarias y actividades de apoyo.
aau.
aav. Las actividades primarias hacen referencia a todas aquellas involucradas
con la creacin fsica del producto, su venta y post-venta. Se reconocen cinco (5)
actividades primarias fundamentales: Logstica Interna, Operaciones (produccin),
Logstica Externa, Marketing y Ventas y Servicios. Por otra parte, las actividades de
apoyo o tambin llamadas auxiliares de micro, son cada una de las actividades que
apoyan a las actividades primarias, como por ejemplo: Infraestructura de la
Organizacin,
Direccin
de
Recursos
Humanos,
Desarrollo
Tecnolgico,
Abastecimiento (compras), entre otras.

aaw.
aax.
aay.
aaz.
aba.
ABASTECIMIENTO
abb.
DESARROLLO TECNOLGICO
abc.
abd.
RECURSOS HUMANOS
abe.
INFRAESTRUCTURA
DE LA EMPRESA
abf.
abg.
abh.
LOGSTICA
LOGSTICA
MARKETING Y VENTAS
SERVICIOS
OPERACIONES
INTERNA
EXTERNA
88
abi.
abj.
abk.
abl.
abm.
abn.
abo.
Figura 11. Representacin de la Cadena de Valor de Porter.
abp.
3.2.7
Lenguaje de Modelado Unificado (UML)
abq.
abr. El lenguaje de modelo unificado, o el muy conocido por todos
simplemente como UML por sus siglas en ingls, es el lenguaje ms usado
actualmente para el modelado de sistemas de software, es decir, es la notacin,
principalmente grfica, utilizada para expresar un diseo. Los autores de este
lenguaje, Grady Booch, Ivar Jacobson y Jim Rumbaugh (2000), lo definen como un
lenguaje estndar para el modelado de software lenguaje para visualizar,
especificar, construir y documentar los artefactos de un sistema con gran cantidad de
software. (p. 430).
abs.
abt. Los orgenes del UML se remontan al ao 1994 como respuesta a la
necesidad que se presentaba en el campo del desarrollo de software para construir
modelos orientados a objetos. Asi que
por iniciativa de Grady Booch y Jim
Rumbaugh se combinaron dos famosos mtodos: el de Booch y el OMT (Object

Modeling Technique). Ms tarde se les uni Ivar Jacobson, creador del mtodo OOSE
(Object-Oriented Software Engineering). En respuesta a una peticin de OMG
(Object Management Group), para definir un lenguaje y una notacin estndar del
lenguaje de construccin de modelos, asi que en el ao 1997 se propuso entonces el
UML como candidato. UML es ante todo un lenguaje, no un mtodo, y como
lenguaje se centra en la representacin grfica de un sistema.
89
abu.
3.2.7.1 Diagramas de UML
abw.
abx. El Lenguaje de Modelado Unificado (UML) ofrece al modelador una
serie de diagramas que permiten representar grficamente diversos elementos junto
con sus respectivas relaciones, todo esto con la finalidad de generar una vista grfica
del sistema sobre el cual se est trabajando. De este modo, cada diagrama representa
un aspecto propio del sistema, es decir, diversas proyecciones visuales que abstraen
de la realidad aquellos aspectos importantes para el desarrollo del software. Cada uno
de estos diagramas se encuentran clasificados dentro de dos tipos de diagramas
generales, estos son: Diagramas Estructurales y Diagramas de Comportamiento.
aby.
abz. Los diagramas de estructura se basan en los elementos que deben existir
en el sistema modelado, entre estos se encuentran: diagrama de clases, diagrama de
objetos, diagrama de componentes y diagrama de despliegue. Por otra parte, los
diagramas de comportamiento permiten visualizar, especificar, construir y
documentar los aspectos dinmicos de un sistema, se encuentran dentro de estas
especificaciones los diagramas de casos de uso, diagramas de interaccin, que a su
vez estn compuestos por los diagramas de secuencia y diagramas de colaboracin;
diagramas de estado y por ltimo, diagramas de actividades.
aca.
acb.
acc.
3.2.7.1.1 Diagramas Estructurales
acd.
1. Diagramas de Clases: este diagrama permite realizar una representacin de las
clases del sistema y sus interrelaciones, mostrando una estructura esttica que
define colaboraciones y relaciones de dependencia.
90
ace.
acf.
acg.
Figura 12. Representacin UML de una Clase.

ach.
aci. Los atributos de una clase se dividen en:
a. Pblicos (+): indican que el atributo ser visible tanto fuera como dentro de la
clase, es decir, es accesible desde todos lados.
b. Privados (-): indican que el atributo solo ser accesible desde dentro de la clase
(solo sus mtodos lo pueden acceder).
c. Protegidos (#) indica que el atributo no ser accesible desde afuera de la clase,
pero si podr ser accesado por mtodos de la clase.
acj.
ack. Por otra parte, los mtodos u operaciones pueden tener las caractersticas:
a. Publico (+): indican que el mtodo ser visible tanto fuera como dentro de la
clase, es decir, es accesible desde todos lados.
b. Privados (-): indican que el mtodo solo ser accesible desde dentro de la clase
(solo otros mtodos de la clase lo pueden acceder).
c. Protegidos (#) indica que el mtodo no ser accesible desde afuera de la clase,
pero si podr ser accesado por mtodos de la clase.
acl.
acm. Bell, D (2007), establece cinco (05) relaciones entre clases, estas son:
91
a. Dependencia: es una relacin de uso, es decir una clase usa a otra, que la
necesita para su cometido.
b. Generalizacin: es una relacin entre un elemento ms general (el padre) y
elemento ms especfico (el hijo).
c. Agregacin: es un tipo especial de asociacin que representa una relacin
estructural entre las clases donde el llamado agregado indica el todo y el
componente es una parte del mismo.
d. Asociacin: relacin estructural que describe un conjunto de conexiones entre
objetos de forma bidireccional.
e. Composicin: es un tipo de agregacin donde la relacin de posesin es tan
fuerte como para marcar otro tipo de relacin.
acn.
aco.
Cuadro 12. Relaciones entre Clases.
acp. NOMBRE
acq. DEPENDENCIA
acr.Dependencia
acs.
act.Generalizacin
acu.
acv.
Agregacin
acw.
acx.
Asociacin
acy.
acz.
Composicin
ada.
adb.
adc.
2. Diagramas de Componentes: los diagramas de componentes representan las
distintas partes del software, es decir, archivos, cabeceras, mdulos, ejecutables,
entre otros que forman parte de un sistema as como tambin refleja las
dependencias entre estas partes. Son muy usados en la arquitectura de software
ya que permiten modelas casi cualquier sistema de software. Cada diagrama
describe una parte del sistema es por ello que no es necesario que en un
diagrama se muestren todos los componentes del mismo.
92
3. Diagrama de Objetos: los diagramas de objetos muestran instancias

compatibles con un diagrama de clases particular, ya que estos pueden
considerarse un caso especial de un diagrama de clases en el que se muestran
instancias especficas de clases (objetos) en un momento particular del sistema,
es decir, estos reflejan la multiplicidad y los roles a los que las clases
instanciadas podran servir.
4. Diagramas de Despliegue: un diagrama de despliegue modela la arquitectura
en tiempo de ejecucin de un sistema. Esto muestra la configuracin de los
elementos de hardware (nodos) y muestra cmo los elementos y artefactos del
software se trazan en esos nodos, es decir, este diagrama muestra la disposicin
de los distintos nodos que conforman un sistema. En el Cuadro 13 se muestran
los elementos bsicos de este tipo de diagramas junto con su smbolo y
respectiva descripcin:
add.
ade.
adf.
adg.
adh.
adi.
adj.
adk.
adl.
NOMBRE
ado.
Nodo
Cuadro 13. Elementos de Diagrama de Despliegue.

adm. SMBO
adn. DESCR
LO
adp.
IPCIN
adr.Objeto fsico
adq.
en tiempo de
Nodo_1
ejecucin
que
representa un
93
recurso
computacion
al. Se utiliza
para
identificar
cualquier
servidor o
terminal de
ads.
Interfaz
adt.
trabajo.
adw. Las
adu.
interfaces se
adv.
utilizan
como lazo de
unin entre
unos
componentes
adx.
ady.
adz.
Componente
aea.
aeb.
Componente_1
y otros.
aec.
Los
componentes
representan
todos los
tipos de
elementos
software que
entran en la
fabricacin
de
aplicaciones
informticas.
94
aed.
aee.
3.2.7.1.2 Diagramas de Comportamiento

aef.
1. Diagramas de Actividades: un diagrama de actividad demuestra la serie de
actividades que deben ser realizadas en un uso-caso, as como las distintas rutas
que pueden irse desencadenando en el uso-caso. ste representa paso a paso los
flujos de trabajo de negocio y operacionales de los componentes en un sistema
con el fin de visualizar un flujo de control general. Los elementos utilizados en
la elaboracin de los diagramas de actividades se muestran en el Cuadro 14.
2.
aeg.
N
aeh.
Cuadro 14. Elementos de Diagrama de Actividades.

aei.SMBOLO
aej.
DESCRIPCIN
OM
BR
E
aek.
cci
ael.
Actividad
n
aen.
odo
aeo.
aep.
de
inici
o
aer.Nod
o de
fin
de
aes.
aem. Nodo de
actividad, primitiva
ejecutable de
asignacin o
computacin.
aeq.
Nodo de control
que indica un flujo de
control cuando una
actividad es
invocada.
aet.Nodo de control que
indica el fin de todos
lo flujos dentro de
una actividad.
Muestra el fin de la
95
acti
actividad.
vida
d
aeu.
lujo
aev.
aew.
de
cont
aex.
Eje de actividad
para flujo de control.
Conecta dos
acciones. Usado para
indicar secuencias.
rol
aey.
N
aez.
odo
afa.
divide un flujo en dos
de
afb.
o ms flujos
afc.Nodo de control que
sinc
concurrentes
roni
(paralelos)
zaci
n
afd.
N
afe.
odo
aff.
que sincroniza
de
afg.
mltiples flujos.
afh.
Nodo de control
con
curr
enci
a
afi. Nod
afj.
o de
afk.
que selecciona entre
deci
afl.
dos o ms flujos de
afm.
salida.
sin
afo.
afn.
Nodo de control
3. Diagramas de Casos de Uso: es un tipo de diagrama que sirve para modelar

procesos del negocio, mostrando la relacin que posee cada actor con los casos de
uso del sistema. Este representa la funcionalidad que ofrece el sistema en base a
96
sus funciones externamente, es decir, que modelan la funcionalidad del sistema

segn lo perciben los agentes externos, llamados actores. Al igual que el resto de
diagramas, los casos de usos poseen una serie de elementos propios para llevar a
cabo una representacin de los procesos, estos elementos son descritos en el
Cuadro 15, presentado a continuacin.
afq.
afp.
Cuadro 15. Elementos de Diagrama de Casos de Uso.
afr.SMBO
afs.DESCRIPCIN
NO
LO
M
B
R
E
aft.
afv.
afy.Representa un conjunto de
afu.
afw.
roles que es jugado por
Acto
afx.
personas, dispositivos de
r
afz.
aga.
C
agb.
Caso_1
agc.
hardware u otro sistema.

agd.
Es una operacin/tarea
especfica que se realiza tras
una orden de algn agente
externo, bien sea un actor u
otro caso de uso.
o
d
e
u
s
o
age.
agf.
Rela
agg.
agh.
Seala relacin simple
entre los casos de uso.
97
c
i
n
d
e
c
o
m
u
n
i
c
a
c
i
n
agi.R
e
l
a
agj.
<<incl
ude>>
agk.
Es una forma de
interaccin o creacin, un
caso de uso dado puede
incluir otro. El primer caso
de uso a menudo depende
del resultado del caso de uso
incluido.
n
d
e
i
98
n
c
l
u
s
i
n
agl.R
agm.
agn.
Comunicar un actor con
un caso de uso, o con otro
actor.
a
c
i
n
d
e
g
e
n
e
r
a
li
z
a
c
i
99
n
ago.
Rela
c
i
agp.
<<exte
nd>>
agq.
Cuando un caso de uso
base tiene ciertos puntos en

los cuales, dependiendo de
criterios, se van a realizar
una interaccin adicional.
n
d
e
e
x
t
e
n
s
i
n
agr.
4. Diagramas de Secuencia: los diagramas de secuencia muestran el intercambio
de mensajes, es decir, la forma en que se invocan, en un momento dado. Los
diagramas de secuencia ponen especial nfasis en el orden y el momento en que
se envan los mensajes a los objetos. Este diagrama representa una interaccin
como un grfico bidimensional, para representar de manera simultnea el
tiempo y los objetos que intercambian mensajes. Consta de dos ejes,
generalmente, el eje vertical es el eje del tiempo, transcurriendo ste de arriba
abajo, y el eje horizontal muestra los roles de clasificador que representan
100
objetos individuales en la colaboracin. Cada rol de clasificador se representa

mediante una columna vertical, tambin llamada lnea de vida.
ags.
agt. Los elementos usados en este tipo de diagrama son representados junto
con su respectiva descripcin en el siguiente cuadro (ver Cuadro 16).
agu.
agv.
Cuadro 16. Elementos de Diagrama de Secuencia.
agw. SMBOLO
agx. DESCRIPCIN
agy.
ahe.
agz.
ahf.
La lnea vertical
aha.ACTOR
representa la existencia de
ahb.
un objeto a lo largo de la
ahc.
Lnea de Vida
ahd.
secuencia de actividades
que transcurren a travs del
tiempo.
ahg.
ahm.
ahh.Objeto_1
ahn.
ahi.
El objeto es representado
ahj.
con un rectngulo seguido
ahk.
de una lnea punteada de
ahl.
flecha en una progresin

vertical.
aho.
ahp.
ahq.
ahs.
SMBOLO
ahu.
Objeto_1
Activacin
ahr.Cuadro 16. (Cont.).

aht.
DESCRIPCIN
aia.Muestra el periodo de
101
ahv.
tiempo en el cual el objeto
ahw.
se encuentra desarrollando
ahx.
alguna operacin, bien sea
ahy.
por s mismo o por medio
ahz.
de delegacin a alguno de
sus atributos. Se denota
como un rectngulo
delgado sobre la lnea de
vida del objeto.
aii. Este smbolo representa el
aib.
Objeto_1
aic.
Objeto_2
envo de mensajes entre
aid.
aie.
objetos y se denota
Mensaje_1 ()
mediante una lnea slida
aif.
aig.
dirigida, desde el objeto

Mensaje_2 ()
que emite el mensaje hacia
aih.
el objeto que lo ejecuta.
aik.
aij.
air.
ail.
ais. Este es el caso particular en
Objeto_1
aim.
que el mensaje es emitido
ain.
aio.
por el mismo objeto que lo

Mensaje ()
recibe.
aip.
aiq.
ait.
5. Diagramas de Estados: en estos diagramas se representan los
diferentes
estados por los cuales pasa un objeto durante su lnea de vida en una aplicacin
como respuesta a ciertos eventos que le hacen modificar dicho estado junto con
sus respuestas y acciones. (ver Cuadro 17).
102
aiu.Cuadro 17. Simbologa de Diagrama de Estados.

aiv.NOMBRE
aiw.
SMBOLO
aix.Estado
aiy.
Nombre de estado
aiz.
aja.Estado compuesto
ajb.
Nombre de estado
concurrente
ajc.
aje.Divisin o unin
ajd.
ajf.
ajg.
aji. Estado inicial
ajh.
ajj.
ajl. Estado final
ajk.
ajm.
ajo.Estado de historia
ajn.
ajp.
ajq.
ajs. Estado de historia profunda
ajr.
ajt.
aju.
ajw.
Estado de unin
ajv.
ajx.
ajy.
aka.
Evento de entrada
ajz.
akb.
akc.
ake.
Evento de salida
Nombre
evento
akd.
akf.
akg.
Nombre
evento
akh.
aki.Cuadro 17. (Cont.).
akj.
NOMBRE
akk.
akl.Bifurcacin
akm.
akn.
SMBOLO
103
akp.
ako.
akq.
Estado de actividad
akr.
aks.
aku.
akt.Estado de flujo de objeto
Nombre: Tipo
akv.
akx.
akw.
aky.
Transicin
akz.
ala.
alc.
alb.Estado de referencia a
submquina
S1 Estado Abreviado
ald.
Include/nombresubmquina
ale.
alf.
6. Diagramas de Procesos: los diagramas de procesos, como lo indica su nombre,
es una representacin grfica de las actividades y procesos en forma secuencial.
En este sentido, haciendo uso de una serie de elementos, se puede resumir,
mediante un bosquejo visual de los procedimientos, toda la informacin
necesaria para el anlisis, cubriendo bsicamente cinco (05) actividades de
suma importancia, estas son: operaciones, transportes, inspecciones, retrasos o
demoras y almacenajes. En el Cuadro 18 se aprecia la representacin grfica de
estas actividades junto con su definicin.
alg.
alh.
ali. Cuadro 18. Representacin de Diagrama de Estados en base a las
Actividades.
alj. SMBO
alk.
A
all. DEFINICIN
LO
alm.
CTIVI
DAD
alp.Operaci
alq.Ocurre cuando un
104
aln.
objeto est siendo
alo.
modificado en sus
caractersticas, se est
creando o agregando
algo o se est
preparando para otra
operacin, transporte,
inspeccin o
alr.
alu.Transp
als.
orte
almacenaje.
alv.Esta accin se da
cuando un objeto o
alt.
grupo de ellos son

movidos de un lugar a
otro, excepto cuando
tales movimientos
forman parte de una
operacin o
alw.
alz.Inspecc
alx.
in
inspeccin.
ama. Es cuando un
objeto o grupo de ellos
aly.
son examinados para

su identificacin o para
comprobar y verificar
la calidad o cantidad
de cualesquiera de sus
amb.
amc.
De
mora
caractersticas.
amd. Ocurre cuando se
interfiere en el flujo de
un objeto o grupo de
105
ellos. Con esto se

retarda el siguiente
ame.
amh.
Al
paso planeado.
ami. Ocurre cuando un
amf.
macena
objeto o grupo de ellos
amg.
je
son retenidos y
protegidos contra
movimientos o usos no
autorizados.
amj.
amk.
aml.
3.2.8
Internet
amm.
amn. Tambin conocida como la red de redes, internet es un conjunto
descentralizado de redes de comunicacin interconectadas que utilizan la familia de
protocolos TCP/IP, de alcance mundial. En otras palabras, es una red que no slo
interconecta computadoras, sino que interconecta redes de computadoras entre s, a
travs de algn medio (cable coaxial, fibra ptica, radiofrecuencia, lneas telefnicas,
etc.) con el objeto de compartir recursos. Ya que una vez conectado a internet,
cualquier usuario puede acceder a innumerable cantidad de informacin y hasta
mantener comunicacin directa con otro usuario en cualquier lugar del planeta.
amo.
amp. La historia de esta gran hazaa en materia de redes de comunicacin se
remonta al ao de 1969, cuando se hizo posible la conexin de las primeras
computadoras como resultado de muchos estudios previos llevados a cabo por
diferentes investigadores. Y aunque inicialmente, el internet era conocido como
ARPANET, por la agencia de nombre ARPA (Advanced Research Projects Agency)
106
del gobierno de los Estados Unidos, no fue sino hasta el ao de 1991 cuando se
anuncia pblicamente el nuevo ttulo de World Wide Web.
amq.
amr. Sin duda alguna, el crecimiento que se ha presentado en los ltimos aos
en materia de internet ha sido notorio, cada da son ms los usuarios que se suman a
la nueva tecnologa y a las ventajas que sta ofrece, as mismo, son muchas las
organizaciones empresariales se han apoyado en esta red de redes para generar un
valor agregado en la atencin de sus clientes y de sus propias operaciones. Y es que el
internet ofrece exactamente lo que necesitan actualmente usuarios y empresas: acceso
ilimitado a informacin de cualquier tipo en cualquier parte del mundo y facilidad,
versatilidad y productividad a la hora de comunicarla.
ams.
amt.
3.2.9
Web
amu.
amv. La red informtica mundial, conocida como World Wide Web es un
sistema de distribucin de grandes cantidades de informacin enlazadas, a la cual
puede accederse a travs de internet. El funcionamiento del mismo est basado en
buscadores y en el protocolo de transporte de hipertexto (hypertext transport protocol
(http)), el cual es capaz de transferir a un usuario a otro sitio web que guarda relacin
con el hipertexto seleccionado. Generalmente estos textos especiales son reconocidos
en los sitios web ya que poseen un color de letra diferente o simplemente se
encuentran subrayados, indicando a los usuarios un enlace directo en esa palabra.
amw.
amx. La web permite, a travs del internet, seguir enlaces o hyperlinks en cada
pgina a otros documentos o incluso devolver informacin al servidor para interactuar
con l. A esta accin de ser transferido de un enlace a otro a veces se le llama navegar
en Internet. Sin embargo, hay que tener en cuenta que la Web es que no es lo mismo
que el internet, ya que la web es solo un componente o subconjunto del internet que
107
consiste en pginas a las que se puede acceder desde internet, y este ltimo no es ms
que la red de redes donde reside toda la informacin.
amy.
3.2.10 Aplicaciones web
amz.
ana. En el rea de la ingeniera y desarrollo de software, una aplicacin web
no es ms que un programa informtico, que es utilizado por usuarios teniendo acceso
a algn servidor web, a travs de internet mediante un navegador. En otras palabras,
una aplicacin web es un programa de software el cual es codificado en algn leguaje
de programacin que sea soportado nicamente por el navegador.
anb.
anc. La popularidad que ha adquirido las aplicaciones web se debe a la
independencia que posee la misma respecto al sistema operativo que posea la
computadora donde se requiera el uso de la aplicacin, ya que el navegador web,
como cliente ligero, es capaz de levantar la aplicacin independientemente del
sistema operativo. Otro aspecto importante que le da ventaja a las aplicaciones web es
la facilidad para actualizar y mantener aplicaciones web sin distribuir e instalar
software a miles de usuarios potenciales.
and.
ane. Por tales razones, hoy en da existen innumerables aplicaciones de este
tipo, como por ejemplo los correos electrnicos, wikis, blogs, tiendas en lnea entre
muchos otros, y no solo eso, sino que muchas organizaciones en todo el mundo han
adquirido este tipo de software como un soporte ms para garantizar su constante
crecimiento y estabilidad operacional, ya que ofrece una comunicacin directa entre
el usuario y la informacin requerida. Ofreciendo al usuario la posibilidad de acceder
a los datos de modo interactivo.
anf.
3.2.11 Herramientas utilizadas
ang.
108
3.2.11.1
Adobe Dreamweaver CS6
anh.
ani. El software de diseo web Adobe Dreamweaver CS6 proporciona una
interfaz visual intuitiva para la creacin y la edicin de sitios web en HTML y apps
para dispositivos mviles. Utiliza el Diseo de cuadrcula fluida, que hace posible la
compatibilidad multiplataforma, para crear diseos adaptables. Permitiendo revisar
los diseos antes de publicarlos con Vista previa multipantalla. Es una aplicacin en
forma de estudio basada en la forma de estudio de Adobe Flash, enfocada a la
construccin y edicin de sitios y aplicaciones Web basados en estndares. Esta
robusta aplicacin proporciona una combinacin potente de herramientas visuales de
disposicin, caractersticas de desarrollo de aplicaciones y soporte para la edicin de
cdigo.
anj.
ank. Adobe Dreamweaver CS6 es un editor de HTML visual, diseado para
desarrolladores profesionales. Dreamweaver hace muy fcil el crear complejas
pginas Web dinmicas, permitiendo que los diseadores puedan crear diferentes
entornos Web. Es compatible con las ltimas tecnologas y tendencias en el desarrollo
web, incluyendo Javascript, CSS, AJAX, XHTM, Adobe AIR, Smart Objects de
Photoshop, subversiones (SVN), frameworks Javascript y un largo etctera. La
compatibilidad con los diversos navegadores no ser un problema con Adobe
Dreamweaver gracias a la tecnologa Live View (una especie de vista previa) y con la
ayuda de Adobe BrowserLab, un servicio online con el que comparar cmo se ve tu
pgina en distintos navegadores.
anl.
anm. Desde la creacin y diseo del sitio web hasta la subida de archivos al
servidor es lo que permite controlar esta innovadora aplicacin, incluyendo la
estructuracin y codificacin del rbol de enlaces. De igual manera su entorno
amigable le brinda al usuario la posibilidad de trabajar en el desarrollo de una pgina
web o una aplicacin de una forma sencilla y segura, ya que incluye herramientas
109
para la edicin de cdigo (tales como coloreado de cdigo y terminacin automtica

de etiquetas) y material de referencia sobre HTML, hojas de estilos en cascada (CSS),
JavaScrip, ColdFusion Markup Language (CFML), Microsoft Active Server Pages
(ASP) y JavaServer Pages (JSP).
ann.
ano. Esta novedosa aplicacin permite crea diseos web compatibles con
diferentes plataformas y navegadores con el sistema de Diseo de cuadrcula fluida
basado en CSS3. Utilizando cdigo limpio y estndar del sector para desarrollar los
proyectos con mayor rapidez y eficacia para un amplio abanico de dispositivos y
ordenadores, a travs de interfaces visualmente sofisticadas y de diseos web de
pginas sin complicacin con el cdigo. Ms sobre Diseo de cuadrcula fluida, que
brinda a tu entorno la flexibilidad de adaptarse a entornos de mvil, tablets y
monitores de pc convencionales administrando eficientemente los recursos.
3.2.11.2
Adobe Fireworks
anp.
anq. Adobe Fireworks, anteriormente conocido como Macromedia Fireworks,
es una potente aplicacin destinada al diseo grfico, principalmente de elementos
web, que ofrece total integracin con otros programas tan famosos como
Dreamweaver o Flash. Haciendo uso de Fireworks es posible crear mapas vectoriales,
optimizar archivos, crear presentaciones de alta calidad, mejorar la apariencia de las
imgenes, comprimir de forma personalizable cualquier imagen, dividir componentes
de pginas entre otras funcionalidades.
anr.
ans. El programa permite tambin exportar cualquier creacin a un editor
HTML, incluso dividiendo los diseos creados en Fireworks. De igual manera genera
grficos JavaScript para elementos animados sin tener que memorizar cdigos de
programacin. En general Macromedia Fireworks es uno de los mejores programas
para el diseo grficos de pginas web. Es uno de los programas ms completos y
que mejor se adapta a las exigencias de los desarrolladores y diseadores ya que
110
ofrece casi todo tipo de grficos para web ofreciendo la opcin de una visualizacin
previa de resultados.
ant.
3.2.11.3
Microsoft Office Project 2007
anu.
anv. Debido a la importancia que posee una correcta preparacin, evaluacin y
control de proyectos, Microsoft Office Project 2007 ofrece unas slidas herramientas
de administracin de proyectos con la dosis adecuada de funcionalidad, potencial y
flexibilidad, con el fin de administrar los proyectos con mayor eficacia y eficiencia.
Es un programa que permite llevar el control de la planificacin y ejecucin de un
proyecto en base a tiempo, recursos y capital. Esta herramienta permite mantenerse
informado y controlar el trabajo, la programacin y las finanzas del proyecto,
mantener la sintona entre los equipos de proyecto y mejorar la productividad gracias
a la integracin con los conocidos programas del sistema Microsoft Office, las
eficaces opciones de elaboracin de informes, el planeamiento asistido y las
herramientas flexibles.
anw.
anx. Microsoft Project ofrece a sus usuarios la opcin de elaborar una eficiente
planificacin de actividades, llevando un seguimiento del origen de las incidencias,
teniendo en cuenta la repercusin de un cambio inesperado en el proyecto. Asimismo
permite experimentar con escenarios hipotticos, para de esta manera estar preparado
ante ciertas eventualidades manteniendo un control de las finanzas.
En forma
general, esta valiosa herramienta brinda a los planificadores la posibilidad de llevar a

cabo anlisis y seguimiento de los proyectos.
any.
3.2.11.4SmartDraw
anz.
aoa. El ambiente de modelado de negocio, potenciado por el uso del lenguaje
UML a travs de SmartDraw, una aplicacin til que permite la creacin de
111
diagramas, planos, grficos o calendarios con resultados profesionales y de forma

rpida, posee herramientas que proveen una estructura competitiva en modelado de
negocio, diseo de software, ingeniera de sistemas, arquitectura de empresas, gestin
de requisitos, pruebas y mucho ms. Esta importante herramienta de software, basada
en UML, incluye ms de sesenta mil smbolos diseados de forma profesional y ms
de 1200 plantillas especficas de la industria, ofreciendo una completa variedad de
elementos y simbologas que se adaptan a cada tipo de diagramas necesarios para el
modelado de la organizacin como fase previa al desarrollo del software, generando,
para una mayor comprensin y anlisis, una visin grfica de la realidad abordada. Su
integracin y compatibilidad con Word, PowerPoint y Excel la hace an ms atractiva
aob.
aoc. En este sentido, haciendo uso de SmarDraw, ser posible llevar a cabo
diseos de software complejos bajo las notaciones de UML. Pasando a ser esta
herramienta de modelado, un soporte para los desarrolladores de software, ya que est
caracterizada por ser flexible, extensible y suficientemente amplia como para servir
de fundamento para todas las necesidades de modelado de sistemas.
aod.
3.3
BASES LEGALES
aof.
3.3.1 Constitucin de la Repblica Bolivariana de Venezuela (1999)
aog.
aoh. Artculo 110. El Estado reconocer el inters pblico de la ciencia, la
tecnologa, el conocimiento, la innovacin y sus aplicaciones y los servicios de
informacin necesarios por ser instrumentos fundamentales para el desarrollo
econmico social y poltico del pas, as como para la seguridad y soberana nacional
() El estado garantizar el cumplimiento de los principios ticos y legales que
deben regir las actividades de investigacin cientfica, humanstica y tecnolgica.
aoi.
112
3.3.2 Decreto 3.390: publicado en la gaceta oficial N 38.095 de fecha

28/12/2004
aoj.
aok. Artculo
1.
La
Administracin
Pblica
Nacional
emplear
prioritariamente Software Libre desarrollado con Estndares Abiertos, en sus

sistemas, proyectos y servicios informticos. A tales fines, todos los rganos y entes
de la Administracin Pblica Nacional iniciarn los procesos de migracin gradual y
progresiva de stos hacia el Software Libre desarrollado con Estndares Abiertos.
aol.
aom. Artculo 3. En los casos que no se puedan desarrollar o adquirir
aplicaciones en Software Libre bajo Estndares Abiertos, los rganos y entes de la
Administracin Pblica Nacional debern solicitar ante el Ministerio de Ciencia y
Tecnologa autorizacin para adoptar otro tipo de soluciones bajo los normas y
criterios establecidos por ese Ministerio.
aon. Artculo 5. El Ejecutivo Nacional fomentar la investigacin y desarrollo
de software bajo modelo Software Libre desarrollado con Estndares Abiertos,
procurando incentivos especiales para desarrolladores.
aoo.
3.3.3 Decreto N 825: publicado en Gaceta Oficial de la Repblica
Bolivariana de Venezuela de fecha 22/05/2000
aop.
aoq. Artculo 1. Se declara el acceso y el uso de Internet como poltica
prioritaria para el desarrollo cultural, econmico, social y poltico de la Repblica
Bolivariana de Venezuela.
aor.
aos. Artculo 3. Los organismos pblicos debern utilizar preferentemente
Internet para el intercambio de informacin con los particulares, prestando servicios
comunitarios a travs de Internet, tales como bolsas de trabajo, buzn de denuncias,
trmites comunitarios con los centros de salud, educacin, informacin y otros, as
como cualquier otro servicio que ofrezca facilidades y soluciones a las necesidades de
113
la poblacin. La utilizacin de Internet tambin deber suscribirse a los fines del

funcionamiento operativo de los organismos pblicos tanto interna como
externamente.
aot.
aou.
aov.
aow.
aox.
aoy.
aoz.
apa.
apb.
3.4 DEFINICIN DE TRMINOS
apc.
apd. Accin: es la unidad fundamental de especificacin de comportamiento
en un diagrama de actividades. (Montilva, J. y Barrios, J., 2006).
ape.
apf. Actividad: conjunto estructurado de acciones o tareas realizadas por uno
o ms actores con la finalidad de alcanzar un objetivo predefinido. Una actividad
utiliza recursos (insumos) para generar productos o prestar servicios. (Montilva, J. y
Barrios, J., 2007).
apg.
aph. Actor del negocio: rol o funcin que ejerce una persona (o sistema) que
interacta con una aplicacin SIE o participa, en modo alguno, en su desarrollo. Un
actor est vinculado de alguna manera al desarrollo del Sistema de Informacin
Empresarial (SIE); bien porque participa directamente en su desarrollo o porque tiene
la necesidad de utilizar este sistema. (Montilva, J. y Barrios, J., 2007).
api.
apj. Aplicacin informtica: un conjunto organizado de datos, programas de
computacin y documentacin que provee servicios de informacin a sus usuarios.
Por servicios de informacin se entiende un conjunto de funciones automatizadas de
114
entrada/adquisicin de datos, gestin de datos y produccin de informacin para

apoyar las actividades que realizan sus usuarios. (Montilva, J. y Barrios, J., 2007).
apk.
apl. Atributo: es una especificacin que define una propiedad de un Objeto,
elemento o archivo.
apm.
apn. Business: negocio.
apo.
app. Caso de uso: es una tcnica para la captura de requisitos potenciales de
un nuevo sistema o una actualizacin software.
apq. Diagrama: es la representacin grfica de un conjunto de elementos y sus
relaciones.
apr.Los diagramas se utilizan para visualizar un sistema desde diferentes
perspectivas.
aps.
(Montilva, J. y Barrios, J., 2006).
apt.
apu. Diseo: se define como el proceso previo de configuracin mental, prefiguracin, en la bsqueda de una solucin en cualquier campo. Es la concepcin
original de un objeto, software u obra destinados a su produccin.
apv.
apw. Dominio de la aplicacin: sistema empresarial para el cual una
aplicacin informtica presta sus servicios de informacin. Es el sistema ampliado,
ambiente o contexto en el cual una aplicacin opera. (Montilva, J. y Barrios, J.,
2007).
apx.
apy. Evento: es una accin de muy corta duracin que activa la ejecucin de
un proceso de negocio, una actividad o una accin y/o cambia el estado de un objeto
de negocio.
apz.
(Montilva J. y Barrios J., 2006).
115
aqa.
aqb. Flujo de control: indica el orden de ejecucin de las acciones. (Montilva,
J. y Barrios, J., 2006).
aqc.
aqd. Gestin: accin y al efecto de administrar o gestionar un sistema negocio.
aqe.
aqf. Herramienta de desarrollo de software: sistema empresarial para el
cual una aplicacin informtica presta sus servicios de informacin. Es el sistema
ampliado, ambiente o contexto en el cual una aplicacin opera. (Montilva, J. y
Barrios, J., 2007).
aqg.
aqh. Instanciacin del mtodo: proceso mediante el cual un equipo de
desarrollo de aplicaciones aplica el mtodo WATCH y lo adecua a las caractersticas
propias de un proyecto y aplicacin particular. (Montilva, J. y Barrios, J., 2007).
aqi.
aqj. Lenguaje de modelado: lenguaje artificial, generalmente de carcter
grfico o textual, empleado en el desarrollo de software y en el modelado de sistemas
para representar diferentes aspectos de una aplicacin. Ejemplos, BPML, BPMN,
UML. (Montilva, J. y Barrios, J., 2007).
aqk.
aql. Mensaje: comunicacin dirigida a un objeto, que le ordena que ejecute
uno de sus mtodos con ciertos parmetros asociados al evento que lo gener.
aqm.
aqn. Mtodo de desarrollo de aplicaciones: conjunto de modelos que
describen, en general, que deben hacer los equipos de desarrollo para un elaborar una
aplicacin informtica. (Montilva, J. y Barrios, J., 2007).
aqo.
116
aqp. Misin: es el propsito de la organizacin que la distingue de otras

organizaciones y que establece el cubrimiento de operaciones, productos, servicios y
personal para lograr dicho propsito. (Montilva, J. y Barrios, J., 2006).
aqq.
aqr. Modelo: representacin de un proceso, producto u otro elemento que
interviene en el desarrollo de un sistema o aplicacin. (Montilva, J. y Barrios, J.,
2007).
aqs.
aqt. Navegador Web: es una aplicacin software que permite al usuario
recuperar y visualizar documentos de hipertexto, comnmente descritos en HTML,
desde servidores web de todo el mundo a travs de Internet.
aqu.
aqv. Negocio: es una empresa u organizacin o una parte de ella. (Montilva, J.
y Barrios, J., 2006).
aqw. Planificacin: es el proceso de establecer metas y elegir medios para
alcanzar dichas metas (Stoner, 1996).
aqx.
aqy. Proceso: conjunto estructurado de actividades que son ejecutadas por un
conjunto de actores con la finalidad de cumplir con objetivos pre-establecidos. Un
proceso transforma un conjunto de recursos (insumos: energa, informacin y materia
prima) en un conjunto de productos o servicios. (Montilva, J. y Barrios, J., 2007).
aqz.
ara. Regla de negocio: conjunto de condiciones que gobiernan un proceso de
negocio de tal manera que ste pueda ocurrir de una manera aceptable para la
empresa. (Montilva, J. y Barrios, J 2006).
arb.
arc. Requisito: condicin necesaria para algo.
ard.
117
are. Rol: cargo o funcin que es ejercido por un actor en el marco del
proyecto de desarrollo de aplicaciones de un SIE. (Montilva, J. y Barrios, J., 2007).
arf.
arg. Servidor: es cualquier recurso de cmputo dedicado a responder a los
requerimientos del cliente. Los servidores pueden estar conectados a los clientes a
travs de redes LANs o WANs, para proveer de mltiples servicios a los clientes y
ciudadanos tales como impresin, acceso a bases de datos, fax, procesamiento de
imgenes, etc. (Gutirrez, J., 2005).
arh.
ari.
Sistema de informacin empresarial (SIE): es un sistema integrado por
un conjunto de procesos de negocio que son ejecutados por los actores de la empresa
con la finalidad de alcanzar objetivos preestablecidos. (Montilva, J. y Barrios, J.,
2007).
arj.
ark. Sistema: conjunto de entes independientes entre s mismos que se
encuentran en interrelacin con ellos mismos y con el ambiente que los rodea.
(Montilva y Barrios,
arl. 2006).
arm.
arn. Software: equipamiento lgico o soporte lgico de un sistema
informtico; comprende el conjunto de los componentes lgicos necesarios que hacen
posible la realizacin de tareas especficas.
aro.
arp. Software Libre: programa de computacin cuya licencia garantiza al
usuario acceso al cdigo fuente del programa y lo autoriza a ejecutarlo con cualquier
propsito, modificarlo y redistribuir tanto el programa original como sus
modificaciones en las mismas condiciones de licenciamiento acordadas al programa
original, sin tener que pagar regalas a los desarrolladores previos.
arq.
118
arr.
Stakeholder: actor, grupo de actores, unidad organizacional de la
empresa usuario externo que participa directamente en el desarrollo de una

aplicacin SIE o que tiene la necesidad de utilizar la aplicacin. (Montilva, J. y
Barrios, J., 2007).
ars.
art.
Usuario: individuo que utiliza una computadora, sistema operativo,
servicio, aplicacin o cualquier sistema informtico.
aru.
arv.
CAPTULO IV
MARCO METODOLGICO
arw.
4.1 TIPO Y NIVEL DE LA INVESTIGACIN

arx.
ary. Hurtado Jacqueline (2008) explica claramente la importancia de la
investigacin como proceso bsqueda de conocimiento, sealando:
arz.
asa.
La investigacin es una bsqueda de conocimiento novedoso, es un
devenir signado por el momento histrico, el ser en situacin del
investigador y el contexto, entre otros aspectos. Es la actividad que en
pro del conocimiento, se realiza sobre un evento, en un mbito
determinado. (p. 22).
asb.
asc. Con referencia a lo anterior, se hace oportuno resaltar que existen
diversos tipos de investigacin. Ahora bien, segn la clasificacin original de Hurtado
de Barrera, Jacqueline y Barrera Morales, Marcos (1995), producto de un estudio
exhaustivo de los aspectos relacionados con la fundamentacin antropolgica y
filosfica de la investigacin, es posible afirmar que el trabajo a realizar sobre la
ingeniera de requisitos aplicado a los procesos de instalacin y reparacin de averas,
realizados por planta externa para la unidad de conmutacin (CX) de la central digital
Maturn-centro, C.A.N.T.V. estado Monagas, se encuentra enmarcado dentro del tipo
de investigacin proyectiva, sobre la cual Hurtado J. (2008), en su libro El Proyecto
de Investigacin expone lo siguiente:
asd.
ase. Este tipo de investigacin propone soluciones a una situacin
determinada a partir de un proceso de indagacin. Implica explorar,
119
describir, explicar y proponer alternativas de cambio, mas no

necesariamente ejecutar la propuesta. Todas las investigaciones
120
102
asf. que implican el diseo o creacin de algo con base en un proceso

investigativo tambin entran en esta categora. (p.114).
asg.
ash. Por otra parte, y en conformidad con lo que el autor Barrera Morales
(1995) recalca en relacin al nivel de investigacin, es importante destacar que la
investigacin para este estudio ser desarrollada dentro de un nivel comprensivo. Y
en referencia a ste ltimo Hurtado J. (2008) puntualiza que: El nivel comprensivo
alude a la explicacin de las situaciones que generan el evento. (p. 92).
asi.
4.2 DISEO DE LA INVESTIGACIN
asj.
ask. El diseo de la investigacin permite explicar diversos aspectos
operativos de la misma y debe ser entendido como un esbozo de la manera en que el
investigador piensa cumplir con su investigacin dentro de su estrategia general de
trabajo. Este se refiere al conjunto de procedimientos por medio de los cuales es
posible recolectar conceptos, ideas, experiencias y dems informacin vital para el
correcto desarrollo de un proceso investigativo. Se adhiere entonces, la
conceptualizacin, que en relacin al diseo, la autora Hurtado J. (2008) sostiene:
asl.
asm. El diseo alude a las decisiones que se toman en cuanto al
proceso de recoleccin de datos (y experimentacin en el caso de las
investigaciones confirmatorias y las evaluativas), que permitan al
investigador lograr la validez interna de la investigacin, es decir, tener
un alto grado de confianza de que sus conclusiones no son erradas. (p.
147).
asn.
aso. En relacin a esto, y segn los diversos criterios para determinar el diseo
de investigacin en relacin a las fuentes de recoleccin de datos, sugeridos por
Hurtado J. (2008), se puede establecer que el presente trabajo se encuentra enmarcado
dentro de un diseo de fuentes mixtas, debido a que los datos recolectados abarcan
tanto fuentes vivas como documentales. (p. 148).
103
4.3 POBLACIN Y MUESTRA

asp.
asq. El diccionario de la RAE (2001) define la poblacin, en su acepcin
sociolgica, como un Conjunto de los individuos o cosas sometido a una evaluacin
estadstica mediante muestreo. En otras palabras, la poblacin es el conjunto de
elementos con caractersticas comunes que constituyen un fenmeno bajo estudio con
la finalidad de cumplir algn propsito, por lo general, el entendimiento del mismo.
asr.
ass. En este caso en particular, la poblacin est constituida por el personal de
planta interna que labora dentro de la unidad de conmutacin y los trabajadores
adscritos al departamento de planta externa involucrados de forma directa con los
procesos de instalacin y reparacin de averas, realizados para la central digital
Maturn-centro, este incluye los empleados de cooperativas, contratistas y parte del
personal fijo perteneciente a la compaa telefnica. Como consecuencia de lo antes
planteado, se puede resumir que la poblacin o universo de individuos en estudio,
est integrada por un total de 58 empleados.
ast.
asu. Por otra parte, el autor Arias (2006) sostiene que
la muestra es
subconjunto representativo y finito que se extrae de la poblacin accesible (p.83). En

este caso se tiene que la poblacin es de tipo finita, esto hace que sea fcil de manejar
y estudiar. Por consiguiente, no es necesario extraer del conjunto de elementos en
estudio una muestra, puesto que la poblacin entera se establece como tal. Es decir, la
muestra est conformada por la misma cantidad de individuos que constituyen a la
poblacin. Fidias Arias (2006), sustenta esto ltimo indicando lo siguiente: Si la
poblacin, por el nmero de unidades que la integran, resulta accesible, no ser
necesario extraer una muestra. En consecuencia, se podr investigar u obtener datos
de toda la poblacin objetivo (p.82).
asv.
asw.
104
4.4 TCNICAS E INSTRUMENTOS DE RECOLECCIN DE DATOS

asx.
asy. Las tcnicas de recoleccin de datos son usadas por el investigador para
la obtencin de informacin necesaria, stas permiten sustraer de diferentes medios
los datos, ideas o experiencias que posteriormente sern transformados en la
informacin requerida para el avance del proyecto investigativo. Hurtado J. (2008),
en relacin a las tcnicas e instrumentos de recoleccin de datos, plantea que:
asz.
ata. Las tcnicas tienen que ver con los procedimientos utilizados para
la recoleccin de datos, es decir, el cmo. Estas pueden ser de revisin
documental, observacin, encuesta, y tcnicas socio mtricas, entre
otras. Los instrumentos representan la herramienta con la cual se va a
recoger, filtrar y codificar la informacin, es decir, el con qu. (p. 153).
atb.
atc. En base a lo ltimo citado, hay que resaltar que las tcnicas que sern
aplicadas para la recoleccin de datos son la revisin documental, la entrevista y la
observacin, las cuales servirn como mecanismos para recoger y registrar la
informacin. Una de las tcnicas ms importantes es la revisin documental, la cual
consiste en explorar, estudiar y analizar registros informativos que sirven de
referencia til para la investigacin. Hurtado J. (2008), aclara que la tcnica de
revisin documental se da cuando La informacin est contenida en textos escritos,
ya sea porque la unidad de estudio es un texto, o documento, o porque ya fue
recogida y asentada por otra persona. (p. 154).
atd.
ate. La entrevista, es otra tcnica de gran relevancia sobre la cual se apoya el
investigador, y que ser de gran utilidad en el desarrollo de este trabajo. Esta no es
ms que un dialogo entre dos o ms personas, no es casual sino que esta previamente
establecido, compartiendo intereses y expectativas de ambas partes. Hurtado J. (2008)
sostiene en que en una entrevista La informacin se recoge solicitndola a otra
105
persona. El investigador no puede tener la experiencia directa del evento. Es otro

quien la tiene. (p. 154).
atf.
atg. De igual manera ser empleada la tcnica de observacin, la cual se lleva
a cabo observando o experienciando. La observacin como tcnica de recoleccin de
datos, consiste en observar atenta y detalladamente algn fenmeno, registrando la
informacin para ser analizada posteriormente. Hurtado J. (2008) recalca que en esta
tcnica La informacin se recoge en presencia del evento, observando o participando
de l. El investigador tiene acceso al evento. (p. 154).
ath.
4.5 TCNICAS DE ANLISIS DE DATOS
ati.
atj.
Con referencia a las tcnicas de anlisis de datos, Hurtado J. (2008)
expresa que Obtenidos los datos, ser necesario analizarlos a fin de descubrir su
significado en trminos de los objetivos planteados al principio de la investigacin;
en este punto de la metodologa el investigador debe especificar qu tipo de anlisis
usar. (p. 152). Es decir, una vez recolectados los datos es necesario realiza un
exhaustivo anlisis de los mismos con el objetivo principal de transformar toda la
data en informacin valiosa que sirva para una mayor comprensin del fenmeno en
estudio.
atk.
atl.
En
esta
investigacin, el conjunto de datos recolectados ser interpretado para la obtencin de

un mayor entendimiento haciendo uso de la tcnica de anlisis de contenido
propuesta por Hurtado J. (2008), quien afirma que El anlisis de contenido puede ser
utilizado en investigaciones descriptivas, cuando se pretende hacer un diagnstico y
agrupar contenidos significativos de una serie de entrevistas, conversaciones u
observaciones. (p.57).
atm.
106
atn.
ato.
4.6 DISEO OPERATIVO
atp.
atq. Con la finalidad de llevar a cabo el desarrollo de este trabajo, y como se
ha mencionado en oportunidades anteriores, se har uso del mtodo Gray Watch, el
cual es una metodologa robusta y verstil para ser empleada en el desarrollo de
software para aplicaciones empresariales. A travs de sus tres (3) fases se generarn
todos los mecanismos y documentos requeridos para el logro de las metas y objetivos
planteados anteriormente. Es oportuno acotar que las actividades que componen cada
una de las fases de la metodologa fueron adaptadas a las necesidades y
requerimientos actuales presentes en el dominio del negocio, con el objetivo de lograr
el presente trabajo de anlisis. A continuacin se presentan las diferentes actividades,
distribuidas en etapas de trabajo propuestas por la metodologa seleccionada.
atr.
ats.Etapa I: estudio de la situacin actual.
att.
atu. El desarrollo de esta fase inicial permitir diagnosticar e identificar la
situacin actual que se presenta en el distribuidor de la central digital de C.A.N.T.V.,
ubicada en la zona centro de Maturn, estado Monagas, de igual manera se busca
analizar y evaluar cada uno de los procesos que constituyen el motor operativo dentro
de la unidad de conmutacin, es por ello que para lograr esto, es necesario que en esta
primera etapa se recolecte toda la informacin relacionada con cada uno de los
procesos para posteriormente analizar el funcionamiento de cada uno de ellos. Est
compuesta de las siguientes actividades:
atv.
a) Primera visita a las instalaciones de la unidad de conmutacin del distribuidor
Maturn centro.
107
b) Reconocimiento de las instalaciones y estructura operacional de la central

digital de C.A.N.T.V.
c) Revisin de informacin documentada en la empresa a travs de manuales y
normas de procedimientos.
d) Adaptacin del mtodo a las necesidades del cliente.
e) Descripcin de los procesos principales llevados a cabo dentro de las
instalaciones de la central digital, especficamente en la unidad de conmutacin
(CX).
f) Entrevista no estructurada con tcnico encargado de proceso de instalacin y
averas realizado por planta externa.
g) Visita de campo a los procesos de instalacin y reparacin de averas en zonas
forneas.
h) Estudio de las necesidades y deficiencias del
proceso de instalacin y
reparacin de averas, realizado por planta externa, con soporte en CX para

determinar el alcance del sistema deseado.
atw.
atx.Etapa II: modelo de negocio.
aty.
atz. Esta segunda fase permitir desarrollar los diferentes modelos de
procesos que describirn el funcionamiento actual de la unidad de conmutacin. De
esta manera se busca llevar a cabo una representacin lo ms exacta posible de la
realidad, con la finalidad de comprender la complejidad de los procesos de la unidad
de conmutacin (CX) de la central digital Maturn-centro perteneciente a la compaa
telefnica C.A.N.T.V. Se compone de las siguientes actividades:
aua.
a) Delimitacin del sistema de negocio.
b) Estructuracin y validacin de la jerarqua de objetivos.
108
c) Elaboracin de la cadena de valor.

d) Descomposicin de los procesos correspondientes a la unidad de conmutacin
(CX).
e) Validacin del modelo de procesos.
f) Determinacin de objetos involucrados en el negocio.
g) Organizacin de objetos de negocio.
h) Construccin del diagrama de objetos.
i) Validacin del modelo de objetos del negocio.
j) Identificacin, representacin y validacin de las reglas del negocio.
k) Identificacin de los actores que intervienen en los procesos de CX junto con
sus responsabilidades.
l) Determinacin de los eventos y representarlos a travs de modelos.
m) Validacin del modelo de eventos.
aub.
auc.
Etapa III: ingeniera de requisitos.
aud.
aue. Por ltimo, en esta fase del proyecto se realizarn todas las tareas
relacionadas con la determinacin de las necesidades y requisitos para el diseo de la
aplicacin de consulta de informacin que ser propuesta para los procesos de
instalacin y reparacin de averas. Esta etapa est constituida por las siguientes
actividades:
auf.
a) Establecimiento de los objetivos de la aplicacin.
b) Delimitacin del dominio del software.
109
c) Recoleccin de los requisitos de la aplicacin en base a las necesidades

actuales.
d) Estudio de los requisitos de software y hardware.
e) Validacin de requisitos.
f) Organizacin y clasificacin de los requisitos.
g) Definicin y validacin de las relaciones entre requisitos.
h) Descripcin de los requisitos en funcin de las necesidades del cliente.
i)
Diseo de interfaz de prototipo de aplicacin.
j) Definicin de pruebas y parmetros de la aplicacin para validar prototipo.

k) Evaluacin de posibles cambios en los requisitos.
aug.
auh.
aui.
auj.
auk.
aul.
aum.
aun.
auo.
aup.
auq.
aur.
110
aus.
4.7 CUADRO OPERATIVO
aut.Cuadro 19. Cuadro Operativo.
auu.
Eta
p
a
s
auv.
M
auz.
avf.
ava.
auw.
Prod
u
c
t
o
s
avp.
avq.
avb.
avg.
avc.
avh.
avi.
D
o
c
u
m
e
n
t
o
avj.
avk.
avl.
I
:
E
s
t
u
d
i
o
d
avm.
avn.
avo.
M
d
e
i
n
i
c
i
o
d
e
l
p
r
o
y
e
c
t
aux.
Act
ividades
auy.Objeti
vos
Especf
icos
avw.
awd.
Primera
visita a
las
instalacio
nes de la
unidad
de
conmuta
cin del
distribuid
or
Maturncentro. 1. Diagnosticar
la
avx. situacin actual de
Reconoci
los procesos de la
miento
de
las
unidad
de
instalacio
conmutacin
nes
y
perteneciente a planta
estructur
interna
del
a
operacio
distribuidor Maturnnal de la
centro para detectar
central
las fallas de la
digital de
C.A.N.T.
misma.
V.
awe.
awf.
Revisin awg.
de
awh.
informac awi.
awj.
in
111
o
.
l
a
s
i
t
u
a
c
i
n
a
c
t
u
a
l
avd.
ave.
P
l
a
n
i
n
t
e
g
r
a
l
d
e
l
p
r
o
y
e
c
t
o
.
D
o
c
u
m
e
n
t
o
documen
tada en la
empresa
a travs
de
manuales
y normas
de
procedim
ientos.
avy. Adaptaci
n
del
mtodo a
las
necesida
des del
cliente.
avz. Descripci
n de los
procesos
principal
es
llevados
a
cabo
dentro de
las
instalacio
nes de la
Central
Digital
de
C.A.N.T.
V,
especfic
amente
en
la
Unidad
de
Conmuta
cin
(CX).
awa.
Entrevist
awk.
awl.
awm.
awn.
awo.
112
d
e
i
n
s
t
a
n
c
i
a
c
i
n
d
e
l
m
t
o
d
o
.
avr.
P
l
a
n
d
e
g
e
s
t
i
n
d
a
no
estructur
ada con
tcnico
encargad
o
de
proceso
de
instalaci
n
y
averas
realizado
por
planta
externa.
awb.
Visita de
campo al
proceso
de
instalaci
n
y
reparaci
n
de
averas
en zonas
forneas.
awc.
Estudio
de
las
necesida
des
y
deficienc
ias
del
proceso
de
instalaci
n
y
reparaci
n
de
averas,
realizado
por
planta
externa
113
e
r
i
e
s
g
o
s
.
avs.
P
l
a
n
d
e
g
e
s
t
i
n
d
e
l
a
c
o
n
f
i
g
u
r
a
c
i
con
soporte
en
CX
para
determin
ar
el
alcance
del
sistema
deseado.
114
n
.
avt.
P
l
a
n
d
e
g
e
s
t
i
n
d
e
a
s
e
g
u
r
a
m
i
e
n
t
o
d
e
l
a
c
a
115
l
i
d
a
d
avu.
avv.
awp.
awq.
Etapa
awv.
aww.
awx.
awy.
awz.
axa.
axb.
axc.
axd.
II:
Modelado
de negocio
axe.
axf.
axg.
axh.
axi.
Cuadro 19. (Cont.).
awr.
Metodo
loga
axj.
axk.
axl.
axm.
axn.
axo.
axp.
axq.
axr. Mtodo
Watch
aws.
Prod
uctos
axs.
axt. Modelado
de
objetivos
axu.
axv.
axw.
axx.
axy.
axz. Modelado
de
procesos
del
negocio
aya.
ayb.
ayc.
ayd.
aye.
Modelo de
objetos
del
negocio
ayf.
ayg.
ayh.
ayi.
ayj.
ayk.
awt.
Activida
ayv.
ayw.
-Delimita
sistema
negocio.
ayx. -Estructuracin
validacin de
jerarqua
objetivos.
ayy.
ayz. -Elaboracin d
cadena de valo
aza. -Descomposici
de
proc
correspondient
la
unidad
conmutacin (
azb. -Validacin
modelo
procesos.
azc.
azd. -Determinaci
objetos
involucrados e
negocio.
aze. -Organizacin
objetos de neg
azf. -Construccin
diagrama
objetos.
azg. -Validacin
modelo de ob
116
ayl.
aym.
Mode
lo de
reglas de
negocio
ayn.
ayo.
ayp.
Modelo de
actores
del
negocio
ayq.
ayr.
ays.
ayt.
ayu.
Modelo de
eventos
del
negocio
azw.
azx.
azz. Pro
baa.
bab.
et
duc
Activi
Objetiv
od
to
da
os
ol
de
Es
og
pec
a
bac.
bad.
baj.
fic
bak.
bal.
bam.
bae.
Descub
rim
baf.
azi. -Identificacin
los actores
intervienen en
procesos de
junto con
responsabilida
azj.
azk.
-Determinaci
los
eventos
representarlos
travs de mode
azl. -Validacin
modelo de eve
azm.
Cuadro 19. (Cont.).
azy. M
Et
del negocio.
azh. -Identificacin
representacin
validacin de
reglas del neg
ient
o
de
req
bav. Es
ta
bl
ec
im
ie
nt
o
de
lo
s
ob
jet
os
bbf. 3.
De
ter
mi
na
r
los
req
uis
ito
s
fun
cio
nal
117
bag.
uisi
M
bah.
tos
ban.
od
bao.
bai.
bap.
II
baq.
at
bar.
ch
An
lis
is
de
req
uisi
tos
bas.
Esp
ecif
icac
in
de
req
uisi
tos
bat.
Val
ida
ci
n
de
iv
os
de
la
ap
lic
ac
i
n.
baw.
D
eli
mi
ta
ci
n
de
l
do
mi
ni
o
de
l
so
ft
w
ar
e.
R
ec
ol
ec
ci
n
de
lo
s
re
qu
isi
to
s
es
y
no
fun
cio
nal
es
qu
e
de
ber
co
nte
ner
la
apl
ica
ci
n a
inc
or
po
rar
a
los
pr
oce
sos
de
ins
tal
aci
n
y
rep
ara
ci
n
de
ave
ra
s.
bbg.
118
req
uisi
tos
bau.
Ges
tin
de
la
ap
lic
ac
i
n.
bax. Es
tu
di
o
de
re
qu
isi
to
s
de
so
ft
w
ar
e
y
ha
rd
w
ar
e.
bay. Va
lid
ac
i
n
de
re
qu
isi
to
s.
baz. Or
ga
4.
Ev
alu
ar
los
req
uer
imi
ent
os
de
co
mp
ati
bili
da
d
de
sof
tw
are
y
ha
rd
wa
re
en
fun
ci
n a
sop
ort
e y
cos
tos.
bbh.
5.
De
sar
rol
lar
la
119
ni
za
ci
n
y
cl
as
ifi
ca
ci
n
de
lo
s
re
qu
isi
to
s.
D
efi
ni
ci
n
de
la
s
rel
ac
io
ne
s
en
tre
re
qu
isi
to
s.
Va
lid
ac
i
ing
eni
er
a
de
req
uis
ito
s
de
la
apl
ica
ci
n
de
co
ns
ult
a
de
inf
or
ma
ci
n
pa
ra
los
pr
oce
sos
de
ins
tal
aci
n
y
rep
ara
ci
n
de
ave
ra
120
n.
bba. C
on
str
uc
ci
n
de
do
cu
m
en
to
de
es
pe
cif
ic
ac
i
n.
bbb.D
es
cri
pc
i
n
de
lo
s
re
qu
isi
to
s
en
fu
nc
i
n
de
la
s
s,
rea
liz
ad
os
po
r
pla
nta
ext
ern
a
pa
ra
la
uni
da
d
de
co
nm
uta
ci
n
(C
X)
de
la
Ce
ntr
al
Di
git
al
Ma
tur
nCe
ntr
o,
C.
A.
N.
T.
V.
121
ne
ce
si
da
de
s
de
l
cli
en
te.
Di
se
o
de
int
er
fa
z
de
pr
ot
oti
po
de
ap
lic
ac
i
n.
D
efi
ni
ci
n
de
pr
ue
ba
s
y
pa
est
ad
o
Mo
na
gas
.
bbi.
122
r
m
etr
os
de
la
ap
lic
ac
i
n
pa
ra
va
lid
ar
pr
ot
oti
po
.
bbc.
bbd.El
ab
or
ac
i
n
de
pr
oc
es
os
de
ge
sti
n
.
bbe. E
va
lu
ac
i
123
n
de
po
si
bl
es
ca
m
bi
os
en
lo
s
re
qu
isi
to
s.
bbj.
CAPTULO V
bbk.
RESULTADOS
bbl.
bbm.
Este captulo refleja de forma detalla los resultados
obtenidos durante el desarrollo del presente proyecto junto con un respectivo anlisis
e interpretacin de los mismos. Destacando el fiel cumplimientos de los objetivos
establecidos una vez finalizado el proceso tcnico de anlisis aplicado a la unidad de
conmutacin (CX), de la central digital Maturn-centro, perteneciente a la compaa
telefnica C.A.N.T.V, el cual abarc el modelado del dominio y la ingeniera de
requisitos, considerada esta ltima como base fundamental de esta investigacin.
bbn.
bbo.
Precisando de una vez, es necesario sealar que el mtodo
Watch, herramienta de desarrollo seleccionada que sirvi como patrn de trabajo,

ofreci, mediante la instanciacin del mtodo, la opcin de ser moldeado y adaptado
a la situacin en estudio. En consecuencia, fueron establecidas tres etapas
fundamentales: estudio de la situacin actual, modelado de negocio e ingeniera de
requisitos. De esta manera, los resultados sern plasmados a travs de estas tres fases,
siendo presentados cada uno de ellos en la etapa especfica en la que se generaron.
bbp.
5.1 ETAPA I: ESTUDIO DE LA SITUACIN ACTUAL
bbq.
bbr.
Como paso inicial al estudio de la situacin que se
manifestaba en la unidad de conmutacin, se hizo uso de la tcnica de observacin,

dado que esa es la primera forma de contacto o de relacin con los objetos que van a
ser estudiados. Esta tcnica la constituye un proceso de atencin, recopilacin y
registro de informacin, haciendo uso de los sentidos (vista, odo, olfato, tacto,
sentidos kinestsicos, y cenestsicos),
124
114
bbs.
para estar al pendiente de los sucesos y analizar los eventos
ocurrentes en una visin global, en todo un contexto natural, de este modo la

observacin no se limita al uso de la vista.
bbt.
bbu. Siguiendo las pautas establecidas por Hurtado J. (2008) en base a la
tcnica de observacin, se realizaron guas de observacin y registros anecdticos que
permitieron documentar y almacenar de manera escrita la informacin referente a la
situacin actual del departamento, sus focos problemticos, los actores que
intervienen en los procesos y el desenvolvimiento de los mismos en relacin a los
procesos, esto sirvi de gran ayuda ya que el proceso de observacin era continuo,
llevndose a cabo durante toda la estada tanto en la unidad CX como en las salidas
de campo.
bbv.
bbw.
De igual manera, con el fin de maximizar el entendimiento
de la realidad presente, se emplearon entrevistas no estructuradas a diferentes actores

involucrados en los procesos. Para ello, Hurtado J. (2008) establece como principal
instrumento las guas de entrevistas, en ella el investigador seala los temas o
aspectos en torno a los cuales va a preguntar. (p. 161). El objetivo de esta tcnica fue
principalmente detectar el nivel de percepcin de los empleados en relacin al
problema, en este sentido se obtuvo nuevos conocimientos que no se encontraban
documentados y que eran propios del individuo, pues estos haban sido adquiridos
por los entrevistados a lo largo de su experiencia laboral.
bbx.
bby.
Por otra parte, se hizo uso de la revisin documental,
bsicamente de manuales y procedimientos del departamento. Esta tcnica de

recoleccin de datos, contribuy a conocer el funcionamiento interno en lo que lo
que respecta a descripcin de tareas, ubicacin, requerimientos, a los puestos
responsables de su ejecucin y a visualizar los lmites del dominio del negocio.
bbz.
115
bca.
Una vez que fue aumentado el grado de conocimiento de la
situacin actual en la unidad de conmutacin, fue posible entonces continuar, en esta

primera fase de anlisis, con los productos generados a partir de la aplicacin del
mtodo WATCH, y que son el resultado de los procesos de gestin y soporte, como
paso inicial al desarrollo de los procesos tcnicos propios del desarrollo de la
aplicacin empresarial.
bcb.
bcc.
Inicialmente se generaron los productos que conciernen a los
procesos de gestin, estos son: el documento enunciado del proyecto, documento

inicio del proyecto, documento instanciacin del mtodo y el plan integral del
proyecto. Cada uno de estos documentos surgi de una serie de actividades de tipo
gerencial necesarias para asegurar que la ejecucin del proyecto se realice de forma
exitosa.
En relacin a esto ltimo, el documento enunciado del proyecto y el
documento inicio del proyecto fueron utilizados para decidir si el proyecto era
iniciado o postergado. Y los documentos de instanciacin del mtodo y del plan
integral, especifican la adaptacin de la metodologa de trabajo junto con la gestin
de ejecucin del proyecto.
bcd.
bce.
Posterior a esto, se realizaron los procesos de soporte que
permiten gestionar tres aspectos muy importantes dentro del desarrollo del proyecto:
los riesgos que puedan presentarse, la calidad de los productos generados y la
configuracin de la aplicacin. Cada uno de los productos generados durante los
procesos de gestin y soporte del proyecto, sern presentados a continuacin:
a) Documento Enunciado del Trabajo.
b) Documento Inicio del Proyecto.
c) Documento Instanciacin del Mtodo.
d) Plan Integral del Proyecto.
116
bcf.
Compaa Annima Nacional Telfonos de Venezuela

Gerencia Red Monagas
bcg.
Ingeniera de requisitos aplicado a los procesos de
instalacin y reparacin de averas, realizados por planta externa para la unidad de

conmutacin (CX) de la central digital Maturn-centro, C.A.N.T.V. estado Monagas.
bch.
ENUNCIADO DEL TRABAJO DE PROYECTO
bci.
Versin <1.0>
bcj.
bck.
bcl.
bcm.
Descripcin
Autor
bcn.
Fecha
bco.
Oscar J. Ruiz
bcr.
Versin
bcp.
bcq.
Versin
27/07/2011
0.89
bcs.
bct.
preliminar propuesta.
bcu.
Primera
Oscar J. Ruiz
bcv.
16/08/2011
0.94
bcw.
bcx.
correccin.
bcy.
Segunda
Oscar J. Ruiz
bcz.
31/08/2011
0.99
bda.
bdb.
correccin.
bdc.
Versin final
06/09/2011
del producto.
Oscar J. Ruiz
bdd.
1. Introduccin.
bde.
bdf.
1.00
El documento enunciado del trabajo del proyecto es el
primer documento preliminar generado a partir de la metodologa WATCH. Este debe

ser realizado antes de que el proyecto sea iniciado formalmente, es por ello que
antecede al documento inicio del proyecto. En este sentido, el documento enunciado
del trabajo presenta una descripcin general del software empresarial que deber ser
desarrollado junto con su justificacin una vez que el proyecto sea aprobado. De igual
manera refleja de forma muy general los requisitos de la aplicacin y el alcance de la
misma.
bdg.
2. Aplicacin que el proyecto deber realizar.
bdh.
117
bdi.
La aplicacin que deber ser desarrollada a partir de la
ingeniera de requisitos propuesta, consiste en un sistema de software va web que

permita acceder
bdj.
bdk.

y conectar de forma remota y en tiempo real al servidor de la compaa para
de esta manera consultar e intercambiar informacin almacenada en la base de datos,

aportando a los empleados de planta externa los datos requeridos para completar sus
actividades sin interrumpir las que se realizan dentro de la unidad de conmutacin.
Esta aplicacin debe ser presentada como solucin al problema de los procesos de
instalacin y reparacin de averas. Todo esto permitir, por una parte, delimitar
responsabilidades, unificar criterios de trabajo, estandarizar las tareas y las
capacitaciones a nuevos integrantes, registrar modificaciones y/o actualizaciones de
una manera ms sencilla, y as mismo, solventar la deficiencia presente en el proceso
de instalacin y reparacin de averas, realizado por planta externa.
bdl.
3. Necesidad de implementar el sistema.
bdm.
bdn.
El departamento de conmutacin de la central digital
Maturn-centro, perteneciente a la compaa annima nacional telfonos de
Venezuela (C.A.N.T.V.) es la unidad encargada de la realizacin de rdenes de trabajo
que requieran de la realizacin de cruzadas, retiros de lazos, recuperacin de puertos,
instalacin y retiro de servicio aba, levantamiento de pares no asociados a la red
central y del mantenimiento general del distribuidor.
bdo.
bdp. Por otra parte, los procesos de instalacin y reparacin de averas es uno
de los procesos internos de la unidad, pero que la mayor parte del mismo es ejecutada
por empleados de la compaa que trabajan en zonas forneas y que se encuentran
adscritos al departamento de planta externa. Estos empleados, para la realizacin de
las instalaciones o reparaciones, requieren, en la mayora de los casos, de informacin
alojada en los servidores de base de datos, a la cual solo puede accederse
118
bdq.

bdr.
desde dentro de las instalaciones de la central. En consecuencia, dada la
carencia de una aplicacin que les brinde la opcin de acceder a la informacin

requerida desde cualquier punto de la ciudad, los trabajadores deben contactar va
telefnica con el personal que se encuentra dentro de la unidad de conmutacin para
solicitarla.
bds.
bdt. Sin duda alguna, esta no es la manera ms ptima de realizar este proceso,
debido a que se interrumpe con las actividades dentro del distribuidor y retrasa el
desarrollo de los procesos, bien sea dentro o fuera de la unidad. Por esta razn, el
desarrollo futuro de la aplicacin empresarial, pretende ofrecer a los empleados la
posibilidad de consultar los datos referentes a pares centrales, locales y terminales
desde el sistema de software sin interrumpir las tareas dentro de conmutacin. La idea
fundamental es hacer los procesos de la compaa lo ms independientes posibles, de
modo que puedan ser realizados de manera eficiente y sin ningn tipo de retrasos,
otorgando inter operatividad, accesibilidad y usabilidad a la informacin.
bdu.
4. Requisitos generales.
bdv.
bdw. Con la finalidad de llevar a cabo la implementacin de la aplicacin
propuesta es necesario contar con equipos de computadora, dispositivos mviles y
acceso a internet que permita el levantamiento del sistema para acceder a los
servidores de la compaa, sustraer la informacin requerida y presentar los datos que
dan soporte al proceso de instalacin y reparacin de averas.
bdx.
bdy.
bdz.
bea.
beb. Compaa Annima Nacional Telfonos de Venezuela
5.
Alcance de la aplicacin.
119
bec.
bed. La ingeniera de requisitos aplicado a los procesos de instalacin y
reparacin de averas, realizados por planta externa para la unidad de conmutacin
(CX) de la central digital Maturn-centro, C.A.N.T.V. estado Monagas, busca brindar
una mayor comprensin y definicin de los procesos, estableciendo las bases
necesarias que permitan consolidar el desarrollo de una aplicacin empresarial capaz
de atender las necesidades actuales en el distribuidor. As mismo, el prototipo de la
aplicacin brindara una idea general de la funcionalidad del mismo y del soporte que
brinda.
bee.
bef.
beg.
beh.
bei.
bej.
bek.
bel.
bem.
ben.
beo.
bep.
beq.
ber.
bes.
bet.
beu.

bev.
120

bew.
DOCUMENTO INICIO DEL PROYECTO
bex.
Versin <1.0>
bey.
bez.
bfa.
bfb.
Descripcin
bfc.
Autor
Fecha
bfd.
Oscar J. Ruiz
bfg.
Oscar J. Ruiz
bfk.
Oscar J. Ruiz
bfo.
1. Introduccin.
bfp.
bfq.
Versin
bfe.
bff.
Versin
29/07/2011
0.90
bfh.
bfi.
bfj.
Primera
22/08/2011
0.95
bfl.
bfm.
correccin.
bfn.
Versin final
08/09/2011
del producto.
1.00
Como primer documento formal, el documento inicio del
proyecto o acta de constitucin del proyecto, avala la existencia del proyecto y otorga
la autoridad para asignar recursos organizacionales a las actividades del mismo.
Bsicamente, la finalidad que posee este documento es justificar de forma tcnica y
econmica la necesidad de proceder con el desarrollo de dicho proyecto.
bfr.
2. Objetivos del proyecto.
bfs.
1.1 Objetivos.
bft.
El objetivo general de este proyecto consiste en desarrollar
la ingeniera de requisitos aplicado a los procesos de instalacin y reparacin de

averas, realizados por planta externa para la unidad de conmutacin (CX) de la
central digital Maturn-centro, C.A.N.T.V. estado Monagas.
bfu.

bfv.
Teniendo como objetivos especficos los siguientes:
121
Diagnosticar la situacin actual de los procesos de la unidad de conmutacin

perteneciente a planta interna del distribuidor Maturn-centro para detectar las
fallas de la misma.
Disear el modelo de negocio de la unidad de conmutacin (CX) de la central
digital Maturn-centro a fin de obtener una visin del sistema a nivel
conceptual.
Determinar los requisitos funcionales y no funcionales para la aplicacin a
incorporar en los procesos de instalacin y reparacin de averas.
Evaluar los requerimientos de compatibilidad de software y hardware en
funcin a soporte y costos.
bfw.
3. Caractersticas generales de la aplicacin.
bfx.
bfy.
La aplicacin que se propone para ser incluida en los
procesos de instalacin y reparacin de averas posee diversas caractersticas que la

enmarcan dentro de los lmites de un sistema de software empresarial, entre ella se
tienen, de forma general, las siguientes:
a) Basada en Ambiente Web: la compaa annima telfonos de Venezuela, es un
motor tecnolgico que impulsa cada da el crecimiento en el rea de las
telecomunicaciones, sta es una de las principales organizaciones capaces de
brindar servicios de internet estables y de alto rendimiento a sus usuarios. Por
tal razn, C.A.N.T.V. cuenta con los requerimientos bsicos necesarios para
bfz.

bga.
trabajar sobre sistemas y aplicaciones basadas en ambiente
web que puedan acceder a servidores a travs de internet mediante navegadores.
122
b) Interfaz Amistosa y Visualmente Atractiva: la finalidad de incorporar una

aplicacin al proceso es mejorarlo y optimizarlo, es por ello que las interfaces
deben ser diseadas de forma sencillas, que sean fciles de manejar y
agradables ante la vista del usuario.
c) Multiplataforma: capaz de levantar el sistema independientemente del sistema
operativo que posea el dispositivo siempre y cuando posea conexin a internet.
d) Sistema de Validacin de Usuario: la informacin extrada de los servidores
de la compaa es totalmente confidencial. La aplicacin debe garantizar la
seguridad en el manejo de los datos, para lograr eso, el sistema contara con una
funcionalidad que permita validar al usuario que intente acceder al sistema
antes de realizar cualquier operacin.
e) Consulta de Informacin: un aspecto fundamental planteado dentro del
proyecto es la carencia de acceso a la informacin por parte de los empleados
de planta externa. Esta deficiencia pretende ser solventada con un software que
les permita a los usuarios realizar operaciones de consulta de datos de manera
fcil, rpida y remota, para de esta manera evitar solicitar la informacin va
telefnica.
bgb.
bgc.
bgd.
bge.
bgf.
bgg.

bgh.
4. Requisitos iniciales.
bgi.
123
bgj.
El
desarrollo
del
proyecto
tiene
establecido
como
requerimiento mnimo un computador que soporte el manejo de los siguientes

programas: SmartDraw, Adobe Dreamweaver CS6, Adobe Fireworks y Microsoft
Project. Por otra parte es necesario contar con un navegador web y el acceso a
internet. Hay que tener en cuenta que estos son requisitos bsicos, pero que sin
embargo, pueden ir variando a medida que el proyecto evoluciona, pudiendo
incrementarse en cualquier punto del mismo, debido a que pudieran agregarse nuevos
requisitos para la elaboracin del proyecto que no fueron detectados al inicio del
mismo.
bgk.
bgl.
Por otra parte se tiene el mtodo de trabajo, en este caso
Gray Watch, es entonces requisito fundamental adquirir una capacitacin tcnica que
brinde el soporte que amerita el trabajo constante en un proyecto de desarrollo de
software. Aunque esta robusta metodologa de desarrollo, ofrece una slida
planificacin, es necesaria la adquisicin de conocimientos para el correcto manejo
tanto de las herramientas de software como del propio mtodo de trabajo, si se quiere
concluir el proyecto en base a tiempo y costos estimados.
bgm.
bgn.
bgo.
bgp.
bgq.
bgr.
bgs.

5. Visin del negocio.

bgt.
bgu.
La unidad de conmutacin (CX) es un departamento que
forma parte de la regin oriental, especficamente de la gerencia red Monagas, junto
124
con la unidad red de acceso y la unidad de transmisin TXDX. Su funcin principal

consiste en procesar todas las rdenes de trabajo asignadas por el sistema
administrativo a esta unidad de forma eficiente, dando respuestas a las solicitudes de
los clientes y evitando de esta manera que el trabajo asignado diariamente sea
acumulado.
bgv.
bgw.
Por lo general estas rdenes de trabajo hacen referencia a
todo tipo de actividades relacionadas con la corrida y retiro de lazos a lo largo de la

red central dentro del distribuidor, bien sea de lneas telefnicas o de servicio de
acceso a banda ancha. De igual manera, la responsabilidad de ejecutar actividades de
mantenimiento del distribuidor tambin recae sobre los tcnicos que laboran dentro
de esta unidad, siempre siguiendo las pautas y lineamientos establecidos en los
manuales de normas y procedimientos de la compaa.
bgx.
6. Necesidad de implementar el sistema.
bgy.
bgz.
De los diversos procesos que se realizan dentro del
departamento, destacan los procesos de instalacin y reparacin de averas, cuya

ejecucin se divide en dos partes, una dentro del distribuidor, de la cual los tcnicos
son los encargados, y otra fuera de las instalaciones, cuyos responsables son los
empleados de planta externa. Estos ltimos vienen realizando, desde mucho tiempo
atrs, su parte de este proceso de una manera poco eficiente que ha venido retrasando
la ejecucin de dicho proceso, afectando la labor de los empleados dentro de la
unidad de conmutacin.
bha.

bhb.
Esta informacin es necesaria en la mayora de los casos
para poder concluir con la tarea que se la ha sido asignada. Por tales razones, el
producto propuesto una vez finalizado el proyecto, constituir la base principal para
125
el desarrollo de una aplicacin empresarial que permita a los empleados que se

encuentran realizando labores de instalacin y reparacin de averas en las calles de la
ciudad, acceder a la base de datos y consultar por si mismos la informacin sin la
necesidad de recurrir a terceros. Y de esta manera, hacer de este proceso una tarea
ms eficiente y rpida, disminuyendo la dependencia actual que presenta con la
unidad de conmutacin.
bhc.
7. Resumen de los interesados del proyecto.
bhd.
bhe.
bhf.
Rol
Cuadro 20. Interesados del Proyecto.

bhg.
Responsabilida
des
bhh.
Respo
nsa
ble
s
bhi.
1. Validar el Plan Integral del Proyecto de

desarrollo de la aplicacin empresarial
que le sea asignada.
2. Prestar asistencia tcnica a los miembros
Lder
del equipo de desarrollo.
3.
Gestionar
los riesgos del proyecto.
del
4. Dirigir y controlar la ejecucin del Plan
Proyecto
Integral del Proyecto.
. 5. Cerrar administrativa y tcnicamente el
proyecto.
bhj.
Ing
.
We
nd
y
Ro
nd
bhk.
1. Validar las etapas de desarrollo del

Responsable proyecto y garantizar la culminacin del
proyecto.
General
bhl.
del
n.
bhm.
Ing.
Yh
uan
126
Proyecto
ail
ys
N
ez
.
bhn.
bho.
bhp.
bhq.

bhr.
bht.
bhs.
Rol
Cuadro 20. (Cont.).

Responsabilida
des
bhu.
Respo
nsa
ble
s
1. Modelar el dominio de la aplicacin

empresarial.
2. Asegurar que los productos del desarrollo
de la aplicacin estn alineados al
sistema de negocios que acta como
dominio de la aplicacin.
3. Descubrir, analizar, especificar y
Analista documentar los requisitos de la
aplicacin.
del 4. Validar, en conjunto con los usuarios, los
Negocio. requisitos establecidos.
5. Gestionar los requisitos.
bhw.
6. Gestionar los tems producidos durante el
Analista del desarrollo y controlar los cambios que
Sistema. puedan surgir en cada una de ellos.
7. Gestionar las versiones de los productos
bhx.
y del prototipo de la aplicacin.
Gestor de
bhv.
bhy.
Br.
Os
car
J.
Rui
z.
127
Configur
acin.
bhz.
1. Definir los estndares y procedimientos

de aseguramiento de la calidad del
software.
Gestor
2. Asegurar la calidad.
de
Calidad.
bia.
T
c.
Yol
is
Tor
rea
lba
.
bib.
8. Restricciones.
bic.
bid. El equipo de trabajo para el desarrollo del proyecto se encuentra
constituido por una fraccin del personal tcnico que cumple funciones dentro de la
unidad de conmutacin, de la
central digital Maturn-centro, perteneciente a la
Compaa Annima Nacional Telfonos de Venezuela (C.A.N.T.V.), junto con otros

actores involucrados que pertenecen a la casa de estudio de la Universidad de
Oriente, entre ellos la responsable general del proyecto y el analista del negocio y del
sistema.
bie.Compaa Annima Nacional Telfonos de Venezuela
bif.
Las restricciones asociadas a la elaboracin del proyecto estn netamente
sometidas a las normas legales, aplicacin de estndares y requisitos de calidad del

producto, como por ejemplo: confiabilidad, desempeo, entre otros requisitos de
ambiente, tales como: sistema operativo, requisitos de compatibilidad, etc.
big.
128
bih.
En relacin a los costos de produccin hay que acotar que
ste viene representado por la primera inversin econmica que realiza el equipo de
trabajo, bien sea durante las etapas de anlisis, modelado, ingeniera de requisitos o
durante la propia construccin del software. Generalmente durante el desarrollo de un
proyecto de software se presentan los siguientes costos:
bii.
a) Costos de equipos y herramientas de trabajo: generados por el hardware y el
software utilizado durante el proyecto.
b) Costos de infraestructura: se calculan por los gastos que generan el
requerimiento de un ambiente de trabajo apto para los equipos y para garantizar
la continuidad del proyecto.
c) Costos de personal: viene representado por las remuneraciones econmicas a
cada integrante del proyecto involucrado de forma directa en el desarrollo del
mismo.
d) Costos de adiestramiento: se refieren a los gastos que amerita la aplicacin de
tcnicas de capacitacin y aprendizaje que le permitan desarrollar aptitudes y
actitudes para realizar sus labores de forma correcta.
e) Costos de materiales que se utilizarn: generados por compras de materiales de
oficina como resmas de papel, carpetas, ganchos de carpetas, cartuchos de tinta
para impresoras, lapiceros, entre otros.
bij. Compaa Annima Nacional Telfonos de Venezuela
bik.

bil.
DOCUMENTO INSTANCIACIN DEL MTODO
bim.
Versin <1.0>
bin.
bio.
bip.
biq.
Descripcin
129
bir.
Autor
Fecha
bis.
Oscar J. Ruiz
biv.
Oscar J. Ruiz
biz.
Oscar J. Ruiz
bjd.
Versin
bit.
biu.
Versin
01/08/2011
0.90
biw.
bix.
biy.
Primera
18/08/2011
0.95
bja.
bjb.
correccin.
bjc.
Versin final
30/09/2011
del producto.
1.00
2. Introduccin.
bje.
bjf.
Este documento contempla la instanciacin del mtodo, el
cual consiste en llevar a cabo una adaptacin de los procesos y actividades propias de
la metodologa, a las caractersticas y necesidades particulares del sistema en estudio.
Es decir, describe detalladamente el proceso que el Equipo de Desarrollo debe seguir
para producir la aplicacin empresarial. Este proceso se establece a travs de la
instanciacin del Mtodo WATCH.
bjg.
3. Procesos que se generan en el proyecto.
bjh.
bji.
Gray Watch es un mtodo que ha sido elaborado
expresamente para el desarrollo de aplicaciones empresariales, es por ello que para

garantizar, gestionar y asegurar, tanto la continuidad como la culminacin del
proyecto, esta centra muchos de sus esfuerzos en tres procesos fundamentales para el
desarrollo.
bjj. Compaa Annima Nacional Telfonos de Venezuela
3.1 Procesos de Gestin
bjk.
bjl.
Como su nombre lo indica, estos cubren todas las actividades
de gestin de proyectos de software, es decir, consta de una serie de actividades

enmarcadas dentro del rea gerencia que son necesarias para que la ejecucin del
130
proyecto sea exitosa. Esto significa que el proyecto sea finalizado en el periodo de
tiempo estimado, dentro del presupuesto establecido y que sea de calidad.
bjm.
bjn.
El lder del proyecto posee la responsabilidad de este proceso
gerencial de vital importancia para el proyecto. Debido que a travs de ste, el lder
realiza la planificacin de trabajo, los actores involucrados juntos con sus roles, controla
la planificacin
y administra razonablemente los recursos asignados al proyecto,
teniendo en cuenta que los procesos de gestin deben llevarse a cabo a lo largo de toda la
duracin del proyecto.
bjo.
3.2 Procesos Tcnicos.
bjp.
bjq.
El grupo de procesos tcnicos enmarcan todas las
actividades de ingeniera que estn relacionadas directamente con el ciclo de

desarrollo de las aplicaciones. En otras palabras, organiza todas las actividades
tecnolgicas que implica la ejecucin de un proyecto de software, entre ellas se
encuentran el modelado del negocio, la ingeniera de requisitos, el diseo
arquitectnico entre otros.
bjr.
3.3 Procesos de Soporte.
bjs.
bjt.
Los procesos de soporte son un conjunto de tareas tcnicas y
gerenciales que contribuyen a hacer ms efectivos los procesos tcnicos y que

complementan los procesos de gestin. Estos
procesos guardan relacin con la
calidad, los riesgos y la

bju.

131
bjv.configuracin de la aplicacin. A continuacin, en la Figura 13 se

presenta los grupos de procesos que sern desarrollados haciendo uso de
la metodologa Gray Watch.
bjw.
bjx.
Modelo de
Procesos
Procesos
de Gestin
Procesos
Tcnicos
Procesos
de Soporte
bjy.Figura 13. Modelo de Procesos.

Fuente: Jons Montilva C. y Judith Barrios A. (2008)
bjz.
bka.
Finalizados los modelos de procesos, junto con el modelado
de productos y actores, es necesario llevar a cabo la instanciacin a fin de asegurar

que el mtodo resultante de la integracin de estos tres modelos, permitir
verdaderamente desarrollar el proyecto.
bkb.
132
4. Productos que se generan en el proyecto.

bkc.
bkd.
En este apartado se presentan cada uno de los productos
entregables que sern el resultado de las diferentes etapas de trabajo pautadas por la
metodologa Gray
bke.
bkf.

bkg.
Watch y que se proponen para este proyecto. Un aspecto
importante que hay que resaltar es que cada uno de los productos que se
generan como resultado de procesos iterativos e incrementales se ven
sometidos a diversas modificaciones o mejoras. En este caso particular,
con la aplicacin del mtodo del reloj, las versiones finales de los
productos se entregaran una vez culminado todo el proceso
metodolgico de desarrollo.
bkh.
bki.
En este sentido, la instanciacin del mtodo, no solo permite
adecuar la metodologa a las necesidades de la realidad abordada, sino que tambin

hace posible determinar cules sern los productos finales que sern generados y que
contendrn las respuestas a la situacin problema actual que est interfiriendo, de
alguna forma u otra, con el correcto funcionamiento del sistema. En el Cuadro 21 se
presentan los productos entregables que son el resultado del proceso de instanciacin
del mtodo.
bkj.
bkl.
bkk.
P
Cuadro 21. Relacin Proceso-Productos.

bkm.
Producto
roceso
bkn.
P
rocesos de
bko.
proyecto.
Documento
enunciado
del
133
Gestin.
bkp.
Documento
inicio
del
proyecto.
bkq.
Documento instanciacin del
mtodo.
bks.
P
rocesos
Plan integral del proyecto.

Modelo del anlisis del
negocio.
Tcnicos.
bkv.
bkr.
bkt.
P
rocesos de
Soporte.
bku.
bkw.
Documento de requisitos.
Plan de gestin de riesgos.
bkx.
Plan
de
gestin
de
la
configuracin.
(Forman
bky.
parte del
Plan de aseguramiento de la
calidad del software.
Plan
Integral del
Proyecto)
bkz.
bla.Compaa Annima Nacional Telfonos de Venezuela
blb.
El cuadro anterior resume el conjunto de productos que se
generaran para el caso particular del proyecto Ingeniera de requisitos aplicado a los
procesos de instalacin y reparacin de averas, realizados por planta externa para la
unidad de conmutacin (CX) de la central digital Maturn-centro, C.A.N.T.V. estado
Monagas., una vez que se proceda con el cierre del mismo. Teniendo en cuenta que
Producto Watch
a travs la metodologa de desarrollo Gray Watch se generan dos tipos principales de

productos, intermedios y entregable, la Figura 14 resume esa informacin de forma
grfica.
blc.
Producto
Intermedio
bld.
Producto Entregable
Producto Producto de Producto de

Aplicacin Empresarial
Gestin
Tcnico
Soporte
134
ble.
blf.
blg.
blh.
bli.
blj.
blk.
bll.
blm.
bln.
blo.
blp.
blq.
blr.
Figura 14. Tipos de productos principales del mtodo Watch.

De esta manera, la instanciacin del mtodo permite
establecer de forma concreta los productos que sern producidos durante todo el
proceso de ejecucin del proyecto y que sern el resultado de una serie de actividades
previamente planificadas.
bls.Compaa Annima Nacional Telfonos de Venezuela
blt.

blu.
PLAN INTEGRAL DEL PROYECTO
blv.
Versin <1.0>
blw.
blx.
bly.
blz.
Descripcin
Autor
bma.
Fecha
bmb.
Oscar J. Ruiz
bme.
Oscar J. Ruiz
bmi.
Versin
bmc.
bmd.
Versin
02/08/2011
0.89
bmf.
bmg.
bmh.
Primera
31/08/2011
0.94
bmj.
bmk.
correccin.
bml.
Segunda
135
Oscar J. Ruiz
bmm.
Oscar J. Ruiz
bmq.
23/09/2011
0.99
bmn.
bmo.
correccin.
bmp.
08/10/2011
del producto.
1.00
Versin final
1. Introduccin.
bmr.
bms.
El plan integral del proyecto determina, rige y gua la
ejecucin de todos los procesos del desarrollo de la aplicacin, es por ello que en
muchas ocasiones es considerado como el documento de mayor importancia dentro
de la gestin del proyecto. Este documento describe los objetivos y alcance de la
aplicacin empresarial, el proceso tcnico necesario para el desarrollo de la misma,
las actividades que componen cada uno de los procesos, el cronograma de ejecucin
de stas actividades, los diferentes recursos manejados y el presupuesto que establece
el costo del proyecto.
bmt.
bmu.
De igual manera, el plan integral del proyecto define cmo
debe ser iniciado, planificado, ejecutado, controlado y cerrado el proyecto de

desarrollo de software, dejando ver entonces la importancia del mismo en cuanto a
planificacin y ejecucin se refiere.
bmv.

2. Objetivos.
bmw.
bmx. Este documento tiene como objetivo la creacin de planes que permitan
manejar de forma efectiva los riesgos que puedan presentarse durante la ejecucin del
proyecto, garantizar la calidad de los productos generados de manera que puedan
cumplir con los requisitos establecidos por los usuarios, dando respuesta a las
necesidades actuales.
bmy.
136
bmz.
De igual modo tiene como finalidad controlar e intervenir
en cualquier cambio que pudiese afectar la configuracin y la planificacin del

proyecto, de manera que pueda asegurar que el desarrollo de la aplicacin se lleve a
cabo de manera sistemtica, organizada, eficaz y eficientemente. Para lograr esto, es
necesario trabajar bajo diversas normativas que permitan estandarizar los
procedimientos, manejar adecuadamente los riesgos y controlar la configuracin de la
aplicacin.
bna.
3. Recursos necesarios.
bnb.
3.1 Recursos Humano.
bnc.
bnd.
La ejecucin del proyecto requiere de un conjunto de actores
que intervienen en las diferentes etapas del mismo, constituyendo un equipo de

trabajo. En este caso el grupo de trabajo est compuesto principalmente por la Ing.
Wendy Rondn, que cumple el rol de lder del proyecto, es la encargada de prestar
asistencia tcnica al equipo, dirigir, controlar y asegurar la correcta ejecucin del plan
del proyecto y es la responsable del mismo dentro de la unidad de conmutacin de la
central digital Maturn-centro.
bne.
bnf.

Por otra parte, la Ing. Yhuanailys Nez, desempeando el
rol de responsable general del proyecto, brinda asesoramiento durante las fases de
desarrollo y es la encargada de validar las etapas de desarrollo y garantizar la
culminacin del proyecto. Una integrante ms del equipo de trabajo, es la tcnico
superior Yolis Torrealba, perteneciente a la unidad de conmutacin desde hace ms de
20 aos, como gestor de calidad, define los estndares y procedimientos de
aseguramiento de la calidad dentro de los lineamientos de la compaa telefnica
C.A.N.T.V.
137
bng.
bnh.
Por ltimo, el Br. Oscar J. Ruiz, es el encargado de la
elaboracin del proyecto, cumpliendo funciones como analista de negocio, analista de

sistema y gestor de la configuracin. Encargado bsicamente de ejecutar actividades
que aporten un mayor entendimiento y comprensin del dominio de la aplicacin,
entre sus responsabilidades se encuentran: realizar los diferentes modelados, asegurar
los productos, descubrir, analizar, especificar y documentar los requisitos de la
aplicacin, controlar los cambios que puedan surgir en cada una de ellos, gestionar las
versiones de los productos y del prototipo de la aplicacin, entre otros.
bni.
3.2 Recursos Tecnolgicos.
bnj.
bnk.
En materia de hardware, el recurso tecnolgico necesario
para dar inicio y continuidad a la ejecucin del proyecto, consiste bsicamente en un

equipo de computadora con requerimientos de rendimiento bsico que permita hacer
uso de diversas herramientas de software que dan soporte a los diferentes procesos y
que constituyen los recursos tecnolgicos en materia de software, estos son:
SmartDraw, Adobe Dreamweaver CS6, Adobe Fireworks y Microsoft Project.
bnl.
bnm.
bnn.

4.2 Recursos Materiales.

bno.
bnp.
Este tipo de recursos se refiere a una serie de materiales de
oficina con el cual el equipo de trabajo debe contar, esto es: resmas de hojas blancas,
CD-ROOM, carpetas y ganchos para carpetas, marcadores, lapiceros entre otros
materiales que sirven de apoyo durante las tareas y actividades que realizan los
involucrados en la ejecucin del proyecto.
bnq.
138
4. Estndares y procedimientos.
bnr.
4.3 Normas de Calidad.
bns.
bnt.
Cada uno de los productos generados a partir de los
diferentes procesos y la ejecucin del proyecto en general y estar regida bajo ciertas
normas estndar a nivel internacional de fabricacin, comercializacin y
comunicacin. En este caso, sern las normas ISO-9126, establecidas por La
Organizacin Internacional de Normalizacin (ISO).
bnu.
bnv.
En base a esto, la norma ISO-9126, es un estndar
internacional para la evaluacin del software y fue originalmente desarrollado en

1992 con el nombre de Tecnologa de la informacin de evaluacin de productos de
software: caractersticas de calidad y directrices para su uso, con el fin de
proporcionar un esquema para la evaluacin de la calidad del software. La normativa
define seis caractersticas de la aplicacin, estas seis caractersticas son dividas en un
nmero de sub- caractersticas, las cuales representan un modelo detallado para la
evaluacin de cualquier sistema informtico.
bnw.
bnx.

La Figura 15 refleja las caractersticas y sus sub-
caractersticas de la norma ISO-9126
139
bny.
Calidad
Calidad
Interna/Externa
Interna/Externa
Funcionalidad
Fiabilidad
Usabilidad
Mantenibilidad
Portabilidad
Eficiencia
Idoneidad
Madurez
Inteligibilidad
Analizabilidad
Adaptabilidad
Comportamiento
en el
tiempo
tiempo
Precisin
Precisin
Tolerancia
Tolerancia aa
fallos
fallos
Facilidad
Facilidad de
de
aprendizaje
aprendizaje
Cambiabilidad
Cambiabilidad
Facilidad
Facilidad de
de
instalacin
instalacin
Utilizacin
Utilizacin
de
de
recursos
recursos
Inter
operabilidad
operabilidad
Capacidad de
recuperacin
recuperacin
Operabilidad
Operabilidad
Estabilidad
Estabilidad
Coexistencia
Coexistencia
Cumplimiento
Cumplimiento
de
la
de la
eficiencia
Seguridad
Cumplimiento
Cumplimiento
de la
fiabilidad
fiabilidad
Atractividad
Pruebabilidad
InterIntercambiabilidad
cambiabilidad
Cumplimiento
Cumplimiento
de
la
de la
usabilidad
usabilidad
Cumplimiento
Cumplimiento
de
la
de la
mantenibilidad
mantenibilidad
Cumplimiento
Cumplimiento
de la
la
de
portabilidad
portabilidad
Cumplimiento
Cumplimiento
de
de la
la
funcionalidad
funcionalidad
bnz.
Figura 15. Caractersticas de la Calidad segn la ISO/IEC 9126.
boa.
4.4 Leyes.
bob.
boc.
(1999):
bod.
boe.
Constitucin de la Repblica Bolivariana de Venezuela
140
bof.
Artculo 110. El Estado reconocer el inters pblico de la
ciencia, la tecnologa, el conocimiento, la innovacin y sus aplicaciones y los

servicios de informacin necesarios por ser instrumentos fundamentales para el
desarrollo econmico social y poltico del pas, as como para la seguridad y
soberana nacional
bog.

boh.
() El estado garantizar el cumplimiento de los principios
ticos y legales que deben regir las actividades de investigacin

cientfica, humanstica y tecnolgica.
boi.
boj.
Decreto 3.390: publicado en la gaceta oficial N 38.095 de
fecha 28/12/2004.
bok.
bol.
bom.
Artculo 1. La Administracin Pblica Nacional emplear
prioritariamente Software Libre desarrollado con Estndares Abiertos, en sus
sistemas, proyectos y servicios informticos. A tales fines, todos los rganos y entes
de la Administracin Pblica Nacional iniciarn los procesos de migracin gradual y
progresiva de stos hacia el Software Libre desarrollado con Estndares Abiertos.
bon.
boo.
Artculo 3. En los casos que no se puedan desarrollar o
adquirir aplicaciones en Software Libre bajo Estndares Abiertos, los rganos y entes
de la Administracin Pblica Nacional debern solicitar ante el Ministerio de Ciencia
y Tecnologa autorizacin para adoptar otro tipo de soluciones bajo las normas y
criterios establecidos por ese Ministerio.
bop.
boq.
Artculo
5.
El
Ejecutivo
Nacional
fomentar
la
investigacin y desarrollo de software bajo modelo Software Libre desarrollado con

Estndares Abiertos, procurando incentivos especiales para desarrolladores.
141
bor.
bos.
Decreto N 825: publicado en Gaceta Oficial de la
Repblica Bolivariana de Venezuela de fecha 22/05/2000.
bot.
bou.
Artculo 1. Se declara el acceso y el uso de Internet como
poltica prioritaria para el desarrollo cultural, econmico, social y poltico de la
Repblica Bolivariana de Venezuela.
bov.
bow.
box.

Artculo 3. Los organismos pblicos debern utilizar
preferentemente Internet para el intercambio de informacin con los particulares,

prestando servicios comunitarios a travs de Internet, tales como bolsas de trabajo,
buzn de denuncias, trmites comunitarios con los centros de salud, educacin,
informacin y otros, as como cualquier otro servicio que ofrezca facilidades y
soluciones a las necesidades de la poblacin. La utilizacin de Internet tambin
deber suscribirse a los fines del funcionamiento operativo de los organismos
pblicos tanto interna como externamente.
boy.
boz.
4.3 Manuales.
bpa.
1. GRAY WATCH Mtodo de Desarrollo de Software de Aplicaciones

Empresariales, 2008 Jons Montilva, Judith Barrios y Milagro Rivero: es una
gua que describe de forma detallada la metodologa Gray Watch para
desarrollo de aplicaciones empresariales con el objetivo de ser usada por los
involucrados en la ejecucin del proyecto como un patrn que permita
establecer y definir las pautas para los diferentes procesos dentro de cada fase
de trabajo.
2. Ingeniera de Requisitos, Jons Montilva, CeiSoft: este documento contiene las
generalidades involucradas en el proceso de ingeniera de requisitos,
enfocndose en los procesos de descubrimiento, anlisis, especificacin,
142
documentacin y validacin de los requisitos de la aplicacin usando

notaciones en UML 2.0.
bpb.
bpc.
bpd.
bpe.

3. Modelado de Sistemas usando UML 2.0, Jons Montilva e Isabel Besembel: este
manual hace una descripcin en cuanto al modelado de sistemas bajo las
notaciones UML 2.0 y UML Bussines. Su finalidad es servir como herramienta
de soporte para el equipo de trabajo, capacitndolos en procesos desarrollo de
software y de modelado de los diferentes aspectos que caracterizan a un sistema
de informacin o aplicacin de software.
4. Manual del Mdulo de Provisin de Servicio. C.A.N.T.V.: es una gua interna de
la compaa annima nacional telfonos de Venezuela, resume toda la
informacin relacionada con la administracin y control de las rdenes de
trabajo. Pretende facilitar conocimientos a los empleados involucrados en los
procesos de instalacin, de modo que se posea un alto nivel de comprensin
referente a cada uno de los procesos organizacionales, guiando en forma rpida
a la solucin de dudas o problemas eventuales que puedan presentarse.
5. Ingeniera Bsica de Planta Externa. Centro de Estudios de Telecomunicaciones
C.A.N.T.V.: presentado en diferentes mdulos, este completo manual
desarrollado por la propia compaa telefnica para garantizar la comprensin
de sus procesos a los empleados, contiene toda la informacin fundamental de
planta externa, desde los diferentes mtodos y formas de tendido subterrneo y
areo, hasta la instalacin, reparacin y pruebas telefnicas. Por tales razones,
esta gua sirve como un instructivo para dar orientacin clara y precisa a los
participantes que integran la planta externa y cada uno de sus diversos procesos.
143
bpf.
bpg.
bph.
bpi.
bpj.

6. Normativa General Interna de la Unidad de Conmutacin (CX): esta normativa

contiene un conjunto de pautas y reglas que rigen cada uno de los procesos que
conforman la unidad de conmutacin. Bsicamente presenta a lo largo de sus
diferentes captulos las reglas que rigen las actividades en su ejecucin ms
ideal, teniendo claro que muchas veces estas actividades, que aunque alejndose
un poco de la teora, tienden a lograr el mismo objetivo. La ida fundamental de
estas normas, como lo presenta en su texto introductorio, es brindar un soporte
terico a los empleados que desempean roles y funciones dentro de cada una
de las actividades de conmutacin.
7. Manual de Operacin y Mantenimiento de las Centrales: este completo manual
presenta una serie de normas con respecto al correcto mantenimiento de las
centrales digitales, sus actividades, tareas y procesos. Va dirigido a todo el
personal que labora dentro de las centrales digitales en cualquiera de sus
unidades, ofreciendo respuestas y soluciones rpidas y eficientes a
innumerables situaciones que pudiesen presentarse en el ambiente laboral.
8. Normas y Procedimientos Gerencia General Tecnologa y Operaciones: este
manual de normas y procedimientos tiene por objetivo suministrar los
lineamientos generales que permitan regir las operaciones y procedimientos
administrativos llevados a cabo por las
Operaciones.
Gerencias de Tecnologas y
144
bpk.

5. Planes.
bpl.
bpm.
Se describen a continuacin los planes establecidos para dar
inicio y asegurar la continuidad y culminacin del proyecto:

bpn.
4.1 Plan de Gestin de Tiempo.
bpo.
bpp.
El plan de gestin de tiempo es un documento propio del
plan integral del proyecto, ste muestra el conjunto de actividades que son necesarias
para la realizacin cronograma del proyecto. De igual manera establece los criterios
que definen el formato para construir el cronograma y los supuestos que deben ser
considerados al programar dichas actividades. En este sentido, la elaboracin del
cronograma requiere de mucha atencin y cuidado, puesto que una vez finalizado,
formar parte del plan de gestin de tiempos.
bpq.
bpr.
Planificar los tiempos es un factor de suma importancia,
puesto que estimar la duracin de las tareas permite asociar un tiempo determinado de
ejecucin a cada actividad. Esto contribuir en el desarrollo del cronograma general,
el cual guiar y controlar las actividades junto con sus tiempos de ejecucin,
indicando sus fechas de inicios y fechas de culminacin, a fin de evitar cualquier tipo
de retraso en el proyecto, para de esta manera garantizar la culminacin del mismo
para la fecha establecida.
bps.
bpt.
La Figura 16, refleja el cronograma general de ejecucin del
proyecto, que organiza el trabajo en iteraciones que contienen las diferentes

actividades con sus respectivos tiempos de ejecucin.
bpu.

145
bpv.
bpw.
bpx.
5.1
5.2
bpy.
bpz.
bqa.
bqb.
bqc.
bqd.
6.2
bqe.
bqf.
bqg.
bqh.
bqi.
bqj.
bqk.
bql.
Figura 16. Plan de Gestin de Tiempos del Proyecto.

bqm.
bqn.
bqo.
bqp.

6.3 Plan de Gestin de Riesgos.
146
bqr.
bqs.
El Plan de Gestin de Riesgos es uno de los planes
subsidiarios que integran el Plan Integral del Proyecto y describe cmo se

estructurar y se realizar la gestin de riesgos en el proyecto. Lo cual es de vital
importancia, debido a que desde mucho antes de dar inicio a la ejecucin de las
tareas, deben ser detectados diversos riesgos a los que pudieran enfrentarse el equipo
de trabajo, determinando la probabilidad de que estos realmente se produzcan,
estimar su impacto y las medidas y acciones para controlarlos o amortiguar el efecto.
bqt.
bqu.
En base a lo anterior, para poder identificar las posibles
amenazas, se comienza con la definicin de las caractersticas del proyecto en

relacin a la complejidad, requisitos, recursos, experiencia del recurso humano, de
manera que se pueda determinar el conjunto de riesgos potenciales a los que el
desarrollo de la aplicacin estar expuesto. De esta manera, son presentados a
continuacin, diversos tipos de riesgos que pudieran influir de forma negativa en el
proyecto de ingeniera de requisitos que se realiza para la unidad de conmutacin
(CX) en relacin a sus procesos, haciendo uso de una herramienta denominada matriz
de evaluacin de riesgo, la cual contribuye a la prevencin de riesgos, es utilizada
para identificar los peligros y evaluar los riesgos asociados a tareas especficas,
permitiendo asignarle una valoracin del riesgo a cada actividad realizada y
determinando medidas necesarias para corregir, controlar o eliminar dichos riesgos y
peligros.
bqv.
bqw.
El siguiente cuadro ejemplifica la aplicacin de la matriz de
evaluacin de riesgo tanto en la determinacin, identificacin y anlisis de los

riesgos, como en la clasificacin de los mismos en funcin de sus prioridades y
efectos. (Ver Cuadro 22).
bqx.

147
bqy.
Cuadro 22. Matriz de Evaluacin de Riesgo.

bra.
Descripcin del Riesgo:
bqz.
(Indicador del
brb.
(lista de cada riesgo al cual se
Riesgo)
brc.
enfrenta el proyecto)
Tipo de Riesgo:
brf.
brd.
(tecnolgico/persona
Riesgo:
l/herramientas/
bre.
brg.
requerimientos/orga
asociada
(catastrfic
o, serio, tolerable e
nizacionales/estimacin)
brh.
Consecuencia:
bri. (consecuencia
Efectos del
insignificante)
brj. Responsable
al
(asignacin de cada
riesgo)
accin de mitigacin
de
riesgos
individuo
un
para
su
resolucin)
Probabilidad: (Cul es la probabilidad de que el riesgo se
brk.
brl.
(s):
convierta en un problema? Selecciona entre las siguientes: )

Bajo
brm.
brn.
Medio
bro.
brr.
brp.
Alto
brq.
Perodo en el cual puede suceder: (Determinar un periodo
del proyecto mediante el cual se produzca el riesgo).

brs.Estrategia de Mitigacin: (Ponderacin de uno o ms enfoques para
controlar, evitar, minimizar, o en ltima instancia mitigar el riesgo).
brt.
bru. Segn autor Ian Somerville en su libro ingeniera de software, los
criterios para la escogencia de los riesgos se centran en los siguientes aspectos:
a) Riesgos tecnolgicos
b) Riesgo personal
c) Riesgos de herramientas
148
d) Riesgos de requerimientos
e) Riesgos de estimacin
brv.

f) Riesgos organizacionales
brw.
brx. La probabilidad de ocurrencia de cada riesgo, estuvo dada por los
siguientes rangos:
a)
b)
c)
d)
Muy Bajo: (< 10%)

Bajo: (10% - 25%)
Moderado o Medio: (25% - 50%)
Alto: (> 75%)
bry.
brz.
Hay que resaltar que los riesgos que son presentados a travs
de este documento, son solo aquellos que han sido considerados como los riesgos ms
importantes. La lista de los mismos incluye una respectiva clasificacin y
jerarquizacin de los mismos, en base a los siguientes aspectos: tecnolgicos,
personal, de herramientas, de requerimientos, de estimacin y organizacionales. La
matriz de evaluacin de riesgos permitir desglosar y documentar los principales
aspectos de cada riesgo, de modo que puedan ser apreciados con mayor facilidad los
elementos de los mismos. Los riesgos a administrar son los siguientes:
bsa.
149
bsb.

bsc.
bse.
bsd.
Cuadro 23. Riesgo N 1.

Descripcin del Riesgo: falta de
001-R
conocimientos en materia de metodologa y
bsf.
herramientas de software.
de
bsg.
Tipo
Riesgo: herramientas.
bsh.
Consecuencia:
retrasos
en
entrega
bsk.
del negocio y analista del

sistema.
Probabilidad
bsl.Medio
bsj.
B
del
Riesgo: tolerable.
bsi. Responsable (s): analista
de
productos.
Efectos
bsm.
ajo
A
lto
bsn.
bsp.
bso.
Perodo en el cual puede suceder: en cualquier etapa de la
bsq.
ejecucin del proyecto.

Estrategia de Mitigacin: capacitar al equipo de trabajo
en el uso de la metodologa seleccionada y de las herramientas de

software que dan soporte a los procesos.
bsr.
bss.
bsu.
bst.
002-R
bsv.
Tipo

Descripcin
del
comunicacin escasa con el cliente.

de
bsw.
Efectos
Riesgo: personal.
bsx.
Consecuencia:
Riesgo:
del
Riesgo: tolerable.
bsy.
Responsable
falta de informacin para el
(s): analista del negocio y
desarrollo del trabajo y
analista del sistema.
posibles inexactitudes en
los requerimientos.
bsz.
Probabilidad
150
bta.
btb.
ajo
btc.
edio
A
lto
btd.
bte.
btf. Perodo en el cual puede suceder: en cualquier etapa de la ejecucin
del proyecto.
Estrategia de Mitigacin: mantener una comunicacin
btg.
estable y constante con el cliente, fomentando la retroalimentacin

entre ambas partes.
bth.
bti. Cuadro 25. Riesgo N 3.
btk.
Descripcin
btj.003R
del
Riesgo:
incumplimiento en la entrega de documentos y

productos
la
Ing.
Yhuanailys
Nez
y a la unidad de conmutacin (CX).

btl.Tipo de Riesgo: personalbtm.
Efectos
estimacin.
btn.
Consecuencia:
Riesgo: serio.
bto. Responsable (s): analista
del negocio y analista del
retraso en la culminacin
del proyecto.
btp.
btq.
del
sistema.
Probabilidad
btr.Medio
ajo
bts.
A
lto
btt.
btu.
btv.Perodo en el cual puede suceder: en cualquier etapa de la ejecucin
btw.
del proyecto.
Estrategia de Mitigacin: revisar de forma frecuente el
cronograma de actividades y las fechas de entrega pautadas

previamente, en caso de no poder cumplir con la entrega, avisar
previamente y exponer justificativos.
btx.
bty.Cuadro 26. Riesgo N 4.
151
btz.
bua.
004-R
bub.
Tipo
Descripcin
del
desconocimiento del negocio.

de
buc.
Riesgo: personal.
bud.
Consecuencia:
falta de informacin.
buf.
bug.
B
buh.
ajo
Riesgo:
Efectos
del
Riesgo: serio.
bue.
Responsable
(s): analista de negocio.
Probabilidad
M
bui.
A
edio
lto
buj.
bul.
buk.
bum.

Estrategia de Mitigacin: recolectar
informacin
concerniente al sistema de negocio, a travs de entrevistas o revisin

documental de manuales.
bun.
buo.
buq.
bup.

Descripcin del Riesgo: interrupcin
005-R
de actividades del equipo de desarrollo por
bur.
causas externas.
de
bus.
Tipo
Riesgo: organizacional.
but.
Consecuencia:
retraso de actividades.
buv.
buw.
B
bux.
ajo
Efectos
del
Riesgo: serio.
buu.
Responsable
(s): agentes externos.
Probabilidad
M
buy.
buz.
bvb.
edio
lto
bva.
bvc.

Estrategia de Mitigacin: establecer otra rea de trabajo a
152
fin de evitar que los retrasos originen efectos catastrficos en la

planificacin.
bvd.
bve.
bvg.
bvf.

Descripcin
del
Riesgo:
006-R
incumplimiento en la entrega de documentos
bvh.
aprobados/corregidos por parte de supervisores.

de
bvi.
Efectos
del
Tipo
bvj.
Consecuencia:
Riesgo: serio.
bvk.
Responsable
prolongacin y retraso en el
(s): lder del proyecto y
cierre del proyecto.
responsable general del
bvl.
bvm.
B
ajo
bvn.
proyecto.
Probabilidad
M
bvo.
bvp.
bvr.
edio
lto
bvq.
bvs.

Estrategia de Mitigacin: para evitar este tipo de retrasos,
los supervisores deben regirse por el cronograma de actividades para

revisiones y entregas.
bvt.
bvu.
bvv.

bvw.
bvy.
bvx.
007-R
bvz.

Descripcin
del
incumplimiento
Tipo
recolectados.
de
en
bwa.
los
Riesgo:
requerimientos
Efectos
del
153
bwb.
Consecuencia:
Riesgo: serio.
bwc.
Responsable
aplazamiento en la entrega
de documentos.
bwd.
bwe.
bwf.
ajo
(s): responsable general del

proyecto.
Probabilidad
M
bwg.
edio
A
lto
bwh.
bwj.
bwi.
bwk.

Estrategia de Mitigacin: realizacin de reuniones con
personal encargado de la unidad de conmutacin para tratar puntos del

proyecto en cuanto a requerimientos.
bwl.
bwm. Cuadro 30. Riesgo N 8.
bwo.
Descripcin del Riesgo: suspensin
bwn.
008-R
de actividades en la unidad de conmutacin, de la
bwp.
Tipo
central Maturn-centro.
de
bwq.
bwr.
Consecuencia:
cancelacin del proyecto.
bwt.
bwu.
B
bwv.
ajo
Efectos
del
Riesgo: catastrfico
bws.
Responsable
(s): agentes externos.
Probabilidad
M
bww.
edio
lto
bwz.
bwx.
bwy.
bxa.

Estrategia de Mitigacin: apegarse al cronograma de
actividades para minimizar efectos de retrasos en caso de presentarse

esta situacin.
bxb.
154
bxc.
bxd.

bxe.
bxg.
bxf.

009-R
inters en el proyecto por parte de los integrantes
bxh.
de la compaa telefnica C.A.N.T.V.

de
bxi.
Efectos
Tipo
bxj.
Consecuencia:
cancelacin del proyecto.
bxl.
bxm.
B
bxn.
ajo
del
Riesgo: catastrfico
bxk.
Responsable
(s): lder del proyecto.
Probabilidad
M
bxo.
edio
lto
bxr.
bxp.
bxq.
bxs.

Estrategia de Mitigacin: mantener informados a los
representantes de la compaa sobre los avances del proyecto,

presentando iteraciones y versiones de productos.
bxt.
bxu. Cuadro 32. Riesgo N 10.
bxw.
bxv.
010-R
bxx.
atencin
Tipo
en
parte
conmutacin (CX).
de
bxy.
bxz.
Consecuencia:
retrasos
por
tiempos
de
entrega de productos.
byb.
byc.
B
byd.
de
los
usuarios
Efectos
de
del
Riesgo: serio.
bya.
Responsable
proyecto.
Probabilidad
M
bye.
155
ajo
byf.
edio
lto
byh.
byg.
byi.

Estrategia de Mitigacin: presentar los adelantos del
proyecto a los usuarios y los beneficios del proyecto para atraer su

atencin e inters.
byj.
byk.
byl.Compaa Annima Nacional Telfonos de Venezuela
bym.
byo.
byn.

Descripcin del Riesgo: dificultad
011-R
para concretar salidas de campo con personal de
byp.
planta externa.
de
Tipo
byr.
Consecuencia:
retrasos
en
tiempos
ajo
byx.
Efectos
del
Riesgo: serio.
bys.
Responsable
de
entrega de productos.
byt.
byu.
B
byv.
byq.
(s): analista de negocio y

analista del sistema.
Probabilidad
M
byw.
edio
lto
byz.
byy.
bza.

Estrategia de Mitigacin: programar las salidas de campo
con el personal de planta externa con anticipacin, a fin de generar los

permisos requeridos a tiempo.
bzb.
bzc.
156
bzd.
bze.
012-R
bzf.
Tipo
Descripcin del Riesgo:
de requerimientos y del alcance del proyecto.

de
bzg.
Efectos
del
Riesgo: requerimientos.
bzh.
Consecuencia:
incumplimiento
cronograma,
aumento
Riesgo: serio.
bzi. Responsable (s): analista
de
de sistemas.
recursos
insuficientes.
bzj.
bzk.
bzl.
ajo
bzn.
Probabilidad
M
bzm.
edio
A
lto
bzp.
bzo.
bzq.

Estrategia de Mitigacin: recolectar los requerimientos y
definir cual ser el alcance del proyecto, cumpliendo con las pautas
establecidas.
bzr.
bzs.

bzt.Cuadro 35. Riesgo N 13.
bzv.
Descripcin
bzu.
013-R
bzw.
Tipo
incumplimiento
de
caa.
cac.
ajo
cae.
del
Riesgo: serio.
bzz.
Responsable
cronograma.
B
Riesgo:
incumplimiento de cronograma.
de
bzx.
Efectos
Riesgo: requerimientos.
bzy.
Consecuencia:
cab.
del
proyecto.
Probabilidad
M
cad.
edio
A
lto
caf.
157
cag.
cah.

Estrategia de Mitigacin: asignar estimaciones de tiempo
y recursos a las actividades de forma razonable, a fin de generar un

cronograma posible de cumplir.
cai.
caj.Cuadro 36. Riesgo N 14.
cal.Descripcin del Riesgo: imprecisin en la
cak.
014-R
cam.
captura de funcionalidades y requerimientos.

de
can.
Efectos
del
Tipo
Riesgo: estimacin.
cao.
Consecuencia:
nmero
innecesaria
correcciones
de
retrasos
general del proyecto.

caq.
car.
B
cas.
ajo
Riesgo: tolerable
cap.
Responsable
(s): analista de negocio y
analista de sistema.
Probabilidad
M
cat.
caw.
edio
lto
cav.
cax.

Estrategia de Mitigacin: cumplir con la entrega de
cau.
artefactos y sacar provecho de las reuniones pautadas con los

clientes/usuarios.
cay.
caz.
cbb.
cba.

Descripcin del Riesgo: estimacin
015-R
no acertada en materia de recursos y personal a
cbc.
asignar al proyecto.
de
cbd.
Tipo
Riesgo: estimacin.
Efectos
Riesgo: tolerable
del
158
cbe.
Consecuencia:
cbf. Responsable (s): lder del
falta de diversos tipos de
proyecto.
recursos.
cbg.
cbh.
cbi.
ajo
cbk.
Probabilidad
M
edio
cbj.
A
lto
cbm.
cbl.
cbn.

Estrategia de Mitigacin: hacer uso de herramientas de
gestin que contribuyan a estimaciones precisas de los recursos que

sern necesarios para el proyecto.
cbo.
6.4 Plan de Gestin de Configuracin.
cbp.
cbq.
La gestin de configuracin es el proceso de identificar y
definir los elementos en el sistema, controlando el cambio de estos elementos a lo

largo de su ciclo de vida, registrando y reportando el estado de los elementos y las
solicitudes de cambio, y verificando que los elementos estn completos y que sean los
correctos. Su objetivo consiste en definir y mantener la integridad de los artefactos
que se generarn a lo largo del ciclo de vida de ste proyecto, debido a que estos
sufren constantes modificaciones a lo largo del proyecto. Por consiguiente, la gestin
de la configuracin se encarga de controlar la evolucin de los productos a travs de
las diferentes iteraciones.
cbr.
cbs.
cbt.Compaa Annima Nacional Telfonos de Venezuela

cbu.
La gestin de configuracin fue llevada a cabo para llevar
un registro de los documentos generados y sus versiones. En el caso de este proyecto
159
de software, los elementos de configuracin o artefactos vienen representados por los

entregables definidos en el modelo de procesos, es decir, los programas, documentos,
datos, entre otros, forman la configuracin del software. Por lo tanto, a medida que el
desarrollo de la aplicacin avanz la configuracin creci rpidamente y surgieron
cambios de diferente tipo, que obviamente afectaron a los productos ya elaborados.
cbv.
cbw.
En base a lo anterior y para controlar estos cambios, se hizo
necesario identificar dichos productos a travs de versiones, las cuales van

aumentando en cada iteracin, hasta llegar a su versin final. Teniendo en cuenta que
los cambios en cada documento eran el producto de una revisin detallada de los
mismos, la que conduca, lgicamente a una nueva versin del producto. En ltima
instancia, es considerada, en caso que se presente, la gestin de las solicitudes de
cambio y de las modificaciones que stas produzcan, informando y publicando dichos
cambios para que sean del conocimiento de todo el equipo de trabajo.
cbx.
cby.
cbz.
cca.
ccb.
ccc.
ccd.
cce.
ccf.
ccg.
5.2 ETAPA II: MODELADO DE NEGOCIO

cch.
cci. La segunda etapa del proyecto Ingeniera de requisitos aplicado a los
procesos de instalacin y reparacin de averas, realizados por planta externa para la
unidad de conmutacin (CX) de la central digital Maturn-centro, C.A.N.T.V. estado
160
Monagas., comprende el modelado del negocio o modelado del dominio de la

aplicacin, el cual forma parte del estudio de la situacin actual, entendiendo que este
resume informacin de la empresa en cuanto a su planificacin, estrategias y
funcionamiento.
ccj.
cck. En base a esto, se puede decir que el modelado de negocio es la base para
comprender mejor la operacin de una organizacin y documentar los procesos
buscando una estandarizacin en la organizacin, puesto que los procesos de negocio
son la base para entender mejor la forma en que opera un negocio en sus diferentes
reas y son una herramienta fundamental para acceder a modelos de calidad y
eficiencia basados en diferentes estndares. El producto final del modelado de
negocio es un modelo que contribuye con el anlisis del negocio bajo estudio.
Generalmente son generados una serie de modelos que describen diferentes aspectos
de la organizacin, el autor Montilva J. (2007) seala los siguientes: propsito,
estructura, funcionalidad, dinmica y lgica de negocios. Son presentados a
continuacin los diferentes modelos generados en esta etapa:
a) Modelo de Objetivos.
b) Modelo de Procesos del Negocio.
c) Modelo de Objetos del Negocio.
d) Modelo de Reglas del Negocio.
e) Modelo de Actores del Negocio.
f) Modelo de Eventos del Negocio.
ccl.Compaa Annima Nacional Telfonos de Venezuela
ccm. Ingeniera de requisitos aplicado a los procesos de instalacin y reparacin de
161
ccp. Autor
ccq. Fech
a
ccr. Ve
ccn. MODELADO DEL NEGOCIO

cco. Versin <1.0>
ccs. Descripcin
cct. Oscar J.
ccu. 03/1
rsin
ccv. 0.8 ccw. Versin preliminar propuesta.
Ruiz
ccx. Oscar J.
1/2011
ccy. 25/1
9
ccz. 0.9 cda. Primera correccin.
Ruiz
cdb. Oscar J.
1/2011
cdc. 09/0
4
cdd. 0.9 cde. Segunda correccin.
Ruiz
cdf. Oscar J.
1/2012
cdg. 21/0
9
cdh. 1.0 cdi. Versin final del producto.
Ruiz
2/2012
cdj.
1. Introduccin.
cdk.
cdl. Este documento tiene como objetivo fundamental describir de forma
precisa el sistema bajo estudio, desde el punto de vista de sus procesos
fundamentales, puesto que en muchas ocasiones stos son difciles de comprender,
bien sea porque son muy amplios o complejos. A travs del documento de modelado
de negocio sern identificados los procesos correspondientes a la unidad de
conmutacin de la central digital Maturn-centro, junto con los elementos
fundamentales que los componen, las relaciones que mantienen entre ellos y los
actores que son responsables de los mismo, a modo de obtener un mayor
entendimiento sobre los requisitos que la aplicacin deber atender y satisfacer. En
este sentido, la importancia del modelado del negocio radica en que el mtodo de
trabajo Gray Watch lo define como una etapa necesaria y fundamental para dar inicio
a la fase de ingeniera de requisitos.
cdm.
cdn. Compaa Annima Nacional Telfonos de Venezuela
2. Representacin del modelado de negocio.
cdo.
162
cdp. A nivel organizacional, el modelado de negocio permite representar de

forma grfica toda la informacin relacionada con los objetivos del sistema,
subsistemas, sus interrelaciones y del entorno o contexto donde se har operativa la
aplicacin. De esta manera, se hace uso de la metodologa Gray Watch, la cual
propone para el modelado del negocio la herramienta UML BUSSINES, orientada
hacia los procesos del negocio, facilitando el modelado de los mismos a travs de
smbolos y estereotipos que brindan significado a los smbolos utilizados. As mismo,
hace uso de la cadena de valor de Michael Porter para modelar y descomponer
procesos con el fin de ser comprendidos de forma ms precisa.
cdq.
cdr. Para lograr esto, fue necesario en primer lugar identificar la unidad de
conmutacin de la central digital Maturn-centro junto con cada uno de los procesos
que se llevan a cabo dentro de sus lmites operacionales, a fin de documentar la forma
como estos deben ser ejecutados. Una vez determinados los procesos, se estableci
nfasis especial en el proceso de instalacin y reparacin de averas, el cual presenta
deficiencia dentro de su ejecucin, requiriendo de la aplicacin que se propone con el
presente proyecto.
cds.
3. Modelo de jerarquas.
cdt.
cdu. Mediante la Figura 17 se puede apreciar el modelo de jerarquas del
sistema de negocio, el cual representa la jerarqua de los sistemas que se delimitan
dentro de la Compaa Annima Nacional Telfonos de Venezuela con respecto al
rea bajo estudio.
cdv.

cdw. Puesto que al considerar los distintos tipos de sistemas que integran a
C.A.N.T.V es posible proporcionar una delimitacin que establezca el entorno del
sistema bajo estudio, enfocndose bsicamente en el supra sistema, sistema y
subsistema.
cdx.
163
cdy.
cdz.
cea.
ceb.
cec.
ced.
cee.
cef.
ceg.
ceh.
cei.
cej.
cek.
cel.
cem.
cen.
ceo.
cep.
ceq.
cer.
ces.
cet.Figura 17. Modelo de Jerarqua de Sistema de la Gerencia Red
Estado Monagas.
ceu.
4. Modelo de objetivos.
cev.
cew. A travs de este modelo se representan jerrquicamente los objetivos del
sistema de negocio en base a la misin y visin de la misma. El anlisis de objetivos
es un procedimiento que permite identificar y clasificar los objetivos por orden de
importancia, permitiendo su visualizacin en un diagrama de relaciones de los
mismos.
cex.
cey. En este importante diagrama va plasmada la orientacin operacional de la
empresa hacia el departamento de conmutacin (CX), dejando ver claramente el
camino que desea recorrer para alcanzar sus metas, teniendo claro lo que son
164
actualmente y hacia dnde quieren llegar. Es por ello que la misin y la visin de la
empresa constituyen los pilares fundamentales de la organizacin, los cuales junto
con sus objetivos operacionales, no operaciones y procesos de negocios hacen posible
la continuidad operativa de la compaa, ofreciendo a los venezolanos servicios de
calidad al alcance de todos.
cez.
cfa. Para sustentar lo dicho anteriormente, el Diagrama 1, presentado a
continuacin, refleja el diagrama de objetivos de la empresa, sealando, de forma
adicional el objetivo institucional, los objetivos por procesos y una breve descripcin
del problema sobre el cual se basa este proyecto.
165
cfb.
cfc.
cfd.
cfe.
cff.
cfg.
cfh.
cfi.
cfj.
cfk.
cfl.
cfm.
cfn.
cfo.
cfp.
cfq.
cfr.
cfs.
cft.
cfu.
Diagrama 1. Diagrama de Objetivos.
166
cfv.Compaa Annima Nacional Telfonos de Venezuela

5. Modelo de Procesos del Negocio.
cfw.
cfx. El objetivo de este modelo es describir los procesos tcnicos,
gerenciales y de soporte que los equipos de trabajo deben estudiar y analizar
para desarrollar posteriormente las aplicaciones de software, considerando el
negocio como el entorno donde se har operativo el sistema. Generalmente
este modelo contiene una representacin detallada de cada uno de los procesos
del negocio, incluyendo cada uno de los elementos que intervienen o forman
parte de los mismos y que son considerados necesarios para que dichos
procesos puedan ser desarrollados de forma eficiente y dentro de los
lineamientos y normativas que los rigen, por ejemplo, las maquinarias o los
actores que se ven involucrado dentro de estos procesos.
cfy.
cfz. Los procesos que son modelados en esta etapa se encuentran
constituidos por una serie de actividades y se caracterizan por ser observables,
medibles, mejorables y repetitivos dentro de la empresa. En este sentido, se
representarn todos estos procesos del negocio, enfocndose en cmo se
llevan a cabo los mismos, sus actividades, reglas y normas que los rigen, los
actores que desempean roles en las actividades y los eventos que activan el
inicio de los procesos.
cga.
5.1 Cadena de Valor del Negocio
cgb.
cgc.Con la finalidad de entender y analizar las actividades especficas
con las cuales las organizaciones pueden crear valor y ventaja competitiva,
enfocados en la unidad de conmutacin de la empresa telefnica C.A.N.T.V.,
se emple el modelo terico que permite describir el desarrollo de las
167
actividades de una organizacin generando valor al cliente final descrito y

popularizado por Michael E. Porter.
cgd.

cge. Sern estudiados entonces las actividades primarias (procesos

fundamentales o primarios) y las actividades de soporte (procesos de apoyo o
soporte) de la unidad de conmutacin (CX) a fin de elevar el nivel de
comprensin de dicho sistema y de su entorno. A continuacin se presenta la
Figura 18, la cual muestra la cadena de valor de Porter para la unidad de
conmutacin (CX) de la Compaa Nacional Telfonos de Venezuela.
cgf.
cgg.
cgh. Cadena de Valor del Negocio
cgi.
cgj.
Reparacin de Averas PF 3
cgk.
Instalaciones PF Retiros
1
PF 2
Procesos Fundamentales
cgl.
cgm.
cgn.
cgo.
INFORMACIN
cgp.
Procesos de Apoyo
cgq.
cgr.
RECURSOS
TECNOLGICOS
Figura 18. Cadena
de Valor de
la Unidad de Conmutacin (CX).
RECURSO HUMANO
cgs. Como lo muestra el diagrama anterior, para la unidad de

conmutacin se presentan tres procesos fundamentales: instalaciones, retiros y
la reparacin de averas. Estos procesos primarios, son los requeridos para que
la empresa pueda prestar un buen servicio a sus suscriptores, garantizando la
calidad del mismo y la atencin inmediata de cualquier avera o falla que
pueda presentarse eventualmente. Adicional a esto se tienen los procesos de
apoyo, las cuales sirven de soporte a las actividades que se realizan dentro del
rea.
168
cgt.Compaa Annima Nacional Telfonos de Venezuela

cgu.Entre las actividades de soporte que apoyan los procesos
fundamentales de la unidad de conmutacin, se encuentran:
cgv.
cgw.
Informacin: constituye el conjunto de datos
procesados, documentados o no, que rigen el correcto
funcionamiento de los procesos (normativas, manuales,
INFORMACIN
reglas de negocio) y que brindan los conocimientos

necesarios a los empleados que laboran dentro de la
unidad.
cgx.
cgy.
cgz.
Recursos Tecnolgicos: hace referencia al
manejo y la gestin de equipos tecnolgicos que sirven

como herramientas para dar soporte a los procesos
RECURSOS
TECNOLGICOS
(Computadoras,
impresoras,
punta
de
pruebas,
ponchador, micro telfono de prueba, jumper)

cha.
chb.
chc.
Recurso Humano: representa a todas las
personas con el talento y la capacidad para realizar de

forma correcta y eficiente cada una de las actividades de
RECURSO
HUMANO
la
unidad
de
telecomunicaciones,
conmutacin.
jumpero,
(Tcnico
tcnico
en
en
servicios
especiales, tcnico instalador, tcnico reparador averas

ABA, tcnico reparador averas telefnicas)
chd.
che.
chf.
chg.

5.2 Diagrama Jerrquico de Procesos.
169
chh.
chi. El diagrama jerrquico de procesos permite representar los procesos
fundamentales de una unidad organizacional, descomponindolos en
subprocesos ms especficos que puedan ser explicados y descritos mediante
una serie de actividades. La cadena de valor cumple un papel muy importante
en esta representacin, debido a que a partir de los procesos primarios es que
se procede con la descomposicin de los mismos en otros procesos que sirven
de apoyo a los procesos fundamentales.
chj.
chk.De esta manera es posible plasmar los procesos organizaciones
representados de forma grfica mediante diferentes niveles, generando
entonces procesos de alto y bajo nivel que mantienen su integridad y
coherencia. El objetivo principal es llegar a representar mediante diagramas
de actividades los procesos de ms bajos nivel que ya no pueden seguir siendo
descompuestos en procesos de niveles inferiores.
chl.
chm.
chn.
cho.
chp.
chq.
chr.
chs.
cht.
chu.
chv.
chw.
Diagrama 2. Diagrama de Jerarqua de Procesos de la Unidad

de Conmutacin.
chx. Compaa Annima Nacional Telfonos de Venezuela

5.3 Diagramas de Proceso para los Procesos Fundamentales de la unidad de
conmutacin: instalaciones, retiros, reparacin de averas.
chy.
PF-1.1 Instalacin ABA.
170
chz.
cia. Este proceso tiene como propsito completar correctamente, y en el
tiempo estimado, todas las solicitudes de instalaciones del servicio de acceso a banda
ancha (ABA).
cib.
cic.
cid.
cie.
cif.
cig.
cih.
cii.
cij.
cik.
cil.
cim.
cin.
cio.
cip.
ciq.
cir. Diagrama 3. Diagrama de Proceso: Instalacin ABA.
cis.
cit. Compaa Annima Nacional Telfonos de Venezuela
ciu. Diagrama de actividades del proceso 1.1 Instalacin ABA:
civ.
Nivel 0
ciw.
cix.
Nivel 1
ciy.
ciz.
cja.
cjb.
cjc.
cjd.
cje.
cjf.
cjg.
cjh.
cji.
cjj.
cjk.
Nivel 2
Nivel 3
171
cjl.
cjm.
cjn.
cjo.
cjp.
cjq.
cjr.
cjs.
cjt.
Diagrama 4. Diagrama de Actividades: Instalacin ABA.
cju.
cjv. PF-1.2 Instalaciones Comerciales.
cjw.
cjx. El propsito de este proceso es realizar todas las rdenes de trabajo en
materia de instalaciones telefnicas a locales comerciales.
cjy.
cjz.
cka.
ckb.
ckc.
ckd.
cke.
ckf.
ckg.
ckh.
cki.
ckj.
ckk.
ckl.
ckm.
ckn.
Diagrama 5. Diagrama de Proceso: Instalaciones Comerciales.
cko.
ckp.
ckq.
ckr.
cks.
ckt.
cku.
ckv.

172
ckw. Diagrama de actividades del proceso 1.2 Instalaciones Comerciales:
ckx.
cky.
ckz.
cla.
clb.
clc.
cld.
cle.
clf.
clg.
clh.
cli.
clj.
clk.
cll.
clm.
cln.
clo.
clp.
clq.
clr.
cls.
clt.
clu.
clv.
Nivel 0
Nivel 1
Nivel 2
Nivel 3
clw.
Diagrama 6. Diagrama de Actividades: Instalaciones

Comerciales.
clx.Compaa Annima Nacional Telfonos de Venezuela

cly. PF-1.3 Instalaciones Residenciales.
clz.
cma. El proceso de Instalaciones residenciales tiene como finalidad completar
todas las solicitudes de instalaciones telefnicas a clientes residenciales.
cmb.
cmc.
cmd.
cme.
cmf.
cmg.
cmh.
cmi.
173
cmj.
cmk.
cml.
cmm.
cmn.
cmo.
cmp.
cmq.
Diagrama 7. Diagrama de Proceso: Instalaciones Residenciales.
cmr.
cms.
cmt.
cmu.
cmv.
cmw.
cmx.
cmy.

cmz. Diagrama de actividades del proceso 1.3 Instalaciones Residenciales:
cna.
cnb.
cnc.
cnd.
cne.
cnf.
cng.
cnh.
cni.
cnj.
cnk.
cnl.
cnm.
cnn.
cno.
cnp.
cnq.
cnr.
cns.
cnt.
cnu.
cnv.
cnw.
cnx.
Nivel 0
Nivel 1
Nivel 2
Nivel 3
174
cny.
cnz.
Diagrama 8. Diagrama de Actividades: Instalaciones

Residenciales.
175
coa.

cob. PF-1.4 Instalaciones Voz y Dato.
coc.
cod. La meta principal de este proceso es realizar todas las rdenes de trabajo
que hacen referencia a instalaciones del servicio telefnico y de internet para un
mismo suscriptor.
coe.
cof.
cog.
coh.
coi.
coj.
cok.
col.
com.
con.
coo.
cop.
coq.
cor.
cos.
cot.Diagrama 9. Diagrama de Proceso: Instalaciones Voz y Dato.
cou.
cov.
cow.
cox.
coy.
coz.
cpa.

cpb. Diagrama de actividades del proceso 1.4 Instalaciones Vos y Dato:

cpc.
cpd.
cpe.
cpf.
cpg.
cph.
cpi.
cpj.
cpk.
Nivel 0
Nivel 1
Nivel 2
Nivel 3
176
cpl.
cpm.
cpn.
cpo.
cpp.
cpq.
cpr.
cps.
cpt.
cpu.
cpv.
cpw.
cpx.
cpy.
cpz.
cqa.
cqb.
Diagrama 10. Diagrama de Actividades: Instalaciones Voz y

Dato.
cqc.

cqd. PF-1.5 Reinstalacin del Servicio.
cqe.
cqf. El proceso de reinstalacin del servicio persigue restablecer nuevamente
el servicio telefnico a aquellos clientes que por algn motivo u otro no cuentan con
su lnea telefnica activa.
cqg.
cqh.
cqi.
cqj.
cqk.
cql.
cqm.
cqn.
cqo.
cqp.
cqq.
cqr.
cqs.
cqt.
cqu.
cqv.
Diagrama 11. Diagrama de Proceso: Reinstalacin del Servicio.
177
cqw.
cqx.
cqy.
cqz.
cra.
crb.
crc.

crd. Diagrama de actividades del proceso 1.5 Reinstalacin del Servicio:
cre.
crf.
crg.
crh.
cri.
crj.
crk.
crl.
crm.
crn.
cro.
crp.
crq.
crr.
crs.
crt.
cru.
crv.
crw.
crx.
cry.
crz.
csa.
csb.
csc.
Nivel 0
Nivel 1
Nivel 2
Nivel 3
csd.
Diagrama 12. Diagrama de Actividades: Reinstalacin del

Servicio.
cse.
csf. PF-1.6 Instalacin de Servicios Especiales.

csg.
178
csh. El propsito del proceso de instalacin de servicios especiales consiste en

completar eficientemente las ordenes de trabajo se solicitud de lneas telefnicas a
clientes importantes o grandes empresas como bancos, empresas gubernamentales,
entre otras.
csi.
csj.
csk.
csl.
csm.
csn.
cso.
csp.
csq.
csr.
css.
cst.
csu.
csv.
csw.
csx.
Diagrama 13. Diagrama de Proceso: Instalacin de Servicios

Especiales.
csy.
csz.
cta.
ctb.
ctc.
ctd.Compaa Annima Nacional Telfonos de Venezuela
cte.
ctf.
ctg.
cth.
cti.
ctj.
ctk.
ctl.
ctm.
ctn.
cto.
ctp.
ctq.
Diagrama de actividades del proceso 1.6 Instalacin de Servicios Especiales:

Nivel 0
Nivel 1
Nivel 2
179
ctr.
cts.
ctt.
ctu.
ctv.
ctw.
ctx.
cty.
ctz.
cua.
cub.
Nivel 3
cuc.
Diagrama 14. Diagrama de Actividades: Instalacin de

Servicios Especiales.
cud.
cue.
cuf.

cug. PF-1.7 Instalacin Telfonos Pblicos.

cuh.
cui. Los telfonos pblicos son un servicio que se encuentra al alcance de
todos los ciudadanos, en la unidad de conmutacin, el proceso consiste en completar
las instalaciones de las rdenes de trabajo para telefona pblica.
cuj.
cuk.
cul.
cum.
cun.
cuo.
cup.
cuq.
cur.
cus.
cut.
cuu.
cuv.
cuw.
cux.
cuy.
cuz.
cva.
Diagrama 15. Diagrama de Proceso: Instalacin Telfonos

Pblicos.
180
cvb.
cvc.
cvd.
cve.
cvf.Compaa Annima Nacional Telfonos de Venezuela
cvg. Diagrama de actividades del proceso 1.7 Instalacin Telfonos Pblicos:
cvh.
cvi.
cvj.
cvk.
cvl.
cvm.
cvn.
cvo.
cvp.
cvq.
cvr.
cvs.
cvt.
cvu.
cvv.
cvw.
cvx.
cvy.
cvz.
cwa.
cwb.
cwc.
cwd.
cwe.
cwf.
Nivel 0
Nivel 1
Nivel 2
Nivel 3
cwg.
Diagrama 16. Diagrama de Actividades: Instalacin Telfonos

Pblicos.
cwh. Compaa Annima Nacional Telfonos de Venezuela

cwi. PF-2.1 Retiro de Lazo.
cwj.
cwk. El proceso 2.1 corresponde al retiro de lazo, el cual tiene por objetivo
desconectar la lnea telefnica de algn suscriptor para suspender el servicio.
cwl.
181
cwm.
cwn.
cwo.
cwp.
cwq.
cwr.
cws.
cwt.
cwu.
cwv.
cww.
cwx.
cwy.
cwz.
cxa.
cxb.
Diagrama 17. Diagrama de Proceso: Retiro de Lazo.

cxc.
cxd.
cxe.
cxf.
cxg.
cxh.
cxi.Compaa Annima Nacional Telfonos de Venezuela
cxj. Diagrama de actividades del proceso 2.1 Retiro de Lazo:

cxk.
cxl.
cxm.
cxn.
cxo.
cxp.
cxq.
cxr.
cxs.
cxt.
cxu.
cxv.
cxw.
cxx.
cxy.
cxz.
cya.
cyb.
Nivel 0
Nivel 1
Nivel 2
Nivel 3
182
cyc.
cyd.
cye.
cyf.
cyg.
cyh.
cyi.
cyj.Diagrama 18. Diagrama de Actividades: Retiro de Lazo.
cyk.
cyl. PF-2.2 Retiro por Pago.
cym.
cyn. Este proceso tiene como finalidad completar todas las rdenes de trabajo
en materia de retiros telefnicos a clientes que no han cumplido con los pagos
establecidos por la prestacin del servicio.
cyo.
cyp.
cyq.
cyr.
cys.
cyt.
cyu.
cyv.
cyw.
cyx.
cyy.
cyz.
cza.
czb.
czc.
czd.
cze.
czf.
Diagrama 19. Diagrama de Proceso: Retiro por Pago.
183
czg.

czh. Diagrama de actividades del proceso 2.2 Retiro por Pago:
czi.
Nivel 0
czj.
czk.
czl.
Nivel 1
Nivel 1
Nivel
Nivel
2 2
czm.
czn.
czo.
czp.
czq.
czr.
Nivel 3
czs.
czt.
czu.
czv.
czw.
czx.
czy.
czz.
daa.
dab.
dac.
Diagrama 20. Diagrama de Actividades: Retiro por Pago.
184
dad.

dae. PF-2.3 Retiro ABA por Solicitud del Cliente.
daf.
dag. El propsito de este proceso es proceder con la desconexin del servicio
de acceso a banda ancha por solicitud del cliente, manteniendo la continuidad de la
seal de voz.
dah.
dai.
daj.
dak.
dal.
dam.
dan.
dao.
dap.
daq.
dar.
das.
dat.Diagrama 21. Diagrama de Proceso: Retiro ABA por Solicitud del
Cliente.
185
dau.

dav. Diagrama de actividades del proceso 2.3 Retiro ABA por Solicitud del Cliente:
daw.
Nivel 0
dax.
day.
Nivel 1
daz.
dba.
dbb.
Nivel 2
dbc.
dbd.
dbe.
dbf.
Nivel 3
dbg.
dbh.
dbi.
dbj.
dbk.
dbl.
dbm.
dbn.
dbo.
dbp.
dbq.
Diagrama 22. Diagrama de Actividades: Retiro ABA.
186
dbr.

dbs. PF-3.1 Averas Telefnicas
dbt.
dbu. El proceso de averas telefnicas tiene como meta solventar en cortos
perodos de tiempo cualquier tipo de fallas que pudiese estar ocasionando problemas
en el servicio telefnico.
dbv.
dbw.
dbx.
dby.
dbz.
dca.
dcb.
dcc.
dcd.
dce.
dcf.
dcg.
dch.
Diagrama 23. Diagrama de Proceso: Averas Telefnicas.
dci.
dcj.
dck.
dcl.
dcm.
dcn.
dco.

dcp. Diagrama de actividades del proceso 3.1 Averas Telefnicas:

dcq.
Nivel 0
dcr.
Nivel 1
187
dcs.
dct.
dcu.
dcv.
Nivel 2
dcw.
dcx.
dcy.
dcz.
dda.
ddb.
ddc.
ddd.
dde.
ddf.
ddg.
ddh.
ddi.
ddj.
ddk.
ddl.
ddm.
ddn.
ddo.
Nivel 3
ddp.
Diagrama 24. Diagrama de Actividades: Averas Telefnicas.

ddq. Compaa Annima Nacional Telfonos de Venezuela

ddr. PF-3.2 Averas ABA.
dds.
ddt. Se consideran averas aba a todas aquellas irregularidades que pudiesen
ocasionar cualquier tipo de fallas en el servicio de acceso a banda ancha, estas averas
van desde una mala configuracin del computador del cliente hasta la no
sincronizacin del modem. En este sentido, el propsito de este proceso consiste en
atender y dar solucin, de forma eficiente y en cortos perodos de tiempos, a las
averas aba reportadas por los suscriptores del servicio.
ddu.
ddv.
ddw.
ddx.
ddy.
188
ddz.
dea.
deb.
dec.
ded.
dee.
def.
deg.
deh.
dei.
dej.Diagrama 25. Diagrama de Proceso: Averas ABA.
dek.
del.
dem.

den. Diagrama de actividades del proceso 3.2 Averas ABA:

deo.
Nivel 0
dep.
Nivel 1
deq.
der.
Nivel 2
des.
det.
deu.
dev.
dew.
dex.
dey.
dez.
dfa.
Nivel 3
189
dfb.
dfc.
dfd.
dfe.
dff.
dfg.
dfh.
dfi. Diagrama 26. Diagrama de Actividades: Averas Aba.
dfj. Compaa Annima Nacional Telfonos de Venezuela
6. Modelos de Objetos del Negocio
dfk.
dfl. Dentro de la ejecucin de cada uno de los procesos del negocio se
ven involucrados una serie de elementos que desempean funciones
especficas dentro de dichos procesos. Estos elementos son conocidos como
objetos, y son creados, usados, consumidos y/o transformados por las
actividades asociados a los procesos de negocio. Generalmente se les conoce
como recursos que utiliza el negocio a nivel de operaciones y procesos.
dfm.
dfn. Existen objetos fsicos y objetos abstractos, los fsicos hacen
referencia a un elemento del
mundo real mientras que los abstractos
representan objetos productos de la mente humana, es decir, no existen

fsicamente. A pesar de esta clasificacin, ambos se caracterizan por poseer
atributos y comportamientos especficos que son definidos durante la
ejecucin de los procesos.
dfo.
6.1 Diagrama de Objetos.
dfp.
190
dfq. Para cada uno de los procesos que constituyen la parte operacional
de la unidad de conmutacin, se presentan diversos objetos que desempean
un papel fundamental en la correcta ejecucin de las actividades. El diagrama
objetos ser presentado por procesos, plasmando de forma grfica los objetos
y haciendo nfasis en las relaciones existente entre cada uno de ellos. A
continuacin se muestran los diagramas de objetos para los procesos de la
unidad de conmutacin (CX) de la central digital Maturn-Centro
perteneciente a la Compaa Nacional Telfonos de Venezuela:
dfr.
dfs.Compaa Annima Nacional Telfonos de Venezuela
dft.
dfu.
dfv.
dfw.
dfx.
dfy.
dfz.
dga.
dgb.
dgc.
dgd.
dge.
dgg.
dgh.
dgi.
dgj.
dgk.
dgl.
dgm.
dgn.
dgo.
dgp.
dgq.
Diagrama 27. Diagrama de Objetos para el proceso Instalacin

ABA.
dgf.
191
dgr.
Diagrama 28. Diagrama de Objetos para el proceso

Instalaciones Comerciales.
dgs.
dgt.

dgu.
dgv.
dgw.
dgx.
dgy.
dgz.
dha.
dhb.
dhc.
dhd.
dhe.
dhf.
dhg.

Instalaciones Residenciales.
192
dhh.
dhi.

Voz y Dato.
dhj.
dhk.
193
dhl.
dhm.
dhn.

Reinstalacin del Servicio.
194
dho.
dhp.

de Servicios Especiales.
dhq. Compaa Annima Nacional Telfonos de Venezuela
dhr.
195
dhs.
dht.

Telfonos Pblicos.
196
dhu.
dhv.
Diagrama 34. Diagrama de Objetos para el proceso Retiro de

Lazo.
dhw. Compaa Annima Nacional Telfonos de Venezuela
197
dhx.
dhy.
dhz.
Diagrama 35. Diagrama de Objetos para el proceso Retiro por

Pago.
198
dia.
dib.
Diagrama 36. Diagrama de Objetos para el proceso Retiro ABA

por Solicitud del Cliente.
dic.Compaa Annima Nacional Telfonos de Venezuela
199
did.
Diagrama 37. Diagrama de Objetos para el proceso Averas

Telefnicas.
die.
dif.
200
dig.
Diagrama 38. Diagrama de Objetos para el proceso Averas

ABA.
dih.
6.2 Diagrama de Clases.

dii.
dij. El propsito de del diagrama de clases es el de representar los
objetos fundamentales del negocio, es decir, los elementos que percibe el
cliente y que forman parte de los procesos empresariales junto con las
respectivas relaciones entre las diferentes clases de objetos. El Diagrama 39
presenta el diagrama de clases de objetos para los procesos de la unidad de
conmutacin (CX).
dik.
dil.
dim.
din.
dio.
dip.
diq.
dir.
dis.
dit.
diu.
div.
diw.
dix.
diy.
diz.
dja.
djb.
djc.Diagrama 39. Diagrama de Clases para la Unidad de Conmutacin

(CX).
201
6.3 Matriz Procesos Vs Objetos.

djd.
djf.
I
djg.
I
djh.
In
dji.
I
djj.
R
djk.
I
djl.
Ins
djm.
R
djn.
R
djo.
Reti
djp.
A
djs.
djt.
dju.
djv.
djw.
djx.
djy.
djz.
dka.
dkb.
dkg.
dkh.
dki.
dkj.
dkk.
dkl.
dkm.
dkn.
dko.
dkt.
dku.
dkv.
dkw.
dkx.
dky.
dkz.
dla.
dlg.
dlh.
dli.
dlj.
dlk.
dll.
dlm.
dlu.
dlv.
dlx.
dly.
dlz.
dma.
dmb.
dmk.
dmm.
dmn.
dmo.
dmp.
dje.
O
djr.
O
dkd.
O
dkf.
dke.
C
dkq.
O
dkr.
dks.
dlc.
O
dld.
dle.
dlf.
dlo.
O
dlq.
dlr.
dls.
dlt.
dlw.
dlp.
dmd.
dme.
dmf.
dmg.
dmh.
dmi.
dmj.
202
dml.
dmr.
O
dms.
dmt.
dmu.
dmv.
dmw.
dmx.
dmy.
dmz.
dna.
dnb.
dnc.
dnm.
dnn.
dno.
dnz.
doa.
dne.
O
dnf.
dng.
dnh.
dni.
dnj.
dnk.
dnl.
dnq.
O
dnr.
dns.
dnt.
dnu.
dnv.
dnw.
dnx.
dny.
doc.
O
dod.
doe.
dof.
dog.
doh.
doi.
doj.
dok.
dol.
doo.
O
dop.
doq.
dor.
dos.
dot.
dou.
dov.
dow.
dox.
doy.
dpa.
O
dpb.
dpc.
dpd.
dpe.
dpf.
dpg.
dph.
dpi.
dpj.
dpk.
dpl.
dpv.
Ins
dpw.
R
dpx.
R
dpy.
Reti
dpz.
A
dpm.
dpn.
dpp.
I
dpq.
I
dom.
Cuadro 38. Matriz Procesos vs Objetos.
dpr.
In
dps.
I
dpt.
R
dpu.
I
dpo.
O
dqb.
203
C
dqc.
T
dqd.
dql.
T
dqm.
dqn.
dqo.
dqp.
dqq.
dqe.
dqf.
dqg.
dqh.
dqi.
dqj.
dqr.
dqs.
dqt.
dqu.
dqv.
dqw.
dqy.
O
dqz.
drl.
T
dra.
drm.
drb.
dro.
drc.
drp.
drd.
drq.
dre.
drr.
drf.
drs.
drg.
drt.
drh.
dru.
dri.
drv.
drj.
drw.
drx.
drn.
drz.
T
dsa.
dsb.
dsc.
dsd.
dse.
dsm.
dso.
dsq.
dsr.
dss.
dst.
dsf.
dsg.
dsh.
dsi.
dsj.
dsk.
dsu.
dsv.
dsw.
dsx.
dsy.
dsz.
dsn.
J
dsp.
dtb.
T
dtc.
dtk.
T
dtl.
dtm.
dtn.
dto.
dtp.
dtd.
dte.
dtf.
dtg.
dth.
dti.
dtq.
dtr.
dts.
dtt.
dtu.
dtv.
204
dtx.
T
dty.
dtz.
dua.
dub.
duc.
dud.
due.
duf.
dug.
duh.
dui.
duk.
Cuadro 38. (Cont.).
205
dul.

7. Modelo de Reglas del Negocio.

dum.
dun.
Los procesos constituyen el motor operacional de cualquier
organizacin, el correcto funcionamiento de estos son los que garantizan a la
empresa continuidad y estabilidad a travs del tiempo. Es aqu donde radico la
importancia que se les acredita a los procesos de negocios, sin estos, las
organizaciones no avanzaran, no cumpliran sus metas. Por tal razn, es
necesario reglas y normas que regulen y controlen dichos procesos, con el
objetivo de asegurar la correcta ejecucin de los mismos. Generalmente, estas
pautas o normas son conocidas a nivel empresarial como reglas de negocio.
duo.
dup.
Las reglas de negocio contienen un texto explicativo con
aclaraciones o instrucciones a seguir. Cuando estas son usadas en los
procesos, reflejan una serie de pautas y normas que deben guiar o instruir, en
la medida de lo posible, a los actores que desempean roles en las actividades
empresariales, a fin de establecer un patrn de accin dentro de los procesos
del negocio.
duq.
7.1 Diagrama de Reglas de Negocio.
dur.
dus.El diagrama de reglas de negocio es uno de los productos del
proceso de modelado de reglas del negocio de una organizacin. Para lograr la
realizacin de este diagrama que rige y regula los procesos dentro de la unidad
de conmutacin (CX) fue necesario identificar, analizar y estudiar cada uno de
los procesos que comprenden el nivel operativo de este importante
departamento perteneciente a la compaa telefnica C.A.N.T.V. La Figura 18
muestra el diagrama de reglas de negocio para la unidad de conmutacin.
206
dut.

duu.
duv.
duw.
dux.
duy.
duz.
dva.
dvb.
dvc.
dvd.
dve.
dvf.
dvg.
dvh.
dvi.
dvj.
Figura 19. Modelo de Reglas del Negocio.

dvk.
8. Modelado de Actores del Negocio.

dvl.
dvm.
Los actores del negocio pueden ser definidos como cualquier
individuo, grupo, entidad, organizacin, mquina o sistema de informacin;
que interacta con los procesos de la organizacin. Generalmente estos
actores desempean un rol dentro de las actividades empresariales, es decir,
cumplen con un rol o una tarea que apoya a los procesos fundamentales del
negocio, muchas veces no solo contribuyen en la ejecucin del procesos, sino
que son responsables de los mismos, por consiguiente, deben garantizar a la
organizacin el cumplimiento de las metas asignadas por cada proceso.
dvn.

dvo.
A nivel empresarial, pueden existir dos tipos de actores, los
internos, que forman parte del sistema de negocio, y aquellos que forman
parte del entorno del negocio pero que interactan con l y son considerados
actores externos. Su clasificacin la define el alcance del actor o del mbito al
207
que pertenezca. Al momento de realizar el modelado de actores el objetivo no

es representar personas sino los roles, funciones o tareas que stas
desempean.
dvp.
dvq.
Para cada proceso, intervienen actores que no necesariamente
deben de participar en los otros procesos, esto es definido en base a los roles
que
desempeen.
Establecindose
entonces
una
estructura
nivel
organizacional y de procesos que indica los niveles de autoridad que rigen las
relaciones entre los actores o unidades de negocio.
dvr.
8.1 Matriz Proceso/Actividad/Actor.
dvs.
dvt. Los actores son parte fundamental dentro de cada organizacin y en
muchas oportunidades son estos la clave para que las tareas sean cumplidas de
forma correcta. Desempeando funciones de calidad en los procesos,
garantizan los logros de la organizacin. Por tal razn, es importante conocer
las actividades que cumple cada actor en los procesos en los cuales forma
parte.
dvu.
dvv.El objetivo de esta matriz es reflejar la relacin que existe entre los
actores y las actividades que estos ejecutan de manera especfica para cada
proceso. De esta manera, el Cuadro 39, muestra los diferentes procesos que se
realizan en la unidad de conmutacin, los actores que cumplen rol en estos
procesos y las actividades que deben realizar.
208
dvw.

dvx.
dvy.
Cuadro 39. Matriz Proceso/Actividad/Actor.
209
dvz.
dwa.
dwb.

dwc.
Cuadro 39. (Cont.).
210
dwd.
dwe.

dwf.
Cuadro 39. (Cont.).
211
dwg.
dwh.

dwi.
Cuadro 39. (Cont.).
212
dwj.
dwk.

dwl.
Cuadro 39. (Cont.).
213
dwm.
dwn.

dwo.
dwp.
dwq.
Cuadro 39. (Cont.).
214
dwr.
dws.
dwt.
dwu.
dwv.
dww.

dwx.
Cuadro 39. (Cont.).
215
dwy.
dwz.
dxa.
dxb.
dxc.
dxd.
216
dxe.

dxg.
dxh.
dxi.
dxj.
dxf.
Cuadro 39. (Cont.).
217
dxk.
dxl.

dxm.
Cuadro 39. (Cont.).
218
dxn.
dxo.

dxp.
Cuadro 39. (Cont.).
219
dxq.

220
9. Modelo de Eventos del Negocio.

dxr.
dxs. A nivel empresarial, los procesos son activados por un hecho o
acontecimiento que da inicio a la ejecucin del mismo. Estos hechos que activan
acciones que deben ser llevadas a cabo por algn actor del negocio para dar
continuidad al proceso y lograr su finalizacin de forma eficiente, se conocen como
eventos. Esta ocurrencia de eventos puede tanto disparar la activacin inmediata de
un proceso como alterar el estado de un objeto en especfico.
dxt.
dxu. Generalmente un evento puede provocar que se d inicio o no a una serie
de acciones dentro de una unidad organizacional. En este sentido, es de mucha
importancia que los eventos sean identificados, teniendo en cuenta sus causas y
posibles consecuencias. Esto brindara a la organizacin la posibilidad de estar
preparados y tener acciones previamente establecidas en caso de presentarse
cualquier situacin.
dxv.
9.1 Enumeracin de Eventos.
dxw.
dxx. Para el modelo de eventos del negocio, es de suma importancia la
enumeracin de los eventos o acontecimientos que pudiesen activar procesos y
acciones a nivel organizacional. A continuacin se presentan de forma enumerada
esta serie de eventos que activan procesos dentro de la unidad de conmutacin (CX):
dxy.
a) Solicitud del servicio ABA por parte del cliente.
b) Solicitud de lnea telefnica por parte del cliente.
dxz.

c) Solicitud de servicios telefnicos e internet por parte del cliente.
221
d) Solicitud de reinstalacin del servicio telefnico por parte del cliente.

e) Solicitud de servicios especiales.
f) Solicitud de telfonos pblicos.
g) Solicitud de suspensin de servicio telefnico por parte del cliente.
h) Solicitud de retiros por falta de pagos.
i) Solicitud de retiro del servicio ABA por parte del cliente.
j) Reporte de averas telefnicas por parte del cliente.
k) Reporte de averas ABA por parte del cliente.
l) Finalizacin de alguna instalacin.
m) Finalizacin de algn retiro.
n) Avera resuelta.
o) Asignacin de rdenes de trabajo en sistema.
dya.
9.2 Diagrama de Eventos.
dyb.
dyc. La finalidad de los diagramas de eventos consiste en plasmar en forma
visual, jerrquica y secuencial la relacin que existe entre cada uno de los eventos
enumerados anteriormente y los procesos del negocio de la cual la unidad de
conmutacin de la central digital Maturn-centro es responsable. Seguidamente a esto,
sern presentados los diagramas de eventos para los procesos de la unidad de
conmutacin (CX):
dyd.

222
dye.
dyf.
Diagrama 40. Diagrama de Eventos para la Unidad de

Conmutacin (CX).
dyg.
223
dyh.
dyi.
Diagrama 40. (Cont.).
dyj.
dyk.
dyl.
dym.
dyn.

224
dyo.
dyp.
dyq.
dyr.
dys.
dyt.
dyu.
dyv.

dyw.
dyx.
dyy.
dyz.
225
9.3 Matriz Procesos vs Eventos.

dza.
dzb. Esta matriz permite resumir parte de la informacin que reflejan los
diagramas de secuencia mostrados anteriormente, en esta oportunidad, se pretende
establecer la relacin directa entre eventos y procesos. El Cuadro 40, mostrado a
continuacin, presenta dicha relacin proceso-evento.
dzc.
dzd.
dze.
dzf.
226
dzg.
Cuadro 40. Matriz Procesos vs Eventos.
227
dzh.
228

10. Integracin de los Sub Modelos.
dzi.
dzj. Este apartado pretende mostrar la relacin que guardan todos los sub
modelos que han sido elaborados para el modelo de procesos referente a la unidad de
conmutacin. Este explica de forma clara y concisa cada uno de los productos que se
son solo el resultado de anlisis y estudios a los procesos de instalaciones, retiros y
reparacin de averas, los cuales son clave para el funcionamiento de este
departamento.
dzk.
dzl. Esta integracin representa, desde un punto de vista general, todo lo que
constituye el modelado de negocio como objetivo fundamental de esta etapa. De igual
manera se busca dejar claro los vnculos entre estos sub modelos, que no son ms que
conexiones que surgen de la estrecha relacin que guardan los procesos entre s. Es
por esto que a travs de los diferentes sub modelos, se hace posible detallar el
funcionamiento de la unidad de conmutacin en todos sus aspectos operacionales.
dzm.
dzn.A continuacin se muestra la Figura 20, que refleja la integracin
de los sub modelos, resumiendo diversos aspectos o elementos del sistema de
negocio como lo son sus: objetivos, procesos de negocio organizacionales,
objetos, reglas, actores y eventos.
dzo.
dzp.
dzq.
dzr.
dzs.
dzt.
229
dzu.

dzv.
dzw.
dzx.
dzy.
dzz.
eaa.
eab.
eac.
ead.
eae.
eaf.
eag.
Figura 20. Integracin de los Sub Modelos.
230
5.3 ETAPA III: INGENIERA DE REQUISITOS

eah.
eai. La ingeniera de requisitos es el proceso que constituye la ltima etapa del
presente proyecto. sta fase es desarrollada necesariamente una vez que el modelado
del negocio ha sido concluido, debido a que este ltimo es el que aporta al equipo de
trabajo los conocimientos concernientes a la situacin actual que presenta la
organizacin en relacin al problema y cualquier otras irregularidades que pudiesen
estar afectando su funcionamiento y productividad.
eaj.
eak. En esta etapa final fueron determinados, y a su vez documentados, una
serie de requisitos funcionales y no funcionales que los actores del sistema de
negocios tienen con respecto a la aplicacin que se desea desarrollar para ser
incorporada en alguno de los procesos empresariales. Este conjunto de requisitos
expresan lo que la aplicacin de software debe realizar a fin de satisfacer las
necesidades de los usuarios, teniendo claro que stos solo reflejan lo que debe hacer
la aplicacin y no la manera cmo hacerlo.
eal.
eam. Jons Montilva C. y Judith Barrios A. (2007) establecen que los requisitos
definen:
ean.
Lo que la aplicacin debe hacer: Las funciones que debe ejecutar, los datos que
debe capturar y almacenar y la informacin que debe producir.
La interaccin entre los usuarios y la aplicacin: La interfaz grfica usuariosistema.
Las restricciones bajo las cuales la aplicacin debe operar: La plataforma de
operacin de la aplicacin (Hardware/Software), la tecnologa de informacin
que debe usar y las interfaces con otros sistemas o aplicaciones.
231
Los atributos de calidad que la aplicacin debe satisfacer: seguridad, facilidad

de uso, documentacin, utilidad, etc.
eao.
eap. Debido a que en esta tercera y ltima etapa se trabaja en funcin a los
requisitos, es necesario resaltar que estos se dividen en dos tipos: requisitos
funcionales y requisitos no funcionales. Los requisitos funcionales, tal y como lo
indica su nombre, determinan la funcionalidad de la aplicacin, es decir, su
comportamiento, interaccin con los usuarios y sus respuestas ante diferentes
eventos, y los requisitos no funcionales, por otra parte, reflejan las limitaciones que se
le impondrn al diseo de la aplicacin, tales como, el ambiente de desarrollo, los
recursos que se disponen para el desarrollo, la plataforma bajo la cual operara la
aplicacin y los atributos que el software deber satisfacer, esto es, utilidad,
confiabilidad, documentacin, rendimiento, seguridad, entre otros.
eaq.
ear. Los documentos que se generan en esta etapa son los siguientes:
eas.
a) Documento definicin de requisitos.
b) Documento especificacin de requisitos.
eat.
eau.
eav.
eaw.
eax.
eay.
eaz.
eba.
ebb.
232
ebc.

ebd. Ingeniera de requisitos aplicado a los procesos de instalacin y reparacin de

ebe. DOCUMENTO DE DEFINICIN DE REQUISITOS
ebf. Versin <1.0>
ebg. Autor
ebh. Fech ebi. Ve
ebj. Descripcin
a
ebk. Oscar J.
ebl. 04/0
rsin
ebm. 0.8 ebn. Versin preliminar propuesta.
Ruiz
ebo. Oscar J.
1/2012
ebp. 01/0
9
ebq. 0.9 ebr. Primera correccin.
Ruiz
ebs. Oscar J.
2/2012
ebt. 06/0
4
ebu. 1.0 ebv. Versin final del producto.
Ruiz
ebw.
3/2012
1. Introduccin.
ebx.
eby. La definicin de requisitos es un documento que se genera una vez que el
sistema bajo estudio ha sido entendido en su totalidad, es por ello que el modelado de
negocio le antecede casi de forma obligatoria. Sin embargo, una vez concluido todo el
proceso de modelado, ya se posee un nivel de comprensin suficiente, tanto del
problema como del sistema de negocio donde se har operativa la aplicacin, por lo
tanto es posible identificar los requisitos fundamentales que deber contener la misma
para brindar soporte a alguno de los procesos de la organizacin.
ebz.
eca. En este sentido, se llevar a cabo una identificacin de las necesidades
que debern ser atendidas por la aplicacin a nivel funcional, por tal razn, este
documento describe cada uno de los requisitos que se identifican, analizan,
especifican y validan durante las actividades de descubrimiento, anlisis,
especificacin, validacin y gestin de requisitos.
233
ecb.

2. Subprocesos del proceso ingeniera de requisitos.

ecc.
ecd. La ingeniera de requisitos requiere de la ejecucin de una serie de
subprocesos que complementan la definicin y especificacin de requisitos de una
aplicacin empresarial. La Figura 21 refleja los subprocesos fundamentales que
constituyen la ingeniera de requisitos.
ece.
ecf.
ecg.
Ingeniera de
Requisitos
ech.
eci.
ecj.
eck.
ecl.
ecm.
ecn.
eco.
Descubrimiento
de
Requisitos
Anlisis
de
Requisitos
Especificacin
de
Requisitos
Gestin de Requisitos
ecp.
Figura 21. Subprocesos del proceso Ingeniera de Requisitos.
3. Descubrimiento de requisitos.
ecq.
ecr. Este proceso tiene por objetivo determinar las primeras funcionalidades
que la aplicacin deber contener, para ello se deben recolectar las necesidades que
los usuarios e interesados tienen con respecto al software empresarial, teniendo en
cuenta que el descubrimiento de los requisitos se relaciona de forma directa con el
dominio de la aplicacin, la identificacin de los usuarios que harn uso de sta y los
problemas que se espera que la aplicacin pueda solventar.
234
ecs.

ect.
ecu.
Modelado del Negocio
ecv.
Documento Inicio del Proyecto
Descubrimiento
de
Requisitos
ecw.
ecx.
ecy.
Dominio
Objetivos
Procesos
Reglas
Actores
Problemas
Lista preliminar de requisitos funcionales
ecz.
eda.
Diagrama 41. Diagrama de Procesos del Descubrimiento de

Requisitos.
edb.
edc. El diagrama anterior presenta el modelado del negocio y el documento
inicio del proyecto como insumos necesarios para el descubrimiento de los requisitos
de la aplicacin, teniendo como principales productos el dominio de jerarqua de
sistemas, los objetivos del negocio, los procesos, las reglas, as como tambin los
actores que forman parte de estos procesos.
edd.
3.1 Jerarqua de procesos del Descubrimiento de Requisitos.
ede.
edf.
edg.
Descubrimiento
de
Requisitos
Anlisis
de
Requisitos
Especificacin
de
Requisitos
edh.
edi.
edj.
edk.
EstablecimientoEntendimiento
edl.
edm.
de
Objetivos
del
Dominio
Organizacin Recoleccin
del
de
Conocimiento Requisitos
235
edn.
Figura 22. Jerarqua de Procesos del Descubrimiento de

Requisitos.
edo.
3.2 Requerimientos de Salida de la Aplicacin.

edp.
edq. La aplicacin que se plantea para ser incorporada a los procesos de
instalacin y reparacin de averas deber cumplir con una serie de objetivos. En este
sentido, sern enumerados una serie de objetivos que debern ser atendidos por la
aplicacin empresarial, estos son:
a) Proporcionar una herramienta capaz de presentar informacin alojada en los
servidores de base de datos de forma remota, eficaz y eficiente, a fin de agilizar
y dar soporte a los procesos de instalacin y reparacin de averas, realizados
por planta externa para la unidad de conmutacin (CX) de la central digital
Maturn-centro, C.A.N.T.V. estado Monagas.
b) Garantizar la seguridad, fiabilidad, transparencia y respaldo de los datos
manejados a travs de la herramienta de software propuesta, entendiendo la
confidencialidad de la informacin.
c) Minimizar la dependencia interdepartamental entre planta externa y
conmutacin.
d) Consultar de forma remota y en tiempo real la informacin tcnica asociada a
los abonados, es decir, par central, puertos aba, par local, terminal y dems
datos relacionados a los suscriptores del servicio, esto es, nombre del cliente,
apellidos, cedula de identidad, numero de contacto y direccin.
e) Actualizar la informacin tcnica de los abonados.
f) Registrar usuarios para permitir el acceso al men de opciones ofrecido por la
aplicacin.
236
g) Consultar registros de ingreso a la aplicacin.

edr.

3.3 Requerimientos de Almacenamiento de Datos.

eds.
edt. El sistema empresarial propuesto deber contar un una base de datos que
permita almacenar la informacin que ser consultada por los usuarios. Sin embargo,
se hace oportuno destacar que la herramienta de software deber ser conectada a los
servidores de base de datos de la empresa telefnica C.AN.T.V., de modo que una vez
que sean integrados los mdulos, sea posible la consulta y modificacin de los datos.
Todo esto, a fin de mantener el resguardo de la informacin y evitar la duplicidad de
los datos mediante la construccin de un nuevo servidor de base de datos exclusivo
para la aplicacin empresarial. A pesar de ello el sistema contar con una base de
datos para almacenar registros e historias de consultas de usuarios.
edu.
3.4 Requerimiento de Apoyo al Usuario.
edv.
edw. Sin duda alguna, la incorporacin de una herramienta tecnolgica al
proceso de instalacin y reparacin de averas, requerir de la capacitacin de los
usuarios finales y de manuales de informacin que sirvan de apoyo para los usuarios
en caso de ser necesarios.
edx.
3.5 Requerimientos de Flexibilidad.
edy.
edz. La aplicacin empresarial deber ser capaz de adaptarse a diversos
equipos de hardware y a diferentes sistemas operativos, por tal razn, sta ser
desarrollada bajo un ambiente web, lo que garantiza la su flexibilidad ante cualquier
sistema operativo.
237
eea.
238
eeb.

3.6 Reglas del Negocio.

eec.
eed.
eee.
eef.
Cuadro 41. Reglas de Negocio.

eeg.
eeh.
eei.
Descri
eej.
Re
pcin
eek.
eel.
eem.
Ten
een.
ees.
eex.
acceso a
eeo.
eet.
eey.
eep.
eeu.
eez.
eeq.
eev.
efa.
eer.
eew.
efb.
drn
la
aplicaci
n
empresa
rial
nicame
nte
los
emplead
os
adscrito
s
al
departa
mento
de
planta
externa
que
posean
usuario
y clave
239
para
acceder
al men
del
efc.
efd.
sistema.
efe. Slo
eff.
efk.
efp.
efg.
efl.
efq.
efh.
efm.
efr.
efi.
efn.
efs.
efj.
efo.
eft.
podrn
actualiz
ar
informa
cin
tcnica
de
los
abonado
s
los
emplead
os
con
perfil de
usuario
administ
rador y
solo ser
har en
casos
estricta
mente
requerid
efu.
efv.
os.
efw.
El
uso
efx.
ega.
egd.
efy.
egb.
ege.
de
la
aplicaci
240
efz.
empresa
egc.
M
egf.
-
rial
estar
sujeto al
horario
de
trabajo
que rige
las
cuadrill
as
de
trabajo
de
egg.
egi.
egj.

egh.
Cuadro 41. (Cont.).
egk.
egl.
egm.
Descri
egn.
Re
pcin
ego.
egp.
egq.
Pla
egr.
egs.
egt.
ehb.
ehg.
ehl.
ehc.
ehh.
ehm.
nta
externa
de
la
compa
a
C.A.N.T
.V
egu.
egx.
egv.
El
sistema
egy.
egw.
eha.
deber
ser
241
egz.
usado
ehd.
ehi.
ehn.
Del
nica y
ehe.
ehj.
eho.
para los
ehf.
ehk.
ehp.
proceso
exclusiv
amente
de
instalaci
n
reparaci
n
de
averas,
realizad
o
por
planta
externa.
ehq.
3.7 Actores del Sistema.
ehr.
ehs. En este apartado sern descritos cada uno de los actores, que de alguna u
otra manera, se ven involucrados con la aplicacin empresarial, interactuando con ella
o siendo responsables del uso adecuado de la misma, constituyendo una de las
principales fuentes para la recoleccin de requisitos, debido a que son ellos quienes se
encuentran inmersos en el ambiente de trabajo donde yace el problema o la
necesidad.
eht.
ehu. Son clasificados en dos tipos, los actores directos, que son aquellos que
forman parte del sistema de negocio, y los actores indirectos, que, aunque no forman
ehv.

242
ehw.
parte del sistema de negocio, interactan con el sistema para
satisfacer. Los actores del sistema sern identificados como lo muestra

el siguiente cuadro:
ehx.
ehz.
eib.
ehy.
Actor/001
eic.
Cuadro 42. Actores del Sistema.

eia.Descripcin
eig.Tcnico Instalador. (Planta Externa).
eii. Este actor es el responsable de llevar a
cabo las rdenes de trabajo en materia
eid.
de instalacin en zonas forneas a la
eie.
eif. Instalador
eij.
eik.
empresa.
eio.Tcnico
Averas
Telefnicas. (Planta Externa).

eiq.Este actor representa el encargado de
eil.
desempear el rol de reparador de
eim.
ein.
Reparador
averas relacionadas con seal de voz.
Reparador
Voz
eis.
eir.
eit. Tcnico
en
Telecomunicaciones.
(Planta Interna).
eiv.Es el encargado de evaluar, supervisar
y validar cada uno de los procesos
Tcnico en Telecomunicaciones
realizados dentro de las instalaciones

de conmutacin.
eiw.
eix.
eiy.
eiz.
eja.
ejb.
ejc.
243
ejd.Compaa Annima Nacional Telfonos de Venezuela

3.8 Usuarios del Sistema.
eje. Son considerados usuarios del sistema a cada uno de los actores, que
desempeando funciones dentro de los procesos, requieren del uso de la aplicacin
empresarial para acceder a los servicios que esta ofrece. En otras palabras, los
usuarios del sistema son un conjunto de actores que interactan de forma directa con
la aplicacin de software. En este sentido, existen diferentes tipos de usuarios que
pueden clasificarse en base a sus funciones o responsabilidades a nivel laboral. Esta
premisa sustenta la idea de que no todos los usuarios debern tener acceso a las
mismas funcionalidades que ofrece la aplicacin, generndose una especie de orden
jerrquico dentro del manejo del software. En base a lo anterior, los actores o usuarios
finales que tendrn acceso al sistema sern clasificados de la siguiente manera:
ejf.
ejg. Usuario Administrador: este el usuario con mayor jerarqua dentro del
nivel de acceso a las opciones ofrecidas por la aplicacin empresarial, bsicamente
posee dominio total sobre el sistema, teniendo acceso a todas las funcionalidades de
la aplicacin, y a los recursos manejados por esta en materia de datos e informacin.
De igual manera, se encargarn de administrar y controlar a otros usuarios de perfil
ms bajo en el orden jerrquico. As mismo, sern los nicos con permisos para
realizar actualizaciones de datos tcnicos a los abonados nicamente cuando sea
necesario.
ejh.
eji. Usuario Estndar: los usuarios que posean este perfil tienen privilegios
para acceder el men de opciones referente a los procesos de instalacin y reparacin
de averas, es decir, consulta informacin tcnica de los abonados: par central, par
local, terminal, y dems datos asociados a los suscriptores del servicio, como nombre
del cliente, apellidos, cedula de identidad, numero de contacto y direccin.
ejj. Compaa Annima Nacional Telfonos de Venezuela
244
ejk.Cuadro 43. Tipo de Usuarios del Sistema.

ejl. Tipo de Usuario
ejm. Actor
ejn. Usuario Estndar.
ejo. Tcnico Instalador.
ejp. Usuario Estndar.
ejq. Tcnico Reparador
Usuario
Averas Telefnicas.
ejs. Tcnico en
Administrador.
Telecomunicaciones.
ejr.
ejt.
3.9 Recoleccin de Requerimientos Iniciales.

eju.
ejw.
ejv.Cuadro 44. Recoleccin de Requerimientos Iniciales.

ejx.
ejy.
ejz.
eka.
Descri
Actor
Pr
Re
ekf.
ekg.
ekb.
pci
n
del
Re
que
rim
ient
o
ekc.
ekd.
eke.
Cargar
Ofi
rd
ene
s de
trab
ajo
soli
citu
des
ekh.
245
de
inst
alac
ion
es
al
sist
ema
TA
eki.
S.
ekj.Gen
erar
ekk.
ekl.
ekm.
Ofi
ekn.
I
Tic
kets
de
Inst
alac
ion
es
Co
mer
cial
eko.
es.
ekp.
ekq.
Haber
Ju
co
mpl
ekr.
etad
o la
eks.
ekt.
eku.
ekv.
246
ekw.
ekx.
eky.

ekz.
ela.
elb.
Cuadro 44. (Cont.).

elc.
eld.
escr
Pro
ipci
del
Req
ele.
elf.
ueri
mie
nto
e
N
e
g
o
c
i
o
elg.
elh.prim
eli.
elj.
elk.
elo.
ell.
elp.
elm.
elq.
eln.
elr.
era
etap
a de
la
orde
n de
247
trab
ajo
elw.
elz.
de
insta
laci
n
com
ercia
l en
con
mut
aci
els.
n.
elt. Veri
elu.
ficar
elv.
que
elx.
el
clien
ely.
te
sea
de
ema.
E
emb.
/
tipo
com
ercia
emc.
l.
emd.
ener
ar
Tick
eme.
emf.
emg.
Of
P
F
emh.
-
emi.
248
ets
de
Insta
lacio
nes
Resi
denc
iales
emj.
.
emk.
aber
eml.
emn.
pleta
emm.
do la
era
etap
a de
la
orde
n de
trab
ajo
de
insta
laci
n
Resi
denc
ems.
emp.
emt.
emq.
emu.
emr.
emv.
Ju
com
prim
emo.
P
F
1
.
3
249
ial
en
con
mut
aci
n
(CX
).
emw.

emx.
emy.
emz.
Cuadro 44. (Cont.).

ena.
enb.
escr
Pro
ipci
del
Req
enc.
end.
ueri
mie
nto
e
N
e
g
o
c
i
ene.
enf.
erifi
eng.
T
o
enh.
eni.
enl.
250
car
enj.
enm.
enn.
que
el
enk.
clien
te
sea
de
tipo
E
eno.
/
resid
enci
enp.
al.
enq.
G
ener
enr.
ens.
ent.
env.
Of
P
ar
Tick
enu.
-
ets
de
Insta
lacio
nes
Voz
y
Dato
enw.
s.
enx.
aber
eny.
eoa.
eob.
Ju
com
eoc.
pleta
enz.
do la
eod.
eof.
251
prim
era
eoe.
etap
a de
la
orde
n de
trab
ajo
de
insta
laci
n
Voz
y
Dato
s en
con
mut
aci
n
(CX
eog.
).
eoh.
ener
eoi.
Of
eoj.
eok.
ar
eol.
Tick
ets
de
eom.
252
Rein
stala
cin
del
Serv
icio.
eon.
eoo.
eop.

eoq.
eor.
eos.
Cuadro 44. (Cont.).

eot.
eou.
escr
Pro
ipci
del
Req
eov.
eow.
ueri
mie
nto
e
N
e
g
o
c
i
eox.
eoy.
aber
eoz.
Ju
o
epb.
epc.
epg.
253
com
epd.
pleta
epa.
do la
epe.
prim
era
epf.
etap
a de
la
orde
n de
trab
ajo
de
Rein
stala
cin
del
Serv
icio
en
con
mut
aci
n
(CX
eph.
).
epi.Carg
epj.
ar
Of
rde
epk.
epl.
epm.
epo.
254
nes
de
epn.
trab
ajo
Rep
orte
de
Aver
as
Tele
fni
cas
al
siste
ma
TAS
epp.
.
epq.
ener
ar
Tick
ets
de
Rep
orte
de
Aver
as
Tele
epr.
eps.
ept.
Of
P
F
1
.
6
epu.
-
epv.
255
fni
cas.
epw.
epx.
epy.
epz.
eqa.
eqb.

3.10 Planillas Volere.

eqc.
eqd.
eqe.
Identifica
Cuadro 45. Planilla Volere.

eqf.
Tipo
eqg.
dor del
de
Caso de
Uso/Evento
requisito
requisito
eqh. Descripcin
eqi.
Justificacin del requisito
eqj.Fuente (interesado que lo
eqk.
Unidad en la que se
propone)
eql.
Criterios de validacin
eqm. Grado de satisfaccin
Grado
de
insatisfaccin
del
del interesado
eqo.
(requisitos que dependen de
soporte
eqs.
Proyecto
equ.
5.4 Requisitos Funcionales.
eqn.
interesado
eqp.
Conflictos (requisitos
Dependencias
este)
eqq. Documentos
origina
de
que son incompatibles con

este)
eqr.
Histrico de cambios
eqt.
Analista
256
eqv.
eqw. Los requisitos funcionales son aquellos que denotan funcionalidades del
sistema, es decir, es una caracterstica requerida del sistema que expresa una
capacidad de accin del mismo capaz de ser expresada en una declaracin de forma
verbal. Por lo general, este tipo de requisitos van asociados de forma directa a al
comportamiento del sistema, su interaccin con los usuarios, su dominio de
aplicacin y sus respuesta ante diferentes eventos. A continuacin sern presentados,
a travs de planillas volere, el conjunto de requisitos funcionales que han sido
establecidos para la aplicacin empresarial una vez que esta se encuentre operativa
dentro del proceso de instalacin y reparacin de averas.
eqx.

eqy.
Cuadro 46. Requisito Funcional N 1.
eqz. Identificador del

erb. Tipo de
erc. Caso de
requisito:
requisito:
Uso/Evento:
era. 001-RF
Funcional
erd. Descripcin: El sistema debe permitir que el usuario ingrese su usuario y contrasea para
ser validado su acceso.
ere. Justificacin del requisito: Este requisito es fundamental para que el acceso a la
aplicacin quede totalmente restringido a usuarios ajenos al sistema, permitiendo el acceso
solo a usuarios registrados.
erf. Fuente : Yhuanailys Nez
erg. Unidad en la que se origina:
Centro de Computacin de la
UDO.
erh. Criterios de validacin: Revisiones peridicas al sistema permitirn determinar y evaluar
si efectivamente la aplicacin impide el acceso a usuarios no registrados.
eri. Grado de satisfaccin del
erj. Grado de insatisfaccin del
interesado: 5
interesado: 1
erk. Dependencias: 2, 8, 10, 11, 30, 31,
erl. Conflictos: No presenta
33, 34, 36.
erm.Documentos de soporte: No
ern. Histrico de cambios: 09/01/2012
Definido
ero. Proyecto: Sistema empresarial
erp. Analista:
para la gestin de informacin en
Oscar Josu Ruiz
los procesos de instalacin y
reparacin de averas.
erq.
err. Cuadro 47. Requisito Funcional N 2.
ers. Identificador del
requisito:
eru. Tipo de
requisito:
erv. Caso de
Uso/Evento:
257
ert. 002-RF
Funcional
erw. Descripcin: El usuario administrador tendr permisos para registrar nuevos usuarios.
erx. Justificacin del requisito: Restringe la creacin de nuevos usuarios solo al usuario
administrador.
ery. Fuente : Yhuanailys Nez
erz. Unidad en la que se origina:
UDO.
esa. Criterios de validacin: Revisiones peridicas al sistema permitirn determinar y evaluar
si efectivamente la aplicacin permite la creacin de nuevos usuarios solo al
administrador.
esb. Grado de satisfaccin del
esc. Grado de insatisfaccin del
interesado: 5
interesado: 1
esd. Dependencias: 1, 3, 4, 5, 8, 32, 34,
ese. Conflictos: No presenta
36, 37.
esf. Documentos de soporte: No
esg. Histrico de cambios: 09/01/2012
Definido
esh. Proyecto: Sistema empresarial
esi. Analista:
Oscar Josu Ruiz
esj. Cuadro 48. Requisito Funcional N 3.

esk. Identificador del
requisito:
esl. 003-RF
eso.
esp.
esq.
ess.
est.
esv.
esx.
esz.
esm.
Tipo
esn. Caso de
de
Uso/Evento:
requisito:
Funcional
Descripcin: El usuario administrador tendr permisos para modificar datos de cualquier
usuario.
Justificacin del requisito: Restringe la modificacin de usuarios solo al administrador.
Fuente : Yhuanailys Nez
esr. Unidad en la que se origina:
UDO.
Criterios de validacin: Se revisar peridicamente que el sistema cumpla con este
requisito.
Grado de satisfaccin del
esu. Grado de insatisfaccin del
interesado: 5
interesado: 1
Dependencias: 2, 8, 32, 34.
esw. Conflictos: No presenta
Documentos de soporte: No
esy. Histrico de cambios: 09/01/2012
Definido
Proyecto: Sistema empresarial
eta. Analista:
Oscar Josu Ruiz
etb.Compaa Annima Nacional Telfonos de Venezuela

etc.Cuadro 49. Requisito Funcional N 4.
etd. Identificador del
requisito:
etf. Tipo de
requisito:
etg. Caso de
Uso/Evento:
258
ete. 004-RF
Funcional
eth. Descripcin: El usuario administrador tendr permisos para eliminar o inhabilitar
cualquier usuario estndar.
eti. Justificacin del requisito: Restringe la eliminacin e inhabilitacin de cualquier usuario
solo al administrador.
etj. Fuente : Yhuanailys Nez
etk. Unidad en la que se origina:
UDO.
etl. Criterios de validacin: Revisiones peridicas al sistema permitirn determinar y evaluar
si efectivamente la aplicacin permite tal funcin al usuario administrador.
etm. Grado de satisfaccin del
etn. Grado de insatisfaccin del
interesado: 5
interesado: 1
eto. Dependencias: 2, 8, 34.
etp. Conflictos: No presenta
etq. Documentos de soporte: No
etr. Histrico de cambios: 09/01/2012
Definido
ets. Proyecto: Sistema empresarial
ett. Analista:
Oscar Josu Ruiz
etu.Cuadro 50. Requisito Funcional N 5.

etv. Identificador del
etx. Tipo de
ety. Caso de
requisito:
requisito:
Uso/Evento:
etw. 005-RF
Funcional
etz. Descripcin: El usuario administrador podr acceder y modificar la lista de usuarios
registrados.
eua. Justificacin del requisito: Restringe la administracin de usuarios solo al administrador.
eub. Fuente : Yhuanailys Nez
euc. Unidad en la que se origina:
UDO.
eud. Criterios de validacin: Se evaluar el sistema peridicamente determinar y evaluar si
efectivamente la aplicacin permite la creacin de nuevos usuarios solo al administrador.
eue. Grado de satisfaccin del
euf. Grado de insatisfaccin del
interesado: 5
interesado: 1
eug. Dependencias: 1, 3, 4, 21, 36, 37.
euh. Conflictos: No presenta
eui. Documentos de soporte: No
euj. Histrico de cambios: 09/01/2012
Definido
euk. Proyecto: Sistema empresarial
eul. Analista:
Oscar Josu Ruiz
eum.
eun.Identificador del
eup.Tipo de
euq.Caso de
requisito:
requisito:
Uso/Evento:
euo. 006-RF
Funcional
eur. Descripcin: El usuario administrador tendr permisos para modificar informacin
tcnica de cualquier abonado.
eus. Justificacin del requisito: Restringe la modificacin de informacin tcnica asociada a
nmeros solo al usuario administrador.
259
eut. Fuente : Wendy Rondn
euu.Unidad en la que se origina:

Unidad de Conmutacin (CX).
euv. Criterios de validacin: Se revisar peridicamente que el sistema cumpla con este
requisito.
euw.Grado de satisfaccin del
eux. Grado de insatisfaccin del
interesado: 5
interesado: 1
euy. Dependencias: 1, 13, 15, 16, 23,
euz. Conflictos: No presenta
27, 34.
eva. Documentos de soporte: No
evb. Histrico de cambios: 09/01/2012
Definido
evc. Proyecto: Sistema empresarial
evd. Analista:
Oscar Josu Ruiz
eve.

evf.
evg. Identificador del

evi. Tipo de
evj. Caso de
requisito:
requisito:
Uso/Evento:
evh. 007-RF
Funcional
evk. Descripcin: El usuario administrador podr acceder a los registros de la aplicacin.
evl. Justificacin del requisito: Restringe la consulta de los registros solo al usuario
administrador.
evm.
evn. Unidad en la que se origina:
UDO.
evo. Criterios de validacin: Revisiones peridicas al sistema permitirn determinar y evaluar
si efectivamente la aplicacin permite tal funcin nicamente al usuario administrador.
evp. Grado de satisfaccin del
evq. Grado de insatisfaccin del
interesado: 5
interesado: 1
evr. Dependencias: 1, 8, 16, 19, 20, 22,
evs. Conflictos: No presenta
25, 26.
evt. Documentos de soporte: No
evu. Histrico de cambios: 09/01/2012
Definido
evv. Proyecto: Sistema empresarial
evw.Analista:
Oscar Josu Ruiz
evx.
evy. Identificador del
requisito:
evz. 008-RF

ewa.
Tipo
ewb.
Caso de
de
Uso/Evento:
requisito:
Funcional
ewc.Descripcin: El sistema regular y controlar el acceso al contenido ofrecido.
ewd.
Justificacin del requisito: Otorga permisos de acceso segn sea el perfil del
usuario.
ewe.Fuente : Yhuanailys Nez
ewf. Unidad en la que se origina:
260
UDO.
ewg.
Criterios de validacin: Se evaluar el sistema peridicamente para determinar y
evaluar si la aplicacin controla el nivel de acceso en base al rol del usuario.
ewh.
ewi. Grado de insatisfaccin del
interesado: 5
interesado: 1
ewj. Dependencias: 1, 2, 3, 4, 10, 11,
ewk.
Conflictos: No presenta
14.
ewl. Documentos de soporte: No
ewm.
Histrico
de
cambios:
Definido
09/01/2012
ewn.
Proyecto:
Sistema
ewo.
Analista:
empresarial para la gestin de
Oscar Josu Ruiz
informacin en los procesos de
instalacin y reparacin de averas.
ewp.
ewq.
Identificador
ews.Tipo de
ewt. Caso de
del requisito:
requisito:
Uso/Evento:
ewr.009-RF
Funcional
ewu.
Descripcin: El sistema permitir la consulta de informacin tcnica de los
abonados tanto a los usuarios estndar como al administrador.
ewv.Justificacin del requisito: Ofrece el acceso a la informacin requerida para dar
continuidad al proceso de instalacin y reparacin de averas.
eww.
Fuente : Wendy Rondn
ewx.
Unidad en la que se origina:
ewy.Criterios de validacin: Se revisar de forma peridica que el sistema cumpla con este
requisito.
ewz.Grado de satisfaccin del
exa. Grado de insatisfaccin del
interesado: 5
interesado: 1
exb. Dependencias: 1, 12, 13, 17, 18,
exc. Conflictos: No presenta
28, 29, 34.
exd. Documentos de soporte: No
exe. Histrico de cambios: 09/01/2012
Definido
exf. Proyecto: Sistema empresarial
exg. Analista:
Oscar Josu Ruiz
exh.

exi.Cuadro 55. Requisito Funcional N 10.

exj. Identificador del
exl. Tipo de
exm.
Caso de
requisito:
requisito:
Uso/Evento:
exk. 010-RF
Funcional
exn. Descripcin: Despus de haber transcurrido cierto tiempo estando el sistema inactivo se
cerrar de forma automtica.
exo. Justificacin del requisito: Resguardo y proteccin de la informacin.
exp. Fuente : Yhuanailys Nez
exq. Unidad en la que se origina:
261
UDO.
exr. Criterios de validacin: Revisiones peridicas al sistema permitirn determinar y evaluar
si efectivamente la aplicacin responde correctamente ante tal situacin.
exs. Grado de satisfaccin del
ext. Grado de insatisfaccin del
interesado: 5
interesado: 1
exu. Dependencias: No presenta
exv. Conflictos: No presenta
exw.Documentos de soporte: No
exx. Histrico de cambios: 09/01/2012
Definido
exy. Proyecto: Sistema empresarial
exz. Analista:
Oscar Josu Ruiz
eya.
eyb. Identificador del

eyd. Tipo de
eye. Caso de
requisito:
requisito:
Uso/Evento:
eyc. 011-RF
Funcional
eyf. Descripcin: Los usuarios podrn salir del sistema en cualquier momento con solo cerrar
su sesin.
eyg. Justificacin del requisito: Resguardo de la integridad de la informacin y del software.
eyh. Fuente : Yhuanailys Nez
eyi. Unidad en la que se origina:
UDO.
eyj. Criterios de validacin: Peridicamente se evaluar el sistema para validar esta funcin.
eyk. Grado de satisfaccin del
eyl. Grado de insatisfaccin del
interesado: 5
interesado: 1
eym.
Dependencias: No presenta
eyn. Conflictos: No presenta
eyo. Documentos de soporte: No
eyp. Histrico de cambios: 09/01/2012
Definido
eyq. Proyecto: Sistema empresarial
eyr. Analista:
Oscar Josu Ruiz
eys.
eyt. Identificador del

eyv. Tipo de
eyw.Caso de
requisito:
requisito:
Uso/Evento:
eyu. 012-RF
Funcional
eyx. Descripcin: El sistema debe mostrar en la consulta de abonados, la siguiente
informacin tcnica: puertos aba, armario, par central, par local y terminal.
eyy. Justificacin del requisito: Brindar informacin requerida a los tcnicos.
eyz. Fuente : Wendy Rondn
eza. Unidad en la que se origina:
ezb. Criterios de validacin: Se revisar continuamente que el sistema cumpla con este
requisito.
ezc. Grado de satisfaccin del
ezd. Grado de insatisfaccin del
interesado: 5
interesado: 1
eze. Dependencias: 1, 8, 9, 17, 18, 28,
ezf. Conflictos: No presenta
29.
ezg. Documentos de soporte: No
ezh. Histrico de cambios: 09/01/2012
262
Definido
ezi. Proyecto: Sistema empresarial
ezj. Analista:
Oscar Josu Ruiz
ezk.
ezl. Compaa Annima Nacional Telfonos de Venezuela
ezm.
ezn. Identificador del

ezp. Tipo de
ezq. Caso de
requisito:
requisito:
Uso/Evento:
ezo. 013-RF
Funcional
ezr. Descripcin: La informacin modificada a travs de la aplicacin se deber actualizar de
forma automtica en la base de datos de origen, a fin de presentarse actualizada de ser
consultada a travs de otro sistema de la compaa.
ezs. Justificacin del requisito: Garantizar que la informacin se mantenga actualizada en los
servidores.
ezt. Fuente : Wendy Rondn
ezu. Unidad en la que se origina:
ezv. Criterios de validacin: Se revisar de forma peridica que el sistema cumpla con este
requisito.
ezw.Grado de satisfaccin del
ezx. Grado de insatisfaccin del
interesado: 5
interesado: 1
ezy. Dependencias: No presenta.
ezz. Conflictos: No presenta
faa. Documentos de soporte: No
fab. Histrico de cambios: 09/01/2012
Definido
fac. Proyecto: Sistema empresarial
fad. Analista:
Oscar Josu Ruiz
fae.Cuadro 59. Requisito Funcional N 14.

faf. Identificador del
fah. Tipo de
fai. Caso de
requisito:
requisito:
Uso/Evento:
fag. 014-RF
Funcional
faj. Descripcin: La aplicacin debe contar con un men principal con mdulos.
fak. Justificacin del requisito: Accesibilidad a las funcionalidades ofrecidas segn el perfil.
fal. Fuente : Yhuanailys Nez
fam.
UDO.
fan. Criterios de validacin: Constantemente se verificar que el sistema presente el men de
opciones.
fao. Grado de satisfaccin del
fap. Grado de insatisfaccin del
interesado: 5
interesado: 1
faq. Dependencias: No presenta.
far. Conflictos: No presenta
fas. Documentos de soporte: No
fat. Histrico de cambios: 09/01/2012
Definido
263
fau. Proyecto: Sistema empresarial

faw.
fav. Analista:
Oscar Josu Ruiz
fax. Identificador del

faz. Tipo de
fba. Caso de
requisito:
requisito:
Uso/Evento:
fay. 015-RF
Funcional
fbb. Descripcin: Al momento de actualizar datos tcnicos, el sistema debe validar si existe
algn abonado con la misma informacin tcnica.
fbc. Justificacin del requisito: Evitar duplicidad de la informacin.
fbd. Fuente : Wendy Rondn
fbe. Unidad en la que se origina:
fbf. Criterios de validacin: De forma peridica se verificara que el sistema cumple con esta
funcin.
fbg. Grado de satisfaccin del
fbh. Grado de insatisfaccin del
interesado: 5
interesado: 1
fbi. Dependencias: 1, 6, 8, 13, 34.
fbj. Conflictos: No presenta
fbk. Documentos de soporte: No
fbl. Histrico de cambios: 09/01/2012
Definido
fbm.Proyecto: Sistema empresarial
fbn. Analista:
Oscar Josu Ruiz
fbo.
fbp.

fbq.
fbr. Identificador del

fbt. Tipo de
fbu. Caso de
requisito:
requisito:
Uso/Evento:
fbs. 016-RF
Funcional
fbv. Descripcin: El sistema debe guardar registros de los ingresos de usuarios a la aplicacin,
consultas realizadas y modificacin de informacin tcnica de los abonados.
fbw. Justificacin del requisito: Controlar el acceso y los movimientos de los usuarios en la
aplicacin.
fbx. Fuente : Wendy Rondn
fby. Unidad en la que se origina:
fbz. Criterios de validacin: Se revisar de forma peridica que el sistema registre tal
informacin.
fca. Grado
de
satisfaccin
del
fcb. Grado de insatisfaccin del
interesado: 5
interesado: 1
fcc. Dependencias:1, 5, 6, 9, 13, 15, 18,
fcd. Conflictos: No presenta
23, 24, 28, 29.
fce. Documentos de soporte: No
fcf. Histrico
de
cambios:
Definido
09/01/2012
fcg. Proyecto: Sistema empresarial para
fch. Analista:
264
la gestin de informacin en los

procesos de instalacin y reparacin
de averas.
Oscar Josu Ruiz
fci. Cuadro 62. Requisito Funcional N 17.

fcj. Identificador del
fcl. Tipo de
fcm.Caso de
requisito:
requisito:
Uso/Evento:
fck. 017-RF
Funcional
fcn. Descripcin: El sistema deber sustraer informacin de la base de datos de la compaa
para ser suministrada a los usuarios cuando sta sea solicitada y en tiempo real.
fco. Justificacin del requisito: Usabilidad y resguardo de la informacin.
fcp. Fuente : Yhuanailys Nez
fcq. Unidad en la que se origina:
UDO.
fcr. Criterios de validacin: Se verificar que el sistema muestre la informacin correcta al
usuario.
fcs. Grado de satisfaccin del
fct. Grado de insatisfaccin del
interesado: 5
interesado: 1
fcu. Dependencias: No presenta.
fcv. Conflictos: No presenta
fcw. Documentos de soporte: No
fcx. Histrico de cambios: 09/01/2012
Definido
fcy. Proyecto: Sistema empresarial
fcz. Analista:
Oscar Josu Ruiz
fda.
fdb. Identificador del

fdd. Tipo de
fde. Caso de
requisito:
requisito:
Uso/Evento:
fdc. 018-RF
Funcional
fdf. Descripcin: Para la consulta de abonados, el sistema debe permitir buscar datos tcnicos
a partir del abonado, armario, par central, par local, terminal o puertos aba en caso de que
posea.
fdg. Justificacin del requisito: Flexibilidad para la consulta de informacin.
fdh. Fuente : Wendy Rondn
fdi. Unidad en la que se origina:
fdj. Criterios de validacin: Se realizarn pruebas para validar esta funcin dentro de la
aplicacin.
fdk. Grado de satisfaccin del
fdl. Grado de insatisfaccin del
interesado: 5
interesado: 1
fdm.Dependencias: 1, 9, 12.
fdn. Conflictos: No presenta
fdo. Documentos de soporte: No
fdp. Histrico de cambios: 09/01/2012
Definido
fdq. Proyecto: Sistema empresarial
fdr. Analista:
Oscar Josu Ruiz
fds.
265
fdt. Compaa Annima Nacional Telfonos de Venezuela

fdu.
fdv. Identificador del

fdx. Tipo de
fdy. Caso de
requisito:
requisito:
Uso/Evento:
fdw.019-RF
Funcional
fdz. Descripcin: El sistema debe mostrar todos los registros y consultas realizadas para cada
abonado.
fea. Justificacin del requisito: Almacenar los movimientos y consultas para cada abonado.
feb. Fuente : Yhuanailys Nez
fec. Unidad en la que se origina:
UDO.
fed. Criterios de validacin: De forma peridica se verificara que el sistema cumple con esta
funcin.
fee. Grado de satisfaccin del
fef. Grado de insatisfaccin del
interesado: 5
interesado: 1
feg. Dependencias: 1, 7, 16.
feh. Conflictos: No presenta
fei. Documentos de soporte: No
fej. Histrico de cambios: 09/01/2012
Definido
fek. Proyecto: Sistema empresarial
fel. Analista:
Oscar Josu Ruiz
fem.
fen. Identificador del
fep. Tipo de
feq. Caso de
requisito:
requisito:
Uso/Evento:
feo. 020-RF
Funcional
fer. Descripcin: El sistema tiene que tener la opcin de bsqueda de cualquier registro de
algn abonado en especfico.
fes. Justificacin del requisito: Flexibilidad para la consulta de informacin.
fet. Fuente : Wendy Rondn
feu. Unidad en la que se origina:
fev. Criterios de validacin: Se realizarn pruebas para validar esta funcin dentro de la
aplicacin.
few. Grado de satisfaccin del
fex. Grado de insatisfaccin del
interesado: 5
interesado: 1
fey. Dependencias: 1, 7, 16, 19.
fez. Conflictos: No presenta
ffa. Documentos de soporte: No
ffb. Histrico de cambios: 09/01/2012
Definido
ffc. Proyecto: Sistema empresarial
ffd. Analista:
Oscar Josu Ruiz
ffe.
fff.
266
ffg.
ffh.
ffi.
ffj.
ffk.
ffl.
ffm.
ffn.Compaa Annima Nacional Telfonos de Venezuela
ffo.Cuadro 66. Requisito Funcional N 21.
ffp. Identificador del
ffr. Tipo de
ffs. Caso de
requisito:
requisito:
Uso/Evento:
ffq. 021-RF
Funcional
fft. Descripcin: El sistema deber mostrar una lista de todos los usuarios registrados.
ffu. Justificacin del requisito: Facilitar la administracin de usuarios.
ffv. Fuente : Wendy Rondn
ffw. Unidad en la que se origina:
ffx. Criterios de validacin: Se evaluar el sistema peridicamente para determinar y evaluar
si la aplicacin muestra la lista de usuarios.
ffy. Grado de satisfaccin del
ffz. Grado de insatisfaccin del
interesado: 5
interesado: 1
fga. Dependencias: 1, 2, 5.
fgb. Conflictos: No presenta
fgc. Documentos de soporte: No
fgd. Histrico de cambios: 09/01/2012
Definido
fge. Proyecto: Sistema empresarial
fgf. Analista:
Oscar Josu Ruiz
fgh.
fgg.
fgi. Identificador del

fgk. Tipo de
fgl. Caso de
requisito:
requisito:
Uso/Evento:
fgj. 022-RF
Funcional
fgm.Descripcin: El sistema debe permitir la impresin de cualquier consulta de abonados,
lista de usuario, informacin de usuarios o de cualquier registro.
fgn. Justificacin del requisito: Generar reportes fsicos.
fgo. Fuente : Yhuanailys Nez
fgp. Unidad en la que se origina:
UDO.
fgq. Criterios de validacin: Debern realizarse pruebas para verificar que el sistema valide la
impresin.
fgr. Grado de satisfaccin del
fgs. Grado de insatisfaccin del
267
interesado: 5
fgt. Dependencias: 1, 2, 3, 5, 9, 16, 36.
fgv. Documentos de soporte: No
Definido
fgx. Proyecto: Sistema empresarial
interesado: 1
fgu. Conflictos: No presenta
fgw. Histrico de cambios: 09/01/2012
fgy. Analista:
Oscar Josu Ruiz
fgz.
fha. Identificador del
fhc. Tipo de
fhd. Caso de
requisito:
requisito:
Uso/Evento:
fhb. 023-RF
Funcional
fhe. Descripcin: El sistema debe permitir modificar informacin tcnica de abonados que
han sido modificados o ingresados al sistema previamente.
fhf. Justificacin del requisito: Permite la modificacin de datos.
fhg. Fuente : Wendy Rondn
fhh. Unidad en la que se origina:
fhi. Criterios de validacin: Se realizarn pruebas para validar esta funcin dentro de la
aplicacin.
fhj. Grado de satisfaccin del
fhk. Grado de insatisfaccin del
interesado: 5
interesado: 1
fhl. Dependencias: 6.
fhm.Conflictos: No presenta
fhn. Documentos de soporte: No
fho. Histrico de cambios: 09/01/2012
Definido
fhp. Proyecto: Sistema empresarial
fhq. Analista:
Oscar Josu Ruiz
fhr.Compaa Annima Nacional Telfonos de Venezuela

fhs.Cuadro 69. Requisito Funcional N 24.
fht. Identificador del
fhv. Tipo de
fhw.Caso de
requisito:
requisito:
Uso/Evento:
fhu. 024-RF
Funcional
fhx. Descripcin: El sistema debe permitir listar todos los abonados en caso de ser solicitado
por el usuario.
fhy. Justificacin del requisito: Generar un listado de todos los abonados.
fhz. Fuente : Wendy Rondn
fia. Unidad en la que se origina:
fib. Criterios de validacin: Se evaluar el sistema peridicamente para determinar y evaluar
si la aplicacin muestra la lista de todos los abonados.
fic. Grado de satisfaccin del
fid. Grado de insatisfaccin del
interesado: 5
interesado: 1
fie. Dependencias: 9, 18, 20, 28.
fif. Conflictos: No presenta
fig. Documentos de soporte: No
fih. Histrico de cambios: 09/01/2012
Definido
268
fii. Proyecto: Sistema empresarial

fij. Analista:
Oscar Josu Ruiz
fik.
fil. Cuadro 70. Requisito Funcional N 25.
fim. Identificador del
fio. Tipo de
fip. Caso de
requisito:
requisito:
Uso/Evento:
fin. 025-RF
Funcional
fiq. Descripcin: El sistema debe impedir que cualquier registro de consulta o actualizacin
sea eliminada.
fir. Justificacin del requisito: Evitar que los registros sean borrados.
fis. Fuente : Yhuanailys Nez
fit. Unidad en la que se origina:
UDO.
fiu. Criterios de validacin: Debern realizarse pruebas para verificar que el sistema en
efecto impide que los registros sean eliminados.
fiv. Grado de satisfaccin del
fiw. Grado de insatisfaccin del
interesado: 5
interesado: 1
fix. Dependencias: No presenta.
fiy. Conflictos: No presenta
fiz. Documentos de soporte: No
fja. Histrico de cambios: 09/01/2012
Definido
fjb. Proyecto: Sistema empresarial
fjc. Analista:
Oscar Josu Ruiz
fjd.
fje. Identificador del
fjg. Tipo de
fjh. Caso de
requisito:
requisito:
Uso/Evento:
fjf. 026-RF
Funcional
fji. Descripcin: El sistema debe permitir listar los registros en base a usuarios, abonados
o fecha.
fjj. Justificacin del requisito: Flexibilidad para la consulta de informacin.
fjk. Fuente : Wendy Rondn
fjl. Unidad en la que se origina:

fjm. Criterios de validacin: Se realizarn pruebas para validar esta funcin dentro de la
aplicacin.
fjn. Grado de satisfaccin del
fjo. Grado de insatisfaccin del
interesado: 5
interesado: 1
fjp. Dependencias: 16, 20, 25.
fjq. Conflictos: No presenta
fjr. Documentos de soporte: No
fjs. Histrico
de
cambios:
Definido
09/01/2012
fjt. Proyecto: Sistema empresarial
fju. Analista:
Oscar Josu Ruiz
269
fjv.
fjw.Compaa Annima Nacional Telfonos de Venezuela
fjx. Cuadro 72. Requisito Funcional N 27.
fjy. Identificador del
fka. Tipo de
fkb. Caso de
requisito:
requisito:
Uso/Evento:
fjz. 027-RF
Funcional
fkc. Descripcin: Al guardar los datos de un abonado, el sistema validara y enviara un
mensaje de aviso, en tal caso que exista un abonado con la misma informacin.
fkd. Justificacin del requisito: Evitar duplicidad de la informacin.
fke. Fuente : Yhuanailys Nez
fkf. Unidad en la que se origina:
UDO.
fkg. Criterios de validacin: Se evaluar el sistema peridicamente para determinar y evaluar
si la aplicacin muestra la lista de todos los abonados.
fkh. Grado de satisfaccin del
fki. Grado de insatisfaccin del
interesado: 5
interesado: 1
fkj. Dependencias: 1, 6.
fkk. Conflictos: No presenta
fkl. Documentos de soporte: No
fkm.Histrico de cambios: 09/01/2012
Definido
fkn. Proyecto: Sistema empresarial
fko. Analista:
Oscar Josu Ruiz
fkp.
fkq. Identificador del

fks. Tipo de
fkt. Caso de
requisito:
requisito:
Uso/Evento:
fkr. 028-RF
Funcional
fku. Descripcin: En el submen de consultar abonado, el sistema tiene que tener la opcin de
bsqueda de cualquier abonado, si es general y no se selecciona ninguno de los campos
de filtrado y mostrara todos los abonados que existen.
fkv. Justificacin del requisito: Generar un listado de todos los abonados.
fkw. Fuente : Yhuanailys Nez
fkx. Unidad en la que se origina:
UDO.
fky. Criterios de validacin: Se verificar peridicamente que el sistema cumple esta
funcionalidad.
fkz. Grado de satisfaccin del
fla. Grado de insatisfaccin del
interesado: 5
interesado: 1
flb. Dependencias: 9, 12, 18.
flc. Conflictos: No presenta
fld. Documentos de soporte: No
fle. Histrico de cambios: 09/01/2012
Definido
flf. Proyecto: Sistema empresarial
flg. Analista:
Oscar Josu Ruiz
270
flh. Cuadro 74. Requisito Funcional N 29.

fli. Identificador del
flk. Tipo de
fll. Caso de
requisito:
requisito:
Uso/Evento:
flj. 029-RF
Funcional
flm. Descripcin: El sistema debe ser capaz de mostrar los abonados ubicados por armario si
as lo solicita el usuario.
fln. Justificacin del requisito: Facilitar la bsqueda de algn abonado por armario.
flo. Fuente : Wendy Rondn
flp. Unidad en la que se origina:
flq. Criterios de validacin: Se evaluar peridicamente que la aplicacin puede mostrar
todos los abonados de cualquier armario solicitado.
flr. Grado de satisfaccin del
fls. Grado de insatisfaccin del
interesado: 5
interesado: 1
flt. Dependencias: 9, 12, 18, 28.
flu. Conflictos: No presenta
flv. Documentos de soporte: No
flw. Histrico de cambios: 09/01/2012
Definido
flx. Proyecto: Sistema empresarial
fly. Analista:
Oscar Josu Ruiz
flz. Compaa Annima Nacional Telfonos de Venezuela

fma.
fmb.
Identificador
del requisito:
fmc.030-RF
Tipo
fme.Caso de
de
Uso/Evento:
requisito:
Funcional
fmf. Descripcin: Slo el administrador podr modificar las contraseas de usuarios.
fmg.Justificacin del requisito: Restringe la modificacin de contrasea solo al
administrador.
fmh.Fuente : Yhuanailys Nez
fmi. Unidad en la que se origina:
UDO.
fmj. Criterios de validacin: Mediante pruebas peridicas se verificar que el sistema brinde
al usuario la opcin de modificar su contrasea.
fmk.Grado de satisfaccin del
fml. Grado de insatisfaccin del
interesado: 5
interesado: 1
fmm.
Dependencias: 1.
fmn.Conflictos: No presenta
fmo.Documentos de soporte: No
fmp.Histrico de cambios: 09/01/2012
Definido
fmq.Proyecto: Sistema empresarial
fmr. Analista:
Oscar Josu Ruiz
fms.
fmt. Identificador del
requisito:
fmd.

fmv.Tipo de
requisito:
fmw.
Caso de
Uso/Evento:
271
fmu.
031-RF
Funcional
fmx.Descripcin: El sistema debe mostrar un mensaje de autenticacin fallida cada vez que el
usuario y contrasea sean invlidos.
fmy.Justificacin del requisito:
fmz.Fuente : Yhuanailys Nez
fna. Unidad en la que se origina:
UDO.
fnb. Criterios de validacin: Se verificar peridicamente que el sistema cumple esta
funcionalidad.
fnc. Grado de satisfaccin del
fnd. Grado de insatisfaccin del
interesado: 5
interesado: 1
fne. Dependencias: 1.
fnf. Conflictos: No presenta
fng. Documentos de soporte: No
fnh. Histrico de cambios: 09/01/2012
Definido
fni. Proyecto: Sistema empresarial
fnj. Analista:
Oscar Josu Ruiz
fnk.
fnl. Identificador del
fnn. Tipo de
fno. Caso de
requisito:
requisito:
Uso/Evento:
fnm.
032-RF
Funcional
fnp. Descripcin: El sistema debe validar que no se puede ingresar un nuevo registro de
usuario con el nombre de usuario, numero de carnet o cdula ya registrado en el mismo.
fnq. Justificacin del requisito:
fnr. Fuente : Yhuanailys Nez
fns. Unidad en la que se origina:
UDO.
fnt. Criterios de validacin: Se evaluar peridicamente que la aplicacin impida el registro
de nuevos usuarios a partir de datos nicos ya registrados.
fnu. Grado de satisfaccin del
fnv. Grado de insatisfaccin del
interesado: 5
interesado: 1
fnw. Dependencias: 37.
fnx. Conflictos: No presenta
fny. Documentos de soporte: No
fnz. Histrico de cambios: 09/01/2012
Definido
foa. Proyecto: Sistema empresarial
fob. Analista:
Oscar Josu Ruiz
foc.

fod.
foe. Identificador del

fog. Tipo de
foh. Caso de
requisito:
requisito:
Uso/Evento:
fof. 033-RF
Funcional
foi. Descripcin: El sistema se bloquear despus de 3 intentos fallidos de acceso por el
272
usuario.
foj. Justificacin del requisito: Seguridad del sistema.
fok. Fuente : Yhuanailys Nez
fol. Unidad en la que se origina:
UDO.
fom.Criterios de validacin: Se verificar mediante pruebas peridicas que el sistema se
bloquee de forma automtica luego de tres intentos fallidos de acceso.
fon. Grado de satisfaccin del
foo. Grado de insatisfaccin del
interesado: 5
interesado: 1
fop. Dependencias: 1, 31.
foq. Conflictos: No presenta
for. Documentos de soporte: No
fos. Histrico de cambios: 09/01/2012
Definido
fot. Proyecto: Sistema empresarial
fou. Analista:
Oscar Josu Ruiz
fov.
fow.
fox. Identificador del

foz. Tipo de
fpa. Caso de
requisito:
requisito:
Uso/Evento:
foy. 034-RF
Funcional
fpb. Descripcin: El Sistema arrojar un mensaje cuando uno de los campos no sea
completado o llenado de forma correcta.
fpc. Justificacin del requisito: Informa al usuario que debe ingresar los datos correctamente.
fpd. Fuente : Yhuanailys Nez
fpe. Unidad en la que se origina:
UDO.
fpf. Criterios de validacin: Se verificar peridicamente que el sistema cumple esta
funcionalidad.
fpg. Grado de satisfaccin del
fph. Grado de insatisfaccin del
interesado: 5
interesado: 1
fpi. Dependencias: 1, 2, 3, 6, 38.
fpj. Conflictos: No presenta
fpk. Documentos de soporte: No
fpl. Histrico de cambios: 09/01/2012
Definido
fpm.Proyecto: Sistema empresarial
fpn. Analista:
Oscar Josu Ruiz
fpo.
fpp. Identificador del
fpr. Tipo de
fps. Caso de
requisito:
requisito:
Uso/Evento:
fpq. 035-RF
Funcional
fpt. Descripcin: El sistema generara de forma automtica cdigos aleatorios para cada
consulta realizada.
fpu. Justificacin del requisito:
fpv. Fuente : Yhuanailys Nez
fpw.Unidad en la que se origina:
273
UDO.
fpx. Criterios de validacin: Se evaluar peridicamente que la aplicacin impida el registro
de nuevos usuarios a partir de datos nicos ya registrados.
fpy. Grado de satisfaccin del
fpz. Grado de insatisfaccin del
interesado: 5
interesado: 1
fqa. Dependencias: 9.
fqb. Conflictos: No presenta
fqc. Documentos de soporte: No
fqd. Histrico de cambios: 09/01/2012
Definido
fqe. Proyecto: Sistema empresarial
fqf. Analista:
Oscar Josu Ruiz
274
fqg.

fqh.
fqi. Identificador del

fqk. Tipo de
fql. Caso de
requisito:
requisito:
Uso/Evento:
fqj. 036-RF
Funcional
fqm.Descripcin: El sistema debe tener un mdulo de Administrar Usuario, en el cual se
puede registrar toda la informacin de los usuarios del sistema.
fqn. Justificacin del requisito: Permite realizar el registro o modificacin de los usuarios que
harn uso del sistema.
fqo. Fuente : Yhuanailys Nez
fqp. Unidad en la que se origina:
UDO.
fqq. Criterios de validacin: Se verificar mediante pruebas peridicas que el sistema posee
el modulo que contenga toda la informacin de los usuarios.
fqr. Grado de satisfaccin del
fqs. Grado de insatisfaccin del
interesado: 5
interesado: 1
fqt. Dependencias: No presenta
fqu. Conflictos: No presenta
fqv. Documentos de soporte: No
fqw. Histrico de cambios: 09/01/2012
Definido
fqx. Proyecto: Sistema empresarial
fqy. Analista:
Oscar Josu Ruiz
fqz.
fra. Identificador del

frc. Tipo de
frd. Caso de
requisito:
requisito:
Uso/Evento:
frb. 037-RF
Funcional
fre. Descripcin: El mdulo Administrar Usuario debe contemplar los siguientes campos:
Usuario, Clave Nombre, Apellido, Cedula, Telfono, Cdigo Carnet, Correo, Tipo de
Usuario.
frf. Justificacin del requisito: Campos requeridos para el registro de usuarios.
frg. Fuente : Wendy Rondn
frh. Unidad en la que se origina:
fri. Criterios de validacin: Se verificar peridicamente que el sistema cumple esta
funcionalidad.
frj. Grado de satisfaccin del
frk. Grado de insatisfaccin del
interesado: 5
interesado: 1
frl. Dependencias: 36.
frm. Conflictos: No presenta
frn. Documentos de soporte: No
fro. Histrico de cambios: 09/01/2012
Definido
frp. Proyecto: Sistema empresarial
frq. Analista:
Oscar Josu Ruiz
frr. Cuadro 83. Requisito Funcional N 38.
275
frs. Identificador del

fru. Tipo de
frv. Caso de
requisito:
requisito:
Uso/Evento:
frt. 038-RF
Funcional
frw. Descripcin: El sistema debe permitir ingresar el mismo armario para ciertos abonados.
frx. Justificacin del requisito: Para cada armario existen una cantidad determinado de
abonados, por lo tanto comparten el mismo armario.
fry. Fuente : Yhuanailys Nez
frz. Unidad en la que se origina:
UDO.
fsa. Criterios de validacin: Mediante pruebas continuas se verificar que la aplicacin
permite que diferentes abonados compartan el mismo nmero de armario.
fsb. Grado de satisfaccin del
fsc. Grado de insatisfaccin del
interesado: 5
interesado: 1
fsd. Dependencias: 6.
fse. Conflictos: No presenta
fsf. Documentos de soporte: No
fsg. Histrico de cambios: 09/01/2012
Definido
fsh. Proyecto: Sistema empresarial
fsi. Analista:
Oscar Josu Ruiz
fsj. Compaa Annima Nacional Telfonos de Venezuela

fsk. 3.10.2 Requisitos No Funcionales.
fsl.
fsm. Adicionalmente a los requisitos funcionales, deben ser agregados al
sistema una serie de requisitos que restringen o condicionan el desarrollo del mismo.
stos no se refieren directamente a las funciones especficas que proporciona el
sistema, sino a las propiedades emergentes de ste como la arquitectura, la seguridad,
el diseo, la implementacin, la fiabilidad, el tiempo de respuesta, la capacidad de
almacenamiento y la plataforma hardware/software del sistema propuesto.
fsn.Cuadro 84. Requisito No Funcional N 1.
fso. Identificador del
requisito:
fsp. 001-RNF
fsq. Tipo de
fsr. Caso de
requisito:
Uso/Evento:
No
Funcional
fss. Descripcin: El sistema debe ser diseado segn la arquitectura cliente/servidor.
fst. Justificacin del requisito: Mejor escalabilidad, control, mantenimiento, seguridad,
interfaces amigables, fcil manejo.
fsu. Fuente : Yhuanailys Nez
fsv. Unidad en la que se origina:
276
UDO.
fsw. Criterios de validacin: No presenta.
fsx. Grado de satisfaccin del
interesado: 5
fsz. Dependencias: No presenta.
ftb. Documentos de soporte: No
Definido
ftd. Proyecto: Sistema empresarial
fsy. Grado de insatisfaccin del

interesado: 1
fta. Conflictos: No presenta
ftc. Histrico de cambios: 09/01/2012
fte. Analista:
Oscar Josu Ruiz
ftf.
Cuadro 85. Requisito No Funcional N 2.
ftg. Identificador del
requisito:
fth. 002-RNF
fti. Tipo de
ftj. Caso de
requisito:
Uso/Evento:
No
Funcional
ftk. Descripcin: Cada usuario del sistema tendr asignado un determinado perfil, con el cual
se podr activar las funciones u opciones que se pueda realizar dentro del sistema.
ftl. Justificacin del requisito: Seguridad de los datos y distribucin de funciones segn los
roles del usuario.
ftm. Fuente : Yhuanailys Nez
ftn. Unidad en la que se origina:
UDO.
fto. Criterios de validacin: No presenta.
ftp. Grado de satisfaccin del
ftq. Grado de insatisfaccin del
interesado: 5
interesado: 1
ftr. Dependencias: No presenta.
fts. Conflictos: No presenta
ftt. Documentos de soporte: No
ftu. Histrico de cambios: 09/01/2012
Definido
ftv. Proyecto: Sistema empresarial
ftw. Analista:
Oscar Josu Ruiz
ftx. Compaa Annima Nacional Telfonos de Venezuela

fty. Cuadro 86. Requisito No Funcional N 3.
ftz. Identificador del
requisito:
fua. 003-RNF
fub. Tipo de
fuc. Caso de
requisito:
Uso/Evento:
No
Funcional
fud. Descripcin: La interfaz del sistema deber ser implementada como una aplicacin Web.
fue. Justificacin del requisito: Simplicidad, flexibilidad, usabilidad, entornos amigables,
portabilidad.
fuf. Fuente : Yhuanailys Nez
fug. Unidad en la que se origina:
UDO.
277
fuh. Criterios de validacin: No presenta.

fui. Grado de satisfaccin del
interesado: 5
fuk. Dependencias: No presenta.
fum.Documentos de soporte: No
Definido
fuo. Proyecto: Sistema empresarial
fuj. Grado de insatisfaccin del

interesado: 1
ful. Conflictos: No presenta
fun. Histrico de cambios: 09/01/2012
fup. Analista:
Oscar Josu Ruiz
fuq.
fur. Cuadro 87. Requisito No Funcional N 4.
fus. Identificador del
requisito:
fut. 004-RNF
fuu. Tipo de
fuv. Caso de
requisito:
Uso/Evento:
No
Funcional
fuw. Descripcin: El sistema debe basar sus comunicaciones en protocolo s estndar de
Internet.
fux. Justificacin del requisito: Estandarizacin de protocolos de comunicacin
fuy. Fuente : Yhuanailys Nez
fuz. Unidad en la que se origina:
UDO.
fva. Criterios de validacin: No presenta.
fvb. Grado de satisfaccin del
fvc. Grado de insatisfaccin del
interesado: 5
interesado: 1
fvd. Dependencias: No presenta.
fve. Conflictos: No presenta
fvf. Documentos de soporte: No
fvg. Histrico de cambios: 09/01/2012
Definido
fvh. Proyecto: Sistema empresarial
fvi. Analista:
Oscar Josu Ruiz
fvj.
fvk. Identificador del
requisito:
fvl. 005-RNF
fvo.
fvp.
fvq.
fvs.
fvt.
fvm.
Tipo
fvn. Caso de
de
Uso/Evento:
requisito:
No
Funcional
Descripcin: La aplicacin deber ser independiente de la plataforma donde se
despliegue.
Justificacin del requisito: Permite a la aplicacin ser ejecutada en diversos sistemas
operativos.
fvr. Unidad en la que se origina:
UDO.
Criterios de validacin: No presenta.
fvu. Grado de insatisfaccin del
278
interesado: 5
fvv. Dependencias: No presenta.
fvx. Documentos de soporte: No
Definido
fvz. Proyecto: Sistema empresarial
interesado: 1
fvw. Conflictos: No presenta
fvy. Histrico de cambios: 09/01/2012
fwa. Analista:
Oscar Josu Ruiz
fwb.
fwc.
fwd.
fwe.

fwf.
fwg.Identificador del
requisito:
fwh.006-RNF
fwi. Tipo de
fwj. Caso de
requisito:
Uso/Evento:
No
Funcional
fwk. Descripcin: El sistema deber tener una interfaz grfica sencilla y amigable, basada en
mens, ventanas, listas desplegables y botones de accin.
fwl. Justificacin del requisito: Adaptacin de usuarios, usabilidad y fcil manejo.
fwm.
fwn.Unidad en la que se origina:
UDO.
fwo.Criterios de validacin: No presenta.
fwp.Grado de satisfaccin del
fwq.Grado de insatisfaccin del
interesado: 5
interesado: 1
fwr. Dependencias: No presenta.
fws. Conflictos: No presenta
fwt. Documentos de soporte: No
fwu.Histrico de cambios: 09/01/2012
Definido
fwv. Proyecto: Sistema empresarial
fww.
Analista:
Oscar Josu Ruiz
fwx.
fwy.
fwz. Identificador del
requisito:
fxa. 007-RNF
fxb. Tipo de
fxc. Caso de
requisito:
Uso/Evento:
No
Funcional
fxd. Descripcin: La aplicacin ser manejada bajo el idioma espaol.
fxe. Justificacin del requisito: Garantiza que el sistema opere bajo el idioma que manejan
los usuarios.
fxf. Fuente : Yhuanailys Nez
fxg. Unidad en la que se origina:
UDO.
279
fxh. Criterios de validacin: No presenta.

fxi. Grado de satisfaccin del
interesado: 5
fxk. Dependencias: No presenta.
fxm.Documentos de soporte: No
Definido
fxo. Proyecto: Sistema empresarial
fxj. Grado de insatisfaccin del

interesado: 1
fxl. Conflictos: No presenta
fxn. Histrico de cambios: 09/01/2012
fxp. Analista:
Oscar Josu Ruiz
fxq.
fxr. Identificador del
requisito:
fxs. 008-RNF
fxt. Tipo de
fxu. Caso de
requisito:
Uso/Evento:
No
Funcional
fxv. Descripcin: La aplicacin debe identificar en ventana activa el usuario que est haciendo
uso de est.
fxw. Justificacin del requisito: Permite verificar la validacin de acceso por parte del
usuario.
fxx. Fuente : Yhuanailys Nez
fxy. Unidad en la que se origina:
UDO.
fxz. Criterios de validacin: No presenta.
fya. Grado de satisfaccin del
fyb. Grado de insatisfaccin del
interesado: 5
interesado: 1
fyc. Dependencias: No presenta.
fyd. Conflictos: No presenta
fye. Documentos de soporte: No
fyf. Histrico de cambios: 09/01/2012
Definido
fyg. Proyecto: Sistema empresarial
fyh. Analista:
Oscar Josu Ruiz
fyi.
fyj.
fyk.

fyl. Cuadro 92. Requisito No Funcional N 9.

fym.
Identificador
del requisito:
fyn. 009-RNF
fyo. Tipo de
fyp. Caso de
requisito:
Uso/Evento:
No
Funcional
fyq. Descripcin: El sistema debe presentar mensajes de alerta que permitan al usuario
identificar el tipo de error.
fyr. Justificacin del requisito: Deteccin de errores por parte del usuario.
fys. Fuente : Yhuanailys Nez
fyt. Unidad en la que se origina:
280
UDO.
fyu. Criterios de validacin: No presenta.
fyv. Grado de satisfaccin del
interesado: 5
fyx. Dependencias: No presenta.
fyz. Documentos de soporte: No
Definido
fzb. Proyecto: Sistema empresarial
fzd.
fyw. Grado de insatisfaccin del

interesado: 1
fyy. Conflictos: No presenta
fza. Histrico de cambios: 09/01/2012
fzc. Analista:
Oscar Josu Ruiz
fze. Identificador del

requisito:
fzf. 010-RNF
fzg. Tipo de
fzh. Caso de
requisito:
Uso/Evento:
No
Funcional
fzi. Descripcin: El sistema debe validar la informacin contenida en los formularios de
ingreso. Durante este proceso, se deben tener en cuenta aspectos tales como:
obligatoriedad de campos, longitud de caracteres permitida por campo, entre otros.
fzj. Justificacin del requisito: Ingreso correcto de datos.
fzk. Fuente : Yhuanailys Nez
fzl. Unidad en la que se origina:
UDO.
fzm.Criterios de validacin: No presenta.
fzn. Grado de satisfaccin del
fzo. Grado de insatisfaccin del
interesado: 5
interesado: 1
fzp. Dependencias: No presenta.
fzq. Conflictos: No presenta
fzr. Documentos de soporte: No
fzs. Histrico de cambios: 09/01/2012
Definido
fzt. Proyecto: Sistema empresarial
fzu. Analista:
Oscar Josu Ruiz
fzv.Cuadro 94. Requisito No Funcional N 11.

fzw. Identificador del
requisito:
fzx. 011-RNF
fzy. Tipo de
fzz. Caso de
requisito:
Uso/Evento:
No
Funcional
gaa. Descripcin: El acceso del sistema deber estar restringido por el uso de claves asignadas
a cada uno de los usuarios. Slo podrn ingresar al Sistema las personas que estn
registradas.
gab. Justificacin del requisito: Restringe el acceso al sistema solo a usuarios registrados.
gac. Fuente : Yhuanailys Nez
gad.Unidad en la que se origina:
UDO.
gae. Criterios de validacin: No presenta.
gaf. Grado de satisfaccin del
gag. Grado de insatisfaccin del
interesado: 5
interesado: 1
281
gah. Dependencias: No presenta.

gaj. Documentos de soporte: No
Definido
gal. Proyecto: Sistema empresarial
gai. Conflictos: No presenta

gak. Histrico de cambios: 09/01/2012
gam.
Analista:
Oscar Josu Ruiz
gan.
gao.

gap.
gaq.Identificador del
requisito:
gar. 012-RNF
gas. Tipo de
gat. Caso de
requisito:
Uso/Evento:
No
Funcional
gau. Descripcin: El diseo grfico del sistema para la gestin de informacin en el proceso de
instalacin y reparacin de averas debe ser adaptado al diseo oficial web de la compaa
telefnica C.A.N.T.V.
gav. Justificacin del requisito: Estandarizacin grfica de web y aplicaciones de la empresa.
gaw.Fuente : Yhuanailys Nez
gax. Unidad en la que se origina:
UDO.
gay. Criterios de validacin: No presenta.
gaz. Grado de satisfaccin del
gba. Grado de insatisfaccin del
interesado: 5
interesado: 1
gbb. Dependencias: No presenta.
gbc. Conflictos: No presenta
gbd. Documentos de soporte: No
gbe. Histrico de cambios: 09/01/2012
Definido
gbf. Proyecto: Sistema empresarial
gbg. Analista:
Oscar Josu Ruiz
gbh.
gbi.
gbj. Identificador del
requisito:
gbk.013-RNF
gbl. Tipo de
gbm.
Caso de
requisito:
Uso/Evento:
No
Funcional
gbn. Descripcin: El sistema debe tener rapidez y rendimiento de respuesta.
gbo. Justificacin del requisito: Mayor eficiencia operativa orientada a la agilizacin del
proceso.
gbp. Fuente : Yhuanailys Nez
gbq.Unidad en la que se origina:
UDO.
gbr. Criterios de validacin: No presenta.
gbs. Grado de satisfaccin del
gbt. Grado de insatisfaccin del
interesado: 5
interesado: 1
282
gbu. Dependencias: No presenta.

gbw.
Definido
gby. Proyecto: Sistema empresarial
gbv. Conflictos: No presenta

gbx. Histrico de cambios: 09/01/2012
gbz. Analista:
Oscar Josu Ruiz
gca.
gcb. Identificador del
requisito:
gcc. 014-RNF
gcd. Tipo de
gce. Caso de
requisito:
Uso/Evento:
No
Funcional
gcf. Descripcin: El sistema debe presentar la fecha completa y hora en la pantalla del men
principal.
gcg. Justificacin del requisito: Acceso rpido a fecha y hora actual.
gch. Fuente : Yhuanailys Nez
gci. Unidad en la que se origina:
UDO.
gcj. Criterios de validacin: No presenta.
gck. Grado de satisfaccin del
gcl. Grado de insatisfaccin del
interesado: 5
interesado: 1
gcm.
Dependencias: No presenta.
gcn. Conflictos: No presenta
gco. Documentos de soporte: No
gcp. Histrico de cambios: 09/01/2012
Definido
gcq. Proyecto: Sistema empresarial
gcr. Analista:
Oscar Josu Ruiz
gcs.
gct.
gcu.

gcv.
gcw.Identificador del
requisito:
gcx. 015-RNF
gcy. Tipo de
gcz. Caso de
requisito:
Uso/Evento:
No
Funcional
gda. Descripcin: En la parte inferior de las pantallas de login y men principal, se debe
mostrar un borde con el ao de la aplicacin, nombre de la institucin y unidad
correspondiente.
gdb. Justificacin del requisito: Identificacin de la compaa para cual fue desarrollado el
sistema.
gdc. Fuente : Yhuanailys Nez
gdd.Unidad en la que se origina:
UDO.
283
gde. Criterios de validacin: No presenta.

gdf. Grado de satisfaccin del
interesado: 5
gdh. Dependencias: No presenta.
gdj. Documentos de soporte: No
Definido
gdl. Proyecto: Sistema empresarial
gdg. Grado de insatisfaccin del

interesado: 1
gdi. Conflictos: No presenta
gdk. Histrico de cambios: 09/01/2012
gdm.
Analista:
Oscar Josu Ruiz
gdn.
gdo.
gdp.Identificador del
requisito:
gdq.016-RNF
gdr. Tipo de
gds. Caso de
requisito:
Uso/Evento:
No
Funcional
gdt. Descripcin: El sistema debe estar en capacidad de permitir en el futuro el desarrollo de
nuevas funcionalidades posteriores a su construccin y puesta en marcha inicial.
gdu. Justificacin del requisito: En caso que se realicen cambios en el sistema
gdv. Fuente : Yhuanailys Nez
gdw.
UDO.
gdx. Criterios de validacin: No presenta.
gdy. Grado de satisfaccin del
gdz. Grado de insatisfaccin del
interesado: 5
interesado: 1
gea. Dependencias: No presenta.
geb. Conflictos: No presenta
gec. Documentos de soporte: No
ged. Histrico de cambios: 09/01/2012
Definido
gee. Proyecto: Sistema empresarial
gef. Analista:
Oscar Josu Ruiz
geg.
geh. Identificador del
requisito:
gei. 017-RNF
gej. Tipo de
gek. Caso de
requisito:
Uso/Evento:
No
Funcional
gel. Descripcin: El sistema debe estar en capacidad de permitir en el futuro su fcil
mantenimiento con respecto a los posibles errores que se puedan presentar durante su
operacin.
gem.
Justificacin del requisito: En caso que se presenten errores en el sistema.
gen. Fuente : Yhuanailys Nez
geo. Unidad en la que se origina:
UDO.
gep. Criterios de validacin: No presenta.
geq. Grado de satisfaccin del
ger. Grado de insatisfaccin del
interesado: 5
interesado: 1
284
ges. Dependencias: No presenta.

geu. Documentos de soporte: No
Definido
gew.Proyecto: Sistema empresarial
gey.
get. Conflictos: No presenta

gev. Histrico de cambios: 09/01/2012
gex. Analista:
Oscar Josu Ruiz

gez.
gfa. Identificador del

requisito:
gfb. 018-RNF
gfe.
gff.
gfg.
gfi.
gfj.
gfl.
gfn.
gfp.
gfc. Tipo de
gfd. Caso de
requisito:
Uso/Evento:
No
Funcional
Descripcin: El sistema debe utilizar los dispositivos de entrada y salida ms adecuados
para el buen funcionamiento del mismo.
Justificacin del requisito: Permite mejor interaccin con el sistema y una mejor
visualizacin de los datos.
gfh. Unidad en la que se origina:
UDO.
gfk. Grado de insatisfaccin del
interesado: 5
interesado: 1
gfm.Conflictos: No presenta
gfo. Histrico de cambios: 09/01/2012
Definido
gfq. Analista:
Oscar Josu Ruiz
gfr. Cuadro 102. Requisito No Funcional N 19.

gfs. Identificador del
requisito:
gft. 019-RNF
gfu. Tipo de
gfv. Caso de
requisito:
Uso/Evento:
No
Funcional
gfw. Descripcin: Existencia de un Manual de Usuario para describir el funcionamiento y el
uso del sistema al usuario final.
gfx. Justificacin del requisito: Brindar informacin sobre el uso del sistema a los usuarios.
gfy. Fuente : Yhuanailys Nez
gfz. Unidad en la que se origina:
UDO.
gga. Criterios de validacin: No presenta.
ggb. Grado de satisfaccin del
ggc. Grado de insatisfaccin del
interesado: 5
interesado: 1
ggd. Dependencias: No presenta.
gge. Conflictos: No presenta
ggf. Documentos de soporte: No
ggg. Histrico de cambios: 09/01/2012
285
Definido
ggh. Proyecto: Sistema empresarial
ggj.
ggk.Identificador del
requisito:
ggl. 020-RNF
ggi. Analista:
Oscar Josu Ruiz

ggm.
Tipo
ggn.Caso de
de
Uso/Evento:
requisito:
No
Funcional
ggo. Descripcin: El sistema debe estar disponible durante el horario de trabajo establecido
para el personal que labora dentro de la unidad de conmutacin y planta externa.
ggp. Justificacin del requisito: Garantizar el uso de la aplicacin en horarios laborales.
ggq. Fuente : Yhuanailys Nez
ggr. Unidad en la que se origina:
UDO.
ggs. Criterios de validacin: No presenta.
ggt. Grado de satisfaccin del
ggu. Grado de insatisfaccin del
interesado: 5
interesado: 1
ggv. Dependencias: No presenta.
ggw.
Conflictos: No presenta
ggx. Documentos de soporte: No
ggy. Histrico de cambios: 09/01/2012
Definido
ggz. Proyecto: Sistema empresarial
gha. Analista:
Oscar Josu Ruiz
ghb.
ghc.

ghd.
ghe. Identificador del
requisito:
ghf. 021-RNF
ghg.Tipo de
ghh.Caso de
requisito:
Uso/Evento:
No
Funcional
ghi. Descripcin: El sistema debe ser definido a travs de clases
ghj. Justificacin del requisito: Permitir la reutilizacin del cdigo a travs de la
programacin orientada a objetos.
ghk. Fuente : Yhuanailys Nez
ghl. Unidad en la que se origina:
UDO.
ghm.
ghn. Grado de satisfaccin del
gho. Grado de insatisfaccin del
interesado: 5
interesado: 1
ghp. Dependencias: No presenta.
ghq. Conflictos: No presenta
ghr. Documentos de soporte: No
ghs. Histrico de cambios: 09/01/2012
Definido
286
ght. Proyecto: Sistema empresarial

ghu. Analista:
Oscar Josu Ruiz
ghv.
ghw.
ghx.Identificador del
requisito:
ghy. 022-RNF
ghz. Tipo de
gia. Caso de
requisito:
Uso/Evento:
No
Funcional
gib. Descripcin: El sistema debe funcionar en un computador con un procesador Pentium 4 o
superiores, memoria RAM de 1024MB o mayor, de 120 a 160 GB en disco duro.
gic. Justificacin del requisito: Especificaciones tcnicas.
gid. Fuente : Yhuanailys Nez
gie. Unidad en la que se origina:
UDO.
gif. Criterios de validacin: No presenta.
gig. Grado de satisfaccin del
gih. Grado de insatisfaccin del
interesado: 5
interesado: 1
gii. Dependencias: No presenta.
gij. Conflictos: No presenta
gik. Documentos de soporte: No
gil. Histrico de cambios: 09/01/2012
Definido
gim.Proyecto: Sistema empresarial
gin. Analista:
Oscar Josu Ruiz
gio.
gip. Identificador del
requisito:
giq. 023-RNF
git.
giu.
giv.
gix.
giy.
gja.
gjc.
gje.
gjg.
gir. Tipo de
gis. Caso de
requisito:
Uso/Evento:
No
Funcional
Descripcin: El sistema debe ser capaz de almacenar consistentemente todos los datos.
Justificacin del requisito: Evitar inconsistencia de datos.
giw. Unidad en la que se origina:
UDO.
giz. Grado de insatisfaccin del
interesado: 5
interesado: 1
gjb. Conflictos: No presenta
gjd. Histrico de cambios: 09/01/2012
Definido
gjf. Analista:
Oscar Josu Ruiz
287
gjh.

gji. Cuadro 107. Requisito No Funcional N 24.

gjj. Identificador del
requisito:
gjk. 024-RNF
gjl. Tipo de
gjm.
Caso de
requisito:
Uso/Evento:
No
Funcional
gjn. Descripcin: La aplicacin debe ser levantada desde equipos mviles con requerimientos
mnimos de procesador de 650 MHz, 512Mb de RAM, memoria interna de 160 Mb,
Navegador WAP/xHTML, HTML, red GSM 850 / 900 / 1800 / 1900/ HSDPA 900 / 2100.
gjo. Justificacin del requisito: Especificaciones tcnicas.
gjp. Fuente : Yhuanailys Nez
gjq. Unidad en la que se origina:
UDO.
gjr. Criterios de validacin: No presenta.
gjs. Grado de satisfaccin del
gjt. Grado de insatisfaccin del
interesado: 5
interesado: 1
gju. Dependencias: No presenta.
gjv. Conflictos: No presenta
gjw. Documentos de soporte: No
gjx. Histrico de cambios: 09/01/2012
Definido
gjy. Proyecto: Sistema empresarial
gjz. Analista:
Oscar Josu Ruiz
gka.
gkb.
gkc.
gkd.
gke.
gkf.
gkg.
gkh.
gki.
gkj.
gkk.
gkl.
gkm.
gkn.
gko.
288
gkp.
gkq.
gkr.
gks.
gkt.

gku.
4. Anlisis de Requisitos.
gkv. Esta etapa permitir aumentar el grado de comprensin y entendimiento
de los requisitos que han sido previamente recolectados, presentando una detallada
descripcin de los mismos, a fin de contribuir en la estructuracin final del sistema,
incluyendo la arquitectura. De igual manera, este subproceso consiste en determinar y
resolver posibles conflictos entre los requisitos y establecer la interaccin de la
aplicacin empresarial con su dominio o ambiente.
gkw.
gkx. Para lograr esto es necesario clasificar los requisitos en base a diversas
categoras establecidas o criterios de agrupamiento que, generalmente, van asociados
al tipo de requisito, bien sea funcional o no funcional, establecer contradicciones
entre requisitos, eliminar incompatibilidades y contradicciones entre requisitos,
determinar viabilidad de los requisitos, redefinir requisitos con el usuario en caso de
ser necesario, entre otras actividades asociadas al subproceso de anlisis de requisitos.
gky.
4.1 Diagrama de Procesos.
gkz.
gla. El proceso de anlisis de requisitos es una fase fundamental dentro de la
ingeniera de requisitos, debido a que durante esta etapa se analizan las necesidades
de los clientes que han sido previamente detectadas para de esta manera alcanzar una
definicin clara de los requisitos de la aplicacin. Obviamente, para poder completar
289
la definicin de los requisitos es fundamental contar con una serie de insumos que
sirvan de entrada al proceso, con el objetivo de generar un producto final que
contenga la definicin clara y detallada de los requisitos recolectados. El Diagrama
42 refleja en forma grfica lo expuesto anteriormente.
glb.

Dominio
Objetivos
Procesos
Reglas
Actores
Problemas
Lista preliminar de requisitos funcionales
Anlisis Documento de Definicin de Requisitos

de
Requisitos
glc.Diagrama 42. Diagrama de Procesos del Anlisis de Requisitos.

gld.
gle. El anlisis de requisitos est compuesto por una serie de actividades que
fue necesario realizar a fin de obtener los requisitos funcionales finales a partir de la
lista preliminar de requisitos previamente establecida. Estas actividades fueron:
glf.
a) Revisar y analizar los requisitos funcionales recolectados.
b) Depurar y agrupar los requisitos funcionales recolectados.
c) Clasificar los requisitos recolectados, agrupndolos por categoras establecidas.
d) Determinar solapamiento y dependencia entre requisitos.
e) Identificar y analizar el grado de completitud de los requisitos.
f) Determinar viabilidad de los requisitos.
290
g) Determinar la clasificacin de aquellos requisitos funcionales que: no son

necesarios, son incompatibles entre s, no son completos o no son factibles.
h) Refinar y revisar los requisitos con los actores o interesados.
i) Validar los requisitos finales.
glg.

4.2 Jerarqua del Proceso Anlisis de Requisitos.

glh.
gli.
glj.
glk.
Descubrimiento
de
Requisitos
Anlisis
de
Requisitos
Especificacin
de
Requisitos
gll.
glm.
gln.
Clasificacin
glo.
de
glp.Requisitos
glq.
Negociacin
de
Requisitos
Modelado
del
Problema
Diseo Inicial
de la
Arquitectura
Figura 23. Jerarqua de procesos del Anlisis de Requisitos.

glr.
4.3 Criterios de Agrupacin de Requisitos Funcionales y No Funcionales.

gls.
glt.
Una vez que los requisitos son recolectados es necesario establecer una
clasificacin de los mismos en base a categoras establecidas. Esta clasificacin debe

realizarse tanto para los requisitos funcionales como para los no funcionales. Todo
esto contribuir con el proceso de anlisis de los requisitos que debe contener la
aplicacin para ser incorporada una vez que est operativa en los procesos de
Por una parte, los requisitos funcionales son aquellos que determinan las
291
funcionalidades del sistema. Ahora bien, la clasificacin de los requisitos funcionales

se llevara a cabo tal y como se muestra a continuacin:
glu.
glv.Compaa Annima Nacional Telfonos de Venezuela
glx.
glw.
Cuadro 108. Clasificacin de Requisitos Funcionales.
Tipo de
gly.Descripcin
glz.Origen del
Requisito
gma.
Requisito
s
del
Negocio
gmd.
Requisitos
del
Requisito
gmb. Se
expresan
desde
la
perspectiva
de
la
empresa:
describen
por que la
empresa
o
cliente desea
desarrollar el
sistema.
Contiene
tambin
objetivos,
metas
o
necesidades
que
la
empresa
desea
alcanzar con
el uso del
sistema.
gme. Se
expresan
desde
la
perspectiva
del Usuario:
gmc.
Centro
de
Computaci
n
de
la
UDO.
gmf.
Empleados
de
Unidad
292
Usuario
gmg.
Requisitos
gmh.
gmi.
del
Sistema
gml.
gmm.
Requisito
s
gmn.
de
describen las
necesidades
que
los
usuarios
tienen y las
tareas
que
los usuarios
realizan con
la aplicacin.
Expresan lo
que
el
usuario ser
capaz
de
hacer con el
sistema.
gmj. Se
expresan
desde
la
perspectiva
del sistema
que contiene
la
aplicacin:
son
requisitos de
alto
nivel
para
productos
que
tienen
componentes
de hardware
y software.
gmo. Se
expresan
desde
la
perspectiva
del
de
Conmutaci
n (CX).
gmk.
Centro
de
Computaci
n
de
la
UDO.
gmp.
gmq.
Pasante:
293
Comp
ortamiento
gms.
desarrollado
r: describen
los servicios
que
el
sistema
presta
a
todos
sus
usuarios
directos.
Expresa lo
que hace el
sistema bajo
ciertos
estmulos o
eventos.
Br.
Oscar
Josu Ruiz.
gmr.
gmt. Los requisitos no funcionales no restringen o condicionan el sistema, por

el contrario, estos requisitos son adicionales a los requisitos funcionales que debe
cumplir el sistema, es decir, no se refieren directamente a las funciones especficas
que proporciona el sistema, sino a las propiedades emergentes de ste,
complementando a si a los requisitos funcionales del mismo. La clasificacin de los
requisitos no funcionales, tomada como referencia, es la definida por Ian
Sommerville (2005) la cual es descrita a continuacin:
gmu.
gmv. Cuadro 109. Clasificacin de Requisitos No Funcionales.
gmw. Tipo de
gmx. Descrip
gmy. Origen
Requisito
gmz.
Requisitos
del
cin
gnb. Especifi
can
el
comportamie
nto
del
del
Requesito
gnc.
Desarrollad
or.
294
gna.
Product
o
gnd.
gne.
gnf.
Req
uisitos
Organiza
cionales
gnj.
Requisitos
gnk.
Externo
s
producto.
Ejemplos:
rapidez de la
ejecucin,
capacidad de
memoria,
fiabilidad,
etc.
gng. Derivan
de polticas y
procedimient
os existentes
en
la
organizacin
del cliente y
del
desarrollador
. Ejemplos:
Estndares
de procesos,
mtodos de
diseo,
lenguajes de
programaci
n, mtodos
de entrega,
etc.
gnl.
Se
derivan de
factores
externos al
sistema y a
sus procesos
de
desarrollo.
Ejemplos:
Requisitos
gnh.
gni.
Compa
a Annima
Nacional
Telfonos de
Venezuela
(C.A.N.T.V.).
gnm.
Personas
que
manipularan
la aplicacin
empresarial.
295
de
inter
operatividad,
legislativos,
ticos, etc.
gnn.
gno.
gnp.
296
4.4 Requisitos Funcionales.

gnq.
gnr. A continuacin se muestran los requisitos funcionales definitivos de la aplicacin empresarial una vez concluido el
proceso de anlisis de requisitos.
gns.
gnt.
C
gob.
0
gnu.
Cuadro 110. Requisitos Funcionales del Sistema.
Descripcin del Requisito
goc. El sistema debe permitir que el

usuario ingrese su usuario y
gnv.
Us
god.
gnw.
Proc
e
s
o
s
d
e
l
gnx.
Neg
o
c
i
o
goe. -
To
gny.
R
gnz.Tip
o de
Req
uisi
to
goa.
M
gof.
gog. De
Co
mpo
rtam
ient
o.
gon. De
goh.
contrasea para ser validado su

acceso.
goi.
goj. El usuario administrador tendr
gok.
gol. -
gom.
goo.
297
permisos para registrar nuevos
Us
Co
mpo
usuarios.
rtam
ient
o.
gop.
0
goq.El usuario administrador tendr
gor.
permisos para modificar datos de
Us
gos. -
got.
-
gou. De
Co
gov.
E
mpo
cualquier usuario.
rtam
ient
o.
gow.
0
gox.El usuario administrador tendr

permisos
inhabilitar
para
eliminar
cualquier
goy.
goz. -
Us
gpa.
-
gpb. De
Co
gpc.
E
mpo
usuario
rtam
estndar.
ient
o.
gpd.
0
gpe. El usuario administrador podr

acceder y modificar la lista de
gpf.
gpg.-
Us
gph.
-
gpi. De
Co
gpj.
E
mpo
usuarios registrados.
rtam
ient
o.
gpk.
0
gpl. El usuario administrador tendr

permisos
para
modificar
informacin tcnica de cualquier
gpm.
Us
gpn.P
F
-
gpp.
0
gpq. De
Co
mpo
gpr.
E
298
abonado.
rtam
ient
o.
1
.
3
;
1
.
4
;
gpo.1
.
5
;
3
.
1
gps.
0
gpt. El usuario administrador podr

acceder a los registros de la
gpu.
gpv.
Us
gpw.
-
gpx.
De
gpy.
E
299
Co
aplicacin.
mpo
rtam
ient
o.
gpz.
gqa.
gqb.
C
gqj.
0
gqc.Descripcin del Requisito
gqk.El sistema regular y controlar

el acceso al contenido ofrecido.
Cuadro 110. (Cont.).

gqd.
Us
gql.
To
gqe.P
r
o
c
e
s
o
s
d
e
l
gqf. N
e
g
o
c
i
o
gqm.
-
gqg.
R
gqh.
Tipo de
Re
qui
sito
gqi.
M
gqn.
gqo.De
gqp.
Sist
ema
300
.
gqq.
0
gqr. El sistema permitir la consulta

de informacin tcnica de los
gqs.
To
gqt. P
F
gqv.
-
gqw.
gqx.
De
abonados tanto a los usuarios
Co
estndar como al administrador.
mp
orta
mie
nto.
1
.
3
;
1
.
4
;
gqu.1
.
5
;
301
.
gqy.
0
gqz. Despus de haber transcurrido
gra.
cierto tiempo estando el sistema
To
1
grb. -
grc.
-
grd. De
Co
inactivo se cerrar de forma
mp
automtica.
orta
gre.
E
mie
nto.
grf.
0
grg. Los usuarios podrn salir del

sistema en cualquier momento
grh.
gri. -
To
grj.
-
grk. De
Co
grl.
E
mp
con solo cerrar su sesin.
orta
mie
nto.
grm.
0
grn. El sistema debe mostrar en la
gro.
consulta de abonados, la siguiente
grq.
grt.
grr. P
gru. De
Co
informacin tcnica: puertos aba,
grp.
mp
armario, par central, par local y
To
orta
mie
nto.
terminal.
2
;
1
.
grv.
E
302
3
;
1
.
4
;
grs. 1
.
5
;
3
.
1
grw.
0
grx. La informacin modificada a

travs de la aplicacin se deber
gsi.
gsa.
gsd.
grz.
la base de datos de origen, a fin
Us
gsc. -
gsf. De
Co
gsb.
actualizar de forma automtica en
gse.
mp
orta
de presentarse actualizada de ser
mie
consultada a
nto.
travs
sistema de la compaa.
gsh.
gry.
de otro
gsg.
E
303
gsj.Cuadro 110. (Cont.).

gsk.
C
gss.
0
gsl. Descripcin del Requisito
gst. La aplicacin debe contar con un

men principal con mdulos.
gsm.
Usu
a
r
i
o
gsu. T
o
gsn.
Pr
gsp.
R
gsq. Tip
o de
Req
uisi
to
gsr.
M
gsw.
gsx. De
gsy.
gso.
Ne
gsv.
-
Co
mpo
rtam
ient
o.
l
o
s
U
s
u
a
r
i
o
s
304
gsz.
0
gta. Al momento de actualizar datos

tcnicos, el sistema debe validar
.
gtb. U
s
gtc.
gte.
PF
gtf. De
Co
gtg.
E
mpo
si existe algn abonado con la
misma informacin tcnica.
gtd.
rtam
1.5
ient
o.
i
o
A
d
m
i
n
i
s
t
r
a
d
o
r
gth.
gti. El sistema debe guardar registros
.
gtj. T
gtk.
gtm.
gtn. De
gto.
305
aplicacin, consultas realizadas y
gtl.
mpo
modificacin
rtam
de
informacin
tcnica de los abonados.
Co
de los ingresos de usuarios a la
ient
o.
l
o
s
U
s
u
a
r
i
o
s
gtp.
0
sustraer
.
gtr. T
informacin de la base de datos
de
ser
gtt.
mpo
usuarios
rtam
cuando sta sea solicitada y en
gtq. El
sistema
la
deber
compaa
suministrada
tiempo real.
los
para
gts.
gtu.
-
gtv. De
Co
ient
o.
gtw.
E
306
l
o
s
U
s
u
a
r
i
o
s
gtx.
0
gty. Para la consulta de abonados, el

sistema
debe
permitir
buscar
.
gtz. T
gua.
gud.
-
gue. De
Co
del
gub.
mpo
abonado, armario, par central, par
PF
rtam
local, terminal o puertos aba en
datos
tcnicos
partir
caso de que posea.
ient
guc.
l
o
s
1.5
o.
guf.
E
307
s
u
a
r
i
o
s
gug.
0
guh.El sistema debe mostrar todos los
.
gui. U
guj.
Co
para cada abonado.
mpo
rtam
ient
o.
A
d
m
i
n
i
s
t
gul. De
registros y consultas realizadas
guk.
gum.
E
308
r
a
d
o
r
.
gun.
guo.
gup.
guq.
C
guy.
0
gur. Descripcin del Requisito
guz. El sistema tiene que tener la

gus. U
s
u
a
r
i
o
gva. U
gut.
Pr
guv.
R
guw.
Tipo de
Req
uisi
to
gux.
M
gvc.
gvd. De
gve.
guu.
Ne
gvb.
registro de algn abonado en
mpo
especfico.
rtam
ient
o.
o
A
d
Co
opcin de bsqueda de cualquier
309
m
i
n
i
s
t
r
a
d
o
r
gvf.
0
gvg.El sistema deber mostrar una

lista
de
registrados.
todos
los
usuarios
.
gvh.U
s
gvi.
-
gvj.
-
gvk. De
Co
mpo
rtam
ient
o.
o
A
d
m
i
gvl.
E
310
n
i
s
t
r
a
d
o
r
gvm.
0
la
.
gvo.T
impresin de cualquier consulta
de abonados, lista de usuario,
informacin de usuarios o de
gvq.
rtam
cualquier registro.
1.5
ient
gvn.El
sistema
debe
permitir
gvp.
gvr.
PF
gvs. De
Co
mpo
o.
l
o
s
U
s
u
a
gvt.
E
311
r
i
o
s
gvu.
0
permitir
.
gvw.
gvx.
gvz.
modificar informacin tcnica de
Usu
PF
gvv.El
sistema
abonados
modificados
debe
que
han
ingresados
sistema previamente.
gwa.
gwb.
De
Co
sido
al
gvy.
mpo
1.5
rtam
ient
o.
A
d
m
i
n
i
s
t
r
a
d
o
312
r
gwc.
0
El sistema debe permitir
.
gwe.
gwf.
gwh.
listar todos los abonados en caso
Todo
PF
gwd.
de ser solicitado por el usuario.
Co
gwj.
E
mpo
gwi. De
gwg.
rtam
1.5
ient
o.
o
s
U
s
u
a
r
i
o
s
gwk.
0
gwl.El sistema debe impedir que

cualquier registro de consulta o
actualizacin sea eliminada.
.
gwm.
Usu
gwn.
-
gwo.
-
gwp.
gwq.
De
Co
mpo
rtam
313
ient
o.
E
s
t
n
d
a
r
gwr.
0
gws.
.
gwt.U
gwu.
gwx.
De
usuarios, abonados o fecha.
Co
mpo
rtam
ient
o.
d
m
i
n
gww.
listar los registros en base a
gwv.
314
i
s
t
r
a
d
o
r
.
gwy.
gwz.
gxa.
gxb.
gxc.
C
gxk.
0
gxd.
gxl. Al guardar los datos de un

gxe. U
s
u
a
r
i
o
gxm.
gxf.
Pr
gxi. Tip
o
de
Re
qui
sito
gxj.
M
gxr.
gxs. De
gxt.
gxg.
Ne
gxo.
abonado, el sistema validara y

enviara un mensaje de aviso, en
gxh.
R
gxn.U
tal caso que exista un abonado
con la misma informacin.
Co
gxp.
mp
PF
orta
mie
nto.
315
gxq.
1.
i
o
A
d
m
i
n
i
s
t
r
a
d
o
r
gxu.
0
gxv.En el submen de consultar
.
gxw.
gxy.
gyb.
gye. De
Co
abonado, el sistema tiene que

tener la opcin de bsqueda de
gxx.T
cualquier abonado, si es general y
no se selecciona ninguno de los
gxz.
gyc.
mp
orta
PF
gyd.
mie
gyf.
E
316
campos de filtrado y mostrara
gya.
todos los abonados que existen.
1.
nto.
l
o
s
U
s
u
a
r
i
o
s
gyg.
0
gyh.El sistema debe ser capaz de
.
gyi. T
mostrar los abonados ubicados
por armario si as lo solicita el
usuario.
gyk.
mp
1.
orta
gyj.
gyl.
PF
gym.
gyn.
De
Co
mie
l
o
nto.
317
U
s
u
a
r
i
o
s
gyo.
0
gyp.Slo
el
modificar
usuarios.
administrador
las
podr
contraseas
de
.
gyq.U
s
gyr.
-
gys.
-
gyt. De
Co
mp
orta
mie
nto.
o
A
d
m
i
n
gyu.
E
318
i
s
t
r
a
d
o
r
gyv.
0
El sistema debe mostrar un
.
gyx.T
mensaje de autenticacin fallida
cada vez que el usuario y
mp
contrasea sean invlidos.
orta
mie
gyw.
gyy.
-
gyz.
-
gza. De
Co
nto.
l
o
s
U
s
u
a
r
gzb.
E
319
i
o
s
gzc.
0
gzd. El sistema debe validar que no se
.
gze. U
gzf.
Co
de usuario con el nombre de
mp
usuario, numero de carnet o
orta
cdula ya registrado en el mismo.
mie
nto.
A
d
m
i
n
i
s
t
r
a
d
o
gzh. De
puede ingresar un nuevo registro
gzg.
gzi.
E
320
r
.
gzj.Cuadro 110. (Cont.).

gzk.
C
gzs.
0
gzl. Descripcin del Requisito
gzt. El sistema se bloquear despus
gzm.
Usu
a
r
i
o
gzu. T
de 3 intentos fallidos de acceso
por el usuario.
ema
l
o
s
U
s
u
a
r
i
gzn.
Pr
gzp.
R
gzo.
Ne
gzv.
-
gzw.
-
gzq.Tip
o
de
Re
qui
sito
gzx. De
Sist
gzr.
M
gzy.
E
321
o
s
gzz.
0
haa. El Sistema arrojara un mensaje
.
hab. T
cuando uno de los campos no sea
completado o llenado de forma
mp
correcta.
orta
mie
hac.
-
had.
-
hae. De
Co
haf.
E
nto.
l
o
s
U
s
u
a
r
i
o
s
hag.
0
hah. El sistema generara de forma

automtica
cdigos
aleatorios
.
hai. T
o
haj.
-
hak.
-
hal. De
Co
ham.
E
322
para cada consulta realizada.
mp
orta
mie
nto.
l
o
s
U
s
u
a
r
i
o
s
han.
0
hao.
El sistema debe tener un
mdulo de Administrar Usuario,
.
hap. U
s
haq.
-
har.
-
has. De
Co
en el cual se puede registrar toda la
mp
informacin de los usuarios del
orta
sistema.
mie
nto.
hat.
E
323
A
d
m
i
n
i
s
t
r
a
d
o
r
hau.
0
El mdulo Administrar
.
haw.
hax.
Usuario debe contemplar los
Usu
hav.
hay.
-
haz. De
Co
siguientes campos: Usuario, Clave
mp
Nombre, Apellido, Cedula,
orta
Telfono, Cdigo Carnet, Correo,
mie
Tipo de Usuario.
nto.
A
d
hba.
E
324
m
i
n
i
s
t
r
a
d
o
r
hbb.
hbc.
0
hbd.
.
hbe. U
ingresar el mismo armario para
ciertos abonados.
hbf.
hbh.
PF
hbi. De
Co
mp
hbg.
orta
1.
mie
i
o
A
d
m
i
nto.
hbj.
E
325
n
i
s
t
r
a
d
o
r
.
hbk.
hbl.
hbm.
hbn.
4.5 Requisitos No Funcionales.
hbo.
hbp. A continuacin se muestra la lista de requisitos no funcionales definitivos del sistema de software.
hbq.
hbr.
hbs.
C
Cuadro 111. Requisitos No Funcionales.
hbt. Descripcin del Requisito
hbu.
Us
hbv.
Pro
c
e
hbx.
R
hby.
Tipo de
Re
qui
hbz.
M
326
s
o
s
hca.
0
hcb. El sistema debe ser diseado segn
hcc.
la arquitectura cliente/servidor.
De
d
e
l
hbw.
Neg
o
c
i
o
hcd. -
sito
hce.
hcf. De
Pro
hcg.
-
duct
o.
hch.
0
hci. Cada usuario del sistema tendr

asignado un determinado perfil, con
el
cual
se
podr
activar
hcj.
hck. -
De
hcl.
hcm.
hcn.
Externo.
hcs.
hct. De
hcu.
las
funciones que se pueda realizar

dentro del sistema
hco.
0
hcp. La interfaz del sistema deber ser

implementada
como
una
hcq.
hcr. -
De
Pro
duct
aplicacin Web.
o.
hcv.
0
hcw.
El sistema debe basar sus
comunicaciones en protocolo s
hcx.
De
hcy. -
hcz.
-
hda. De
Pro
hdb.
E
327
duct
estndar de Internet.
o.
hdc.
0
hdd.La
aplicacin
deber
ser
independiente de la plataforma
hde.
hdf. -
De
hdg.
-
hdh. De
Pro
hdi.
E
duct
donde se despliegue.
o.
hdj.
0
hdk.El sistema deber tener una

interfaz
amigable,
hdq.
0
grfica
basada
sencilla
en
hdl.
hdm.
To
hdn.
-
hdo.Org
aniz
mens,
acio
ventanas, listas desplegables y
nal.
botones de accin.
hdr. La aplicacin ser manejada bajo
el idioma espaol.
hds.
hdt. -
De
hdu.
-
hdv. Org
aniz
hdp.
E
hdw.
E
acio
nal.
hdx.
hdy.
C
hdz.

hea.
Us
heb.
Pro
hed.
R
c
e
s
o
s
d
e
l
hec. N
hee. Tip
o
de
Re
qui
sito
hef.
M
328
heg.
0
hen.
0
heh. La aplicacin debe identificar en

ventana activa el usuario que est
haciendo uso de est.
heo. El sistema debe
presentar
mensajes de alerta que permitan
hei.
e
g
o
c
i
o
hej. -
De
hep.
hek.
-
heq. -
De
her.
-
al usuario identificar el tipo de

heu.
0
error.
hev. El sistema
debe
validar
la
informacin contenida en los
hel. Ext
ern
o.
hes. Ext
ern
hew.
hex. -
De
hey.
-
hez. De
Pro
duct
este proceso, se deben tener en
o.
aspectos
obligatoriedad
tales
de
E
het.
E
o.
formularios de ingreso. Durante

cuenta
hem.
hfa.
E
como:
campos,
longitud de caracteres permitida

hfb.
0
por campo, entre otros.

hfc. El acceso del sistema deber estar
restringido por el uso de claves
asignadas a cada uno de los
usuarios. Slo podrn ingresar al
Sistema las personas que estn
hfd.
De
hfe. -
hff.
-
hfg. Ext
ern
o.
hfh.
E
329
hfi.
0
registradas.
hfj. El diseo grfico del sistema para
la gestin de informacin en el
proceso
de
instalacin
hfk.
hfl. -
De
hfm.
-
hfn. Org
aniz
acio
reparacin de averas debe ser
nal.
hfo.
E
adaptado al diseo oficial web de

la
hfp.
0
compaa
telefnica
C.A.N.T.V.
hfq. El sistema debe tener rapidez y
rendimiento de respuesta.
hfr.
hfs. -
De
hft.
-
hfu. De
pro
hfv.
E
duc
hfw.
0
hfx. El sistema debe presentar la fecha

completa y hora en la pantalla del
men principal.
hfy.
hfz. -
De
hga.
-
to.
hgb.Org
aniz
hgc.
E
acio
nal.
hgd.
hge.
hgf.
C
hgg.

hgh.
Us
hgi. P
r
o
c
e
s
o
s
hgk.
R
hgl. Tip
o
de
Re
qui
sito
hgm.
M
330
hgn.
0
hgo.En la parte inferior de las

pantallas
de
login
men
hgp.
d
e
l
hgj. N
e
g
o
c
i
o
hgq.-
De
hgr.
-
hgs. Org
aniz
principal, se debe mostrar un
acio
borde con el ao de la aplicacin,
nal.
hgt.
E
nombre de la institucin y unidad

hgu.
0
correspondiente.
hgv.El sistema debe
estar
en
capacidad de permitir en el futuro

el
desarrollo
de
hgw.
hgx.-
De
hgy.
-
hgz. Org
aniz
nuevas
acio
funcionalidades posteriores a su
nal.
hha.
E
construccin y puesta en marcha

hhb.
0
inicial.
hhc. El sistema debe permitir en el
futuro su fcil mantenimiento con
hhd.
De
hhe. -
hhf.
-
hhg.De
pro
respecto a los posibles errores que
duc
se puedan presentar durante su
to.
operacin.
hhh.
E
331
hhi.
0
hhj. El sistema debe utilizar los

dispositivos de entrada y salida
hhk.
hhl. -
De
hhm.
-
ms adecuados para el buen

hhp.
0
funcionamiento del mismo.

hhq.Existencia de un Manual de
Usuario
para
describir
el
sistema al usuario final.

hhx.El sistema debe estar disponible
pro
hho.
-
duc
hhr.
hhs. -
De
hht.
-
funcionamiento y el uso del

hhw.
hhn.De
to.
hhu.Ext
ern
hhv.
E
o.
hhy.
durante el horario de trabajo
hia.
hic.
hib. -
hie.
hig.
hif. Org
establecido para el personal que
hhz.
hid.
aniz
hih.
labora dentro de la unidad de
De
acio
conmutacin y planta externa.
nal.
hii. Cuadro 111. (Cont.).

hij.
C
hik. Descripcin del Requisito
hil.
Us
him.
Pro
c
e
s
o
s
d
e
l
hin. N
e
g
hio.
R
hip. Tip
o
de
Re
qui
sito
hiq.
M
332
hir.
0
his. El sistema debe ser definido a

travs de clases.
hit.
o
c
i
o
hiu. -
De
hiv.
-
hiw.Org
aniz
hix.
-
acio
hiy.
0
hjk.
0
hiz. El sistema debe funcionar en un
hja.
computador con un procesador
hjc.
hje.
hjd. -
Pentium 4 o superiores, memoria
hjb.
hjf.
pro
hjj.
RAM de 1024MB o mayor, de
De
duc
120 a 160 GB en disco duro.

hjl. El sistema debe ser capaz de
almacenar consistentemente todos
hjm.
hjn. -
De
hjo.
-
desde
equipos
to.
hjp. De
pro
hjq.
E
duc
hjs. La aplicacin debe ser levantada

requerimientos
mviles
con
mnimos
de
hjt.
hjw.
hjz.
hjx.
hju.
hjy. -
to.
hkc.
hkf.
hkd.
hka.
procesador de 650 Mhz, 512Mb
hke. De
hkg.
pro
de Ram, memoria interna de 160
hjv.
hkb.
duc
hkh.
Mb, Navegador WAP/xHTML,
De
to.
HTML, red GSM 850 / 900 /

1800 / 1900/ HSDPA 900 / 2100.
hki.
hji.
hjh. De
los datos.
hjr.
nal.
hjg.
333
hkj.
hkk.
334
hkl.

4.6 Atributos de Calidad.

hkm.
hkn. Al momento de disear y desarrollar una aplicacin de software es
necesario considerar un aspecto de suma importancia que en muchas ocasiones
determina el correcto funcionamiento del mismo una vez que se ha hecho operativo y
el nivel de aceptacin y conformidad del usuario con dicho software. Se est
hablando entonces de la calidad, la cual es una de las principales preocupaciones de
los desarrolladores. Sin embargo, todo proyecto tiene como meta producir un
software de la mejor calidad posible, es decir, que cumpla y supere, de ser posible, las
expectativas de los usuarios.
hko.
hkp. Ahora bien, la calidad del software es el grado con el que un sistema,
componente o proceso cumple los requerimientos especificados y las necesidades o
expectativas del cliente o usuario. (IEEE, Std. 610-1990). En otras palabras, la
calidad es la aptitud de un producto o servicio para satisfacer las necesidades de los
usuarios que hacen uso del mismo. Es por ello que en el desarrollo de software, la
calidad de un producto final, es el resultado de un diseo de calidad, de un
levantamiento de requisitos de calidad,
de un desarrollo de calidad y de una
implementacin de calidad.
hkq.
hkr. En este sentido, la calidad del software debe ser evaluada en base a
diversos atributos de calidad que toman en consideracin diversos criterios que mide
el nivel de satisfaccin de los desarrolladores, mantenedores, adquisidores y usuarios
finales. Para efectos de este proyecto, se tom referencia el modelo de calidad
propuesto por la ISO/ IEC (Internacional Standard Information technology
Software Product Quality), denominado como ISO 9126-1, el cual es un estndar
335
internacional pensado para los desarrolladores, que son los responsables de

especificar y evaluar la
hks.

hkt.
calidad del software que producen. Por tanto, puede servir para
validar la completitud de una definicin de requisitos, identificar

requisitos de calidad de software, objetivos de diseo y prueba, criterios
de aseguramiento de la calidad, etc.
hku.
hkv. Con el paso de los aos han desarrollado diferentes modelos para la
evaluacin de la calidad. Sin embargo la mayora de ellos se basan en los criterios de
evaluacin propuestos en la norma ISO9126, la cual estructura los atributos de
calidad de software en seis caractersticas: funcionalidad, fiabilidad, usabilidad,
eficiencia, mantenibilidad y transportabilidad.
hkw.
hkx.
Fase de ISO 9126:
hky.
Calidad del Producto
hkz.
hla.
hlb.
9126-1
hlc.
Calidad Interna
9126-3
Calidad Externa
9126-2
Calidad en Uso
9126-4
hld.
hle.
hlf.
hlh.
hli.
hlg.
Figura 24. Calidad y Medicin de ISO.
Fuente: Coral Calero, Ismael Caballero, M ngeles Moraga,
Manuel Serrano (2008/2009).
336
hlj.
hlk.
hll. Compaa Annima Nacional Telfonos de Venezuela

hlm. Mtricas Internas de Calidad del producto de Software Segn la Norma
ISO 9126-3
hln.
hlo. Estas normas
pueden ser aplicadas a un producto de software no
ejecutable, es decir, que permite medir, bajo ciertos criterios, una aplicacin aun
cuando no se ha hecho operativa y funcional en su dominio, lo cual es totalmente
aplicable al presente proyecto de ingeniera de requisitos. De igual manera, estas
mtricas aplican durante las etapas del desarrollo del software, permitiendo medir la
calidad de los entregables intermedios y predecir la calidad del producto final.
hlp.
hlq. Ahora bien, de forma general, la norma ISO 9126-3, establece un modelo
de calidad que clasifica al software en un conjunto estructurado de caractersticas
basndose en ciertas mtricas internas de calidad, estas son:
hlr.
hls. Mtricas de Funcionalidad: Permiten calificar si el software maneja en
forma adecuada el conjunto de funciones que satisfagan las necesidades para las
cuales fue diseado. Entre sus caractersticas se encuentran:
hlt.
hlu.
1. Adecuacin: Capacidad del producto software para proporcionar un
conjunto apropiado de funciones para tareas y objetivos de usuario

especificados.
hlv.
2. Exactitud: Capacidad del producto software para proporcionar los
resultados o efectos correctos o acordados, con el grado necesario de precisin.
337
hlw.
3. Interoperabilidad: Capacidad del producto software para interactuar
con uno o ms sistemas especificados.

hlx.

5.5 Seguridad: Capacidad del producto software para proteger informacin y
datos de manera que las personas o sistemas no autorizados no puedan leerlos
o modificarlos, al tiempo que no se deniega el acceso a las personas o
sistemas autorizados.
5. Conformidad de la funcionalidad: Capacidad del producto software para
adherirse a normas, convenciones o regulaciones en leyes y prescripciones
similares relacionadas con funcionalidad.
hly. Para efectos de este proyecto es necesario medir la adecuacin y la
seguridad del software. A continuacin se muestras los criterios de evaluacin que la
ISO propone.
hlz.
hma.
hmc.
Propsit
o
hme. Fr
mula
hmg.
Detalles
de la
Frmul
a
hml.
Cuadro 112. Medicin de la Adecuidad.

hmb. ADECUIDAD
hmd. Esta caracterstica es medida para
garantizar al usuario que el sistema cumple con
la totalidad de tareas necesarias.
hmf. X = 1 A/B
hmh. A = nmero de funciones faltantes
hmi. B = nmero de funciones descritas en la
especificacin de requisitos.
hmj. 0 <= X <= 1
hmk. Entre ms cercano a uno, ms completa.
hmm. Cuadro 113. Medicin de la Seguridad.

hmn. SEGURIDAD
hmo.
hmp. Se mide esta caracterstica para garantizar
Propsit
al usuario que el sistema protege de forma
338
o
hmq. Fr
mula
hms.
Detalles
de la
Frmul
a
slida los datos.

hmr. [1-AMENAZA X (1-SEGURIDAD)]
hmt. AMENAZA=probabilidad de que un cierto
tipo de amenaza ocurra en un tiempo.
hmu. SEGURIDAD=probabilidad de que se
pueda contrarrestar un cierto tipo de ataque.
hmv.

hmw. Mtricas de Usabilidad: Consiste de un conjunto de atributos que

permiten evaluar el esfuerzo necesario que deber invertir el usuario para utilizar el
sistema. Sus caractersticas son:
hmx.
1. Entendibilidad: Capacidad del producto software que permite al
usuario entender si el software es adecuado y cmo puede ser usado para

unas tareas o condiciones de uso particulares.
hmy.
2. Aprendibilidad: Capacidad del producto software que permite al
usuario aprender sobre su aplicacin.

hmz.
3. Operatibilidad: Capacidad del producto software que permite al
usuario operarlo y controlarlo.

hna.
4. Atractivo: Capacidad del producto software para ser atractivo al
usuario.
hnb.
5. Conformidad de la usabilidad: Capacidad del producto software para
adherirse a normas, convenciones, guas de estilo o regulaciones

relacionadas con la usabilidad.
hnc.
hnd. En base a la usabilidad, es necesario medir en el presente proyecto, la
entendibilidad y la operabilidad del software, los cuales son atributos importantes que
debe poseer cualquier producto de software. La norma ISO tiene establecidos
339
patrones que se rigen por frmulas para establecer medidas en forma cuantitativa, no
solo de estos dos elementos, sino de mucho otros que de igual manera son de gran
importancia. En los siguientes cuadros se muestran los criterios establecidos para la
medicin de tales caractersticas, junto con el propsito de la medicin, su respectiva
frmula y una especificacin de las variables utilizadas.
hne.
hnf.

hng.
hni.
Propsit
o
hnk. Fr
mula
hnm.
Detalles
de la
Frmul
a
hnu.
Propsit
o
hnw. Fr
mula
hnz. Det
alles de
la
Frmul
Cuadro 114. Medicin de la Entendibilidad.

hnh. ENTENDIBILIDAD
hnj.
Esta caracterstica es medida para
garantizar al usuario que el sistema cumple un
determinado nmero de tareas adecuadas.
hnl.
X = A/B
hnn. X = A/B
hno. A = nmero de funciones (o tipos de
funciones) evidentes
hnp. al usuario
hnq. B = total de funciones (o tipos de
funciones)
hnr. 0 <= X <= 1 ; Entre ms cercano a 1,
mejor
hns.
Cuadro 115. Medicin de la Operabilidad.
hnt.
OPERABILIDAD
hnv.
Se mide esta caracterstica para garantizar
al usuario que el sistema le permite realizar
completamente sus tareas.
hnx. xito=(n de tareas terminadas+(n medias
0.5))100/n
hny.
total de tareas
hoa.
Tarea terminada tiene peso 1,tarea a medio
terminar 0.5 y
hob. tarea no terminada 0
340
a
hoc.
hod. Mtricas de Confiabilidad: Se refieren a la capacidad que posee el
software de mantener un nivel estable de ejecucin. Entre sus caractersticas estn:
hoe.
hof.
1. Madurez: Capacidad del producto software para medir la frecuencia de
falla por errores en el software.

hog.
2. Tolerancia a fallos: Se refiere a la habilidad de mantener un nivel
especfico de funcionamiento en caso de fallas del software o de cometer

infracciones de su interfaz especfica.
hoh.
3. Recuperacin: Se refiere a la capacidad de restablecer el nivel de
operacin y recobrar los datos que hayan sido afectados directamente por una
falla, as como al tiempo y el esfuerzo necesarios para lograrlo.
hoi.

hoj. La confiabilidad es una de las cualidades ms importantes de un producto

de software, tanto as, que todos los atributos que componen este importante elemento
se orientan al sentido de confianza y seguridad que adquiere el usuario con respecto
al software con el cual interacta. Por tal razn, para efectos de este proyecto es
necesario medir los tres atributos que componen la confiabilidad: la madurez del
software, la tolerancia a fallos y la recuperacin. A continuacin, se muestran las
frmulas adecuadas para esto:
hok.
hol.
hon.
Propsit
o
Cuadro 116. Medicin de la Madurez.

hom. MADUREZ
hoo. Se mide esta caracterstica para garantizar
al usuario que el sistema esta creado para
obtener un nivel de respuesta alto ante fallas
durante el uso del mismo.
341
hop.
Fr
mula
hor.
Detalles
de la
Frmul
a
hov.
hoq.
X = A/B
hos.
A = nmero de casos de pruebas en el plan
hot.
B = nmero de casos de pruebas
requeridos.
hou. 0 <= X ;
Entre X sea mayor, mejor la
suficiencia.
how.
Cuadro 117. Medicin de la Tolerancia a Fallos.

hox. TOLERANCIA A FALLOS
hoz.
Se mide esta caracterstica para garantizar al
hoy.
usuario que el sistema brinda un nivel alto de
Propsit
servicio, en caso de fallas.
o
hpb.
ANULACION DE FALLAS SERIAS
hpa. Fr
X=A/B
mula
hpd.
<= X <= 1 ; el ms cercano a 1.0 es el
hpc.
mejor
Detalles
hpe.
A=nmero de fallas serias anuladas contra
de la
los
casos
de
Frmul
hpf.
prueba del modelo de errores que casi causa
a
la falla
hpg.
B=nmero de casos de pruebas ejecutadas
del modelo de
hph. errores que casi causa la falla durante la
prueba
hpi.
hpj.
hpk.
hpl.
hpm. Compaa Annima Nacional Telfonos de Venezuela
hpn.
hpp.
Propsit
o
hpr.
Fr
Cuadro 118. Medicin de la Recuperacin.

hpo. RECUPERACIN
hpq.
Se mide esta caracterstica para garantizar al
usuario que el sistema es capaz de continuar
realizando lo que est en proceso en caso de
algn inconveniente externo.
hps.
TIEMPO DE RECUPERACION (1)
342
mula
hpw.
Detalles
de la
Frmul
a
hpt.Tiempo medio= X = suma=(T)/B

hpu.
TIEMPO ESTIMADO DE REINICIO (2)
hpv.
Promedio =X=A/B
5.6 0 <X el menor es el mejor
hpx.
T=tiempo para recuperar bajas del sistema
software en
hpy.
cada oportunidad
hpz.
B=nmero de veces que el software
observado entro en
hqa.
proceso de recuperacin
hqb.
(2) 0 <= X el mayor y ms cercano a 1.0 es
el mejor
hqc.
A=Un ero de oportunidades de reinicio que
se dieron en el tiempo estimado.
hqd.
B=Nmero total de oportunidades de reinicio
durante las
hqe.
pruebas o el apoyo al funcionamiento al
usuario
hqf.
hqg. Mtricas de Eficiencia: Estas mtricas permiten evaluar la relacin entre
el nivel de funcionamiento del software y la cantidad de recursos usados. Sus
caractersticas son:
hqh.
hqi.
1. Comportamiento en el tiempo: Capacidad del producto software para
proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados,

bajo condiciones determinadas.
hqj.
2. Utilizacin de recursos: Capacidad del producto software para usar las
cantidades y tipos de recursos adecuados cuando el software lleva a cabo su

funcin bajo condiciones determinadas.
hqk.
3. Conformidad de la eficiencia: Capacidad del producto software para
adherirse a normas o convenciones relacionadas con la eficiencia.
343
hql.

hqm. Para efectos de este proyecto solo se har necesario medir el

comportamiento en el tiempo, se presenta entonces en el siguiente cuadro la formula
apropiada para lograr esto:
hqn.
Cuadro 119. Medicin del Comportamiento en el Tiempo.

hqo. COMPORTAMIENTO EN EL TIEMPO
hqq.
La medicin de esta caracterstica permite
hqp. Pro
determinar
cul es el tiempo estimado para
psito
completar una tarea.
hqs.
X = tiempo (calculado o simulado)
hqr. Fr
mula
hqt.
Det
hqu. Entre ms corto, mejor
alles de
la
Frmul
a
hqv.
hqw. Mtricas de Mantenibilidad: Es la capacidad que posee el software para
ser modificado, bien sea para correccin de errores o fallas, o para ser agregadas
nuevas funcionalidades. Sus caractersticas principales son las siguientes:
hqx.
1. Analizabilidad: Relativo al esfuerzo necesario para diagnosticar las
deficiencias o causas de fallas, o para identificar las partes que debern ser
modificadas.
hqy.
2. Cambiabilidad: Mide el esfuerzo necesario para modificar aspectos del
software, remover fallas o adaptar el software para que funcione en un ambiente

diferente.
hqz.
3. Estabilidad: Permite evaluar los riesgos de efectos inesperados debidos
a las modificaciones realizadas al software.

hra.
4. Examinabilidad: Se refiere al esfuerzo necesario para validar el
software una vez que fue modificado.
344
hrb.
hrc.Las frmulas para realizar esto se muestran en los siguientes cuadros:
hrd.
hre.

hrf.Cuadro 120. Medicin de la Analizibilidad.

hrg. ANALIZIBILIDAD
hrh. Pro
hri. Se mide para garantizar al usuario que el
psito
sistema puede o no ser modificado en algn
proceso.
hrj.
Fr
hrk.
Tiempo medio en analizar un fallo:
mula
hrl. X = sum(Tout-Tin) / N
hrm. Det
hrn.
siendo Tout = momento en el que se
alles de
encuentran las causas
la
hro.
del fallo (o son reportadas por el usuario)
Frmul
hrp.
Tin = momento en el que se recibe el
a
informe del fallo
hrq.
y N = nmero total de fallos registrados
hrr. Cuadro 121. Medicin de la Cambiabilidad.
hrs.
CAMBIABILIDAD
hrt.
Pro
hru.
Es medida esta caracterstica para
psito
garantizar al usuario que el sistema puede ser
modificado.
hrv.
Fr
hrw. X = A/B
mula
hrx.
hry.
A = nmero de cambios a funciones o
mdulos que tienen
Detalles
hrz.
comentarios
de la
hsa.
confirmados
Frmul
hsb.
B = total de funciones o mdulos
a
modificados
hsc.
0 <= X <= 1
hsd.
Entre ms cercano a 1, ms registrable.
hse.
0 indica un control de cambios deficiente o
pocos cambios
hsf.y alta estabilidad
hsg.
Cuadro 122. Medicin de la Estabilidad.
345
hsi.Propsit
o
hsm.
Fr
mula
hsr.
Detalles
de la
Frmul
a
hta.
hsh. ESTABILIDAD
hsj. Esta caracterstica se mide para garantizar al
usuario que el
hsk.
sistema no tendr efectos secundarios en
caso de algn
hsl. cambio
hsn.
Frecuencia de fallos debidos a efectos
laterales producidos
hso.
despus de una
hsp.
modificacin:
hsq.
X = 1 A/ B
hss.siendo A= nmero de fallos debidos a efectos
laterales
hst. detectados y corregidos
hsu.
y B= nmero total de fallos corregidos el
usuario)
hsv.
Tin = momento en el que se recibe el
informe del fallo
hsw. y N = nmero total de fallos registrados0 <=
X <= 1
hsx.
Entre ms cercano a 1, ms registrable.
hsy.
0 indica un control de cambios deficiente o
pocos cambios
hsz.
y alta estabilidad
htb. Mtricas de Transportabilidad: Esta mtrica permite medir cuan fcil

puede ser trasladado el software de un entorno a otro. Las caractersticas principales
de la transportabilidad son las siguientes:
htc.
1. Adaptabilidad: Capacidad del producto software para ser adaptado a
diferentes entornos especificados, sin aplicar acciones o mecanismos distintos

de aquellos proporcionados para este propsito por el propio software
considerado.
htd.
2. Facilidad de instalacin: Es el esfuerzo necesario para instalar el
software en un ambiente determinado.
346
hte.
3. Remplazabilidad: Capacidad del producto software para ser usado en
lugar de otro producto software, para el mismo propsito, en el mismo entorno.

htf.
4. Conformidad de la transportabilidad: Capacidad del producto software
para adherirse a normas o convenciones relacionadas con la portabilidad.

htg.
hth. Para efectos de este proyecto solo ser necesario medir la conformidad de
transportabilidad. El cuadro que se presenta continuacin presenta la frmula
adecuada para lograr esto:
hti.
htj. Cuadro 123. Medicin de la Conformidad de Transportabilidad.
htk.
CONFORMIDAD DE TRANSPORTABILIDAD
htl.Propsit
htm. Se mide esta caracterstica para garantizar
o
al usuario que el sistema se ajustar al entorno
y normas preestablecidas.
htn.
Fr
hto.
X = A/B
mula
htp.
Det
htq.
A = nmero de artculos implementados de
alles de
conformidad
la
htr. B = total de artculos que requieren
Frmul
conformidad
a
hts.
0 <= X <= 1
htt. Entre ms cercano a 1, ms completa.
htu.
htv.
htw.

htx. Ingeniera de requisitos aplicado a los procesos de instalacin y reparacin de

hty. DOCUMENTO DE ESPECIFICACIN DE REQUISITOS
htz. Versin <1.0>
hua. Autor
hub. Fech huc. Ve
hud. Descripcin
347
hue. Oscar J.
a
huf. 06/0
rsin
hug. 0.8 huh. Versin preliminar propuesta.
Ruiz
hui. Oscar J.
1/2012
huj. 03/0
9
huk. 0.9 hul. Primera correccin.
Ruiz
hum. Oscar J.
2/2012
hun. 15/0
4
huo. 1.0 hup. Versin final del producto.
Ruiz
huq.
3/2012
1. Introduccin.
hur.
hus. El documento de especificacin de requisitos permite describir a mayor
nivel de profundidad cada uno de los requisitos funcionales que deber contener la
aplicacin empresarial y que fueron detectados e identificados en el documento de
definicin de requisitos. Para este documento, las funcionalidades del sistema sern
representadas de forma grficas a travs de modelos de casos de uso de sistema, los
cuales reflejan las interacciones que se dan entre el usuario final y el sistema,
haciendo nfasis en las funciones y operaciones que desempea cada actor de acuerdo
a su rol.
hut.
2. Requisitos Especficos.
huu.
huv. Como se ha sealado anteriormente, la finalidad de este documento es
enfocarse en los requisitos especficos sobre los cuales deber desarrollarse el
sistema.
huw.

hux. Por tal razn, y a fin de alcanzar una mayor comprensin de los mismos y
lograr un anlisis detallado de los requisitos, se llev a cabo un riguroso estudio desde
el punto de vista del modelo funcional representado por los diagramas de casos de
usos, el modelo estructural, que viene representado por los diagramas de clases y el
348
modelo dinmico que hace referencia en los diagramas de secuencia, acompaados de

sus respectivas descripciones y observaciones. Adicionalmente a esto, el prototipo de
la aplicacin, representado mediante interfaces, le servir al cliente como una
representacin limitada del producto final que este proyecto ofrece, a fin de apoyar
la evaluacin del producto, clarificar requisitos de usuario y definir alternativas.
huy.
2.1 Casos de Uso.
huz.
hva. Los casos de usos son una herramienta ms que ofrece UML (Unified
Modeling Languaje) y que son utilizados bsicamente para la representacin visual
del sistemas en cuanto a interacciones se refiere, partiendo de una perspectiva o
percepcin planteada a travs del paradigma orientado a objetos, entendiendo que la
interaccin es esencial para una descripcin coherente del comportamiento deseado
del mismo. De esta manera, los diagramas de casos de uso son representados
mediante los actores que interactan con la aplicacin, especificando la accin y los
requisitos funcionales que se esperan del sistema.
hvb.
hvc. De esta manera, se busca alcanzar una representacin visual del entorno
de la aplicacin junto con sus funcionalidades principales, mediante una notacin
grfica que defina la naturaleza del comportamiento y de los requerimientos bsicos
del sistema con solo dar una vista general simple de un caso de uso o un conjunto de
casos de usos.
hvd.

349
2.1.1
Diagrama de Caso de Uso General del Sistema.

hve.
hvf. Este caso de uso particular, muestra la representacin ms generalizada

del sistema en cuanto a interacciones y actores. Desde la validacin del usuario que le
permite acceder al men de opciones ofrecidas por el sistema empresarial para la
gestin de informacin en los procesos de instalacin y reparacin de averas. Hay
que tener en cuenta que debido a que la aplicacin deber contener el control de
contenido, las opciones del men principal dependern del nivel de acceso que posea
el usuario, bien sea usuario estndar o usuario administrador. Se muestra entonces en
la Figura 43, el diagrama de caso de uso general del sistema junto con la
especificacin detallada correspondiente al mismo.
hvg.
350
hvh.
hvi.
Diagrama 43. Diagrama de Caso de Uso General del Sistema.
hvj.
hvk.

hvl.
<< CU-1
hvm.
Caso
de
U
so
hvn.
Validar Usuario.
351
hvo.
Actor
es
hvp. Tcnico en Telecomunicaciones (Planta Interna).

hvq. Tcnico Instalador (Planta Externa).
hvr.
Tcnico Reparador Averas Telefnicas (Planta
Externa).
hvt.
Documento Definicin de Requisitos.
hvs.
Refer
en
ci
as
hvu.
Preco
n
di
ci
n
hvw.
Postc
on
di
ci
n
hvy.
Versi
n
hwa.
Autor
hwc.
Fecha
hwe.
hvv.
El usuario introduzca su nombre de usuario y su clave
y pulse Entrar.
hvx. Entrada de usuario al sistema e ingreso al men

principal
hwg.
hvz.
1.0
hwb.
Oscar Josu Ruiz.
hwd.
20/01/2012
hwf. Propsito
Representar de forma visual la validacin de los usuarios que harn uso de la
aplicacin.
hwh.
hwj.
hwk.
hwi. Resumen
En este caso de uso los usuarios debern ingresar su nombre de usuario y contrasea
para que el sistema valide su acceso al mismo.
352
hwl.
Diagrama de Caso de Uso

hwm.
hwn.
hwo.
hwp.
hwq.
hwr.
hws.
hwt.
hwu.
hwv.
hww.
hwx.
hwy.
hwz.
hxa.
Diagrama 44. Diagrama de Caso de Uso Validar Usuario.

hxb. Compaa Annima Nacional Telfonos de Venezuela
hxc. Curso Normal (BSICO)

hxe. Accin del
hxf.
hxg. Respuesta del
Actor
Sistema
hxi.
hxj.
hxk. El sistema mostrar
interfaz de
autenticacin con los
campos de usuario y
clave.
hxm. Ingresa usuario,
hxn.
hxo. Valida usuario y
clave y pulsa
clave.
Entrar.
hxq.
hxr.
hxs.
Verificar el estado
de cuenta del usuario.
hxu.
hxv.
hxw. Autoriza al usuario
segn su nivel de
acceso.
hxy.
hxz.
hya.
Muestra men
principal.
hxd.
hxh.
hxl.
hxp.
hxt.
hxx.
hyb.
353
hyc. Cursos Alternos

hye.
Si el usuario o clave son incorrectos el sistema muestra
mensaje de autentificacin fallida y permite ingresar nombre de
usuario y clave nuevamente.
hyg. Si el usuario est inhabilitado el sistema mostrar un mensaje
de notificacin.
hyd.
hyf.
hyh.
hyi.
Diagrama de Clases
hyj.
hyk.
hyl.
hym.
hyn.
hyo.
hyp.
hyq.
hyr.
hys.
hyt.
hyu.
hyv.
hyw.
hyx.
hyy.
hyz.
hza.
hzb.
Diagrama 45. Diagrama de Clase Validar Usuario.
354
hzc.

hzd.
Diagrama de Secuencia
hze.
hzf.
hzg.
hzh.
hzi.
hzj.
hzk.
hzl.
hzm.
hzn.
hzo.
hzp.
hzq.
hzr.
hzs.
hzt.
hzu.
hzv.
hzw.
hzx.
hzy.
hzz.
355
iaa.
iab.
iac.Diagrama 46. Diagrama de Secuencia Validar Usuario.
356
iad.

iae.
<< CU-2
iaf. C
as
o
de
U
so
iah.
Actor
es
ial. R
ef
er
en
ci
as
ian.
Preco
n
di
ci
n
iap.
Postc
on
di
ci
n
iar.Ve
rs
i
n
iat. A
ut
iag.Consultar Abonado.
iai. Tcnico en Telecomunicaciones (Planta Interna).

iaj. Tcnico Instalador (Planta Externa).
iak.Tcnico Reparador Averas Telefnicas (Planta Externa).
iam. Documento Definicin de Requisitos.
iao.El usuario debe ser validado en sistema correctamente.
iaq.El actor consult la informacin tcnica de algn abonado.
ias. 1.0
iau.Oscar Josu Ruiz.
357
or
iav.Fe
ch
a
iax.
iaw.
20/01/2012
iay.Propsito
iaz.Representar el proceso de Consulta de Abonados haciendo uso de la aplicacin empresaria
iba.
ibb.
Resumen
ibc.Este caso de uso presenta la funcin que ofrece el sistema de consultar la informacin
tcnica de los abonados a travs de diferentes filtros de bsqueda.
ibd.
ibe.
Diagrama de Caso de Uso

ibf.
ibg.
ibh.
ibi.
ibj.
ibk.
ibl.
ibm.
ibn.
ibo.
ibp.
ibq.
ibr.
ibs.
ibt.
ibu.
Diagrama 47. Diagrama de Caso de Uso Consultar Abonado.

ibv.Compaa Annima Nacional Telfonos de Venezuela
ibx.
iby.
ibw. Curso Normal (BSICO)

Accin del Actor
ibz.
ica.Respuesta del
Sistema
358
icf.
icj.
icn.
icc.
icd.
icg.El usuario selecciona

la opcin Consultar
Abonado del men
principal.
ick.El usuario ingresa
datos para la
bsqueda.
ico.Presiona botn
Consultar.
ich.
ice.Mostrar men
principal.
ici. Mostrar formulario
de consulta de
abonado.
icm.
icp.
icq.Mostrar la
informacin tcnica
del abonado.
icr.
ics. Cursos Alternos
icu.Si los datos proporcionados al sistema son incorrectos se mostrar
un mensaje de notificacin y se permitir realizar la consulta
nuevamente.
ict.
icv.
icw.
Diagrama de Clases
icx.
icy.
icz.
ida.
idb.
idc.
idd.
ide.
idf.
idg.
idh.
idi.
idj.
idk.
idl.
idm.
idn.
ido.
Diagrama 48. Diagrama de Clase Consultar Abonado.
359
idp.

a. Diagrama de Secuencia
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
m.
n.
o.
p.
q.
idq.
idr.
ids.
idt.
360
idu.
idv.
idw.
idx.
idy.
idz.
iea.Diagrama 49. Diagrama de Secuencia Consultar Abonado.
361
ieb.Compaa Annima Nacional Telfonos de Venezuela

iec.
<< CU-3
ied.
Caso
de
U
so
ief. A
ct
or
es
ieh.
Refer
en
ci
as
iej. Pr
ec
on
di
ci
n
iel. P
os
tc
on
di
ci
n
ien.
Versi
n
iep.
Autor
ier. Fe
ch
iee.Administrar Usuario.
ieg.Tcnico en Telecomunicaciones (Planta Interna).
iei. Documento Definicin de Requisitos.
iek.El usuario administrador ha sido validado por el sistema y

se ha cargado correctamente su men de administrador.
iem. El administrador realiz cambios en los usuarios del

sistema segn la seleccin (agregar, editar, eliminar o
inhabilitar un usuario).
ieo.1.0
ieq.Oscar Josu Ruiz.

ies. 05/02/2012
362
a
iet.
ieu.
Propsito
iev.Permitir al usuario con acceso a esta opcin, administrar los usuarios y la informaci
concerniente a los mismos.
iew.
iex.Resumen
iey.En este caso de uso se describe el proceso administrar usuario, el cual es realizad
nicamente por el usuario administrador del sistema, ste proceso ofrece funciones qu
permiten registrar nuevos usuarios con toda su informacin, modificar usuario
previamente cargados, inhabilitar usuarios o eliminar usuarios de ser necesario.
iez.
ifa. Diagrama de Caso de Uso
ifb.
ifc.
ifd.
ife.
iff.
ifg.
ifh.
ifi.
ifj.
ifk.
ifl.
ifm.
ifn.
ifo. Diagrama 50. Diagrama de Caso de Uso Administrar Usuario.
ifp. Compaa Annima Nacional Telfonos de Venezuela
ifr.
ifz.
ifq.Curso Normal (BSICO)

ifs. Accin del Actor
ift.
ifu.Respuesta del
Sistema
ifw.
ifx.
ify. Mostrar men
principal.
iga.El usuario selecciona la
igb.
igc.Mostrar interfaz de
opcin Administrar
Administrar Usuario.
Usuario del men
363
igd.
igh.
igl.
igp.
igt.
igx.
ihb.
ihf.
ihj.
ihn.
ihr.
principal.
ige.El usuario pulsa la
opcin Agregar
Usuario en el submen.
igi. El usuario ingresa datos
del nuevo usuario.
igm. Presiona botn
Guardar.
igf.
igg.
Mostrar
formulario de
agregar usuario.
igk.
ign.
igq.
El usuario
selecciona la opcin
Modificar Usuario
en el sub-men.
igu.
El usuario
selecciona en la lista el
usuario a modificar.
igy.El usuario presiona el
botn Modificar.
igr.
ihc.El usuario modifica los

datos.
ihg.
El usuario presiona
el botn Guardar.
ihd.
ihk.
El usuario
selecciona la opcin
Eliminar Usuario en
el sub-men.
iho.
El usuario
selecciona en la lista el
usuario a eliminar.
ihs.El usuario presiona el
botn Eliminar.
ihl.
igo.
El sistema
muestra mensaje
Datos guardados
con xito.
igs.Mostrar lista de
igw.
igz.
ihh.
ihp.
iht.
iha.El sistema mostrar

formulario para
modificar con los
datos actuales del
usuario.
ihe.
ihi. El sistema mostrar
un mensaje Datos
guardados con
xito.
ihm. Mostrar lista de
ihq.
ihu.
El sistema
muestra mensaje
364
Usuario
Eliminado con
xito.
ihv.
ihw. Cursos Alternos

ihy.De la lista de usuarios el administrador selecciona el usuario al que se dese
restringir el acceso al sistema y presiona opcin Inhabilitar.
ihx.
ihz.
iia.
iib. Compaa Annima Nacional Telfonos de Venezuela

iic.
iid. Diagrama de Clases
365
iie.
iif.
iig.
iih.
iii.
iij.
iik.
iil.
iim.
Diagrama 51. Diagrama de Clase Administrar Usuario.

iin.
366
iio. Compaa Annima Nacional Telfonos de Venezuela

iip. Diagrama de Secuencia
iiq.
iir.
iis.
iit.
iiu.
iiv.
iiw.
iix.
iiy.
iiz.
ija.
ijb.
ijc.
ijd.
ije.
ijf.
ijg.
ijh.
iji.
ijj.
ijk.
ijl.
ijm.
ijn.
ijo.
ijp.
ijq.
ijr.
ijs.
ijt.
iju.
ijv.
ijw.
ijx.
367
ijy.
ijz.
ika.
ikb.
Diagrama 52. Diagrama de Secuencia Administrar Usuario.
368
ikc.Compaa Annima Nacional Telfonos de Venezuela

ikd.
<< CU-4
ike.
Caso
de
U
so
ikg.
Actor
es
iki. R
ef
er
en
ci
as
ikk.
Preco
n
di
ci
n
ikm.
Postc
on
di
ci
n
iko.
Versi
n
ikq.
Autor
iks.Fe
ch
a
ikf. Actualizar Informacin Tcnica del Abonado.
ikh.
Tcnico en Telecomunicaciones (Planta Interna).
ikj. Documento Definicin de Requisitos.
ikl. El usuario administrador ha sido validado por el sistema y

ikn.
El usuario administrador modific datos tcnicos de
algn abonado (par central, armario, par local, terminal,
puertos aba)
ikp.
1.0
ikr. Oscar Josu Ruiz.

ikt. 03/02/2012
369
iku.
ikv.
Propsito
ikw.
Representar grficamente el proceso de actualizacin de la informacin tcnica de lo
abonados, la cual puede ser llevada a cabo nicamente por el usuario administrador.
ikx.
iky.
Resumen
ikz.En este caso de uso se refleja el curso como el usuario administrador, a travs de una de la
funcionalidades del sistema, es capaz de modificar la informacin tcnica de cualquie
abonado almacenado en la base de datos, modificando datos como, par central, par loca
armario, terminal, entre otros, solo en casos estrictamente necesarios.
ila.
ilb. Diagrama de Caso de Uso
ilc.
ild.
ile.
ilf.
ilg.
ilh.
ili.
ilj.
ilk.
ill.
ilm.
iln.
ilo. Diagrama 53. Diagrama de Caso de Uso Actualizar Inf. Tcnica del
Abonado.
ilp. Compaa Annima Nacional Telfonos de Venezuela
ilr.
ilz.
ilq. Curso Normal (BSICO)

ils. Accin del Actor
ilt.
ilu. Respuesta del
Sistema
ilw.
ilx.
ily. Mostrar men
principal.
ima. El usuario
imb.
imc. El sistema
selecciona la opcin
mostrar formulario
Actualizar
de bsqueda de
Abonado del men
abonados.
370
imd.
ime.
imh.
principal.
El usuario ingresa
datos de bsqueda.
imi.
El usuario
modifica la
informacin tcnica
del abonado.
imm. Presiona botn
Actualizar.
iml.
imf.
imj.
imn.
img. El sistema
mostrar formulario
para modificar con la
informacin tcnica
actual del abonado.
imk.
imo. El sistema
muestra datos
actualizados.
imp.
imq. Cursos Alternos

ims.
En caso de que el usuario haya introducido datos errneos del abonado tendr l
opcin de modificar los datos del abonado previamente cargados.
imr.
imt.
imu.
Diagrama de Clase
imv.
imw.
imx.
imy.
imz.
ina.
inb.
inc.
ind.
ine.
inf.
ing.
inh.
ini.
inj.
ink.
inl.
inm.
Diagrama 54. Diagrama de Clase Actualizar Inf. Tcnica del

Abonado.
371
inn.

ino.
r.
s.
t.
u.
v.
w.
x.
y.
z.
aa.
ab.
ac.
ad.
ae.
af.
ag.
ah.
ai.
aj.
inp.
inq.
372
inr.
ins.
int.
inu.
inv.
inw.
inx.
iny.
inz.Diagrama 55. Diagrama de Secuencia Actualizar Informacin Tcnica del Abonado.
ioa.
iob.
373
ioc.Compaa Annima Nacional Telfonos de Venezuela

iod.
<< CU-5
ioe.C
as
o
de
U
so
iog.
Actor
es
ioi. R
ef
er
en
ci
as
iok.
Preco
n
di
ci
n
iom.
Versi
n
ioo.
Autor
ioq.
Fecha
ios.
iou.
iov.
iox.
iof. Consultar Registros.
ioh.
Tcnico en Telecomunicaciones (Planta Interna).
ioj. Documento Definicin de Requisitos.
iol. El usuario administrador ha sido validado por el sistema y

ion.
1.0
iop.
Oscar Josu Ruiz.
ior. 07/02/2012
iot. Propsito
Representar el proceso de Consulta de Registros.
iow. Resumen
Permite al usuario administrador consultar todo el registro histrico
374
de los ingresos y consultas realizados por los usuarios.

ioy.
ioz.Diagrama de Caso de Uso
ipa.
ipb.
ipc.
ipd.
ipe.
ipf.
ipg.
iph.
ipi.
ipj.
ipk.
ipl.
ipm.
ipn.
ipo.
ipp.
ipq.
ipr.
ips.Diagrama 56. Diagrama de Caso de Uso Consultar Registros.
ipt. Compaa Annima Nacional Telfonos de Venezuela
ipu.
ipv.
Curso Normal (BSICO)
Accin del Actor
ipy.
ipz.
N
iqb.
iqc.
iqd.
ipw.
ipx.
iqe.
iqf. El usuario selecciona

la opcin Consultar
Registros del men
principal.
iqg.
iqi.
iqj.Diagrama de Clase
Respuesta del
Sistema
Mostrar men
principal.
iqh.
Mostrar el
registro histrico de
actividades de los
usuarios.
375
iqk.
iql.
iqm.
iqn.
iqo.
iqp.
iqq.
iqr.
iqs.
iqt.
iqu.
iqv.
iqw.
iqx.
iqy.
iqz.
ira. Diagrama 57. Diagrama de Clase Consultar Registros.
irb.
irc.
ird.
ire.
irf.
irg.
irh.
iri. Compaa Annima Nacional Telfonos de Venezuela
irj.
irk.
irl.
irm.
irn.
iro.
irp.
irq.
irr.
irs.
irt.
iru.
376
irv.
irw.
irx.
iry.
irz.
isa.
isb.
isc.
isd.
ise.
isf.
isg.
ish.
isi. Diagrama 58. Diagrama de Secuencia Consultar Registros.
isj.
377
isk.Compaa Annima Nacional Telfonos de Venezuela

5.4 PROTOTIPO DE LA APLICACIN
isl.
ism. En el mundo de la industria, existe la necesidad clara del desarrollo de
prototipos rpidos que permitan la pronta validacin de los requisitos con el usuario.
Es por ello que en muchas oportunidades es necesario para el cliente visualizar, de no
ser posible el resultado final del software, por lo menos una representacin limitada
del producto que desea. Sin duda alguna, esto permite al cliente tener una idea
general de la aplicacin con la cual debern interactuar los usuarios que estn
inmersos en el entorno donde esta sea implementada y a probar o conocer, tal vez de
forma muy superficial, las funcionalidades que ofrece.
isn.
iso. Un prototipo no es ms que una versin inicial de un sistema de software
que es utilizado para demostrar funcionalidades, concretar y validar requisitos, probar
opciones de diseo y entender mejor la necesidad que se presenta y su solucin. En
esta oportunidad se presenta el prototipo de la aplicacin que deber ser incorporada
en los procesos de instalacin y reparacin de averas, realizado por el personal de
planta externa para la unidad de conmutacin (CX) de la central digital Maturncentro perteneciente a la empresa telefnica C.A.N.T.V. El objetivo fundamental de
este prototipo es emular la interaccin entre el usuario y el sistema una vez que este
sea implementado, descubrir nuevos requisitos en caso de ser necesario y facilitar el
proceso de validacin de los requisitos previamente identificados.
isp.
isq. De esta manera se presenta entonces el prototipo que, mediante un
enfoque iterativo y evolutivo, fue desarrollado para la Compaa Annima Nacional
Telfonos de Venezuela.
isr.
iss.
378
ist. Compaa Annima Nacional Telfonos de Venezuela

isu.
isv. Figura 25. Interfaz Validar Usuario.
isw.
isx.
isy.
isz.
ita.
itb.
itc.
itd.
ite.
itf.
itg.
ith. Figura 26. Interfaz Men Usuario Administrador.
379
iti. Compaa Annima Nacional Telfonos de Venezuela

itj.
itk. Figura 27. Interfaz Men Usuario Estndar.
itl.
itm.
itn.
ito.
itp.
itq.
itr.
its.
itt.
itu.
itv. Figura 28. Interfaz Consultar Abonado.
380
itw.Compaa Annima Nacional Telfonos de Venezuela

itx.
ity. Figura 29. Interfaz Consultar Abonado. Respuesta de Bsqueda
itz.
iua.
iub.
iuc.
iud.
iue.
iuf.
iug.
iuh.
iui.
iuj. Figura 30. Interfaz Sub-men Administrar Usuario.
iuk.
Comp1aa Annima Nacional Telfonos de Venezuela
381
iul.
ium.
Figura 31. Interfaz Registro de Nuevo Usuario.

iun.
iuo.
iup.
iuq.
iur.
ius.
iut.
iuu.
iuv.
iuw.
iux.
iuy.Figura 32. Interfaz Seleccin de Usuario a Modificar/Inhabilitar.
iuz.Compaa Annima Nacional Telfonos de Venezuela
iva.
382
ivb.
ivc.
ivd.
ive.
ivf.
ivg.
ivh.
ivi.
ivk.
ivn.
ivj.
Figura 33. Interfaz Modificar Datos de Usuario.
ivl.
ivm.
Figura 34. Interfaz Datos de Usuario Modificado.

ivo.Compaa Annima Nacional Telfonos de Venezuela
383
ivp.
ivq.
Figura 35. Interfaz Seleccin de Usuario a Eliminar.

ivr.
ivs.
ivt.
ivu.
ivv.
ivw.
ivx.
ivy.
ivz.
iwa.
iwb.
iwc.
Figura 36. Interfaz Bsqueda de Abonado a Actualizar.
384
iwd.

iwe.
iwf.
Figura 37. Interfaz de Actualizacin de Informacin Tcnica del

Abonado.
iwg.
iwh.
iwi.
iwj.
iwk.
iwl.
iwm.
iwn.
iwo.
385
iwp.
iwq.
Figura 38. Interfaz Informacin Tcnica de Abonado

Actualizada.
iwr.
iws.
iwt.
Figura 39. Interfaz Consulta de Registros.

iwu.
iwv.
iww.
iwx.
iwy.
iwz.
ixa.
ixb.
ixc.
ixd.
ixe.
386
ixf.
ixg.
ixh.
ixi.
ixj. Figura 40. Interfaz Bsqueda de Registros Filtrados.
ixk.
5.5 ANLISIS COSTO-BENEFICIO
ixl.
ixm. El anlisis costo-beneficio es una herramienta financiera que mide la
relacin entre los costos y beneficios asociados a un proyecto de inversin con el fin
de evaluar su rentabilidad, entendindose por proyecto de inversin no solo la
creacin de un nuevo negocio, sino tambin, como inversiones que pueden ser
llevadas a cabo en las organizaciones, tales como el desarrollo de nuevo producto o la
adquisicin de nueva maquinaria.
ixn.
ixo. En esta oportunidad, el anlisis costo-beneficio pretende fundamentar la
base que justifique la elaboracin de este proyecto, haciendo nfasis en los beneficios
tangibles e intangibles que sern obtenidos a partir de este. Como paso inicial sern
descritos los costos que incurrieron en el desarrollo del proyecto.
ixp.
5.5.1 Costos
ixq.
ixr.
Costo de Personal: los costos de personal son todos los pagos
correspondientes al recurso humano como remuneracin a sus esfuerzos y

contribucin al desarrollo de esta investigacin. En el caso particular de este
proyecto, el cual fue desarrollado para la unidad de conmutacin por el bachiller en
calidad de pasante, la Universidad de Oriente no incurre en ningn gasto de este tipo.
ixs.
387
ixt.
Costos de Equipos y Herramientas: estos costos tienen relacin con la
adquisicin de algn tipo de herramienta de software o equipos de hardware

requeridos para la realizacin del proyecto. En este caso no fue necesaria la
adquisicin de ningn software o hardware, debido a que la unidad de conmutacin y
la Universidad de Oriente contaba con los equipos y herramientas requeridas.
ixu.

ixv. Costos de Adiestramiento: se generan por la capacitacin e instruccin

del personal involucrado en el proyecto con la finalidad de elevar sus conocimientos
en el rea. Generalmente estos adiestramientos se llevan a cabo a travs de charlas,
cursos y talleres. Para la elaboracin del proyecto fueron necesarios talleres sobre la
metodologa GRAY WATCH, la herramienta UML, taller de manejo SmartDraw 2012
y la nueva versin de diseo web Adobe Dreamweaver CS6.
ixw.
ixx. Costos de Materiales de Oficina: son los costos relacionados con la
adquisicin de materiales de oficina usados a diario como, como resmas de papel
necesarias para la documentacin, carpetas, ganchos, cartuchos de tinta para
impresora, libreta de anotaciones, lpices, lapiceros, entre otros. Es importante
sealar que estos costos fueron financiados por el pasante. A continuacin, la
siguiente tabla presenta un resumen de los costos del proyecto, detallando cada uno
de ellos con sus respectivos valores en bolvares.
ixy.
ixz. A continuacin se muestra el Cuadro 124, con un resumen general de los
costos asociados al desarrollo del proyecto, teniendo en cuenta el personal
involucrado, los equipos y herramientas, los costos de adiestramientos y de materiales
de oficina.
iya.
iyb.
iyc.
388
iyd.
iye.
iyf.
iyg.
iyh.
iyi. Compaa Annima Nacional Telfonos de Venezuela
iyj. Cuadro 124. Costos de Materiales. Fuente: autor 2012
iyk.
Concepto
iyl. Costos
iym. Costos de Equipos y Herramientas de
iyn.
Val
trabajo
or (Bs.)
iyo.
Hardware
iyp.
0
iyq.
Software
iys.Total costos de equipos y herramientas:
iyu.
Costos de Infraestructura
Bs
iyr. 0 Bs
iyt. 0 Bs
iyv.Valor
iyw.
(Bs.)
iyx.
0
Sala de Trabajo
iyy.Mobiliario
iza.Total costos de infraestructura:
Bs
iyz.0 Bs
izb.
0
izc.Costo de Personal
Bs
izd.Valor
ize.Responsable General del Proyecto

izg.Lder del Proyecto
izi. Analista de Procesos de Negocio
izk.
Analista de Sistemas
izm. Total costos del personal:
(Bs.)
izf. 0 Bs
izh.0 Bs
izj. 0 Bs
izl. 0 Bs
izn.
0
izo.Costos de Adiestramiento
izq.Taller GRAY WATCH
izs. Curso UML
izu.Curso Adobe Dreamweaver CS6
Bs
izp.Valor
(Bs.)
izr. 0 Bs
izt. 0 Bs
izv.0 Bs
389
izw.
Taller SmartDraw
izy.Total costos de adiestramientos:
jaa.
izx.0 Bs
izz.0 Bs
jab.
jac.
jad.
jae.
jaf. Compaa Annima Nacional Telfonos de Venezuela
jah.
jag.Cuadro 124. (Cont.).

Costos de Materiales
jaj. Papel tipo carta (5 resmas x 65 Bs)

jal. Papel tipo oficio (2 resmas x 85 Bs)
jan.CD-ROM (11 unidades x 8 Bs)
jap.Recarga sistema de kmpresin (8 unidades x
50 Bs)
jar. Unidad USB / Pendrive (2 x 80) Bs
jat. Carpetas tipo carta (5 unidades x 2 Bs)
jav.Carpetas tipo oficio (4 unidades x 2 Bs)
jax.Lapiceros (3 unidades x 5 Bs)
jaz.Lpiz de minas carbn (4 unidades x 3 Bs)
jbb.
Fotocopias (487 x 1 Bs)
jbd.
Pega de barra (2 unidades x 12 Bs)
jbf. Corrector (1 x 12 Bs)
jbh.
Otros
jbj.Total costos de materiales:
jbl.Total Costos de Produccin:
jai. Valor
(Bs.)
jak.325
jam. 170
jao.88
jaq.400
jas. 160
jau.10
jaw.
8
jay.15
jba.12
jbc.487
jbe.24
jbg.
12
jbi. 220
jbk.
193
jbm.
1
193
1
jbn.
5.5.2 Beneficios
jbo.
390
jbp. Los beneficios son las mejoras o ventajas asociadas al desarrollo del
proyecto. Estos se clasifican en beneficios tangibles o beneficios intangibles.
jbq.
jbr.
Beneficios Tangibles: estos beneficios o ventajas se caracterizan por ser
posible la cuantificacin de los mismos una vez que el sistema sea incorporado dentro
de los procesos, es decir, son las oportunidades que se obtienen una vez que se inicia
jbs.Compaa Annima Nacional Telfonos de Venezuela
jbt. el uso del sistema. En este sentido el presente proyecto, basado en una
ingeniera de requisitos, permitir el diseo y construccin de una
aplicacin empresarial que generar los siguientes beneficios tangibles
de forma directa:
jbu.
1. Ejecucin de los procesos de instalacin y reparacin de averas ms eficientes,
incorporando mejores modelos operativos y prcticas de negocios mediante la
aplicacin de herramientas tecnolgicas que permitan a la empresa colocarse a
la vanguardia del mercado en el que se desenvuelve y sobresalir entre sus
competidores.
2. Aumento de la productividad del personal, optimizando el uso del recurso
humano,
eliminando
retrasos
en
los
procesos
la
dependencia
interdepartamental que limitaba el trabajo realizado por el personal de planta

externa.
3. Manejo eficiente de los recursos para los procesos de instalacin y reparacin
de averas.
4. Disponibilidad de informacin en lnea, confiable, que facilite gestionar e
impulsar eficazmente los procesos empresariales.
391
5. Disminucin del tiempo empleado en la bsqueda de informacin y datos

tcnicos asociados a los abonados.
6. Obtencin de informacin oportuna en forma ms rpida y segura.
7. Integracin de la informacin entre las diferentes reas de la empresa.
8. Reduccin de costos en tiempos de llamadas.
9. Optimizacin de los procesos de instalacin y reparacin de averas.
jbv.
jbw.

jbx. Beneficios Intangibles: son todos aquellos beneficios o ventajas

adquiridas por la empresa pero que debido a su naturaleza no pueden ser
cuantificados. Sin embargo, brindan grandes oportunidades y ventajas a la
organizacin una vez que el proyecto sea ejecutado. En el caso de los beneficios
intangibles, se tienen los siguientes:
jby.
1. Precisa y un acceso ms rpido a los datos para tomar decisiones oportunas.
2. Aumento del conocimiento del personal en relacin a los procesos del negocio.
3. Mejora la respuesta del cliente.
4. Aumento de la satisfaccin del cliente y suscriptores del servicio.
5. Incremento de la transparencia organizativa funcional.
6. Visualizacin de los aspectos crticos que presenta la unidad de conmutacin..
7. Captacin de los requerimientos de los usuarios del negocio de la unidad de
conmutacin.
8. Motivacin del personal al utilizar herramientas modernas que le permitan
eliminar tareas rutinarias o tediosas.
392
9. La calidad del servicio aumentara.
jbz.
CONCLUSIONES
jca.
jcb. Como producto de cada etapa concluida y de la ejecucin de las
diferentes actividades programadas a travs de la metodologa utilizada, se
originaron una serie de resultados que sin lugar a dudas permiten llegar a
diferentes conclusiones:
1. Desde que fueron iniciadas las actividades dentro de la unidad de conmutacin
(CX) de la central digital Maturn-centro, se dio inicio a un riguroso proceso de
diagnstico, el cual permiti detectar diversas fallas o debilidades dentro de la
ejecucin de los procesos de este departamento, focos problemticos que dejan
abierta una brecha que causa vulnerabilidad a la unidad en relacin al
cumplimiento eficiente de sus actividades y procesos. Por tal razn fueron
estudiadas las posibles causas a estas debilidades dejando clara la necesidad de
documentar el funcionamiento ideal de los procesos y la construccin de una
aplicacin empresarial que pueda gestionar informacin en los procesos de
instalacin y reparacin de averas con la finalidad de optimizar dichos
procesos.
2. Como resultado de la aplicacin de las tcnicas de recoleccin de datos, se
encontr que los empleados que forman parte del personal de planta externa se
ven en la necesidad de contactar va telefnica de manera constante a
empleados que se encuentren dentro de las instalaciones de la central, y cuenten
con acceso a la base de datos, para solicitar informacin requerida en los
procesos de instalacin y reparacin de averas por no contar con una aplicacin
empresarial que les permita consultar y gestionar la informacin de forma ms
eficiente.
3. La etapa dedicada al modelado del negocio permiti incrementar el nivel de
comprensin del sistema bajo estudio, a travs de diferentes modelos que tienen
por objetivo representar, de forma precisa y detallada, aspectos propios de la
393
394
jcc. organizacin, como sus objetivos, reglas, normativas y procesos.

Asimismo, el modelado logro plasmar dentro de cada proceso, los actores
responsables de los mismos, los objetos de negocio, eventos y las relaciones
entre cada uno de ellos.
4. Respecto al levantamiento de los requisitos, estos fueron identificados en base
a las necesidades fundamentales que debern ser solventadas a travs de la
construccin de la aplicacin empresarial. En este sentido, fueron capturados
los diferentes requisitos mediante las planillas volere, las cuales permitieron
describir, analizar y relacionar los requisitos funcionales y no funcionales de
forma sencilla, eficaz y ordenada.
5. En cuanto a la ingeniera de requisitos, una vez que los requisitos fueron
recolectados, fue posible depurar la lista de requisitos, eliminando alguno que
haya sido considerado innecesario o adicionando algn otro. Todo esto con la
intencin de establecer las funcionalidades especficas que deber contener la
aplicacin empresarial como producto de la ingeniera de requisitos y
desarrollar el prototipo del sistema de software que se propone para ser
incorporado en los procesos de instalacin y reparacin de averas.
6. Dado que los empleados adscritos al departamento de planta externa realizan
sus funciones laborales desde zonas forneas a las instalaciones de la compaa,
se hace necesario el manejo de un dispositivo mvil con requerimientos
mnimos de manera que soporte el levantamiento del sistema va web.
7. De forma general, en base a la propuesta planteada como solucin a los
principales problemas detectados en la unidad de conmutacin (CX), se
desarroll la ingeniera de requisitos completa, junto con el prototipo de la
aplicacin y el anlisis costos beneficio referente a la ejecucin del proyecto.
jcd.
RECOMENDACIONES
jce.
1. Continuar apoyando las estrategias ligadas al uso y desarrollo de sistemas de
informacin que permitan seguir impulsando el desarrollo de la compaa y el
avance tecnolgico en materia de telecomunicaciones e informtica,
manteniendo el liderazgo que ha caracterizado a la empresa en su ramo.
2. Ejecutar proyectos basados en estudios tcnicos de anlisis de negocio en otras
sedes de la empresa, abarcando nuevas regiones y redes, a fin de identificar,
detectar y atacar cualquier vulnerabilidad o falla que haya sido diagnosticada a
nivel de procesos, el modelado de negocio, tal como se aplic a este estudio,
contribuy en este tipo de situaciones.
3. Evaluar los niveles actuales de rendimiento del personal en los procesos de
instalacin y reparacin de averas, con la finalidad de justificar la ejecucin de
este proyecto.
4. Respaldar la construccin de la aplicacin empresarial propuesta como sistema
para la gestin de informacin en los procesos de instalacin y reparacin de
averas, en respuesta inmediata a la carencia de un sistema de software que
agilice dichos procesos. De esta manera se incrementar la interoperabilidad, el
acceso a la informacin y la eficiencia, disminuyendo otros factores como
retrasos en los procesos y probabilidad de errores.
5. Realizar labores de entrenamiento y capacitacin del personal que labora en la
unidad de conmutacin (CX) y planta externa, respecto a la correcta ejecucin
de los procesos y las normativas que los rigen.
6. Actualizar la base de datos de los gestores que contienen toda la informacin
tcnica de los abonados, con la intencin de evitar irregularidades durante la
realizacin de los procesos, tales como inconsistencia e incongruencia de datos.
322
jcf.
BIBLIOGRAFA
jcg.
jch. Abreu, M. (2007). Modelo de Negocios del Departamento Tcnico de la
Direccin de Servicios Generales de la Universidad de los Andes. Tesis de grado,
Ingeniera de Sistemas. Universidad de los Andes. Mrida, Venezuela.
jci.
jcj. Arias, F. (2006). El proyecto de investigacin: Introduccin a la metodologa
cientfica. (5 ed.) Caracas - Venezuela: Episteme.
jck.
jcl. Balestrini Acua, M. (2002). Cmo se Elabora el Proyecto de Investigacin.
(6a. Ed.). Caracas: BL Consultores Asociados.
jcm.
jcn. Brrientos, Enrquez (2005). El desarrollo de sistemas de informacin
empleando el lenguaje de modelado unificado UML. Documento en lnea.
Disponible
en
http://www.monografias.com/trabajos16/lenguaje-modelado-
unificado/lenguaje-modelado-unificado.shtml#PRINCIP.
[Consultado
2011,
Diciembre].
jco.
jcp. Bch, Grady Et Al (1999). El lenguaje Unificado de Modelado, Primera Edicin,
Editorial Addison Wesley.
jcq.
jcr.
C.A.N.T.V. Escritorio Interno Digital, Internet de C.A.N.T.V.
Disponible: http://cired.cantv.com.ve. [Consultado 2011, Octubre].
jcs.
jct.
Cedeo, L. (2010). Implementacin de un sistema automatizado que optimice
la gestin de los procesos administrativos del rea servicios mdicos de la

Universidad de Oriente Ncleo Monagas. Trabajo Especial de Grado realizado
para obtener el ttulo de Ingeniero de Sistemas en la Universidad de Oriente,
Ncleo Monagas
323
324
jcu. Constitucin de la Repblica Bolivariana de Venezuela (1999). Gaceta Oficial

de la Repblica Bolivariana de Venezuela. N 36.860.
jcv.
jcw. Garca, Y. (2011). Desarrollo de un software empresarial para la automatizacin
de los indicadores de gestin del departamento de programacin de la
superintendencia de mantenimiento operacional plantas de proceso adscrito a la
gerencia de produccin PDVSA, distrito morichal. Trabajo de Grado realizado
para obtener el ttulo de Ingeniero de Sistemas en la Universidad de Oriente,
Ncleo Monagas
jcx.
jcy. Hernndez Sampieri, Roberto (2001) Metodologa de la Investigacin.
McGraw- Hill Editores. Mxico.
jcz.
jda. IEEE (2005). ISO 9126: The software Product Evaluation Standard.
Dsiponible:
http://www.angelfire.com/nt2/softwarequality/ISO9126.pdf.
[Consultado 2012, Enero].

jdb.
jdc. Ingeniera Bsica de Planta Externa. Centro de Estudios de Telecomunicaciones.
Material de Estudio Interno de la Empresa C.A.N.T.V.
jdd.
jde. Jacobson, I., Booch, G. & Rumbaugh, J. (2000). El Lenguaje Unificado de
Modelado. Madrid: Pearson Addison Wesley.
jdf.
jdg. Kendall E. y Kendall J. (2005). Anlisis y Diseo de Sistemas. Sexta Edicin.
Mxico: Pearson Educacin S.A.
jdh.
jdi. Kuhlman F. y Alonso A. (2003). Informacin y Telecomunicaciones.
Disponible:http://bibliotecadigital.ilce.edu.mx/sites/ciencia/volumen3/ciencia3/14
9/htm/informac.htm. [Consultado 2011, Noviembre].
jdj. Manual de Operacin y Mantenimiento de las Centrales NEAX 61E. Material de
Estudio Interno de la Empresa C.A.N.T.V.
jdk.
jdl. Manual del Mdulo de Provisin de Servicio (2002). Material de Estudio
Interno de la Empresa C.A.N.T.V.
jdm.
325
jdn.
Martin, F. Y Kendall S. (1999). "UML Gota a Gota. 1era Edicin.
jdo.
jdp. Mata, V. (2010). Modelado de Negocios y procesos operacionales de la
gerencia de plantas de gas y agua del distrito norte de Pdvsa Exploracin y
Produccin Oriente. Trabajo Especial de Grado realizado para obtener el ttulo
de Ingeniero de Sistemas en la Universidad de Oriente, Ncleo Monagas
jdq.
jdr. Milano C. (2010). Diseo e Implantacin de una herramienta de sistema NGN
para optimizar el proceso de gestin del software en Cantv estado
Monagas.Trabajo de grado. Universidad Nacional Experimental Politcnica de la
Fuerza Armada Nacional. Tucupita, Venezuela.
jds.
jdt. Montilva J. (2004). Desarrollo de Aplicaciones Empresariales.
El
Mtodo
Watch.
Disponible:
http://es.scribd.com/doc/57229693/Metodo-
WATCH-de-Prof-Jonas-Montilva. [Consultado 2011, Agosto].

jdu.
jdv. Montilva J. y Barrios J. (2007). Desarrollo de Software Empresarial.
Disponible:
http://es.scribd.com/doc/48005028/METODO-WATCH-2006.
[Consultado 2011, Agosto].

jdw.
jdx.
Montilva J., Barrios J. y Rivero M. (2008). GRAY WATCH
Mtodo de Desarrollo de Software para Aplicaciones Empresariales.
jdy.
jdz.
Normas y Procedimientos Gerencia General Tecnologa y
Operaciones. Centro de Estudios de Telecomunicaciones. Material de Estudio
Interno de la Empresa C.A.N.T.V.
jea.
jeb. Normativa General Interna de la Unidad de Conmutacin (CX). Centro de
Estudios de Telecomunicaciones. Material de Estudio Interno de la Empresa
C.A.N.T.V.
jec.
jed. Pastor, J. (s.f). Usos de los sistemas de informacin en la organizacin. Editorial
UOC, p.10.
jee.
326
jef.
Pressman R. (2002). Ingeniera del software un enfoque prctico. (5ta. Ed).
Mxico: Mc. Graw Gill.

jeg.
jeh. Real Academia Espaola (2001) Diccionario de la lengua espaola, 22.
edicin. Madrid: Espasa Calpe. [Edicin en CD-Rom de la 22. ed., Madrid,
Espasa Calpe, 2003] [Disponible: http://www.rae.es].
jei.
jej. SABINO, C. (2000). El Proceso de la Investigacin. Venezuela:
Panapo.
jek.
jel.
Salazar, C. (2006). Especificacin y Evaluacin de alternativas de software
para el departamento de repuestos de ALMARCA. Tesis de grado de la

especialidad de Ingeniera de Sistemas de la Universidad de los Andes Mrida.
jem.
jen. Sarabia, K. (2011). Ingeniera de requisitos para procesos de ejecucin de
estrategias de mercadeo (Impulsos y Fachadas), coordinacin de desarrollo en el
punto de venta Cervecera Polar C.A territorio comercial oriente sur. Trabajo
Especial de Grado realizado para obtener el ttulo de Ingeniero de Sistemas en la
Universidad de Oriente, Ncleo Monagas
jeo.
jep. Senn, J. (1992). Anlisis y Diseo de Sistemas de Informacin. (2da. ed).
Mxico: Mc. Graw Gill.
jeq.
jer. Serrano G. (1996). Ingeniera de Sistemas de Software. Primera Edicin.
Madrid: Isdefe.
jes.
jet. Sommerville I. (2005). Ingeniera del Software. Sptima Edicin. Madrid:
Pearson Educacin S.A.
jeu.
jev. Universidad Pedaggica Experimental Libertador (2002). Introduccin a la
Investigacin. Caracas: UPEL-IMPM.
jew.
327
jex. Whitten, J., Blentley. L. & Barlow, V. (1996). Anlisis y Diseo de Sistemas de
Informacin. (3ra. ed). Mxico: Mc. Graw Gill.
jey.
jez.
jfa.
jfb.
jfc.
jfd.
jfe.
jff.
jfg. ANEXOS
328
jfh.
Universidad de Oriente
Ingeniera de Sistemas
Maturn/Monagas/Venezuela
jfi. Anexo 1. Modelo de Entrevista.
jfj. Entrevista N 1:
jfk.
jfl. Objetivo de la Entrevista: Indagar el nivel de conocimiento que
poseen los empleados de planta externa en relacin con los proceso de
instalacin y reparacin de averas y evaluar el funcionamiento de dicho
proceso en materia de rendimiento y eficiencia.
jfm.
jfn.Entrevistados:
Tcnicos Instaladores.
Tcnicos Reparadores de Averas Telefnicas.
Tcnicos en Telecomunicaciones.
Jumperos.
jfo.
jfp.Instrucciones:
Las preguntas sern realizadas a los diferentes tcnicos que intervienen en el

proceso en base a las funciones que stos desempeen dentro del mismo.
Ser considerado el tiempo de ingreso del entrevistado al momento de ser

entrevistado, sin embargo, las preguntas irn tomando forma segn el matiz que
vaya tomando la entrevista.
La gua est elaborada de forma semiestructurada, por lo tanto no todas las

preguntas se encuentran consignadas en dicho documento.
jfq.
jfr. Gua de Preguntas:
jfs.
Conoce usted la finalidad de los procesos de instalacin y reparacin de

averas?
Ha tenido la oportunidad de chequear los manuales de operaciones que rigen

dicho proceso?
Considera usted que las instalaciones y reparaciones de averas son una tarea
fcil, rpida y sencilla de realizar?
En lo personal. Cumple usted con la ejecucin de la totalidad de las rdenes de

trabajo que se le son asignadas diariamente?
Cmo considera su rendimiento laboral?
Podra mencionar 3 ventajas y 3 desventajas que implica la ejecucin de los

procesos de instalacin y reparacin de averas?
Existen procesos dentro de la compaa ms sencillos de realizar que los que

involucran las instalaciones y reparaciones de averas?
jft.
jfu.
jfv.
jfw.
jfx.
jfy.
jfz.
jga.
jgb.
jgc.
Universidad de Oriente
Ingeniera de Sistemas
Maturn/Monagas/Venezuela
jgd.
Anexo2. Modelo de Entrevista.
jge. Entrevista N 2:
jgf.
jgg.
Objetivo de la Entrevista: Examinar levemente el nivel de
aceptacin/resistencia de los empleados ante un cambio en los procesos
de instalacin y reparacin de averas.
jgh.
jgi. Entrevistados:
Tcnicos Instaladores.
Tcnicos Reparadores de Averas Telefnicas.
Tcnicos en Telecomunicaciones.
Jumperos.
jgj.
jgk.
Instrucciones:
Las preguntas sern realizadas a los diferentes tcnicos que intervienen en el

proceso en base a las funciones que stos desempeen dentro del mismo.
Ser considerado el tiempo de ingreso del entrevistado al momento de ser

entrevistado, sin embargo, las preguntas irn tomando forma segn el matiz que
vaya tomando la entrevista.
La gua est elaborada de forma semiestructurada, por lo tanto no todas las

preguntas se encuentran consignadas en dicho documento.
jgl.
jgm.
jgn.
Gua de Preguntas:
Considera usted que los procesos de instalacin y reparacin de averas

podran ser optimizados en cuanto a ejecucin se refiere?
Sera capaz usted de mencionar, dentro de dichos procesos, al menos un punto

crtico que debiera ser atendido en funcin de alguna mejora?
Usted en lo personal, se le dificulta adaptarse a los cambios?
Ve usted a la tecnologa como una aliada o como una enemiga?
De existir algn proyecto que proponga optimizar los procesos de instalacin y

reparacin de averas, Tendra usted algn motivo para abstenerse al cambio o
a no formar parte de este?
jgo.
jgp.
jgq.
jgr.
jgs.
jgt.
jgu.
jgv.
jgw.
jgx.
jgy.
jgz.
jha.
jhb.
jhc.
jhd.
jhe.
jhf.
jhg.
HOJAS METADATOS
Hoja de Metadatos para Tesis y Trabajos de Ascenso - 1/6

jhi.
jhh.
Ttul
o
jhk.
Subt
it
u
l
o
jhj.INGENIERA DE REQUISITOS APLICADO A

LOS PROCESOS DE INSTALACIN Y
REPARACIN DE AVERAS, REALIZADOS
POR PLANTA EXTERNA PARA LA UNIDAD
DE CONMUTACIN (CX) DE LA CENTRAL
DIGITAL MATURN-CENTRO, C.A.N.T.V.
ESTADO MONAGAS.
jhl.
jhm.
jhn.
El Ttulo es requerido. El subttulo o ttulo alternativo es
opcional.
jho. Autor(es)
jhp.
Apellidos y
Nombres
jhq.
jht.
C
jhr.
jhs.
Ruiz, Oscar J.
jhu.
C.I. 18.754.110
jhw.
e jhx. oscar406@.hotmail.com
jhz.
e
jib.
Cdigo CVLAC / e-mail
jia. oscar406@gmail.c
om
jic. Se requiere por lo menos los apellidos y nombres de un autor. El formato para
escribir los apellidos y nombres es: Apellido1 InicialApellido2., Nombre1
InicialNombre2. Si el autor est registrado en el sistema CVLAC, se anota el
cdigo respectivo (para ciudadanos venezolanos dicho cdigo coincide con el
nmero de la Cedula de Identidad). El campo e-mail es completamente
opcional y depende de la voluntad de los autores.
jid.
Palabras o frases claves:

jie. Ingeniera de requisitos
jif. Gray Watch
jig. Aplicacin empresarial
jih. Cantv
jii.
jij. El representante de la subcomisin de tesis solicitar a los miembros del jurado la lista
de las palabras claves. Deben indicarse por lo menos cuatro (4) palabras clave.
jik.
jil.
jim.
jin.Lneas y sublneas de investigacin:
jio.rea
jip.Sub-rea
jir. Ingeniera de Sistemas
jiq. Tecnologa (Ciencias
Aplicadas)
jit.
jiv.
jix.
jiw.
jiz.
jjb.
jjc. Debe indicarse por lo menos una lnea o rea de investigacin y por cada rea
por lo menos un subrea. El representante de la subcomisin solicitar esta
informacin a los miembros del jurado.
jjd.Resumen (Abstract):
jje. El objetivo principal del trabajo de grado que se presenta a continuacin
consiste en el desarrollo de los procesos tcnicos de anlisis
propuestos por la metodologa Gray Watch, los cuales comprenden el
modelado del negocio o dominio de la aplicacin y el de ingeniera de
requisitos. Este ltimo, orientado a la especificacin de los requisitos
que debe satisfacer el sistema empresarial propuesto para la gestin de
informacin en los procesos de instalacin y reparacin de averas,

realizado por planta externa para la unidad de conmutacin (CX) de la
central digital Maturn-Centro. Esta aplicacin se plantea para ser
incorporada a uno de los procesos vitales de la compaa, permitiendo
gestionar el acceso y manipulacin de datos mediante tecnologas de
informacin, garantizando elevados ndices de rendimiento a nivel de
personal y de procesos. La investigacin es de tipo proyectiva, de nivel
comprensivo y de diseo de fuentes mixtas. Fueron utilizadas para la
recoleccin de datos la revisin documental, la entrevista y la
observacin como mecanismos de registro de informacin, siendo
estudiadas mediante la tcnica de anlisis de contenido. El patrn de
trabajo fue el propuesto por el mtodo Watch en conjunto con el
Lenguaje Unificado de Modelado (UML). En general, esta investigacin
plasma la solucin basada en la construccin de un sistema
desarrollado bajo ambiente web al que los empleados de planta externa
puedan acceder desde zonas forneas, y como base a esta necesidad,
todo el fundamento de ingeniera que sustenta dicha propuesta.
jjf. Hoja de Metadatos para Tesis y Trabajos de Ascenso - 3/6

jjg.Contribuidores:
jjh. Apellidos y
jji. Cdigo CVLAC / e-mail
Nombres
jjj.
jjm. jjn. C
jjo. A jjp. T jjq. J
jjk. Nez Q.,
R
A
S
U
U
Yhuanailys
Del V.
jjs.
jjl.
C
jjt. C.I 16.699.296
jjv.
e-
jjw.yhuanunez@gmail.com
jjy.
e-
jjz.
jkc. jkd. C
A
R
jka.
jkb.
jki.
C
Rond
n R.,
Wendy J.
jkl.
ejko.
e-
jke.
A
jkr.
Anderi
co N.,
Desiree
Del V.
jkg.
J
jkj. C.I 13.767.220

jkm. wendyrondon1@gm
ail.com
jkp.
jks. jkt. C
A
R
jkq.
jkf.
T
jku.
A
jkv.
T
jky.
C
jkz.
jlb.
e-
jlc. danderico@udo.edu.ve
jle.
e-
jlf.
C.I 11.781.658
jkw.
J
jli. jlj. C
A
R
jlg. Vivenes
O., Nelsy
E.
jlh.
jlk.
A
jll.
T
jlo.
C
jlp.C.I 14.284.846
jlr.
e-
jls. nvivenes@udo.edu.ve
jlu.
e-
jlv.
jlm.
J
jlw. Se requiere por lo menos los apellidos y nombres del tutor y los otros dos (2)
jurados. El formato para escribir los apellidos y nombres es: Apellido1
InicialApellido2., Nombre1 InicialNombre2. Si el autor est registrado en el
sistema CVLAC, se anota el cdigo respectivo (para ciudadanos venezolanos
dicho cdigo coincide con el nmero de la Cedula de Identidad). El campo email es completamente opcional y depende de la voluntad de los autores. La
codificacin del Rol es: CA = Coautor, AS = Asesor, TU = Tutor, JU = Jurado.
jlx.
jly. Fecha de discusin y aprobacin:
jlz.
jma.
jmb.
A
M
D
jmc.
2
jmd.
1
jme.
1
jmf. Fecha en formato ISO (AAAA-MM-DD). Ej: 2005-03-18. El dato fecha es requerido.
jmg. Leng
jmh. Requerido. Lenguaje del texto discutido y aprobado, codificado
uaje:
usuando ISO 639-2. El cdigo para espaol o castellano es spa.
spa
El cdigo para ingles en. Si el lenguaje se especifica, se asume
que es el ingls (en).
jmi.
jmj.

Archivo(s):
jmk.
Nombre de archivo
jml.
OSCAR_JOSUE_RUIZ.
DOCX
jmm. Caracteres permitidos en los nombres de los archivos: A B C
DEFGHIJKLMNOPQRSTUVWXYZabcdefghi
jklmnopqrstuvwxyz0123456789_-.
jmn.
jmo.
jmp.
jmq.
jmr.
jms.
Alcance:
Espacial: __________________ (opcional)
Temporal: __________________ (opcional)
Ttulo o Grado asociado con el trabajo:
jmt. Ingeniero de Sistemas

jmu. Dato requerido. Ejemplo: Licenciado en Matemticas,
Magister Scientiarium en Biologa Pesquera, Profesor
Asociado, Administrativo III, etc
jmv. Nivel Asociado
con el trabajo:
jmw. Pre-Grado
jmx. Dato requerido. Ejs: Licenciatura, Magister, Doctorado, Postdoctorado, etc.

jmy.
rea de Estudio:
jmz.
Tecnologa (Ciencias Aplicadas)
jna. Usualmente es el nombre del programa o departamento.

jnb.
Institucin(es) que garantiza(n) el Ttulo o grado:
jnc. Universidad de Oriente Ncleo de Monagas

jnd. Si como producto de convenciones, otras instituciones adems de la
Universidad de Oriente, avalan el ttulo o grado obtenido, el nombre de estas
instituciones debe incluirse aqu.
jne.
jnf.
jng.
Hoja de metadatos para tesis y trabajos de Ascenso- 5/6
jnh.
jni.
jnj.
jnk.

Ruiz Oscar 004 R924

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ruiz Oscar 004 R924

Caricato da

Copyright:

Formati disponibili

UNIVERSIDAD DE ORIENTE

INGENIERA DE REQUISITOS APLICADO A LOS PROCESOS DE

Propuesta de Trabajo de Grado, Modalidad Pasanta, presentado como requisito

Br. Oscar Josu Ruiz

Maturn, Octubre de 2012

Se hace oportuno entonces mencionar al profesor Jess Chaparro, quien

COMISIN DE TRABAJOS DE GRADO

Cuadro 6. Descripcin de los Subprocesos del Proceso Modelado de Eventos del

Cuadro 48. Requisito Funcional N 3........................................................................238

Cuadro 91. Requisito No Funcional N 8..................................................................253

Diagrama 11. Diagrama de Proceso: Reinstalacin del Servicio..............................174

Diagrama 51. Diagrama de Clase Administrar Usuario............................................297

guardan la forma de hacer negocios con la administracin de la informacin y la

antecedentes de la investigacin que sirvieron de referencia a este estudio junto con la

telecomunicaciones, la C.A.N.T.V. ha logrado impulsar el buen vivir de todas y

1.2.1 El inicio de la era del cobre (1930-1952)

Telecomunicaciones, y se promulga la Ley de Telecomunicaciones que deroga la Ley

manera, el Estado venezolano inicia un proceso de adquisiciones de empresas

telefnicas que culmina con la compra de la Compaa de Telfonos de San Fernando

Telecomunicaciones, y luego se convirti en la Direccin de Telecomunicaciones del

creacin del Centro de Estudios para Tcnicos de Telecomunicaciones (CETT),

En octubre de ese mismo ao, se constituye la filial C.A. Venezolana de Guas

nuevos clientes en 1989 y elevar la densidad telefnica de 6 a 12 telfonos por cada

1.500.000 telfonos instalados.

Una demanda satisfecha de 47%.

1.2.3 De compaa de telfonos a corporacin de telecomunicaciones

En efecto, se construyen 1.981 kilmetros del ms importante proyecto de

Paralelamente, se introducen novedosos puntos de contacto con el cliente, como

En esta etapa se trabaja en el mercado de la banda ancha, de los contenidos y de

Con la construccin de ms de 6.609 kilmetros de Fibra ptica y la

Somos la empresa estratgica del estado venezolano operadora y proveedora de

1. Democratizar el servicio con justicia social: ampliando la cobertura geogrfica,

5. Avanzar hacia la soberana tecnolgica: la nueva C.A.N.T.V. apoyar la

Promover el uso responsable, claro y racional de los recursos pblicos que se

la contribucin como trabajadoras y trabajadores al desarrollo y

Comprometerse en el diseo, desarrollo, ejecucin, evaluacin y control de las

Atender con cordialidad, humanidad, rapidez y sentido de oportunidad los

Propiciar el intercambio de saberes con la sociedad, contribuyendo en el

1.7 ESTRUCTURA ORGANIZATIVA

Figura 1. Organigrama general de C.A.N.T.V.

1.8 ESTRUCTURA DEL DEPARTAMENTO

Figura 2. Organigrama de Gerencia Gral. Tecnologa y Operaciones.

Dentro de la Gerencia Red Estado Monagas, se encuentra

conmutacin, que para efectos de este proyecto, es considerada el objeto de estudio.

a. Coordinar y controlar los programas de operacin y mantenimiento de las

1.9.2 Funciones del departamento de conmutacin

a. Reducir el tiempo en las reparaciones e instalaciones y reparar las averas de las

2.1 PLANTEAMIENTO DEL PROBLEMA

h. La gestin de procesos es parte fundamental en la administracin

Hoy en da las organizaciones empresariales orientan la mayora de sus

esfuerzos en optimizar su desempeo, con la finalidad de mantener un nivel

deficiencias que stas presentan. Es por ello que constantemente en las

organizaciones se aplican mtodos de modelado, como el modelo de objetivos, el cual

innumerables aplicaciones desarrolladas en

funcin a requerimientos estrictamente identificados con el objetivo de contribuir con

mercados masivos. Haciendo un enfoque en el departamento gerencia general,

De igual manera hay que sealar que la unidad de conmutacin forma

parte de dos departamentos adicionales, que delimitan la ubicacin de los equipos y

ocupan de la revisin de pares en armarios ubicados en puntos estratgicos de la

La causa principal de todo esto es que los empleados adscritos al

departamento de planta externa, los cuales intervienen en los procesos de instalacin

acceder a la base de datos y suministrar la informacin necesaria para dar

Ahora bien, otro problema que se presenta en la unidad de conmutacin

De acuerdo con los razonamientos que se han venido realizando, se puede