Tesis de Grado Ingeniería de Sistemas - Richard Rodríguez Salazar

REPBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR

PARA LA EDUCACIN SUPERIOR
INSTITUTO UNIVERSITARIO POLITCNICO
SANTIAGO MARIO
EXTENSIN MRIDA
INGENIERA DE REQUISITOS PARA EL DESARROLLO DE UN

SISTEMA DE INFORMACIN EN LOS SERVICIOS ESTADALES
DE ATENCIN DE EMERGENCIAS
Trabajo Especial de Grado presentado como requisito parcial

para optar al Ttulo de Ingeniero de Sistemas
Autor: Rodrguez, Richard

Tutor Acadmico: Snchez, Yudit
Tutor Metodolgico: Briceo, Mximo
Mrida, Agosto de 2.010

APROBACIN DE LA TUTORA
En mi carcter de Tutora del Trabajo Especial de Grado titulado: INGE-

NIERA DE REQUISITOS PARA EL DESARROLLO DE UN SISTEMA DE
INFORMACIN EN LOS SERVICIOS ESTADALES DE ATENCIN DE
EMERGENCIAS, presentado por el ciudadano Richard Jos Rodrguez Sa-
lazar, Cdula de Identidad N V-11.360.777, para optar al Ttulo de Ingeniero
de Sistemas, considero que ste rene los requisitos y mritos suficientes
para ser sometido a presentacin pblica y evaluacin por parte del Jurado
Examinador que se designe.
En la ciudad de Mrida, a los veinte y seis (26) das del mes de Agosto
del ao dos mil diez (2.010).
Yudit Snchez
C.I. V-8.044.725
II
APROBACIN DEL ASESOR METODOLGICO
En mi carcter de Asesor Metodolgico del Trabajo Especial de Grado ti-

tulado: INGENIERA DE REQUISITOS PARA EL DESARROLLO DE UN
SISTEMA DE INFORMACIN EN LOS SERVICIOS ESTADALES DE
ATENCIN DE EMERGENCIAS, presentado por el ciudadano Richard Jos
Rodrguez Salazar, Cdula de Identidad N V-11.360.777, para optar al Ttu-
lo de Ingeniero de Sistemas, considero que ste rene los requisitos y mri-
tos suficientes para ser sometido a presentacin pblica y evaluacin por
parte del Jurado Examinador que se designe.
Mximo Briceo
C.I. V-8.011.554
III
SANTIAGO MARIO
EXTENSIN MRIDA
INGENIERA DE SISTEMAS

SISTEMA DE INFORMACIN EN LOS SERVICIOS
ESTADALES DE ATENCIN DE EMERGENCIAS
Trabajo Especial de Grado APROBADO en nombre del Instituto Universi-

tario Politcnico Santiago Mario, por el Jurado Examinador designado.
Ing. William Snchez Ing. Edgar Achong

C.I. V-8.030.372 C.I. V-11.463.585
Ing. Mayela Uzctegui

C.I. V-13.500.336
IV
DEDICATORIA
A mis padres, Aid y Ely Sal

para honrarlos en el cielo
V
Cielos nuevos y tierra nueva
Porque he aqu que yo creo cielos nuevos y tierra nueva.

No habr ms memoria de las cosas primeras,
ni vendrn ms al pensamiento.
Ms bien, gozaos y alegraos para siempre en las cosas que yo he creado.
Porque he aqu que yo he creado a Jerusaln para alegra,
y a su pueblo para gozo.
Yo me gozar por Jerusaln y me regocijar por mi pueblo.
Nunca ms se oir en ella la voz del llanto ni la voz del clamor.
No habr all ms bebs que vivan pocos das,
ni viejos que no completen sus das.
Porque el ms joven morir a los cien aos,
y el que no llegue a los cien aos ser considerado maldito.
Edificarn casas y las habitarn;
plantarn vias y comern de su fruto.
No edificarn para que otro habite,
ni plantarn para que otro coma;
porque como la edad de los rboles ser la edad de mi pueblo.
Mis escogidos disfrutarn plenamente de las obras de sus manos.
No se esforzarn en vano, ni darn a luz hijos para el terror;
porque sern linaje bendito de Jehovah,
y de igual manera sus descendientes.
Y suceder que antes que llamen, yo responder;
y mientras estn hablando, yo les escuchar.
El lobo y el cordero pacern juntos.
El len comer paja como el buey,
y la serpiente se alimentar de polvo.
No harn dao ni destruirn en todo mi santo monte,
dijo Jehovah
Isaas 65:17-25
VI
AGRADECIMIENTOS
A mi Dios, que me ha dado la fuerza, felicidad, salud y paz.
A mi mam, que diste todo por m hasta que te fuiste.

Siempre te extraar, muacatia. Bendicin!
A mi pap, a quien no conoc porque temprano se fue con Dios;

pero hiciste todo para que tu familia, estuviera por siempre bien,
lo que lograste con xito. Bendicin!
A m esposa Marta, quien lleg para quedarse hasta ser viejitos. I love you.
A toda mi familia, que nunca dejaron de creer en m.
Al Politcnico Santiago Mario, y sus Profesores, en donde

pude obtener mi anhelada profesin
A las Profesoras Yudit, Alexis, Alix y al Profesor Mximo,

excelentes Profesores que me ayudaron enormemente.
A mis amigos y compaeros de trabajo,

que han sido siempre muy solidarios. Gracias.
VII
NDICE GENERAL
P.p.
LISTA DE CUADROS ................................................................................. XII
LISTA DE FIGURAS .................................................................................. XIV
RESUMEN ................................................................................................. XVII
INTRODUCCIN ............................................................................................ 1
CAPTULO I: EL PROBLEMA ....................................................................... 5
Contextualizacin del problema .................................................................. 5
Objetivo general.......................................................................................... 8
Objetivos especficos .................................................................................. 8
Justificacin de la investigacin .................................................................. 8
CAPTULO II: MARCO REFERENCIAL ...................................................... 10
Resea histrica del problema ................................................................. 10
Antecedentes de la investigacin ............................................................. 12
Bases tericas .......................................................................................... 14
Servicio de Atencin de Emergencias (SAE) ....................................... 14
Sistemas de informacin ...................................................................... 20
Bases de datos ..................................................................................... 22
Modelado de datos ............................................................................... 23
Modelo Entidad-Relacin (E-R) ............................................................ 23
Ingeniera de software .......................................................................... 27
Modelos de Ingeniera de software....................................................... 28
Metodologa de proceso unificado de Racional (RUP) ......................... 29
Modelado de negocios ......................................................................... 32
Ingeniera de requisitos ........................................................................ 34
Lenguaje unificado de modelado (UML) ............................................... 36
Bases Legales ...................................................................................... 39
Sistemas de variables de la investigacin ............................................ 45
VIII
Variable dependiente............................................................................ 45
Variable independiente ......................................................................... 46
Definicin de trminos bsicos ............................................................. 46
CAPTULO III: MARCO METODOLGICO ................................................. 50
Modalidad de investigacin ...................................................................... 50
Tipo de investigacin ................................................................................ 51
Fases de la investigacin ......................................................................... 51
Operacionalizacin de variables ............................................................... 54
Poblacin y muestra ................................................................................. 55
Tcnicas e instrumentos de recoleccin de datos .................................... 56
Tcnicas de anlisis ................................................................................. 58
Tcnicas de anlisis cuantitativas ........................................................ 58
Tcnicas de anlisis cualitativas........................................................... 59
CAPTULO IV: RESULTADOS .................................................................... 60
Diagnstico del SI del SAE 171 Mrida ................................................ 60
Observacin directa ....................................................................... 61
Entrevistas ..................................................................................... 62
Anlisis e interpretacin de los resultados ........................................... 73
Presentacin y discusin de los resultados.............................................. 75
Modelado de datos del SIAE .......................................................... 77
Documento de Definicin de requisitos (DDR) ............................... 77
Ingeniera de requisitos del SIAE ................................................... 79
Propuesta del proyecto ......................................................................... 81
Documento de Definicin de Requisitos (DDR) .................................... 83
1. Introduccin................................................................................ 86
2. Informacin general.............................................................................. 87
2.1. Sistema de Informacin para la Atencin de Emergencias ........... 87
2.2. Mdulos de SIAE .............................................................................. 87
2.3. Objetivo general ................................................................................ 91
IX
2.4. Objetivos especficos ........................................................................ 91
2.5. Alcance .............................................................................................. 91
2.6. Delimitacin ....................................................................................... 92
3. Ingeniera de requisitos (IR)................................................................. 93
Documento de Requisitos de Usuario (DRU)................................................ 95
3.1. Documento visin: Modelado de negocios (MN)............................ 96
3.1.1. Objetivos del sistema de negocios ....................................... 96
3.1.1.1. Misin ................................................................................ 97
3.1.1.2. Visin ................................................................................ 97
3.1.2. Procesos del negocio ........................................................... 98
3.1.2.1. Cadena de valor ................................................................ 98
3.1.2.2. Procesos vitales ................................................................ 99
3.1.3. Objetos del sistema de negocio ......................................... 103
3.1.4. Actores/unidades organizacionales .................................... 104
3.1.5. Regla de negocios ............................................................. 107
3.2. Especificacin de requisitos de usuario ................................. 107
Documento de Requisitos de Sistema (DRS) ............................................. 112
3.3. Especificacin de requisitos de sistema ................................ 113
3.4. Desarrollo de la baseline de la arquitectura ................................ 121
3.5. Construccin del producto..................................................... 153
3.5.1. Modelado de datos ............................................................. 153
3.5.1.1. Diccionario de datos ........................................................ 153
3.5.1.2. Diagrama de clases......................................................... 164
3.5.1.3. Modelo de datos Entidad-Relacin (E-R) ........................ 164
3.5.2. Modelo de dominio ............................................................. 164
3.5.3. Mapa de comportamiento a nivel de hardware .................. 167
3.6. Producto final ................................................................................... 170
3.6.1. Plan de gestin de desarrollo ...................................................... 175
3.6.1.1. Factibilidad social ...................................................................... 175
X
3.6.1.2. Factibilidad tcnica.................................................................... 176
3.6.1.3. Factibilidad de Recursos humanos ................................. 178
3.6.1.4. Factibilidad econmica ............................................................. 179
CONCLUSIONES ....................................................................................... 185
RECOMENDACIONES ............................................................................... 189
REFERENCIAS .......................................................................................... 191
Bibliogrficas .......................................................................................... 191
No Bibliogrficas ..................................................................................... 193
Electrnicas ............................................................................................ 194
ANEXOS ..................................................................................................... 196
Anexo A: Hoja de observacin aplicada al SAE Mrida ........................ 197
Anexo B: Cuestionario de Preguntas al personal del SAE Mrida: ....... 199
RESUMEN CURRICULAR DEL AUTOR ................................................... 204
XI
LISTA DE CUADROS
Cuadro P.p.
Cuadro 1: Vistas y diagramas de UML ........................................................ 35
Cuadro 2: Fases del Trabajo de Investigacin ...................................................... 52
Cuadro 3: Tabla de operacionalizacin de las variables .............................. 54
Cuadro 4: Poblacin y espacio muestral del SAE 1-7-1 .............................. 55
Cuadro 5: Tcnicas e Instrumentos de Recoleccin de Datos .................... 57
Cuadro 6: Existencia de Sistema de Informacin ........................................ 63
Cuadro 7: Operatividad del Sistema de Informacin actual ......................... 64
Cuadro 8: Fallas del Sistema de Informacin actual .................................... 65
Cuadro 9: Necesidad de un nuevo Sistema de Informacin ........................ 66
Cuadro 10: Objetivos del nuevo Sistema de Informacin ............................ 67
Cuadro 11: Funciones que debe tener el nuevo Sistema de Informacin .... 68
Cuadro 12: Instituciones que deben incorporarse al nuevo SI ..................... 69
Cuadro 13: Condicin de la tecnologa existente ......................................... 70
Cuadro 14: Tecnologa a incorporar al nuevo Sistema de Informacin ....... 71
Cuadro 15: Tecnologa a modernizar del nuevo Sistema de Informacin .... 72
Cuadro 16: Matriz FODA del SI del SAE 1-7-1 Mrida ................................ 73
Cuadro 17: Anlisis cuantitativo de la matriz FODA .................................... 74
Cuadro 18: actores y unidades organizacionales del SIAE ....................... 105
Cuadro 19: Especificacin de requisitos de usuario .................................. 108
Cuadro 20: Requisitos de usuario: activar SIAE ........................................ 109
Cuadro 21: Requisitos de usuario: diversidad de mecanismos.................. 110
Cuadro 22: Requisitos de usuario: ampliar comunicaciones ..................... 111
Cuadro 23: Especificacin de requisitos de sistema .................................. 113
Cuadro 24: Requisitos de sistema: elaborar SIAE en software libre .......... 114
Cuadro 25: Requisitos de sistema: determinar ubicacin de llamadas ...... 115
Cuadro 26: Requisitos de sistema: advertir sobre llamadas de sabotaje ... 116
XII
Cuadro 27: Requisitos de sistema: agilizar atencin de llamadas ................ 117
Cuadro 28: Requisitos de sistema: acceder a datos de S.I.P.O.L. ............... 118
Cuadro 29: Requisitos de sistema: acceder a datos meteorolgicos......... 119
Cuadro 30: Requisitos de sistema: rastreo de unidades mviles............... 120
Cuadro 31: descripcin del diagrama de caso de uso del men principal ........ 124
Cuadro 32: descripcin del diagrama de caso de uso del mdulo
reportar emergencia ............................................................................................. 129
atender el reporte de una emergencia...................................................... 134
Cuadro 34: descripcin del diagrama de caso del mdulo auditar la
llamada de emergencia ............................................................................. 139
Cuadro 35: descripcin del diagrama de caso de uso del mdulo despachar
el servicio ................................................................................................... 144
Cuadro 36: descripcin del diagrama de caso de uso del mdulo atender
emergencia ................................................................................................ 149
Cuadro 37: Entidad: LlamadasEmergencia ............................................... 154
Cuadro 38: Entidad: Despachos ................................................................ 155
Cuadro 39: Entidad: AtencionEmergencia ................................................. 156
Cuadro 40: Entidad: Usuarios .................................................................... 157
Cuadro 41: Entidad: InstitucionesSeguridad .............................................. 158
Cuadro 42: Entidad: UnidadesAtencion ..................................................... 159
Cuadro 43: Entidad: Colaboradores........................................................... 160
Cuadro 44: Entidad: TipoEmergencia ........................................................ 161
Cuadro 45: Entidad: RegistrosDelictivos .................................................... 162
Cuadro 46: Entidad: GPS .......................................................................... 163
Cuadro 47: Factibilidad econmica sala central de servidores .................. 180
Cuadro 48: Factibilidad econmica plataforma tecnolgica 24 Estados .... 181
Cuadro 49: Factibilidad econmica recursos humanos ............................. 181
Cuadro 50: Resumen general de factibilidad econmica SIAE .................. 182
XIII
LISTA DE FIGURAS
Figura P.p.
Figura 1: Sala de Operadores del SAE Mrida ............................................ 18
Figura 2: Sala de Operadores del SAE Mrida ............................................ 18
Figura 3: Sala de Despachadores del SAE Mrida ...................................... 19
Figura 4: Sala de Despachadores del SAE Mrida ...................................... 19
Figura 5: Elementos de un Sistema de Informacin .................................... 21
Figura 6: Diagrama Entidad-Relacin .......................................................... 24
Figura 7: Ligadura de correspondencia uno a uno....................................... 25
Figura 8: Ligadura de correspondencia uno a varios. .................................. 25
Figura 9: Ligadura de correspondencia varios a uno. .................................. 26
Figura 10: Ligadura de correspondencia varios a varios ............................. 26
Figura 11: Esfuerzo en actividades segn fase del proyecto ....................... 31
Figura 12: Representacin grfica del cuadro 6 .......................................... 63
Figura 16: Representacin grfica del cuadro 10 ........................................ 67
Figura 23: Diagnstico del Sistema de Informacin actual .......................... 76
Figura 24: Esquema conceptual del Modelado de Datos del SIAE .............. 78
Figura 25: Esquema conceptual de la Ingeniera de Requisitos del SIAE ... 80
Figura 26: Esquema conceptual del DDR .................................................... 82
XIV
Figura 27: Estructura de la Ingeniera de Requisitos ................................... 94
Figura 28: Estructura del Modelo de Negocio .............................................. 96
Figura 29: Modelo de Objetivos del sistema de negocios ............................ 97
Figura 30: Cadena valor .............................................................................. 99
Figura 31: Proceso reportar una emergencia .......................................... 100
Figura 32: Proceso atender reporte de emergencia ................................ 101
Figura 33: Proceso despachar el servicio ................................................ 101
Figura 34: Proceso atender emergencia ................................................. 102
Figura 35: Procesos SIAE .......................................................................... 103
Figura 36: Modelado de reglas de negocio SAE ........................................ 107
Figura 37: Diagrama general de caso de uso del SIAE ...................................... 122
Figura 38: Diagrama de caso de uso del men principal.................................... 123
Figura 39: Diagrama de secuencia del men principal ....................................... 125
Figura 40: Diagrama de estados del men principal ........................................... 126
Figura 41: Diagrama de colaboracin del men principal................................... 127
Figura 42: Diagrama de caso de uso del mdulo reportar emergencia .......... 128
Figura 43: Diagrama de secuencia del mdulo reportar emergencia ............. 130
Figura 44: Diagrama de estados del mdulo reportar emergencia .......... 131
Figura 45: Diagrama de colaboracin del mdulo reportar emergencia .. 132
Figura 46: Diagrama de caso de uso del mdulo atender reporte de
emergencia............................................................................................................. 133
Figura 47: Diagrama de secuencia del mdulo atender reporte de
emergencia............................................................................................................. 135
Figura 48: Diagrama de estados del mdulo atender reporte emergencia..... 136
Figura 49: Diagrama de colaboracin del mdulo atender reporte de
emergencia............................................................................................................. 137
Figura 50: Diagrama de caso de uso del mdulo auditar llamada de
emergencia............................................................................................................. 138
Figura 51: Diagrama de secuencia del mdulo auditar llamada emergencia . 140
XV
Figura 52: Diagrama de estados del mdulo auditar llamada emergencia..... 141
Figura 53: Diagrama de colaboracin del mdulo auditar llamada de
emergencia............................................................................................................. 142
Figura 54: Diagrama detallado de caso de uso del mdulo despachar el
servicio.................................................................................................................... 143
Figura 55: Diagrama de secuencia del Mdulo despachar el servicio ............ 145
Figura 56: Diagrama de estados del Mdulo despachar el servicio ................ 146
Figura 57: Diagrama de colaboracin del Mdulo despachar el servicio ........ 147
Figura 58: Diagrama detallado de caso de uso del Mdulo atender
emergencia............................................................................................................. 148
Figura 59: Diagrama de secuencia del mdulo atender emergencia .............. 150
Figura 60: Diagrama de estados del mdulo atender emergencia.................. 151
Figura 61: Diagrama de colaboracin del mdulo atender emergencia ......... 152
Figura 62: Diagrama de Clase de la Base de Datos del SIAE ........................... 165
Figura 63: Diagrama E-R del SIAE ............................................................ 166
Figura 64: Diagrama de paquetes del SIAE ............................................... 167
Figura 65: Diagrama de despliegue (nivel de descriptor) del SIAE ............ 168
Figura 66: Diagrama de componentes del SIAE ........................................... 169
Figura 67: Procesos SIAE con actores ................................................................ 171
Figura 68: Diagrama de despliegue (nivel de instancia) del SIAE ................ 172
Figura 69: Esquema conceptual del SIAE ................................................. 173
XVI
SANTIAGO MARIO
EXTENSIN MRIDA
INGENIERA DE SISTEMAS

SISTEMA DE INFORMACIN EN LOS SERVICIOS
ESTADALES DE ATENCIN DE EMERGENCIAS
Lnea de Investigacin: Tecnologa Web, Modelado de Sistemas

Tutor Acadmico: Snchez, Yudit
Tutor Metodolgico: Briceo, Mximo
Mrida, Agosto de 2.010
RESUMEN
Esta investigacin confronta la problemtica existente en el Servicio de
Atencin de Emergencias de Venezuela, abordando el caso Estado Mrida,
debido a la ausencia de un software para tales fines, situacin presentada
ante el cambio de filosofa de aplicacin de tecnologas en Venezuela, las
cuales deben ser libres y no privativas; motivo por el cual se propone una
Ingeniera de Requisitos para el desarrollo de un Sistema de Informacin en
los Servicios Estadales de Atencin de Emergencias. La modalidad de inves-
tigacin utilizada es la de proyecto factible, y el tipo de investigacin que se
aplic es la descriptiva apoyada de la investigacin de campo. Para el desa-
rrollo de la propuesta final, se obtuvo el Documento de Definicin de Requisi-
tos (DDR), el cual consta del Documento de Requisitos de Usuario (DRU), y
el Documento de Requisitos de Sistema (DRS), para los cuales se aplic la
metodologa de desarrollo de Software denominada Proceso Unificado de
Racional RUP, mediante el uso del Lenguaje Unificado de Modelado
(UML), lo que permite a cualquier grupo de programadores, el desarrollo de
la aplicacin final en cualquier lenguaje de programacin.
Descriptores: Ingeniera de Requisitos, Sistema de Informacin, Servicios

Estadales de Atencin de Emergencias.
XVII
INTRODUCCIN
Un Sistema de Informacin en los Servicios de Atencin de Emergencias

de Venezuela, debe activarse al momento de que una persona desea que se
le ayude a resolver una emergencia presentada, para lo cual el servicio crea-
do para tal fin, debe funcionar como un mecanismo de coordinacin entre los
Organismos de Seguridad del Estado, a fin de acudir a los sitios de sucesos,
los ms rpido posible, sin muchas dilaciones, salvando vidas, evitando
agravamientos de emergencias, tragedias y muertes innecesarias por retar-
dos de servicios; lo que se traducira en la disminucin de los ndices de in-
seguridad.
Se abord el caso Estado Mrida, con estudios realizados hasta el mes
de diciembre del ao 2.008, en la extinta institucin de Seguridad Ciudadana
denominada Servicio Autnomo de Telecomunicaciones del Estado Mrida
(SATEM), hoy Direccin del Poder Popular para las Telecomunicaciones e
Informtica (DppTI), adscrita a la Gobernacin del Estado Mrida; cuyo
espritu de la investigacin, no es ms que aportar una solucin a los
problemas ocasionados ante la ausencia de un sistema integral, aplicando en
conjunto los recursos tecnolgicos de los gobiernos Municipales, Regionales
y Nacional.
En el caso de este estudio de carcter tecnolgico, fue necesario revisar
conceptos apropiados relacionadas con el enfoque de integracin de los Or-
ganismos de Seguridad Ciudadana, mediante el diseo de una Ingeniera de
Requisitos para el desarrollo de un Sistema de Informacin en los Servicios
Estadales de Atencin de Emergencias en Venezuela (SIAE), con irradiacin
para cualquier pas del mundo con similares fundamentos conceptuales en la
atencin de emergencias de sus ciudadanos; basada en la Constitucin y
Leyes de la Repblica Bolivariana de Venezuela, as como tambin, los Pro-
yectos Tecnolgicos publicados como lineamientos de modernizacin del
1
Estado impartidos por el Ministerio del Poder Popular para la Ciencia y tecno-
loga (MppCT); reunidos todos los anteriores en la Gua para el Plan de Mi-
gracin a Software Libre en la Administracin Pblica Nacional (APN) de la
Repblica Bolivariana de Venezuela desarrollado por el Centro Nacional de
Tecnologas de Informacin (CNTI) (2005).
La Ingeniera de Requisitos, como parte integral de la Ingeniera de Soft-
ware, cumple un papel primordial en el proceso de produccin de software,
ya que enfoca un rea fundamental: la definicin de lo que se desea producir.
Su principal tarea consiste en la generacin de especificaciones correctas
que describan con claridad, sin ambigedades, en forma consistente y com-
pacta, el comportamiento del sistema; de esta manera, se pretende minimizar
los problemas relacionados al desarrollo de sistemas.
El reemplazo de plataformas y tecnologas obsoletas, la compra de sis-
temas completamente nuevos, las modificaciones de todos o de casi todos
los programas que forman un sistema, entre otras razones, llevan a desarro-
llar proyectos en calendarios sumamente ajustados y en algunos casos irrea-
les; esto ocasiona que se omitan muchos pasos importantes en el ciclo de
vida de desarrollo, entre estos, la definicin de los requisitos.
Estudios realizados muestran que ms del 53% de los proyectos de soft-
ware fracasan por no realizar un estudio previo de requisitos. Otros factores
como falta de participacin del usuario, requisitos incompletos y el cambio a
los requisitos, tambin ocupan sitiales altos en los motivos de fracasos.
Como producto final, se obtiene el Documento de Definicin de Requisi-
tos (DDR), el cual permite gestionar las necesidades del proyecto en forma
estructurada, evitando rechazos de los usuarios finales; mejorando la capaci-
dad de predecir cronogramas de proyectos, as como sus resultados, asegu-
rando la calidad del software y la comunicacin entre equipos; redundando
ampliamente en la disminucin de costos y retrasos en el proyecto.
2
El captulo I, hace una contextualizacin del problema en los Servicios
de Atencin de Emergencias (SAE), en el caso Estado Mrida, describiendo
los sntomas que indican la presencia de problemas en dicho servicio; diag-
nosticando los problemas presentes en el mismo; determinando sus causas y
pronosticando las posibles consecuencias de no corregirse tales problemas;
y finalmente proponiendo una solucin tecnolgica, lo cual conforma el obje-
tivo principal desglosado en cuatro objetivos especficos; justificados plena-
mente ya que aportar altos beneficios en las Instituciones que lo apliquen,
en las comunidades que sean beneficiadas y para el desarrollo de futuros
Proyectos de Investigacin similares a este.
El captulo II, explana el marco referencial que ha servido al autor del
Proyecto como gua para el desarrollo de la propuesta, haciendo una resea
histrica del problema, una revisin de tres Trabajos de Investigacin simila-
res al presente Proyecto, determinando las bases tericas adquiridas de au-
tores reconocidos a nivel nacional e internacional, de los conceptos utilizados
en esta Investigacin; y revisando las bases legales de la Repblica Boliva-
riana de Venezuela, que determinarn las maneras jurdicas apropiadas para
la aplicacin de Tecnologas en la Administracin Pblica en el pas.
El captulo III presenta la metodologa que permitir desarrollar el presen-
te Trabajo Especial de Grado, mostrndose aspectos como las fases de la
modalidad de investigacin, las tcnicas y procedimientos que sern utiliza-
dos para llevar a cabo esta Investigacin.
El captulo IV, presenta la propuesta final que es el desarrollo del docu-
mento de definicin de requisitos del Sistema de Informacin de Atencin de
Emergencias, mediante el modelo de desarrollo de software basado en
Componentes, a travs de la metodologa del Proceso Unificado de Racional
(RUP).
Existe escasa documentacin con respecto a los servicios tecnolgicos
en los SAE de Venezuela, debido a que estos organismos son de reciente
3
data, adems de que han sido totalmente derribados los cimientos tradiciona-
les de aplicacin de tecnologas privativas; para dar paso al desarrollo e im-
plementacin de tecnologas libres en la Administracin Pblica del pas en
todas sus formas, como parte del proyecto de transformacin sociopoltica
del Estado Venezolano en la actualidad.
Por ltimo, la investigacin puede servir como antecedente para futuras
investigaciones que sean realizadas, porque estas son acciones pioneras en
las nuevas concepciones que se estn aplicando en el pas, las cuales son
fundamentos en los proyectos de conformacin de plataformas de tecnolo-
gas libres, en la Administracin Pblica Nacional Venezolana.
4
CAPTULO I
EL PROBLEMA
Contextualizacin del Problema
El Servicio de Atencin de Emergencias (SAE) debe funcionar como un

rgano de coordinacin entre los organismos de seguridad en cualquier parte
del pas, a fin de acudir a los sitios de emergencias en general, los ms rpi-
do posible, sin muchas dilaciones salvando vidas, evitando agravamientos de
emergencias, tragedias y muertes innecesarias por retardos de servicios; lo
que se traducira en la disminucin de los ndices de inseguridad.
En el caso Estado Mrida, en el extinto Servicio Autnomo de Telecomu-
nicaciones del Estado Mrida (SATEM), hoy Direccin del Poder Popular Es-
tadal para la Teleinformtica (DppTI), adscrita a la Direccin del Poder Popu-
lar Estadal de Seguridad Ciudadana (DppSS) del Ejecutivo Regional; funcio-
na el SAE 171 de esta entidad, la cual ha venido operando normalmente
desde hace quince aos, con diferentes organizaciones y estructuras, con
amplia escasez de recursos, intentando integrar una diversidad de Organis-
mos de Seguridad con estructuras funcionales totalmente independientes
unas de otras, debiendo ejecutarse acciones de coordinacin excesivamente
burocrticas, tales como reuniones y convenios, que ralentizan el proceso de
atencin de emergencias, pudiendo adecuarse una organizacin que acte
inmediatamente; conforme a la naturaleza de tales servicios pblicos.
En la actualidad, se presentan una serie de aspectos que indican la pre-
sencia de una problemtica en el referido servicio, y que han inspirado el
desarrollo de una investigacin integral de sistematizacin, como lo es la
existencia de amplios retrasos y cierta descoordinacin de los organismos de
seguridad en la atencin de emergencias; tiempo perdido mientras se espera
5
ayuda ante una emergencia; dificultades de las poblacin para contactar a
los organismos de seguridad; incremento en los ndices de inseguridad; tra-
gedias, enfermedades agravadas y muertes innecesarias ocurridas ante los
retrasos de los organismos de seguridad; insatisfaccin y crticas en las per-
sonas.
Los sntomas detectados con anterioridad, han ocasionado una creciente
insatisfaccin de las comunidades que consideran que la Institucin y el Go-
bierno no estn cumpliendo cabalmente con sus funciones; los cuales estn
siendo causados por varios motivos, entre los cuales se encuentran:
Inicialmente, se observ que el Sistema de Informacin actual est total-
mente inoperativo desde hace dos (2) aos, el cual se encargaba de gestio-
nar las emergencias reportadas con los organismos encargados de atender-
las. Este sistema aparte de que no est funcionando, fue elaborado en soft-
ware privativo, dependiendo totalmente de los propietarios del software, cu-
yas contrataciones estn prohibidas por ley. Esto imposibilita el acceso al
cdigo fuente de la central telefnica existente, desarrollado igualmente me-
diante sistema privativo, que imposibilita su re-programacin libre e integra-
cin a cualquier sistema de informacin.
Asimismo, no hay posibilidad de acceso al registro de abonados de las
empresas de telefona pblica, residencial y mvil; para llevar el control de
las llamadas telefnicos reales innecesarias; junto con su procedencia, en
cuyo caso, las llamadas innecesarias denominadas sabotaje, ocasionan
congestionamiento de las lneas telefnicas y sobrecarga de trabajo a los
operadores que atienden las mismas, retardando la atencin efectiva de
emergencias reales.
Tambin los operadores telefnicos que atienden el nmero 171, realizan
excesivas preguntas a los ciudadanos que demandan de un servicio, ante
situaciones que ameritan urgente atencin, al momento de la toma de datos
del reporte de dichas emergencias. Igualmente, existe una ausencia de me-
6
canismos digitales que permitan acceder al Sistema Nacional de Registro
Delictivo, Emergencias y Desastres, para consultar inmediatamente va on
line los registros policiales, delictivos y judiciales de las personas, del sistema
S.I.P.O.L. llevado por el Cuerpo de Investigaciones Cientficas Penales y
Criminalsticas (C.I.C.PC.); y a la informacin metereolgica; lo cual reduce
ampliamente el tiempo de consulta a los referidos datos, mediante las vas de
radiocomunicaciones o telefnicas.
Adicionalmente, no existe un mecanismo alterno de solicitud de atencin
de emergencias para las personas, que permita asumir las fallas en el servi-
cio telefnico tradicional actual de discado 1-7-1; disminuyendo las posibili-
dades de atencin y respuestas ms oportunas a emergencias reales.
Se detect a su vez, que las unidades de atencin de emergencias no
cuentan con un mecanismo diferente de radio transmisores, para la recep-
cin de rdenes de atencin de una emergencia, enlazados por la troncal de
radiocomunicaciones, que al caerse deben hacer uso de los telfonos celula-
res para comunicarse.
De igual forma, hay inexistencia de un mecanismo tecnolgico de ubica-
cin fsica de las unidades de atencin de emergencias, que permita monito-
rear la ubicacin exacta de dichas unidades, disminuyendo la posibilidad de
evitar que se encuentren en lugares inapropiados, adems de determinar la
disponibilidad de unidades y las ms prximas a los eventos presentados,
atendindose menos oportunamente las emergencias; pudiendo utilizarse la
red inalmbrica externa en aplicaciones tecnolgicas de atencin de emer-
gencias, la cual est en desuso, lo que ocasiona el desaprovechamiento de
los recursos existentes de la extinta SATEM (hoy DppTI).
De no resolverse las deficiencias anteriormente descritas, se pronostica
un colapso en el servicio telefnico de atencin de emergencias, con el in-
cremento en los ndices de inseguridad, agravamientos de emergencias, tra-
gedias y muertes innecesarias por retardos de servicios, en consecuencia,
7
prdida sustancial de la calidad y credibilidad de la gestin de seguridad ciu-
dadana de la Institucin del Servicio Merideo de Atencin de Emergencias.
En atencin a los problemas planteados con anterioridad, se propone
como proyecto de investigacin, una Ingeniera de Requisitos para el desa-
rrollo de un Sistema de Informacin en los Servicios Estadales de Atencin
de Emergencias; y para llevar a cabo el referido Proyecto de Investigacin,
se debe cumplir con los siguientes objetivos:
Objetivo General
Desarrollar una Ingeniera de Requisitos para Sistema de Informacin en

los Servicios Estadales de Atencin de Emergencias.
Objetivos Especficos
Diagnosticar el funcionamiento del actual Sistema de Informacin del Ser-

vicio de Atencin de Emergencias (SAE) 171 del Estado Mrida.
Disear el modelado de datos del Sistema de Informacin para la Aten-
cin de Emergencias.
Elaborar el documento de definicin de requisitos para el desarrollo del
Sistema de Informacin de Atencin de Emergencias.
Justificacin
El actual SI inoperativo desde hace dos (2) aos, est diseado para
funcionar solo en un mbito regional, y fue elaborado en Software privativo;
por lo tanto, no hay posibilidad de una re-ingeniera del mismo para adaptarlo
a las exigencias del SAE; por lo que la Ingeniera de Requisitos permitir sol-
8
ventar los problemas especificados con anterioridad, conformando un efecti-
vo y eficiente Sistema de Informacin, ayudando a mejorar la calidad de
cualquier Servicio de Atencin Estadal de Emergencia en el pas; por consi-
guiente, una mejora sustancial en la calidad de vida de la poblacin, en virtud
que obtendrn respuestas ms rpidas y efectivas ante las emergencias pre-
sentadas. Este Sistema de Informacin ayudar a descargar parte del trabajo
que realiza el personal que labora en este servicio de emergencia, incremen-
tando la calidad de la atencin de las llamadas que se realicen, y brindando
rapidez en el envo de las unidades de los organismos de seguridad, lo cual
redundar positivamente en el desempeo de sus funciones. Finalmente,
este trabajo podr ser utilizado para referencias en futuras investigaciones.
9
CAPTULO II
MARCO REFERENCIAL
Resea Histrica
Segn Len (1996), el trmino Ingeniera de Sistemas de Software, fue

acuado en 1969 en el transcurso de un curso de verano de la OTAN en
Garmisch, y su consolidacin ha sufrido una evolucin en etapas en paralelo
con la propia evolucin de la programacin. Se destacan cuatro etapas:
La primera etapa es la que determina la programacin como base del
desarrollo (1955-1965), en la cual se hizo nfasis absoluto en la tarea de es-
cribir el cdigo en un lenguaje de programacin. Alrededor de los nuevos
lenguajes de alto nivel, los programadores se alejan de la estructura de los
ordenadores y comienzan a acercarse a la complejidad de las aplicaciones
de usuario.
Seguidamente, la segunda etapa es la de la gnesis (1965-1975), ligada
a la crisis de la programacin se plantea la necesidad de controlar el proceso
de desarrollo. Se definen modelos de ciclo de vida como una referencia en la
que enmarcar las actividades requeridas. El concepto de ciclo de vida en
cascada surge de la necesidad del Departamento de Defensa de EE.UU. de
disponer de una documentacin normalizada, para todas las etapas del desa-
rrollo, y poder controlar en base a ella a los suministradores de productos
software.
As, le sigui la tercera etapa de la consolidacin (1975-1985), en la cual,
el control de las actividades de desarrollo debera permitir gestionar el proce-
so. Durante esta etapa aparecen mtricas para estimar a priori el coste o el
tamao del sistema; se difunde el uso de mtodos de desarrollo. Con ello, el
10
programador se convierte en analista, diseador o gestor. Se vislumbra la
idea de ingeniero de software.
Finalmente, la cuarta etapa dio los pasos definitivos hacia una ingeniera
(1985-1995), aceptando una consolidacin de las tecnologas de software, la
mejora viene de la mano de un mejor conocimiento de los procesos con el fin
de incrementar la calidad de los productos. Aparece una gestin sofisticada
del proceso de desarrollo ligada al control de riesgos y a la madurez de los
procesos.
A lo largo de estas etapas, han existido avances puntuales significativos
tanto en la tecnologa empleada como en la propia percepcin del proceso de
desarrollo. El progreso hacia la ingeniera de sistemas de software ha sido
acumulativo en los aos cubiertos por las etapas mencionadas y no se puede
entender ningn progreso sin la experiencia obtenida de xitos y fracasos
anteriores.
Analizados globalmente, estos hitos significativos en el desarrollo de la
Ingeniera de Sistemas de Software, han ido intercalando el nfasis sobre las
tecnologas de desarrollo con el nfasis en la gestin del proceso. En cada
una de estas etapas se consigui un incremento de la calidad del proceso de
desarrollo.
Si inicialmente la esperanza de una mejora de calidad del producto se
centraba en el empleo de nuevos lenguajes de programacin, despus se
hizo necesario una mejor comprensin del ciclo de vida.
Posteriormente, fue necesario robustecer ese ciclo de vida en cascada
con tecnologas de software, que facilitasen las primeras fases del ciclo de
vida. Pero el empleo de mtodos y herramientas software de ayuda no haca
ms predecible y eficiente el desarrollo de un gran sistema: el nfasis se si-
tu de nuevo sobre los aspectos de gestin con la mejora del proceso.
La Ingeniera de Requisitos, como parte integral de la Ingeniera de Soft-
ware, cumple un papel primordial en el proceso de produccin de software,
11
ya que enfoca un rea fundamental: la definicin de lo que se desea producir.
Su principal tarea consiste en la generacin de especificaciones correctas
que describan con claridad, sin ambigedades, en forma consistente y com-
pacta, el comportamiento del sistema; de esta manera, se pretende minimizar
los problemas relacionados al desarrollo de sistemas.
El reemplazo de plataformas y tecnologas obsoletas, la compra de sis-
temas completamente nuevos, las modificaciones de todos o de casi todos
los programas que forman un sistema, entre otras razones, llevan a desarro-
llar proyectos en calendarios sumamente ajustados y en algunos casos irrea-
les; esto ocasiona que se omitan muchos pasos importantes en el ciclo de
vida de desarrollo, entre estos, la definicin de los requisitos.
Estudios realizados muestran que ms del 53% de los proyectos de soft-
ware fracasan por no realizar un estudio previo de requisitos. Otros factores
como falta de participacin del usuario, requisitos incompletos y el cambio a
los requisitos, tambin ocupan sitiales altos en los motivos de fracasos.
Antecedentes de la Investigacin
Los antecedentes de la investigacin realizados por algunos autores, as

como lo referente a las proposiciones tericas que sustentan la investigacin,
son los siguientes:
En primer lugar, Colmenares (2005), en su Proyecto de Grado de la Uni-
versidad de Los Andes, Mrida, Venezuela, titulado Optimizacin de los n-
dices de Gestin y Operatividad en el Servicio 1-7-1 de SATEM, en el cual
utiliz la metodologa de proyecto factible; y realiz un diagnstico del SAE
en el Estado Mrida, de los datos estadsticos de los servicios prestados, a
los fines de optimizar la efectividad y eficiencia de esa Institucin, lo cual
puede ser considerado en esta Investigacin, en el sentido de dejar claro que
la aplicacin de estrategias que permitan la integracin de los recursos en la
12
Institucin, redundar en una mayor aproximacin al xito y ms calidad de
los servicios del SAE; el cual sirve de gua para este proyecto para conocer
el funcionamiento del sistema privativo que estuvo en funcionamiento hasta
mediados del ao 2.008, dando a conocer la realidad de la Institucin; lo cual
aporta insumos tericos para ser aplicados en el desarrollo de la Ingeniera
de Requisitos objeto de este Trabajo de Investigacin.
Asimismo, Jurez (2007), en su Trabajo Especial de Grado del Instituto
Universitario Politcnico Santiago Mario, extensin Mrida, denominado
Ingeniera de Requerimientos para el desarrollo de un Software que permita
mejorar el control de inventario en el Departamento de Datos de una empre-
sa de telecomunicaciones, donde realiz un anlisis de la situacin en dicha
organizacin y determin problemas de inventario, referentes al desconoci-
miento de la existencia en el almacn, descontrol en la asignacin de produc-
tos, informacin tarda, actividades manuales entre otras. Este autor present
como propuesta, el desarrollo de una Ingeniera de Requisitos para una apli-
cacin que permita el control de inventario en el Departamento de Datos en
una empresa de telecomunicaciones, a fin de satisfacer las necesidades
planteadas por los mismos. De esta manera, se realiz un modelado del ne-
gocio, el levantamiento de los requisitos, y el diseo de un prototipo no fun-
cional del software. Este trabajo especial de grado, adopt la modalidad de
proyecto factible, apoyado en una investigacin documental y de campo de
tipo investigacin descriptiva. El aporte de este antecedente al presente tra-
bajo de investigacin, lo constituye el diseo de modelado del negocio, don-
de se incluyen diagramas de casos de usos, y la metodologa para el levan-
tamiento y verificacin de los requisitos.
Finalmente, Dvila (2009), en su Trabajo Especial de Grado del Instituto
Universitario Politcnico Santiago Mario, extensin Mrida, denominado
Ingeniera de Requerimientos y Modelado de Datos para el Sistema de In-
formacin de Caudales en Acueductos Urbanos, determin la problemtica
13
existente en los sistemas de medicin de la empresa Aguas de Mrida, cau-
sndoles prdidas en la recaudacin de dinero, al no determinarse la medi-
cin real del consumo de la poblacin meridea. Ante la problemtica pre-
sentada, la autora realiz la propuesta de desarrollo de una Ingeniera de
Requisitos para el sistema de informacin que funciona en dicha empresa,
que registra los caudales en los acueductos urbanos, a fin de solventar las
fallas de medicin detectadas. De esta manera, se realiz un modelado del
negocio, el levantamiento de los requisitos, y el diseo de un prototipo no
funcional del software. Este trabajo especial de grado, adopt la modalidad
de proyecto factible, apoyado en una investigacin documental y de campo
de tipo investigacin descriptiva. Dicho trabajo de investigacin, aport al
presente proyecto, las concepciones necesarias para el desarrollo de una
Ingeniera de Requisitos, en cuanto al diseo de modelado del negocio, con
sus diagramas de modelado UML, realizados mediante la metodologa para
su desarrollo.
Bases Tericas
Servicio de Atencin de Emergencias (SAE)
El Servicio de Atencin de Emergencias (SAE) en Mrida, se inici con el

uso de una lnea directa telefnica en cada institucin de seguridad y defensa
civil, codificadas con nmeros como 161, 168 y 169, entre otros, los cuales
eran discados por las personas para requerir de los servicios de la institucin
a que llamaban.
El mecanismo era manual, y funcion por ms de treinta aos, y era
atendido como una llamada telefnica comn y corriente, por un recepcionis-
ta que comunicaba directamente a las unidades disponibles en la sede de la
institucin o va radio transmisor, el reporte de las emergencias requeridas;
14
adems, no exista un mtodo de deteccin de llamadas de sabotaje, ya que
la tecnologa existente para el momento se encontraba en pleno crecimiento,
y no ofreca mtodos que minimizaran los errores e incrementara la eficiencia
y eficacia.
En cada Estado del pas, en la dcada de los aos 90, se crearon los
Servicios de Atencin de Emergencias (SAE) 171 adscritos a las Direccio-
nes de Seguridad Ciudadana de cada Gobernacin, los cuales han tenido
como funcin primordial, atender las llamadas de auxilio o emergencia que
tenga la ciudadana. Para este fin, se cuenta con varias lneas telefnicas
entrantes de CANTV, las cuales se encuentran encadenadas al nmero 171,
y son atendidas por varios Operadores Telefnicos, las 24 horas del da,
quienes recopilan la emergencia, en forma detallada toda la informacin, se
canaliza la ayuda que se enviar al sitio del acontecimiento, a travs de los
diferentes organismos de Seguridad, entes Pblicos o Privados.
En el ao 1.995, se cre la Fundacin para Desastres del Estado Mrida
(FUNDEM), durante el Gobierno del Gobernador del Estado Mrida Dr. Wi-
lliam Dvila Barrios, cuya Institucin fue concebida como ente integrador de
las acciones de defensa civil y acciones de atencin de emergencias y
desastres, incluyendo el Sistema 171, aplicando sistemas de telecomunica-
ciones e informtica, para la conformacin de la Red de Telecomunicaciones
e Informtica del Estado Mrida (RETIEM), que interconect todos los entes
de Gobierno, Seguridad, Educacin y Salud pblica del Estado Mrida.
Posteriormente, en fecha 6 de agosto de 2.001, se disuelve FUNDEM, y
se crea el Instituto de Proteccin Civil y Accin contra Desastres del Estado
Mrida (INPRADEM), asumiendo las competencias de FUNDEM, segn Ga-
ceta Oficial del Estado Mrida, No. 239, luego de haber sido decretada la
emergencia administrativa en fecha 14 de agosto de 2.000, mediante la cual
el Gobernador Lic. Florencio Porras Echezura, cre la Comisin Reorgani-
zadora de INPRADEM.
15
Dos aos despus, la gestin de este tipo de servicios estuvo presente
en el Estado Mrida a travs SATEM, a partir del 23 de Diciembre del 2003,
creado mediante Decreto No. 326 del Gobernador Florencio Antonio Porras
Echezura, quedando adscrito a la Direccin de Seguridad Ciudadana; cuyo
organismo estuvo gestionando los SAE en el Estado Mrida, mediante la ins-
talacin de una plataforma tecnolgica, que integraba un Sistema de Infor-
macin para el Control de Emergencias 171, diseado por una empresa pri-
vada mediante el lenguaje de programacin Visual Basic, bajo la arquitectura
cliente-servidor, con manejador de base de datos SQL Server, instalado en
dos (2) servidores paralelos Windows Server 2000, conectados a la central
telefnica ERICSON, y al sistema Mirror de almacenamiento de quince lneas
entrantes encadenadas del nmero de discado 171. Este sistema se encuen-
tra inoperativo desde mediados del ao 2.008, originado por causas desco-
nocidas que se describen como fallas tcnicas en el software y hardware que
conforman la plataforma tecnolgica, las cuales son difciles de solventar, por
encontrarse diseados con software privativo que obliga a depender del di-
seador del Sistema de Informacin, el cual es el nico ente que provee del
soporte tcnico al mismo.
Igualmente, SATEM aplic el proyecto de Telecomunicaciones, que per-
mitan la interconexin de todas las poblaciones de la entidad meridea, re-
tomando el proyecto RETIEM en el ao 2.005, denominndolo RETIEM Plus,
mediante la inversin de altos recursos econmicos en equipos de enlaces
inalmbricos, ubicando equipos de repeticin de ondas de radiofrecuencias
de ltima tecnologa en sitios estratgicos, y la instalacin de un cableado de
fibra ptica que permite acceder a los Pueblos del Sur del Estado Mrida, a
los servicios de telefona e Internet que provee la Compaa Annima Nacio-
nal Telfonos de Venezuela (CANTV), mediante convenios interinstituciona-
les.
16
A partir del 1 de enero de 2.010, la gestin de los Servicios Telemticos
para Atender Emergencias a travs del discado telefnico 171 en el Estado
Mrida, se encuentra a cargo de la Direccin del Poder Popular Estadal para
la Teleinformtica (DppTI), organismo adscrito a la Direccin del Poder Popu-
lar Estadal de Seguridad Ciudadana de la Gobernacin del Estado Mrida,
creado el 1 de enero del 2.010, mediante el decreto No. 361, del Gobernador
del Estado Mrida Marcos Daz Orellana, asumiendo plenamente las funcio-
nes de SATEM cesando sus funciones el 31 de diciembre de 2.009.
Hoy da, la DppTI intenta sumarse a proyectos para ampliar la cobertura
de sus servicios, proyectando un futuro enlace al satlite Simn Bolvar,
puesto en rbita por el Gobierno Nacional a travs de la Asociacin Boliva-
riana de Actividades Espaciales ABAE, el 1 de noviembre de 1.999; ade-
ms de la implementacin de Sistemas de Informacin modernos en su pla-
taforma tecnolgica, que incrementen la accin eficaz de los SAE en el Esta-
do Mrida, desarrollando acciones conjuntas con el MppRIJ, las cuales an
no se han concretado ya que ese Ministerio est desarrollando proyectos
para tales fines, aportndose las propuestas del presente trabajo de investi-
gacin para enriquecer tales proyectos.
Segn la Ley de Coordinacin de Seguridad Ciudadana (2001), se le
asign al Ministerio del Poder Popular para las Relaciones Interiores y Justi-
cia MppRIJ, las funciones de coordinar las acciones de Seguridad Ciuda-
dana en todo el territorio nacional, incluyendo los SAE, impartiendo linea-
mientos a los distintos rganos descentralizados del pas en los referidos
servicios, con acceso al Sistema Nacional de Registro Delictivo, Emergencias
y Desastres, a los fines de que dispongan de un sistema de informacin y su
base de datos de registros delictivos y judiciales, denominado Sistema de
Informacin Policial (SIPOL), administrado por el Cuerpo de Investigaciones
Cientficas, Penales y Criminalsticas (CICPC), que faciliten la debida planifi-
17
cacin, formulacin y ejecucin integral de los planes, estrategias y acciones
de Seguridad Ciudadana.
Para Colmenares (2005), se define el SAE como el servicio permanente
de atencin ciudadana, donde se reciben y procesan todas las llamadas de
emergencia y auxilio en Venezuela. Es el nico servicio pblico gratuito para
las llamadas de emergencia a nivel nacional desde cualquier telfono mvil,
jo, residencial, comercial o pblico, disponible las 24 horas del da, marcan-
do 1-7-1, y se utiliza para reportar cualquier tipo de emergencia o eventuali-
dad que se le presente al ciudadano.
Figuras 1 y 2: Sala de Operadores SAE Mrida en funciones de atencin de llamadas de

emergencias utilizando el anterior en el Sistema de Informacin.
Fuente: Colmenares (2005)
Fue creado en respuesta a las necesidades de la colectividad, con la fi-

nalidad de resguardar la vida y bienes de los ciudadanos, brindando condi-
ciones de seguridad confiables, a travs de un servicio accesible y econmi-
co, y para lograr este objetivo, se requiere de la coordinacin entre los distin-
tos organismos de seguridad que contribuyen a la seguridad ciudadana.
El SAE 171 Mrida recibe todas las llamadas de auxilio y emergencia
que se emiten en cada Estado de Venezuela (ver Figuras 1 y 2), a travs de
los Operadores, que se manejan mediante la centralizacin de las comunica-
ciones de los organismos de seguridad presentes en el Servicio, permitiendo
con ello la unin de todas las fuerzas necesarias para lograr una respuesta
18
efectiva.
Actualmente en el SAE 171 Mrida se encuentran presentes, en la sala
de Despachadores (ver Figuras 3 y 4), los siguientes representantes de los
organismos de seguridad del estado, tales como, Cuerpo de Bomberos, Poli-
cas Municipales y Estadales, Cuerpo Tcnico de Vigilancia y Trnsito Te-
rrestre (CTVTT), Fuerza Armada Nacional (FAN), Cuerpo de Investigaciones
Cientficas, Penales y Criminalsticas (CICPC), Proteccin Civil (PC), Servicio
Bolivariano de Inteligencia (SEBIN), adems otros Organismos compuestos
por voluntariados, tales como, Grupos de Rescate, Bomberos Universitarios y
Forestales, organizaciones humanitarias altruistas, ecolgicos y conservacio-
nistas, entre otros.
Figuras 3 y 4: Sala de Despachadores SAE Mrida en funciones de despacho de

Organismos de Seguridad utilizando el anterior en el Sistema de Informacin.
Fuente: Colmenares (2005)
Todos estos organismos funcionan bajo la coordinacin del SAE 171 M-

rida, con la finalidad de brindar todo el apoyo que permita solventar la nece-
sidad de los ciudadanos, para esto, existe una central digital telefnica que
permiten identificar el nmero desde donde el ciudadano realiza la llamada,
ayudando al rpido envo de la unidad de auxilio.
Los objetivos del SAE 171 en Venezuela son:
Fortalecer la coordinacin con otras instituciones nacionales, regiona-
les, municipales y de la sociedad civil, con la finalidad de dar respues-
19
ta inmediata a las solicitudes de emergencia.
Coordinar la emergencia ciudadana con los organismos de seguridad
del estado para casos de emergencia y desastres naturales.
Realizar las estadsticas de las llamadas recibidas y procesadas a tra-
vs del SAE 171 con la finalidad de maximizar la eficiencia de los ser-
vicios de seguridad y auxilio.
Coordinar con los organismos de seguridad regional a n de unicar
criterios de informacin y comunicacin como apoyo al SAE 171.
Centralizar los sistemas de comunicaciones de los diferentes organis-
mos de seguridad presentes en el SAE 171 mejorando la transmisin
y el tiempo de respuesta de las unidades operativas que darn res-
puesta a la emergencia ciudadana que se plante.
Asimismo, las funciones del SAE 171 son:
La funcin primordial es atender todo tipo de emergencia solicitada por
la ciudadana del Estado Mrida.
Velar por dar respuestas inmediatas a las solicitudes de la ciudadana.
Dar un trato adecuado al solicitante.
Orientar y calmar al ciudadano en las diferentes emergencias que se
presenten.
Mantener una buena comunicacin con los diferentes organismos in-
volucrados con el sistema.
Sistemas de Informacin (SI)
Para Blanchard (1995), es una combinacin de recursos, tales como se-

res humanos, materiales, equipos, software, instalaciones, datos, etc. (Ver
Figura 5) integrados de forma tal que cumplan una funcin especfica en res-
puesta a una necesidad designada de un usuario. No slo incluye los recur-
20
sos utilizados directamente en el cumplimiento de la misin, los cuales son el
equipo principal, software operativo, personal usuario; sino tambin los dife-
rentes elementos del apoyo, como por ejemplo, los equipos de apoyo y prue-
ba, repuestos y requisitos relacionados de inventario, personal de manteni-
miento e instalaciones.
Figura 5: Elementos de un Sistema de Informacin

Fuente: Enciclopedia digital Wikipedia (2010)
Esta es una definicin genrica que incluye todo tipo de sistemas. Desde
sistemas en los que no existen recursos software, hasta aquellos otros en los
que sos son los elementos fundamentales para conseguir la funcionalidad
pretendida.
Desde esta perspectiva tan amplia, un sistema se considerar como SI,
cuando sus recursos software constituyan su elemento bsico y la fuente de
su funcionalidad bsica. Dicho de otro modo, cuando en el proceso de desa-
rrollo sean los recursos software los que determinan el proceso general de
desarrollo de todo el sistema, y cuando su ejecucin pueda realizarse sobre
una plataforma hardware genrica.
Para distinguir entre un SI y un programa ejecutable, un programa es un
algoritmo codificado junto con unas estructuras de datos. Algunas veces se
emplea el trmino paquete ejecutable, para referirse a un conjunto de pro-
21
gramas que se necesitan mutuamente durante la ejecucin del sistema y que
deben distribuirse conjuntamente al usuario final.
Un SI, por el contrario, es mucho ms ya que implica una interaccin con
el contexto al que sirve que constituye el referente bsico de su utilidad. Un
SI posee programas ejecutables pero tambin otros tipos de recursos (fiche-
ros de datos, de documentacin, etc.).
Gran parte de los problemas que acechan a los diseadores e implemen-
tadores actuales, reside en que emplean durante el proceso de desarrollo,
una perspectiva limitada a los programas necesarios; y no a una concepcin
sistmica del desarrollo del mismo ni del contexto social, humano y tcnico
que enmarca su ejecucin. La ingeniera de Software es, ante todo, una In-
geniera.
La complejidad de un sistema, depende no slo de las mltiples interac-
ciones entre los recursos de que consta; sino tambin de la forma en la que
puede evolucionar en respuesta a las necesidades del entorno; ya que el
control de la complejidad de un sistema, depende generalmente de las fun-
ciones dependientes de sus recursos software y de como stas se adapten al
mundo externo.
Bases de Datos (BD)
Para Silberschatz y otros (2002), una base de datos o banco de datos, es

un conjunto de datos pertenecientes a un mismo contexto y almacenados
sistemticamente para su posterior uso.
En este sentido, una biblioteca puede considerarse una base de datos
compuesta en su mayora por documentos y textos impresos en papel e in-
dexados para su consulta. En la actualidad, y debido al desarrollo tecnolgico
de campos como la informtica y la electrnica, la mayora de las bases de
22
datos estn en formato digital (electrnico), que ofrece un amplio rango de
soluciones al problema de almacenar datos.
Modelado de Datos (MD)
Silberschatz y otros (2002) lo define como una coleccin de herramien-

tas conceptuales para describir los datos, las relaciones de datos, la semn-
tica de los datos y las ligaduras de consistencia.
Los MD Se clasifican en tres grupos, los cuales son los modelos lgicos
basados en objetos; los cuales son los modelos lgicos basados en registros
y los modelos fsicos.
Modelo Entidad-Relacin (E-R)
Para, Silberschatz y otros (2002), es el que est basado en una percep-

cin del mundo real que consta de una coleccin de objetos bsicos, llama-
dos entidades y de relaciones entre estos objetos.
Es para facilitar el diseo de bases de datos permitiendo la especifica-
cin de un esquema de la empresa que representa la estructura lgica com-
pleta de una base de datos. El modelo de datos E-R es uno de los diferentes
modelos de datos semnticos; el aspecto semntico del modelo radica en el
intento de representar el significado de los datos.
La estructura lgica general de una base de datos se puede expresar
grficamente mediante un diagrama E-R. Tal diagrama consta de rectngu-
los, elipses, rombos y lneas, los cuales denotan las entidades, relaciones y
sus atributos (ver Figura 6).
Entidades
Es un objeto en el mundo real que es distinguible de todos los dems ob-
jetos. Por ejemplo, cada persona en un desarrollo es una entidad. Una enti-
23
dad tiene un conjunto de propiedades, y los valores para algn conjunto de
propiedades pueden identificar una entidad de forma precisa.
Figura 6: Diagrama Entidad-Relacin

Fuente: Silberschatz y otros (2002)
Conjunto de Entidades
Es la totalidad de las entidades del mismo tipo que comparten las mis-
mas propiedades o atributos. Las entidades individuales que constituyen un
conjunto se llaman la extensin del conjunto de entidades. Los conjuntos de
entidades no son necesariamente disjuntos.
Atributos
Una entidad se representa mediante un conjunto de atributos. Los atribu-
tos describen propiedades que posee cada miembro de un conjunto de enti-
dades. La designacin de un atributo para un conjunto de entidades expresa
que la base de datos almacena informacin similar concerniente a cada enti-
dad del conjunto de entidades; sin embargo, cada entidad puede tener su
propio valor para cada atributo.
Ligaduras de Correspondencia
Un esquema de desarrollo E-R puede definir ciertas ligaduras a las que
los contenidos de la base de datos se deben adaptar. Dos de los tipos ms
importantes de ligaduras, son las correspondencias de cardinalidades y las
dependencias existentes.
24
La correspondencia de cardinalidades expresa el nmero de entidades a
la que otra entidad puede estar asociada va un conjunto de relaciones bina-
rias.
Para un conjunto de relaciones binarias R entre los conjuntos de entida-
des Ay B, la correspondencia de cardinalidades debe ser una de las siguien-
tes:
Uno a uno: Una entidad en A se asocia con, a lo sumo, una entidad
en B; y una entidad en B se asocia con, a lo sumo, una entidad en A
(ver Figura 7).
Figura 7: Ligadura de correspondencia uno a uno.

Fuente: Propia (2010)
Uno a varios: Una entidad en A se asocia con cualquier nmero de

entidades en B; y una entidad en B se asocia con, a lo sumo, una en-
tidad en A (ver Figura 8).
Figura 8: Ligadura de correspondencia uno a varios.

25
Varios a uno: Una entidad en A se asocia con, a lo sumo, una entidad
en B; y una entidad en B se asocia con cualquier nmero de entidades
en A (ver Figura 9).
Figura 9: Ligadura de correspondencia varios a uno.

Varios a varios: Una entidad en A se asocia con cualquier nmero de

entidades en B; y una entidad en B se asocia con cualquier nmero de
entidades en A (ver Figura 10).
Figura 10: Ligadura de correspondencia varios a varios.

Dependencias de Existencia
Si la existencia de la entidad x depende de la existencia de la entidad y;
entonces se dice que x tiene dependencia de existencia de y. Operacional-
mente, si y se borra, tambin se borra x. La entidad y se dice que es la enti-
dad dominante, y la entidad x se llama entidad subordinada.
26
Claves
Permiten hacer las distinciones entre las entidades y relaciones indivi-
duales debido a que estas ltimas son distintas. Desde una perspectiva de
bases de datos, la clave se debe expresar en trminos de sus atributos.
Ingeniera de Software (IS)
Para la IEEE, el software es el conjunto de los programas de cmputo,

procedimientos, reglas, documentacin y datos asociados que forman parte
de las operaciones de un sistema de computacin.
Asimismo, Blanchard (1995) llama recurso software, a un programa o
conjunto de programas ejecutables que proporcione algunas de las funciones
requeridas por el sistema.
Ahora bien, la Ingeniera de Sistemas (ISI) la define Blanchard (1995),
como la aplicacin efectiva de esfuerzos cientficos y de Ingeniera, para
transformar una necesidad operativa en una configuracin definida de un sis-
tema mediante el proceso iterativo de anlisis de requisitos, la seleccin del
concepto, y asignacin, sntesis, soluciones de compromiso y optimizacin
del diseo, prueba y evaluacin.
Entre las caractersticas de la ISI, se incluye su estructura de arriba-
abajo que ve el sistema como un todo; una orientacin del ciclo de vida que
considera todas las fases desde el diseo conceptual hasta la retirada del
sistema; un enfoque interdisciplinar en equipo, que incluya todas las disci-
plinas adecuadas de diseo de forma oportuna y concurrente; y la necesaria
integracin para asegurar que todos los objetivos de diseo se han cumplido
de forma efectiva y eficaz. Est orientada al proceso, e incluye las provisio-
nes esenciales de realimentacin y control.
Determinadas las definiciones del software y la Ingeniera de Sistemas,
se aborda la IS, segn Pressman (2001), el cual la define enfatizando aspec-
27
tos concretos de calidad, referidos con el establecimiento y uso de principios
de ingeniera robustos, orientados a obtener software econmico que sea
fiable y funcione de manera eficiente sobre mquinas reales.
Pressman presupone que el sistema de software a realizar cumpla con
la misin encomendada, satisfaga las expectativas del usuario, etc. Si se
compara esta definicin con la de ISI anterior del mismo autor, la ISI est
enfocada al proceso de desarrollo y no tanto a la tecnologa con la que se
desarrolla; para l es ms una Ingeniera de proceso y no tanto de producto.
De su anlisis se desprende que la Ingeniera de Software es una espe-
cializacin de la Ingeniera de Sistemas, cuya creciente importancia est li-
gada a la de los sistemas de software en nuestra sociedad.
Modelos de Ingeniera de Software
Para Pressmar (2001), un modelo de IS es una estrategia de desarrollo

que acompae al proceso, mtodos y capas de herramientas y las fases ge-
nricas. Esta estrategia a menudo se llama modelo de proceso o paradigma
de ingeniera del software.
Asimismo, indica que se selecciona un modelo de proceso para la inge-
niera del software segn la naturaleza del proyecto y de la aplicacin, los
mtodos y las herramientas a utilizarse, y los controles y entregas que se
requieren.
Algunos de los modelos que se pueden destacar por ser los ms utiliza-
dos son:
1. El modelo lineal secuencial.
2. El modelo de construccin de prototipos.
3. El modelo Desarrollo Rpido de Aplicaciones (DRA).
4. Modelos evolutivos de proceso del software:
a. Modelo incremental.
28
b. Modelo espiral.
c. Modelo espiral Win-Win.
d. Modelo de desarrollo concurrente.
5. Modelos basados en componentes.
6. El modelo de mtodos formales.
7. Modelos de cuarta generacin
Modelo Basado en Componentes:

Metodologa de Proceso Unificado de Racional (RUP)
Para Jacobson y otros (2000), el Proceso Unificado (RU) representa un

nmero de modelos de desarrollo basados en componentes que han sido
propuestos en la industria. Utilizando el Lenguaje de Modelado Unificado
(UML), el RU define los componentes que se utilizarn para construir el sis-
tema y las interfaces que conectarn los componentes. Utilizando una com-
binacin del desarrollo incremental e iterativo, el proceso unificado define la
funcin del sistema aplicando un enfoque basado en escenarios (desde el
punto de vista del usuario). Entonces acopla la funcin con un marco de tra-
bajo arquitectnico que identifica la forma que tomar el software.
RUP, es la versin registrada por la International Business Machines
(IBM) en el ao 2001, de la metodologa de RU, por lo que aplica el mismo
concepto descrito en el prrafo anterior.
Segn IBM (2001), los autores de RUP destacan que el proceso de soft-
ware propuesto por RUP tiene tres caractersticas esenciales: est dirigido
por los casos de uso, est centrado en la arquitectura, y es iterativo e incre-
mental; tal como describen a continuacin:
Proceso Dirigido por Casos de Uso
Los casos de uso son una tcnica de captura de requisitos que fuerza a
pensar en trminos de importancia para el usuario y no slo en trminos de
29
funciones que sera bueno contemplar. Se define un Caso de Uso como un
fragmento de funcionalidad del sistema que proporciona al usuario un valor
aadido. Los Casos de Uso representan los requisitos funcionales del siste-
ma.
En RUP los Casos de Uso no son slo una herramienta para especificar
los requisitos del sistema. Tambin guan su diseo, implementacin y prue-
ba. Los Casos de Uso constituyen un elemento integrador y una gua del tra-
bajo.
Proceso Centrado en la Arquitectura
La arquitectura de un sistema es la organizacin o estructura de sus par-
tes ms relevantes, lo que permite tener una visin comn entre todos los
involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema
completo, necesaria para controlar el desarrollo.
Proceso Iterativo Incremental
El equilibrio correcto entre los Casos de Uso y la arquitectura es algo
muy parecido al equilibrio de la forma y la funcin en el desarrollo del produc-
to, lo cual se consigue con el tiempo. Para esto, la estrategia que se propone
en RUP, es tener un proceso iterativo e incremental en donde el trabajo se
divide en partes ms pequeas o mini proyectos. Permitiendo que el equili-
brio entre Casos de Uso y arquitectura se vaya logrando durante cada mini
proyecto, as durante todo el proceso de desarrollo. Cada mini proyecto se
puede ver como una iteracin (un recorrido ms o menos completo a lo largo
de todos los flujos de trabajo fundamentales) del cual se obtiene un incre-
mento que produce un crecimiento en el producto.
Fases de la Metodologa RUP
RUP divide el proceso en cuatro fases (inicio, elaboracin, construccin y
transicin), dentro de las cuales se realizan varias iteraciones en nmero va-
riable segn el proyecto y en las que se hace un mayor o menor hincapi en
los distintas actividades. En la Figura 11 se muestra cmo vara el esfuerzo
30
asociado a las disciplinas segn la fase en la que se encuentre el proyecto
RUP.
Las primeras iteraciones (en las fases de Inicio y elaboracin) se enfocan
hacia la comprensin del problema y la tecnologa, la delimitacin del mbito
del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de
una baseline de la arquitectura. En cada fase participan todas las discipli-
nas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina vara.
Figura 11: Esfuerzo en actividades segn fase del proyecto

Fuente: Jacobson y otros (2000)
Fase de Inicio: Las iteraciones ponen mayor nfasis en actividades mo-

delado del negocio y de requisitos. Los artefactos que utiliza son:
el documento visin y
la especificacin de requisitos.
Fase de Elaboracin: Las iteraciones se orientan al desarrollo de la ba-
seline de la arquitectura, abarcan ms los flujos de trabajo de requisitos,
modelo de negocios (refinamiento), anlisis, diseo y una parte de implemen-
tacin orientado a la referida baseline de la arquitectura. Los artefactos que
utiliza son:
31
los diagramas de caso de uso.
Fase de Construccin: Se lleva a cabo la construccin del producto por
medio de una serie de iteraciones. Los artefactos que utiliza son los docu-
mentos de arquitectura que trabaja con las siguientes vistas:
los que corresponden a la vista esttica lgica (diagrama de clases y
el Modelo E-R);
la vista de interaccin (diagramas de secuencia, estados y colabora-
cin);
la vista conceptual (modelo de dominio); y
las vistas fsicas (diagramas de componentes y diagramas de desplie-
gue).
Para cada iteracin se selecciona algunos casos de uso, se refina su
anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una
pequea cascada para cada ciclo. Se realizan tantas iteraciones hasta que
se termine la implementacin de la nueva versin del producto.
Fase de Transicin: Se pretende garantizar que se tiene un producto
preparado para su entrega a la comunidad de usuarios.
Modelado de Negocios (MN)
Para Len (1996), con este flujo de trabajo pretendemos llegar a un me-
jor entendimiento de la organizacin donde se va a implantar el producto. Los
objetivos del modelado de negocio son:
Entender la estructura y la dinmica de la organizacin para la cual el

sistema va ser desarrollado (organizacin objetivo).
Entender el problema actual en la organizacin objetivo e identificar
potenciales mejoras.
32
Asegurar que clientes, usuarios finales y desarrolladores tengan un
entendimiento comn de la organizacin objetivo.
Derivar los requisitos del sistema necesarios para apoyar a la
organizacin objetivo.
Para lograr estos objetivos, el modelo de negocio describe como desarro-

llar una visin de la nueva organizacin, basado en esta visin se definen
procesos, roles y responsabilidades de la organizacin por medio de los si-
guientes modelos
Modelado de casos de uso del negocio.
Modelado de objetivos del sistema de negocios: all se puede obser-
var el resultado al que se quiere llegar, refleja el modo de pensar de la orga-
nizacin, orienta el desempeo empresarial y permitir evaluar la continuidad
del departamento.
Modelado de procesos del negocio: El modelado de procesos de ne-
gocio, se utiliza para documentar los procesos, Mejorar buscando una mayor
eficiencia en sus procesos y Agilizar para poder reaccionar con mayor agili-
dad a los constantes cambios que exige la competencia actual.
Modelado de objetos del sistema de negocio: Los objetos del negocio
son de gran importancia para el desarrollo del SIAE, ya que cada uno de
ellos tiene asociado propiedades (atributos) que determinaran la estructura
del objeto; adems, tiene asociada una dinmica de comportamiento.
Modelado de actores/unidades organizacionales: Dentro de un mode-
lo de negocio o empresarial, los actores son aquellas personas, mquinas o
software que ejecutan los procesos de una organizacin o empresa. Cada
uno de estos actores se organizan en estructuras de trabajo, llamadas unida-
des organizativas. El conjunto de unidades organizativas clasificadas en divi-
siones, departamentos o secciones, conforman la estructura organizativa je-
rrquica de una organizacin o empresa.
33
Modelo de regla de negocios: es una declaracin que rige el funciona-
miento de algn aspecto del negocio, tales como polticas, condiciones, res-
tricciones; as como tambin los tipos de requisitos de operacin del negocio;
y son revisadas y definidas por el grupo de proyectos, usuarios y clientes.
Ingeniera de Requisitos (IR)
Len (1996), indica que el objetivo de la fase de IR (especificacin de-

finicin de requisitos), es obtener una clara comprensin del problema a re-
solver, extraer las necesidades del usuario y derivar de ellas las funciones
que debe realizar el sistema.
Posiblemente con anterioridad a esta fase ha existido algn estudio de
factibilidad que permite asegurar que el software a realizar es realizable, res-
ponde a un mercado potencial o real, etc. La fase de IR suele subdividirse en
dos sub-fases:
La primera sub-fase de anlisis de requisitos de usuario, la cual tiene
como objetivo conocer las necesidades de los usuarios y cules deben ser
los servicios que un SI debe ofrecerles para satisfacerlas. La fase implica la
creacin del Documento de Requisitos de Usuario (DRU) que constituye el
documento base para que, al final del desarrollo, el sistema sea aceptado por
el usuario. Esta sub-fase se aprovecha tambin para generar el plan de
desarrollo con una estimacin de costes y recursos.
Los requisitos de los usuarios pueden ser de muchos tipos diferentes.
Por un lado, el usuario tiene requisitos que corresponden al servicio que el
sistema de software que se pretende construir le debe proporcionar. En otros
casos, se trata de limitaciones existentes en la operacin del sistema. Como
ejemplo, un usuario puede requerir un sistema de control de un ascensor
que, entre otros muchos requisitos, desde que el usuario pulsa un botn en la
34
puerta hasta que sta se cierre, no deba transcurrir ms de tres segundos.
Este requisito corresponde a un servicio que debe proporcionar al usuario.
La segunda sub-fase de anlisis de requisitos del sistema, consiste en la
construccin de un modelo lgico del SI, describiendo las funciones que sean
necesarias (sin tomar ninguna decisin sobre cmo implementarlas) y las
relaciones entre ellas suponiendo que no existen limitaciones de recursos.
Por modelo lgico se entiende la identificacin de las funciones de soft-
ware requeridas para satisfacer los requisitos del usuario. Esta identificacin
se suele realizar en varios niveles de detalle, hasta llegar a uno en el que las
funciones identificadas estn suficientemente claras, de tal forma que no exi-
ja un refinamiento posterior.
El producto generado en esta sub-fase es el Documento de Requisitos
de Software (DRS). Tambin se genera en esta sub-fase, el plan de gestin
del desarrollo con estimaciones de costes y recursos ms ajustados que en
la primera sub-fase.
Es importante distinguir en esta sub-fase, entre requisitos funcionales y
requisitos no funcionales, que no pueden ligarse a funciones concretas den-
tro del sistema.
Los mecanismos de control (en estas etapas son las revisiones de los
documentos generados) deben asegurar que los requisitos software satisfa-
cen completamente los requisitos de usuario. Esta actividad ser parte de la
validacin del sistema.
Siguiendo con el ejemplo anterior, el requisito de usuario puede implicar
un conjunto de funciones de software cuya relacin debe establecerse en el
modelo lgico. Concretamente, implicar una funcin de cierre de puerta
cuyo tiempo de ejecucin deber ser inferior a tres segundos (aunque en es-
ta fase no se pueda asegurar; ser posteriormente cuando se pueda estimar
y luego comprobar que, efectivamente, ello es posible).
35
Lenguaje Unificado de Modelado (UML)
Rumbaugh y otros (2000), indican que es un lenguaje de modelado vi-

sual que se usa para especificar, visualizar, construir y documentar artefactos
de un sistema de software. Captura decisiones y conocimientos sobre los
sistemas que se deben construir.
Se usa para entender, disear, hojear, configurar, mantener, y controlar
la informacin sobre tales sistemas; y es un "lenguaje de modelado" de pro-
psito general que pueden usar todos los modeladores. No tiene propietario y
est basado en el comn acuerdo de gran parte de la comunidad informtica.
Est pensado para reemplazar a los modelos OMT, Booch y Objectory, y
otros. Se pens para ser tan familiar como sea posible, usar las notaciones
de los ltimos referidos modelos, incorporando buenas prcticas de diseo,
tales como encapsulacin, separacin de los temas, y la captura de la inten-
cin del modelo construido. Pretende abordar los problemas actuales del
desarrollo de software, tales como gran tamao, distribucin, concurrencia,
patrones y desarrollo en equipo.
Se desarroll para hacerlo tan simple como fuera posible, pero mante-
niendo la capacidad de modelar toda la gama de sistemas que se necesita
construir; con la intencin de hacerlo un lenguaje universal, como cualquier
lenguaje de programacin de propsito general.
Vistas de UML
Para Rumbaugh y otros (2000), una vista es simplemente un subconjun-

to de UNL que modela construcciones que representan un aspecto de un
sistema. Se clasifican en tres reas (ver Cuadro 1), las cuales son la clasifi-
cacin estructural, el comportamiento dinmico y la gestin del modelo.
36
Cuadro 1: Vistas y diagramas de UML
Conceptos
rea Vista Diagrama
principales
Diagrama de Clase, asociacin, generalizacin,
Vista esttica
clases dependencia, realizacin, interfaz
Caso de uso, actor, asociacin,
Diagrama de
Vista de casos de uso extensin, inclusin, generaliza-
casos de uso
Estructural cin de casos de uso
Vista de Diagrama de Componente, interfaz,
Vista implementacin componentes dependencia, realizacin
fsica Vista Diagrama de Nodo, componente,
de despliegue despliegue dependencia, localizacin
Diagrama de
Vista de mquina de
estados Estado, evento, transicin, accin
estados
eventos
Diagrama de Estado, actividad, transicin de
Vista de actividad
Dinmica actividad terminacin, divisin, unin
Diagrama de Interaccin, objeto, mensaje, acti-
secuencia vacin
Vista de Interaccin
Diagrama de Colaboracin, interaccin,
colaboracin rol de colaboracin, mensaje
Vista conceptual
Gestin de Diagrama de
gestin del modelo Paquete, subsistema, modelo
Modelo clases
de dominio
Diagrama de
objetos
Extensin Restriccin, estereotipo.
Todas Diagrama
de UML valores etiquetados
cadena valor
Todos
Fuente: Rumbaugh y otros (2000)
La clasificacin estructural describe los elementos del sistema y sus rela-

ciones con otros elementos. Proporcionan la base sobre la cual se construye
el comportamiento dinmico.
El comportamiento dinmico describe el comportamiento de un sistema
en el tiempo, y se puede describir como una serie de cambios a las fotos del
sistema dibujadas a partir de la visin esttica.
La gestin del modelo describe la organizacin de los propios modelos
en unidades jerrquicas. El paquete es la unidad genrica de organizacin
para los modelos.
37
Vista esttica o lgica: Modela los conceptos del dominio de la aplicacin,
as como los conceptos internos inventados como parte de la implementacin de
la aplicacin. Esta visin es esttica porque no describe el comportamiento del
sistema dependiente del tiempo, que se describe en otras vistas. Una clase es la
descripcin de un concepto del dominio de la aplicacin o de la solucin de la
aplicacin. Las clases son el centro alrededor del cual se organiza la vista de cla-
ses; otros elementos pertenecen o se unen a las clases. La visin esttica se ex-
hibe en los diagramas de clases, llamados as porque su objetivo principal es la
descripcin de clases.
Para el caso de esta investigacin, de acuerdo a la Metodologa de ingenie-
ra de Software, denominada Proceso Unificado de Racional (RUP), antes
explicada, se utilizarn las siguientes vistas:
Vistas de caso de uso: Modela la funcionalidad del sistema segn lo perci-
ben los usuarios externos, llamados actores. Un caso de uso, es una unidad
coherente de funcionalidad, expresada como transaccin entre los actores y el
sistema. El propsito de la vista de casos de uso es enumerar a los actores y los
casos de uso, y demostrar cuales actores participan en cada caso de uso.
Vistas fsicas: Son las que modelan la estructura de implementacin de la
aplicacin por s misma, su organizacin en componentes, y su despliegue en
nodos de ejecucin. Estas vistas proporcionan una oportunidad de establecer
correspondencias entre las clases y los componentes de implementacin y no-
dos. Hay dos vistas fsicas, la de implementacin y la de despliegue.
La vista de implementacin modela los componentes de un sistema, a partir
de los cuales se construye la aplicacin, as como las dependencias entre los
componentes, para poder determinar el impacto de un cambio propuesto. Tam-
bin modela la asignacin de clases y de otros elementos del modelo de compo-
nentes.
Por otro lado, la vista de despliegue representa la disposicin de las instan-
cias de componentes de ejecucin en instancias de nodos. Un nodo es un recur-
38
so de ejecucin, tal como una computadora, un dispositivo o memoria. Esta vista
permite determinar las consecuencias de la distribucin y asignacin de recursos.
Vista de mquina de estados: Modela las posibles historias de vida de
un objeto de una clase. Una mquina de estados contiene los estados conec-
tados por transiciones. Cada estado modela un perodo de tiempo, durante la
vida de un objeto, en el que satisface ciertas condiciones. Cuando ocurre un
evento, se puede desencadenar una transicin que lleve el objeto a un nuevo
estado. Cuando se dispara una transicin, se puede ejecutar una accin uni-
da a la transicin. Las mquinas de estados se muestran como diagramas de
estados.
Vista de interaccin: Describe secuencias de intercambios de mensajes en-
tre los roles que implementan el comportamiento de un sistema. Un rol de clasifi-
cador, es la descripcin de un objeto, que desempea un determinado papel den-
tro de una interaccin, distinto de los otros objetos de la misma clase. Esta visin
proporciona una vista integral del comportamiento de un sistema; es decir, mues-
tra el flujo de control a travs de muchos objetos. La vista de interaccin se exhibe
en dos diagramas centrados en distintos aspectos: diagramas de secuencia y
colaboracin.
Vista conceptual de gestin de modelo: Es un modelo mediante el
cual cualquier sistema grande se puede dividir en unidades ms pequeas,
de modo que las personas puedan trabajar con una cantidad de informacin
limitada, a la vez y de modo que los equipos de trabajo no interfieran con el
trabajo de los otros. La gestin de modelos consiste en paquete y relaciones
de dependencia entre paquetes.
Bases Legales
El basamento jurdico que enmarca el desarrollo de polticas pblicas en

las materias de Tecnologas para la Atencin de Emergencias en la Repbli-
39
ca Bolivariana de Venezuela se fundamenta principalmente en la Constitu-
cin de la Repblica Bolivariana de Venezuela (CRBV) (1999), mediante la
cual expresa su artculo 55, los derechos constitucionales para su seguridad
por parte del Estado, de la siguiente manera:
Artculo 55. Toda persona tiene derecho a la proteccin
por parte del Estado a travs de los rganos de seguri-
dad ciudadana regulados por ley, frente a situaciones
que constituyan amenaza, vulnerabilidad o riesgo para
la integridad fsica de las personas, sus propiedades, el
disfrute de sus derechos y el cumplimiento de sus debe-
res () (p. 44)
De igual forma, en el artculo 110 de la misma CRBV, consagra constitu-
cionalmente, la importancia que tiene para el Estado, la Ciencia, Tecnologa
e Innovacin, expuesto as:
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 nece-
sarios por ser instrumentos fundamentales para el
desarrollo econmico, social y poltico del pas, as co-
mo para la seguridad y soberana nacional. Para el fo-
mento y desarrollo de esas actividades, el Estado desti-
nar recursos suficientes y crear el sistema nacional
de ciencia y tecnologa de acuerdo con la ley () (p.
81)
Asimismo, el artculo No. 322 de la CRBV, ordena la participacin de las
empresas para contribuir con el desarrollo integral del Estado, expresado
textualmente de la siguiente manera:
Artculo 322. La seguridad de la Nacin es competencia

esencial y responsabilidad del Estado, fundamentada
en el desarrollo integral de sta y su defensa es res-
ponsabilidad de los venezolanos y venezolanas; tam-
bin de las personas naturales y jurdicas, tanto de de-
recho pblico como de derecho privado, que se encuen-
tren en el espacio geogrfico nacional. (p. 121)
40
La Ley Orgnica de la Administracin Pblica (2001), en su artculo 12,
consagra la prioridad de implementacin de tecnologas y del Internet en la
Administracin Pblica Nacional, como mtodo de simplificacin de trmites,
y prestacin de servicios al pblico, hacindolo textualmente de la siguiente
manera:
Artculo 12. La actividad de la Administracin Pblica se
desarrollar con base en los principios de economa,
celeridad, simplicidad administrativa, eficacia, objetivi-
dad, imparcialidad, honestidad, transparencia, buena fe
y confianza. Asimismo, se efectuar dentro de parme-
tros de racionalidad tcnica y jurdica.
La simplificacin de los trmites administrativos ser ta-
rea permanente de los rganos y entes de la Adminis-
tracin Pblica, as como la supresin de los que fueren
innecesarios, todo de conformidad con los principios y
normas que establezca la ley correspondiente.
A fin de dar cumplimiento a los principios establecidos
en esta Ley, los rganos y entes de la Administracin
Pblica debern utilizar las nuevas tecnologas que
desarrolle la ciencia, tales como los medios electrni-
cos, informticos y telemticos, para su organizacin,
funcionamiento y relacin con las personas. En tal sen-
tido, cada rgano y ente de la Administracin Pblica
deber establecer y mantener una pgina en la internet,
que contendr, entre otra informacin que se considere
relevante, los datos correspondientes a su misin, or-
ganizacin, procedimientos, normativa que lo regula,
servicios que presta, documentos de inters para las
personas, as como un mecanismo de comunicacin
electrnica con dichos rganos y entes disponible para
todas las personas va Internet. (p. 2)
Seguidamente, se encuentra la Ley Orgnica de Ciencia, Tecnologa e
Innovacin (LOCTI) (2005), la cual, se cre inspirada en el anterior artculo
110 de la CRBV, impartiendo el uso que debe ser aplicado a la Tecnologa,
en cuanto al beneficio de la humanidad, cuyo artculo se lee as:
Artculo 5. Las actividades de ciencia, tecnologa, inno-
vacin y sus aplicaciones, as como, la utilizacin de los
resultados, deben estar encaminadas a contribuir con el
41
bienestar de la humanidad, la reduccin de la pobreza,
el respeto a la dignidad, a los derechos humanos y la
preservacin del ambiente. (p. 6)
Por su parte, la Ley Orgnica de Telecomunicaciones (LOT) (2000), la

cual se crea como marco regular de las comunicaciones en el pas, y en su
artculo 5, la considera como tema de inters general, de la siguiente mane-
ra: Artculo 5.- El establecimiento o explotacin de redes de telecomunica-
ciones, as como la prestacin de servicios de telecomunicaciones se consi-
deran actividades de inters general (p. 5)
Tambin se encuentra en la LOT, en el artculo 12, ordinal 5, que expre-
sa que la regulacin de las Telecomunicaciones es atribucin del Estado Ve-
nezolano, y le da a los usuarios de los servicios en dicha rama, una serie de
derechos, de los cuales se encuentran los relacionados con la materia de los
SAE; obligando a los operadores de telecomunicaciones a poner a la dispo-
sicin gratuita de un servicio de llamadas de emergencia, cuyo tema es
abordado en el presente Trabajo de Investigacin, indicado textualmente de
la manera siguiente:
Artculo 12.- En su condicin de usuario de un servicio
de telecomunicaciones, toda persona tiene derecho a:
()
5. Disponer de un servicio gratuito de llamadas de
emergencia, cualquiera que sea el operador responsa-
ble de su prestacin y con independencia del tipo de
terminal que se utilice. El enrutamiento de las llamadas
a los servicios de emergencia ser a cargo del opera-
dor. (p. 7)
Ahora bien, la Ley de Coordinacin de Seguridad Ciudadana (LCSC)
(2001), establece que los Organismos de Seguridad, inclusive los SAE, de-
ben establecer la aplicacin de Sistemas de Informacin, en beneficio del
desempeo de sus funciones, para lo cual se cre el Sistema Nacional de
Registro Delictivo, Emergencias y Desastres con la finalidad que los rganos
de Seguridad cuenten con ese Sistema de Informacin, para complementar
42
sus funciones. Se extraen los siguientes artculos 3 ordinal 4, 29, 33 al 38 de
la LCSC, que dicen textualmente lo siguiente:
Artculo 3. Corresponde a los rganos de seguridad
ciudadana, sin perjuicio de las competencias estableci-
das por la Ley que los regule: ()
4. Organizar y desarrollar sistemas informticos, comu-
nicacionales, administrativos y de cualquier otra natura-
leza que permitan optimizar la coordinacin entre los
distintos rganos de seguridad ciudadana.
Artculo 29. Se crea el Sistema Nacional de Registro
Delictivo, Emergencias y Desastres con la finalidad que
los rganos de seguridad ciudadana dispongan de un
sistema de informacin que facilite la debida planifica-
cin, formulacin y ejecucin integral de los planes, es-
trategias y acciones de seguridad ciudadana.
Artculo 33. El Ministerio del Interior y Justicia organiza-
r y administrar un sistema de informacin automati-
zado que permitir a los integrantes del Sistema Nacio-
nal de Registro Delictivo, Emergencias y Desastres en
sus respectivos mbitos de actuacin, disponer de la in-
formacin relacionada con cada mdulo del sistema en
una base de datos central.
Artculo 34. El servicio telefnico del Sistema de Emer-
gencia Nacional 171 o el que contemple la ley respecti-
va, estar bajo la administracin de los entes Coordina-
dores de Seguridad Ciudadana y tendr entre sus fun-
ciones apoyar y complementar el Sistema Nacional de
Registro Delictivo, Emergencias y Desastres.
Artculo 35. Los integrantes del Sistema Nacional de
Registro Delictivo, Emergencias y Desastres organiza-
rn y activarn en sus respectivas instalaciones una
unidad administrativa responsable de la recopilacin,
organizacin, remisin e insercin de la informacin re-
lacionada con cada mdulo en la base de datos del sis-
tema de informacin previsto en este Decreto Ley.
Artculo 36. La Coordinacin Nacional de Seguridad
Ciudadana y las Coordinaciones Regionales de Seguri-
dad Ciudadana, como administradores de las bases de
datos de sus respectivas localidades, procesarn la da-
ta e informacin suministrada por los integrantes del
sistema y generarn los reportes de informacin rela-
43
cionados con el comportamiento de la accin delictiva,
emergencias y situaciones de desastres.
Artculo 37. Las informaciones y documentos derivados
del procesamiento de informacin realizado por el Sis-
tema Nacional de Registro Delictivo, Emergencias y
Desastres sern agrupados, segn su contenido, en
clasificados y no clasificados. La organizacin, la admi-
nistracin y el manejo de los clasificados se regirn por
la ley que rige la materia, y los no clasificados estarn a
la disposicin de las autoridades o personas interesa-
das.
Artculo 38. Los medios, instrumentos y recursos tecno-
lgicos empleados por el Sistema Nacional de Registro
Delictivo, Emergencias y Desastres para el cumplimien-
to de la finalidad enunciada en este Decreto Ley, estn
reservados a los rganos del Poder Pblico Nacional,
Estadal y Municipal. (p. 13, 20, 22, 23)
El Presidente de la Repblica, firm el Decreto con fuerza de Ley No.
3.390, para el Uso de Software Libre en la Administracin Pblica Nacional
(D3390) (2004), en el cual establece el uso estandarizado del Software Libre,
como poltica de Estado, tal como se lee en el artculo 1 que dice lo siguiente:
Artculo 1. La Administracin Pblica Nacional emplea-
r prioritariamente Software Libre desarrollado con Es-
tndares Abiertos, en sus sistemas, proyectos y servi-
cios informticos. A tales fines, todos los rganos y en-
tes de la Administracin Pblica Nacional iniciarn los
procesos de migracin gradual y progresiva de stos
hacia el Software Libre desarrollado con Estndares
Abiertos. (p. 336.626)
En el Decreto con fuerza de Ley No. 825 para el uso prioritario de Inter-
net por los Entes de la Administracin Pblica (D825) (2000), se estableci
la aplicacin de Internet para la prestacin de sus servicios, lo cual es consi-
derado ampliamente en el desarrollo de esta propuesta, basado en los ar-
tculos 1 al 3 del Decreto, los cuales se expresan as:
Artculo 1: Se declara el acceso y el uso de Internet
como poltica prioritaria para el desarrollo cultural, eco-
44
nmico, social y poltico de la Repblica Bolivariana de
Venezuela.
Artculo 2: Los rganos de la Administracin Pblica
Nacional debern incluir en los planes sectoriales que
realicen, as como en el desarrollo de sus actividades,
metas relacionadas con el uso de Internet para facilitar
la tramitacin de los asuntos de sus respectivas com-
petencias.
Artculo 3: Los organismos pblicos debern utilizar
preferentemente Internet para el intercambio de infor-
macin con los particulares, prestando servicios comu-
nitarios a travs de Internet, tales como bolsas de tra-
bajo, 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 () (p.
345.502)
Igualmente, la Resolucin No. 321 (2006) del Ministerio del Poder Popu-
lar para la Ciencia y Tecnologa, en acatamiento de las anteriores Leyes y
Decretos, en su artculo 2, dispone las normativas de adquisicin de Hardwa-
re de Tecnologas Libres por parte los Entes de la Administracin Pblica
Nacional, con la manera expuesta a continuacin:
Artculo 2: Los rganos y entes de la Administracin
Pblica Nacional deben implantar modelos de arquitec-
tura de hardware que permitan la interoperatibilidad con
el resto de las plataformas existentes en los organis-
mos de la Administracin Pblica Nacional, de prefe-
rencia considerar modelos de arquitectura abierta te-
niendo en consideracin el decreto No. 3.390. (p.
345.502)
Sistemas de Variables de la Investigacin
Variable Independiente
Sistema de Informacin: es un sistema integrado usuario-mquina para

proporcionar informacin que soporte las funciones de operacin, administra-
45
cin, anlisis y toma de decisin en una organizacin. Est integrado por cin-
co componentes, los cuales son: hardware; software; procedimientos manua-
les de aplicacin modelos para anlisis, planeacin, control y toma de deci-
siones; recursos humanos y las base de datos, cuyos elementos deben inter-
relacionarse integralmente entre s, para que los administradores, gerentes o
directivos, puedan ejercer acciones de tomas de decisiones con los resulta-
dos generados de las funciones del sistema.
Variable Dependiente
Ingeniera de requisitos: es la documentacin impresa conformada por

el diseo de modelo de datos junto con el documento de definicin de requi-
sitos, la cual ser desarrollada mediante la metodologa de desarrollo de
Software denominada Proceso Unificado de Racional (RUP) (2001), luego de
realizar la revisin de la documentacin correspondientes, y el registro hist-
rico de la informacin aportada por los usuarios del Sistema de Informacin
de Atencin de Emergencias, diseado en el presente Trabajo de Investiga-
cin.
Definicin de Trminos Bsicos
Arquitectura Software: Descripcin de los mdulos de un sistema de soft-

ware y su relacin.
Baseline: es una instantnea del estado de todos los artefactos de la Meto-
dologa de desarrollo de Software, registrada para efectos de gestin de
configuracin y control de cambios.
Bases de Datos: Una base de datos o banco de datos es un conjunto de
datos pertenecientes a un mismo contexto y almacenados sistemtica-
mente para su posterior uso.
46
Bases de datos Orientadas a Objetos: la informacin se representa me-
diante objetos como los presentes en la programacin orientada a obje-
tos.
Comunicacin: Transmisin de mensajes entre personas.
Documento de Requisitos de Sistema (DRS): consiste en la construccin
de un modelo lgico del SI, describiendo las funciones que sean necesa-
rias y las relaciones entre ellas, suponiendo que no existen limitaciones
de recursos.
Documento de Requisitos de Usuario (DRU): constituye el documento ba-
se para que, al final del desarrollo, el sistema sea aceptado por el usua-
rio.
Escalabilidad: posibilidad de incrementar sustancialmente el nmero de
usuarios u otros parmetros.
GPS: Global Positioning System (GPS): Sistema de Posicionamiento Glo-
bal, el cual permite determinar en todo el mundo la posicin de un objeto,
una persona, un vehculo o una nave, con una precisin.
Hardware: corresponde a todas las partes fsicas y tangibles de una compu-
tadora, sus componentes elctricos, electrnicos, electromecnicos y
mecnicos.
IEEE (Institute of Electrical and ElectronicsEngineering): Instituto de In-
genieros Elctricos y Electrnicos. Organizacin profesional de EEUU.
Informacin: es cualquier seal o input capaz de cambiar el estado de un
sistema constituye un pedazo de informacin.
Informtica: disciplina encargada del estudio de mtodos, procesos, tcni-
cas, desarrollos y su utilizacin en ordenadores (computadores) con el fin
de almacenar, procesar y transmitir informacin y datos en formato digi-
tal.
47
Ingeniera: es el conjunto de conocimientos y tcnicas cientficas aplicadas,
que se dedica a la resolucin u optimizacin de los problemas que afec-
tan directamente a la humanidad.
Manejador de Bases de Datos: es una coleccin de numerosas rutinas de
software interrelacionadas, cada una de las cuales es responsable de al-
guna tarea especfica.
Mantenibilidad: facilidad para que el sistema evolucione y se modifique una
vez entregado al usuario.
Modelo: es un generador de potenciales configuraciones de sistemas.
Modelo Lgico: se entiende la identificacin de las funciones de software
requeridas para satisfacer los requisitos del usuario.
Programacin Orientada a Objeto: se refiere a un mtodo de programacin
y al diseo del lenguaje, en donde los datos y el cdigo (funciones o m-
todos) se combinan en entidades llamadas objetos.
Red inalmbrica (Wi-Fi): son aquellas que se comunican por un medio de
transmisin no guiado (sin cables) mediante ondas electromagnticas. La
transmisin y la recepcin se realiza a travs de antenas.
Redes informticas: conjunto de equipos conectados por medio de cables,
seales, ondas o cualquier otro mtodo de transporte de datos, que
comparten informacin, recursos y servicios, entre otros.
Requisitos funcionales: aquellos ligados a la relacin entre datos de entra-
da y sus datos de salida como resultados, que debe presentar el sistema,
incluidos los derivados de restricciones temporales cuando stas estn
cuantificadas).
Requisitos no funcionales: incluyen todos los aspectos de calidad del sis-
tema: por ejemplo, mantenibilidad, escalabilidad, facilidad de uso, etc.
Sistema: es un conjunto de elementos dinmicamente relacionados forman-
do una actividad para alcanzar un objetivo operando sobre datos, energa
o materia para proveer informacin.
48
Sistema de informacin: es un conjunto de elementos orientados al trata-
miento y administracin de datos e informacin, organizados y listos para
su posterior uso, generados para cubrir una necesidad u objetivo.
Software: es el conjunto de los programas de cmputo, procedimientos, re-
glas, documentacin y datos asociados que forman parte de las opera-
ciones de un sistema de computacin.
Software Libre: Programa de computacin cuya licencia garantiza al usuario
acceso al cdigo fuente del programa y lo autoriza a ejecutarlo, modifi-
carlo y redistribuir con cualquier propsito, sin tener que pagar regalas a
los desarrolladores previos.
Software Propietario: Programa de computacin cuya licencia establece
restricciones de uso, redistribucin o modificacin por parte de los usua-
rios, o requiere de autorizacin expresa del Licenciador.
Tecnologa: Aplicacin de los conocimientos cientficos para facilitar la reali-
zacin de las actividades humanas. Supone la creacin de productos,
instrumentos, lenguajes y mtodos al servicio de las personas.
Tecnologas de la Informacin y la Comunicacin (TIC): es el conjunto de
avances tecnolgicos que nos proporcionan la informtica, las telecomu-
nicaciones y las tecnologas audiovisuales.
Telecomunicaciones: tcnica de transmitir un mensaje desde un punto a
otro, normalmente con el atributo tpico adicional de ser bidireccional,
mediante los satlites, la telefona y los dispositivos WiFi.
Telemtica: rea de conocimiento que forma parte de la informtica, puesto
que sta engloba a todos los tratamientos que se realicen sobre la infor-
macin de manera automtica y la comunicacin es un intercambio de in-
formacin.
49
CAPTULO III
Marco Metodolgico
Modalidad y Tipo de la Investigacin
Modalidad de la Investigacin
De acuerdo con el problema referido al anlisis del SAE en el Estado M-
rida, la investigacin fue de tipo proyecto factible apoyado de la investigacin
de campo. Para Rodrguez y Pineda (2003) el proyecto factible constituye la
sntesis del proceso de transformacin de una parcela de la realidad, al cubrir
un vaco de necesidad, empleando el paradigma de los modelos... (p. 80).
En el caso de la presente investigacin, se dise la solucin al problema
planteado en el Servicio de Atencin de Emergencia (SAE), en cuanto al Sis-
tema de informacin; adems, se apoya en la investigacin de campo, la
cual, igualmente para los referidos autores, aplica el conocimiento en la re-
cabacin de datos de problemas reales y en las condiciones en que apare-
cen... (p. 80).
Se aplicaron diagnsticos para conocer con exactitud las fallas que se
desean corregir, mediante una observacin directa y manteniendo un contac-
to directo con el personal que trabaja en el servicio. Se encontraron presen-
tes fallas en la saturacin de las lneas telefnicas entrantes las cuales son
insuficientes para atender el volumen de llamadas entrantes; no existe un
software de gestin de emergencias; y no existe un mtodo alterno para re-
portar las llamadas de emergencias.
Finalmente, se complementa con la investigacin documental, que segn
Rodrguez y Pineda, se refiere al desarrollo de las capacidades reflexivas y
50
crticas a travs de la interpretacin, anlisis y confrontacin de los informes
recogidos... (p. 82).
Tipo de Investigacin
El tipo de estudio que se aplic para el presente proyecto es el descripti-
vo, el cual est definido por Rodrguez y Pineda como un estudio que busca
caracterizar, precisar o determinar condiciones o caractersticas concurrentes
en el hecho o problema (...) (p. 83)
Se dise un modelo de los datos y se propuso una Ingeniera de Requi-
sitos para desarrollar un Sistema de Informacin de Atencin de Emergen-
cias, que d una mxima respuesta efectiva al menor tiempo posible por par-
te del SAE y de los Organismos de Seguridad; que disminuya los ndices de
inseguridad; y adems que opere en plataforma cliente-servidor en una ex-
tranet bajo tecnologas libres; mediante una metodologa moderna de Inge-
niera de Software denominada Proceso Unificado de Racional (RUP), en
cuyos procesos se encuentra la Ingeniera de Requisitos, junto a la represen-
tacin grfica del software y su arquitectura, mediante los diagramas del
Lenguaje Unificado de Modelado UML.
Fases de la Investigacin
En atencin a esta modalidad de investigacin, se introdujeron cinco fa-

ses en el estudio, a fin de cumplir con los requisitos involucrados en un pro-
yecto factible (ver Cuadro 2). El cumplimiento de las fases abarcaron un es-
pacio de diez meses, a partir del mes de noviembre de 2008, mes en que se
dio inici a las revisiones bibliogrficas y los diagnsticos correspondientes,
quedando descritas las fases de la siguiente manera:
51
Cuadro 2: Fases del Trabajo de Investigacin
Fases del Meses

DDR y MD 1 2 3 4 5 6 7 8 9 10
Fase I: Revisin de Literatura
Fase II: Diagnstico del Funciona-
miento del actual SI
Fase III: Diseo del Modelado
Fase IV: Definicin de Requisitos
Fase I: Revisin de Literatura
Inicialmente, se hizo una revisin del funcionamiento del actual Sistema

de Informacin en el Servicio de Atencin de Emergencias (SAE) 171, atri-
buciones correspondientes al extinto Servicio Autnomo de Telecomunica-
ciones del Estado Mrida (SATEM), hoy Direccin del Poder Popular para las
Telecomunicaciones e Informtica (DppTI); para obtener toda la informacin
requerida y as conocer los fundamentos tericos y legales, que permitan
desarrollar una propuesta tecnolgica en los SAE en Venezuela; evaluando
todos los registros documentales bibliogrficos y no bibliogrficos, a travs
textos especializados; leyes; proyectos nacionales; sitios web contentivos de
las experiencias de los SAE nacionales e internacionales; trabajos afines rea-
lizados en otros proyectos de investigacin; y los informes con registros es-
tadsticos de los aos anteriores al 2008 inclusive.
Fase II: Diagnstico del Funcionamiento del actual SI
Seguidamente, se diagnostic el funcionamiento del actual Sistema de

Informacin del Servicio de Atencin de Emergencias (SAE) 171, en el ex-
52
tinto SATEM, hoy DppTI, mediante la realizacin de una exhaustiva observa-
cin directa (ver Anexo A), detallndose el funcionamiento de los procesos
correspondientes al SAE; visualizndose el funcionamientos de los equipos
de procesamiento de datos, mtodo de trabajo, detallando y documentando
los procedimientos actuales desde que los usuarios realizan las llamadas.
Tambin se obtuvo informacin aportada por los trabajadores en la sede
administrativa de la extinta SATEM, hoy DppTI, mediante los cuales se regis-
traron los datos de entrevistas realizadas a los operadores, despachadores,
supervisores, personal informtico, administrativo y Directora General de la
Institucin (ver Anexo B), concernientes al funcionamiento del actual Sistema
de Informacin del SAE 171 Mrida.
Fase III: Diseo del Modelado
Posteriormente, se dise el modelado de datos del Sistema de Informa-

cin de Atencin de Emergencias (SIAEM); que permiti determinar las es-
tructuras de datos de la base, sus restricciones de integridad, y las operacio-
nes de manipulacin de los datos, integrndose los diferentes actores pbli-
cos y privados que formaran parte del Sistema de Informacin, aplicando el
criterio de inters pblico y seguridad de la nacin.
Fase IV: Definicin de Requisitos
Finalmente, se elabor el Documento de Definicin de Requisitos para

desarrollar el SIAEM, el cual permitir disminuir ampliamente los ndices de
inseguridad en el pas, con acciones mancomunadas entre los rganos de
Seguridad Ciudadana de los Gobiernos Nacional, Estadales y Municipales;
aplicando una metodologa de desarrollo de Software denominada Proceso
Unificado de Racional (RUP) (2001), junto a la representacin grfica del
53
software y su arquitectura, mediante los diagramas de modelado de sistemas
del Lenguaje Unificado de Modelado (UML).
Operacionalizacin de las Variables
Las variables dependiente e independiente identificadas en esta Investi-

gacin correspondiente a la Ingeniera de Requisitos para el desarrollo de un
Sistema de Informacin en los Servicios Estadales de Atencin de Emergen-
cias, se representan en el siguiente Cuadro 3:
Cuadro 3: Tabla de operacionalizacin de las variables
OBJETIVO VARIABLE DE
VARIABLES INDICADORES
GENERAL MEDIDA
Independiente: -Hardware -No. de equipos
Sistema de con tecnologa de
Informacin punta
-Mdulos desarrollados -No. de mdulos
del SIAE desarrollados
-Procedimientos -No. de procesos
-Recursos humanos -No. de personas
Ingeniera de Requi- -Base de datos -No. de registros
sitos para el desa- de datos efectivos
rrollo de un Sistema -Instalaciones -No. de oficinas
de Informacin en -Materiales -No. de materiales
los Servicios Esta- Dependiente:
dales de Atencin Ingeniera de -Documentacin revisa- -No. de documen-
de Emergencias Requisitos da tos
-Registro histrico -No. de instrumen-
-Metodologa de desa- tos
rrollo de software -No. de fases de la
-Modelo de Datos metodologa
-Documento de defini- -No. de esquemas
cin de requisitos -No. de diagramas
UML
54
Poblacin y Muestra
Poblacin 1, Sistema de Informacin actual
Sabino (1996), la define como cualquier grupo de individuos que posean

una ms caractersticas en comn de inters para el investigador, la pobla-
cin puede estar constituida por todos los individuos de un particular tipo o
por una parte ms restringida de ese grupo (p. 115). De lo que se puede
deducir que la poblacin constituye el universo de la totalidad de los elemen-
tos que se estudiarn.
La poblacin est compuesta por el Sistema de Informacin actual inope-
rativo desde el ao 2008, contndose como fuente de informacin, con se-
senta (60) trabajadores entre personal operativo, directivo, administrativo e
informtico, que componen el total del personal adscrito a SATEM (ver Cua-
dro 4), Institucin que dirige el SAE en Mrida. Esta poblacin se caracteriza
por ser homognea, determinados por normas y cadena mando que estable-
ce un comportamiento estandarizado y predeterminado; con un tamao to-
talmente finito limitado a una nmina de trabajadores legalmente establecida;
y se pueden ubicar sus miembros ya que estn establecidos organizacional-
mente en la Institucin a la que pertenecen.
Cuadro 4: Poblacin y muestra de los Usuarios del actual Sistema de Informacin

Clasificacin Poblacin Muestra
Directora General 1 1
Coordinador 171 1 1
Asistentes 171 2 1
Supervisores 6 3
Operadores 24 8
Despachadores 12 4
Trunking 6 3
Telemtica 8 4
Total trabajadores: 60 25
Porcentajes: 100% 41,7%
Fuente: Propia (Ao 2.008)
55
Para Arias (1999), la muestra es una parte representativa de una pobla-
cin, cuyas caractersticas deben reproducirse en ella lo ms exactamente
posible (p. 127). De lo que se determina que la muestra es solo una parte
del total de la poblacin a someterse a estudio, lo cual se puede considerar
que es perfectamente representativo de la referida poblacin. La muestra se
extrae cuando no hay posibilidades de medir a la totalidad de la poblacin.
En consecuencia, el espacio muestral del Servicio de Atencin de Emer-
gencias (SAE) 171 en el extinto Servicio Autnomo de Telecomunicaciones
del Estado Mrida (SATEM), lo componen 25 trabajadores a los cuales se les
realizaron las entrevistas, que corresponden el 41,7% de la totalidad de la
poblacin constituida por 60 trabajadores.
Asimismo, se realizaron las observaciones directas a las salas operati-
vas, de despacho, administrativas y de supervisin del SAE.
Para la seleccin de la muestra se aplicaron tcnicas de muestreo pro-
babilstico o aleatorio simple, debido a que los sujetos que fueron sometidos
al estudio, se seleccionaron sin predeterminacin alguna por parte del inves-
tigador; sino por el contrario las personas que se encontraban de turno en su
trabajo, hasta completar el 53% del total de la poblacin.
Tcnicas e Instrumentos de Recoleccin de Datos
Para el desarrollo de esta investigacin fue necesario utilizar herramien-

tas que permitieron recolectar el mayor nmero de informacin necesaria (ver
Cuadro 5), con el fin de obtener un conocimiento ms amplio de la realidad
de la problemtica, aplicndose la revisin bibliogrfica, observacin directa,
as como entrevistas a los trabajadores mediante cuestionarios de preguntas
abiertas, y as poder determinar sus causas para luego determinar la proble-
mtica existente en el SAE en cuanto al Sistema de Informacin, y todas las
necesidades que deberan ser consideradas en la propuesta final.
56
Cuadro 5: Tcnicas e Instrumentos de Recoleccin de Datos
Tcnica Instrumento
Fichas bibliogrficas, textos, Internet,
Revisin bibliogrfica
manuales, informes de gestin
Observacin directa Hoja de Observacin (Anexo A)
Entrevista Cuestionario de preguntas (Anexo B)
La revisin bibliogrfica permiti obtener toda la informacin requerida

para conocer los fundamentos tericos y legales, y desarrollar una propuesta
tecnolgica en los SAE en Venezuela; evaluando todos los registros docu-
mentales bibliogrficos y no bibliogrficos, a travs textos especializados;
leyes; proyectos nacionales; sitios web contentivos de las experiencias de los
SAE nacionales e internacionales; trabajos afines realizados en otros proyec-
tos de investigacin; y los informes con registros estadsticos de los aos
anteriores al ao 2.008 inclusive.
Segn Hurtado y Toro (2001), la observacin es la tcnica de investiga-
cin por excelencia, es un principio y validacin de todas las teoras cientfi-
cas, equivale a mirar detalladamente, es la forma ms usada para obtener
informacin del mundo que les rodea (p. 198). La observacin directa aport
la informacin concerniente al funcionamiento del actual Sistema de Informa-
cin del SAE 171 Mrida, en los meses de septiembre, octubre y noviembre
del ao 2008, que equivalen a tres (3) meses, durante todos los das hbiles
y tres das de fines de semana, en las oficinas del SAE 171 Mrida, durante
las jornadas de trabajo rutinarias, con alta presin, con acciones en vivo y en
caliente, atendiendo y despachando unidades de atencin de emergencias;
visualizndose el funcionamiento de los equipos de procesamiento de datos
57
y el mtodo de trabajo, detallando y documentando los procedimientos actua-
les desde que los ciudadanos realizan las llamadas.
Arias (2006), define las entrevistas, como una tcnica basada en un dia-
logo o conversacin, entre el entrevistador y entrevistado acerca de un tema
previamente determinado, de tal manera que el entrevistador pueda obtener
la informacin requerida (p. 73). Igualmente, Sierra (1996), el cuestionario
es un conjunto de preguntas preparado cuidadosamente, sobre los hechos y
aspectos que interesan a una investigacin. (p. 202). En esta investigacin,
las entrevistas realizadas con cuestionarios de preguntas abiertas, permitie-
ron registrar los datos de entrevistas a los operadores, despachadores, su-
pervisores y Directora General de la Institucin, en la sede administrativa de
la extinta SATEM, ubicada en la parte trasera de la sede de INPRADEM, con
ambientes cordiales, ampliamente cordial y con alta disposicin a colaborar y
aportar ideas.
Tcnicas de Anlisis
Tcnicas de Anlisis Cuantitativas
Para Tamayo (2003), son la medicin de variables en funcin de la

magnitud, extensin o cantidad (p. 151). Para el procesamiento de la infor-
macin, se agrupan y se clasifican los datos con la finalidad de generar grfi-
cos para la toma de decisiones, utilizando la entrevista semi-estructurada
como el instrumento que permiti determinar la Ingeniera de Requisitos para
el desarrollo del Sistema de Informacin para la Atencin de Emergencias,
que se propone aplicar en el Servicio de Atencin de Emergencias (SAE) de
cualquier parte del pas, con irradiacin internacional a los SAE de otros pa-
ses.
58
Tcnicas de Anlisis Cualitativas
El mismo autor Tamayo, la define como la distribucin de una clase de

objetos a otra segn el tipo de la especie y no por la magnitud de los mis-
mos (p. 151). A travs de estas tcnicas se pudo analizar el SAE del Estado
Mrida, el flujo de procesos as como el desempeo de sus trabajadores,
tomando como fuente de informacin la que se obtuvo a travs de las entre-
vistas realizadas y la observacin directa, indicndose de manera crtica el
comportamiento de las variables estudiadas; igualmente como en el caso de
las anteriores tcnicas de anlisis, permitieron aportar insumos de desarrollo
de la Ingeniera de Requisitos para el desarrollo del Sistema de Informacin
para la Atencin de Emergencias, que se plantea con esta investigacin, en
el Servicio de Atencin de Emergencias (SAE) de cualquier ente estadal de
Venezuela, con irradiacin internacional a los SAE de otros pases.
59
CAPTULO IV
RESULTADOS
Diagnstico del Funcionamiento del Sistema de Informacin del

SAE 171 del Estado Mrida
Inicialmente se registraron los datos de la observacin directa en las ofi-

cinas del SAE, para conocer el funcionamiento de los equipos de procesa-
miento de datos, mtodo de trabajo, normas y procedimientos, y cualquier
elemento que sea necesario considerar en el desarrollo de la Investigacin.
El instrumento utilizado fue la hoja de observacin, la cual consisti en
prestar atencin acuciosa al funcionamiento en caliente de las salas de ope-
radores, despachadores, supervisin, departamento de Truncking y coordi-
nacin, las cuales son las reas operativas y administrativas del SAE 171
Mrida y registrar todo lo observado.
Igualmente se registraron los datos de las entrevistas realizadas a los
operadores, despachadores, supervisores, personal informtico, administrati-
vo y Directora General de la Institucin, concernientes al funcionamiento del
actual Sistema de Informacin del SAE 171 Mrida.
Este instrumento de entrevista, fue un cuestionario adaptativo, el cual se
dise en base a diez (10) preguntas realizadas al espacio muestral, cons-
tante de veinticinco (25) trabajadores, entre los cuales se tiene a una directo-
ra, un coordinador, un administrativo, tres supervisores, ocho operadores
telefnicos, cuatro despachadores de unidades, tres tcnicos de telecomuni-
caciones del departamento de red troncalizada (Trunking) y cuatro profesio-
nales del rea de sistemas telemticos; cuyas preguntas estaban relaciona-
das con los procesos que se llevan a cabo en el SAE 171.
60
Se procedi al anlisis de resultados obtenidos de las anteriores herra-
mientas, aplicndose las tcnicas de anlisis cualitativas y cuantitativas a
que se hizo referencia en el anterior Captulo II, tabulndose y representn-
dose grficamente cada uno de los resultados obtenidos con los datos apor-
tados por los sujetos sometidos a las preguntas, los cuales permitieron reco-
lectar el mayor nmero de informacin necesaria, con el fin de obtener un
conocimiento ms amplio de la realidad de la problemtica, y as poder de-
terminar sus causas, lo cual facilit detectar la situacin actual del SAE, con
respecto al Sistema de Informacin actual para la Atencin de Emergencias a
travs del discado 171.
Observacin Directa
De las observaciones directas realizadas en las oficinas del SAE 171 de
Mrida, se obtuvo la siguiente informacin:
El SAE posee equipos de alta tecnologa, tales como computadoras de
ltima generacin, sistema troncalizado y Wi-Fi; sistema de grabacin de las
llamadas recibidas. Tambin recibe ms atencin por parte del Ejecutivo Re-
gional; por la alta prioridad de la Seguridad Ciudadana en la asignacin de
recursos presupuestarios; adems de estar ubicado en la estructura organi-
zacional descentralizada en la Gobernacin del Estado Mrida; y por las ex-
celentes relaciones existentes con el Gobierno Nacional.
Asimismo, se determin que el SAE tiene el monopolio de los Servicios
de Atencin de Emergencia en Mrida; posee Hospedaje de Pgina Web y
Servicio de correo electrnico; hay coordinacin con otros organismos pbli-
cos y privados; existe alta disposicin de parte del MppRIJ, MppCyT, Funda-
cite y Cenditel Mrida en contribuir con la Institucin; se cuentan con una
amplia legislacin que apoya la Seguridad Ciudadana y la Ciencia, Tecnolo-
ga e Innovacin; el MppRIJ desarrolla proyecto de automatizacin para los
SAE de cada Estado; hay disponibilidad de uso del Satlite Simn Bolvar
61
VENESAT1, y los de los convenios internacionales; la Alta prioridad de la
Ciencia, Tecnologa e Innovacin para el uso en la Administracin Pblica
Nacional; y la existencia de la Zona Libre, Cientfica, Cultural y Tecnolgica
del Estado Mrida.
De igual forma, se observ que las unidades de los Organismos de Se-
guridad del Estado que la integran no prestan su servicio directamente desde
el SAE; sino desde su correspondiente sede; no cuenta con un Mdico de
guardia; no existe sistema GPS; cada organismo de seguridad desempea
su respectiva funcin autnomamente; no posee interconexin con los dife-
rentes organismos de seguridad de los estados vecinos; No hay acceso on-
line a los datos de los distintos Organismos de Seguridad, metereolgicos,
telefona pblica y privada; nacionales e internacionales (S.I.P.O.L., informa-
cin Meteorolgica, registro de abonados de telefona pblica y privada); no
posee un sistema de inteligencia para verificar y sancionar las llamadas de
sabotaje; la razn social de la DppTI, no es compatible con las funciones de
Atencin de Emergencias; escaso personal en el rea tecnolgica y la estruc-
tura fsica est sin ventilacin dependiendo totalmente de aire acondicionado.
Tambin, se observ que existe poca credibilidad en el sistema de aten-
cin de emergencias por parte del pblico; deficiencias presupuestarias en el
situado constitucional del Estado Mrida; altos ndices de inseguridad; altos
ndices de llamadas de sabotaje; divisin de recursos presupuestarios entre
Teleinformtica y Seguridad Ciudadana; perfil de Direccin difcil de acoplar-
se en la conduccin de dos reas del conocimiento incompatibles entre s
(Seguridad Ciudadana y Tecnologa).
Entrevistas
A continuacin se presentan los resultados obtenidos en las entrevistas a
los trabajadores que prestan el SAE en Mrida:
62
En relacin a la pregunta N 1: An existe el sistema de informacin (SI)
en el Servicio de Atencin de Emergencias (SAE)?, se observ lo siguiente:
Cuadro 6: Existencia de Sistema de Informacin en SAE Mrida
Opciones S No
Respuestas 23 2
Porcentajes 92% 8%
S
No
Figura 12: Representacin grfica del cuadro 1,

existencia de SI en SAE Mrida
Segn el Cuadro 6 y Figura 12, se determin que el 92% de los encues-

tados s conocen sobre la existencia de un Sistema de Informacin, ya que
son trabajadores que operaron el referido sistema hasta mediados del ao
2008, y conocen su funcionamiento mientras estuvo operativo y prestando
servicio en la atencin de emergencia.
63
La pregunta N 2 formul si: Est operativo el actual SI del SAE? arro-
jndose como resultados lo siguientes:
Cuadro 7: Operatividad del Sistema de Informacin actual
Opciones S No
Respuestas 0 25
Porcentajes 0% 100%
0%
S
No

operatividad del SI actual
En el Cuadro 7 y Figura 13, se determin que el 100% de los encuesta-

dos afirman categricamente, que no se encuentra operativo el SI para la
atencin de emergencias que estuvo funcionando hasta mediados del ao
2008. De estas respuestas se deduce que a pesar de que existe en los servi-
dores de SATEM un SI, no hay ningn software que se encuentre funcionan-
do en alguna instancia del SAE.
64
Seguidamente, la pregunta N 3 que dice Cules son las principales fa-
llas que estn presentes en el actual SI del SAE?, con la cual se determina-
ron los siguientes resultados:
Cuadro 8: Fallas del Sistema de Informacin actual
Opciones Privativo Lentitud Incompleto Disfuncional complicado Ineficiencia Inestable

Respuestas 20 20 15 6 6 5 3
Porcentajes 26,7% 26,7% 20% 8% 8% 6,6% 4%
26,7% 26,7%
20,0%
8,0% 8,0%
6,6%
4,0%
Lentitud
complicado
Privativo
Incompleto
Disfuncional
Inestable
Ineficiencia

fallas del SI actual
De acuerdo el Cuadro 8 y Figura 14, los encuestados expusieron las tres

principales fallas que posee el actual SI inoperativo desde el ao 2008, las
cuales son: en primer lugar que es un programa que funciona lento (26,7%);
adems que es un software privativo imposible de modificar o mejorar sin el
consentimiento de su autor (26,7%); est incompleto ya que les faltan funcio-
nes para el SAE (20%). Aqu se determin que por las fallas principales ex-
puestas, el SI actual es un sistema que no ha sido ampliado ni evolucionado,
para hacerlo ms eficiente al momento de atender una llamada de emergen-
cia.
65
De la pregunta N 4 que formula la pregunta Qu hay que hacer con el
SI del SAE?, se determin:
Cuadro 9: Necesidad de un nuevo Sistema de Informacin
Opciones Hacer uno Reactivar el

nuevo actual
Respuestas 22 3
Porcentajes 88% 12%
Nuevo
Reactivar

necesidad de un nuevo SI
Con el Cuadro 9 y Figura 15, se conoci que el 88% de los trabajadores

encuestados opinan que es necesario que en el SAE se implemente un Sis-
tema de Informacin (SI). Esto indica la opinin de que es urgente la necesi-
dad de implementar un Sistema de Informacin en el SAE, descartando el
actual que no est operativo.
66
Asimismo, con la pregunta N 5: Cules son los objetivos que debe
perseguir el SI del SAE?, se explan lo siguiente:
Cuadro 10: Objetivos del nuevo Sistema de Informacin
Opciones Rapidez colabo- Integra- Sencillo Tecnol. Decisin centralizado descentrali-

rador dor Libres zado
Respuestas 24 13 13 9 8 4 2 2
Porcentajes 32% 17,3% 17,3% 12% 10,7% 5,3% 2,7% 2,7%
32,0%
17,3%
17,3%
12,0% 10,7%
5,3%
2,7% 2,7%
Rapidez
Decisin
centralizado
Sencillo
descentralizado
colaborador
Integrador
Tecnol. Libres
Figura 16: Representacin grfica del cuadro 5, objetivos del nuevo SI
En relacin al Cuadro 10 y Figura 16, se determinaron los tres principa-

les objetivos que debe perseguir un SI en el SAE, los cuales son los siguien-
tes: debe proporcionar rapidez en sus funciones (32%); que colabore con
todos los entes que participan en el SAE (17,3%); y que integre a todos los
entes que participan en el SAE (17,3%). Tambin es destacable por su ele-
vada opinin, los dos objetivos planteados siguientes: que tenga sencillez en
su operacin, instalacin y mantenimiento (12%); y que sea desarrollado con
tecnologas libres (10,7%). Los objetivos expuestos como necesarios, han
sido planteados ante la necesidad causada, debido al vaco presente por la
ausencia de un SI en el SAE. Aqu se evidencia que se est demandando
urgentemente un software basado en tecnologas libres, que provea de rapi-
dez en el servicio, as como la coordinacin con los dems entes y departa-
mentos.
67
Ahora, con la pregunta N 6 que dice Cules son las funciones que de-
be tener el SI del SAE?, se conoci lo siguiente:
Cuadro 11: Funciones que debe tener el nuevo Sistema de Informacin
Opciones Operador Telefo- enlace Anti- Proce- SIPOL GPS WiFi Bitcora Graba
y na a Web sabotaje dencia servicio voz
despacho
Respuestas 13 13 11 11 7 7 5 3 3 2
Porcentajes 17,3% 17,3% 14,7% 14,7% 9,3% 9,3% 6,7% 4% 4% 2,7%
17,3% 17,3% 14,7%

14,7%
9,3%
9,3%
6,7%
4,0% 4,0% 2,7%
WiFi
SIPOL
enlace a
Bitcora
sabotaje
Procedencia
GPS
Operador y
Graba voz
servicio
Telefona
despacho
Web
Anti-
Figura 17: Representacin grfica del cuadro 6, funciones que debe tener el nuevo SI
Con el Cuadro 11 y Figura 17, se definen las cuatro principales funcio-

nes que debe perseguir un SI en el SAE, las cuales son los siguientes: contar
con los servicios de operadores y despachadores y disponer de servicios de
telefona enlazados al SI (ambos con 17,3% cada uno); contar con Internet
para servicios al pblico y que sea capaz de combatir el sabotaje de llama-
das (ambos con 14,7% cada uno). Tambin es destacable por su elevada
opinin, las dos funciones sugeridas siguientes: que tenga sencillez en su
operacin, instalacin y mantenimiento (12%); que se pueda acceder a los
datos de SIPOL llevados por el CICPC, y que sea capaz de detectar la pro-
cedencia de las llamadas (ambos con 9,3% cada uno). Aqu se deduce que
debe ser aplicada ampliamente las tecnologas de telecomunicaciones y re-
des de datos, con acceso a otros organismos para elaborar un SI ms efecti-
vo y que monitoree las llamadas de emergencia.
68
De seguidas, con la pregunta N 7: Cules son las instituciones que
deben incorporarse a las funciones del SI del SAE? se determinaron los si-
guientes datos:
Cuadro 12: Instituciones que deben incorporarse al nuevo Sistema de Informacin
Opciones MppRIJ Comu- Escue- Tele- Fundaci- 171 GPS funciona- ISPs Mete-
nas/Otr las fona te/ otros rios pbli- reolo-
os MppCT estados cos ga
Respuestas 20 13 10 9 8 6 4 4 2 2
Porcentajes 22,7% 17,3% 13,3% 12% 10,7% 8% 5,3% 5,3% 2,7% 2,7%
22,7%
17,3%
13,3% 12,0%
10,7%
8,0%
5,3% 5,3%
2,7% 2,7%
MppRIJ
Telefona
Gps
Meteorologa
Comunas /
Escuelas
Fundacite /
171 otros
Funcionarios
ISP's
estados
MppCyT
otros
Figura 18: Representacin grfica del cuadro 7, instituciones

que deben incorporarse al nuevo SI
En el Cuadro 12 y Figura 18, se encuentran las tres principales Institu-

ciones que deberan participar en el SI del SAE, segn la opinin de los en-
cuestados, los cuales son: el Ministerio de Relaciones Interiores MppRIJ
(22,7%); los consejos comunales u otras formas de organizacin vecinal
(17,3); y las instituciones escolares (13,3%). Tambin son destacables las
empresas de telefona pblica y privada (12%); el MppCT, Fundacite Mrida
(10,7%), as como los SAE de otras entidades regionales vecinas, tales como
Barinas, Tchira y Zulia. Con estos resultados se evidencia la necesidad de
promover convenios interinstitucionales o acciones mancomunadas con otros
organismos y la poblacin, para incorporarlos a las funciones del SAE.
69
Igualmente, en la pregunta N 8: La tecnologa existente en el SAE es
la apropiada?, los trabajadores expusieron su opinin as:
Cuadro 13: Condicin de la tecnologa existente
Opciones S No
Respuestas 10 15
Porcentajes 40% 60%
40%
S
No
60%

condicin de la tecnologa existente
En el anterior Cuadro 13 y Figura 19, se determin que el 60% de los

trabajadores encuestados opinan que la tecnologa existente no es apropiada
para prestar los servicios en el SAE. A pesar de que las opiniones son dividi-
das es relativamente baja; la tendencia es ms predominante a considerar
que no se cuentan con los recursos tecnolgicos existentes. Aunque es evi-
dente que dicha opinin est influenciada y acentuada por la ausencia del SI
para el SAE, lo cual refleja la enorme relevancia que tiene el mismo.
70
Tambin, con la pregunta N 9: Cuales son las tecnologas que deben
incorporarse en el SI del SAE?; se obtuvo la siguiente opinin:
Cuadro 14: Tecnologa a incorporar al nuevo Sistema de Informacin
Opciones Servicios Central BD Software GPS hard- Satli- Wi-FI redes

Web telefnica exter- libre ware tes
nas
Respuestas 16 14 11 10 9 6 4 4 1
Porcentajes 21,4% 18,7% 14,7% 13,3% 12% 8% 5,3% 5,3% 1,3%
21,4%
18,7%
14,7%
13,3%
12,0%
8,0%
5,3% 5,3%
1,3%
telefnica
GPS
Wi-FI
redes
Servicios
Software
externas
hardware
Satlites
Central
Web
libre
BD
Figura 20: Representacin grfica del cuadro 9, tecnologa a incorporar al nuevo SI
Por el Cuadro 14 y Figura 20, se resume la opinin consultada de las

tres tecnologas que hay que incorporar al SI, las cuales son: servicios de
Internet (21,4%); central telefnica (18,7%); acceso directo a bases de datos
externas (14,7%). Son destacables dos tecnologas ampliamente considera-
das, los cuales son: software y dems tecnologas libres (13,3%); y dispositi-
vos de localizacin de unidades mviles mediante GPS (12%). Se observa
que las principales sugerencias de tecnologas a utilizar para ser ms efi-
ciente en el SAE, principalmente estn determinadas por las telecomunica-
ciones, as como poder contar ampliamente con la informacin que poseen
otros organismos, adems de incorporar tecnologas libres a el SAE.
71
Finalmente, con la pregunta N 10: Cules son las tecnologas que de-
ben modernizarse en el SI del SAE?, se conoci lo siguiente:
Cuadro 15: Tecnologa a modernizar del nuevo Sistema de Informacin
Opciones software Central Redes Hardwa- bases graba- servido- Internet

telefnica voz/dato re de datos dor de res
s voz
Respuestas 21 20 2 2 2 1 1 1
Porcentajes 42% 40% 4% 4% 4% 2% 2% 2%
42% 40%
4% 4% 4% 2%
2% 2%
internet
telefnica
grabador
bases de
software
redes de
Hardware
servidores
de voz
central
datos
datos
voz y

tecnologa a modernizar del nuevo SI
Del anterior Cuadro 15 y Figura 21, explana las tecnologas que presen-
tan fallas y que requieren urgente modernizacin, por ser ampliamente nece-
sarios en el SAE. Estos son el Sistema de Informacin de Atencin de Emer-
gencias (42%); y la central telefnica (40%). Aqu se deduce que son total-
mente necesarios adecuar a las tecnologas modernas tanto el SI como el
servicio de telefona interna, ya que son extremadamente necesarios para
prestar un eficiente servicio de atencin de emergencias a la poblacin meri-
dea, aportando un total apoyo a la presente investigacin.
72
Anlisis e Interpretacin de los Resultados
Se aplic como mtodo de anlisis de informacin, a los fines de ponde-

rar la situacin del SAE, la matriz de evaluacin estratgica FODA, mediante
la cual se describen exhaustivamente las fortalezas, oportunidades, debilida-
des y amenazas presentes en la referida Institucin, cuya matriz se muestra
en el Cuadro 16.
Cuadro 16: Matriz FODA del SI 1-7-1 Mrida
Fortalezas Amenazas:
Posee equipos de alta tecnologa. Cierta inconformidad en el sistema de
Posee un sistema de grabacin de las atencin de emergencias por parte del
llamadas recibidas. pblico.
Alta prioridad de la Seguridad Ciudadana Deficiencias presupuestarias en el situado
en la asignacin de recursos presupues- constitucional del Estado Mrida.
tarios. Altos ndices de inseguridad.
Estructura organizacional descentralizada Altos ndices de llamadas de sabotaje.
del Ejecutivo Regional Divisin de recursos presupuestarios
Excelentes relaciones Gobiernos Nacio- entre Teleinformtica y Seguridad Ciuda-
nal y Mrida. dana.
Debilidades: Oportunidades:
Las unidades de los organismos de segu- Tiene el monopolio de los Servicios de
ridad del estado que la integran no pres- Atencin de Emergencia en Mrida.
tan su servicio directamente desde el Posee servidores de Hospedaje de Pgi-
SAE; sino desde su respectivamente se- na Web y Servicio de correo electrnico
de. (hosting).
No existe sistema GPS. Coordinacin con otros organismos pbli-
Cada organismo de seguridad desempe- cos y privados.
a su respectiva funcin autnomamente. Disposicin de MppRIJ, Fundacite y Cen-
No posee interconexin con los diferentes ditel Mrida a contribuir con la Institucin.
organismos de seguridad de los estados MppRIJ desarrolla proyecto de automati-
vecinos. zacin para los SAE de cada Estado.
No hay acceso on-line a los datos de los Disponibilidad de uso del Satlite Simn
distintos organismos de seguridad meteo- Bolvar VENESAT1, y los de los conve-
rolgicos, Telefona pblica y privada; na- nios internacionales.
cionales e internacionales. Amplia legislacin en Seguridad Ciuda-
No posee un sistema de inteligencia para dana y Tecnologa.
verificar y sancionar las llamadas de sa- Alta prioridad de la Ciencia, Tecnologa e
botaje. Innovacin para el uso en la Administra-
Escaso personal en el rea tecnolgica cin Pblica Nacional.
Fallas en el aire acondicionado. Existencia de la Zona Libre, Cientfica,
El SI est inoperativo, y no existe perso- Cultural y Tecnolgica del Estado Mrida
nal capacitado para reactivarlo. Personal formndose en tecnologa libres.
El SI est elaborado en software privativo
73
Tal como se aprecia en el Cuadro 16, se determinaron 30 registros de
observacin los cuales fueron distribuidos entre la matriz FODA, de los cua-
les cinco (16,7%) correspondieron a las fortalezas; otros cinco (16,7%) se
ubicaron en las amenazas; diez (33,3%) fueron determinados como debilida-
des; y otros diez (33,3%) para las oportunidades.
Se aprecia del anlisis cuantitativo realizado a la matriz FODA del Cuadro
16, que el actual SI del SAE presenta una tendencia ms pronunciada tanto en
las debilidades como en las oportunidades en igual proporcin; quedando con
menor relevancia las fortalezas y amenazas, lo que refleja que el actual SI, est
mayormente caracterizado por sus debilidades, pero con igual grado en las opor-
tunidades que tiene para ser nuevamente, un mecanismo tecnolgico efectivo
para el SAE.
Cuadro 17: Anlisis cuantitativo de la matriz FODA
Opciones Fortalezas Oportunidades Debilidades Amenazas

Respuestas 5 10 10 5
Porcentajes 16,7% 33,3% 33,3% 16,7%
40,00% 33,30% 33,30%
30,00%
16,70% 16,70%
20,00%
10,00%
0,00%
Fortalezas Oportunidades Debilidades Amenazas

Anlisis cuantitativo de la matriz FODA SI
Asimismo, del cuadro 17 y Figura 22, se puede interpretar que el actual SI, a
pesar de no poseer fortaleza en el SAE, de igual forma son inferiores los factores
que amenazan su presencia en los sistemas de cmputos del referido SAE, aun-
74
que no se pueden banalizar dichos factores, debido a que representan condicio-
nes importantes a ser considerados.
Presentacin y Discusin de los Resultados
Para Rodrguez y Pineda (2003), es el momento de los descubrimientos de

investigacin, donde se expondrn las percepciones, actitudes, valores, datos de
inters, tendencias conductuales y de comportamiento, totales cuantificados y
cdigos agrupados (). (p. 115).
Para presentar los resultados correspondientes a cada uno de los objetivos
especficos planteados en la presente investigacin, como resultados de los anli-
sis realizados a los datos recolectados en la seccin anterior; se proceder a ex-
poner los argumentos y razonamientos lgicos, que explican el cumplimiento de
cada uno de los objetivos especficos y general, a que se contrae la presente in-
vestigacin, los cuales fueron explanados en el Captulo I de la presente investi-
gacin.
Con la aplicacin de los instrumentos de recoleccin de informacin, a tra-
vs de entrevistas con cuestionarios adaptativos, as como con la observa-
cin directa, representados, graficados, tabulados y representados grfica-
mente, se logr analizar integralmente en una matriz FODA, cada uno de los
resultados obtenidos con los datos aportados por los sujetos sometidos a las
preguntas, en la parte inicial del presente captulo IV.
En ese sentido, tal como se muestra en la Figura 23, con resultados simi-
lares a la investigacin realizada por Colmenares (2005), en su Proyecto de
Grado de la Universidad de Los Andes, Mrida, Venezuela, titulado Optimi-
zacin de los ndices de Gestin y Operatividad en el Servicio 1-7-1 de SA-
TEM; el diagnstico revela que el SAE 171 Mrida presenta una serie de
problemas que deben ser considerados en el desarrollo del SIAE.
75
Figura 23: Diagnstico del SI actual
Se observa que existe una creciente insatisfaccin en la poblacin meri-

dea en cuanto al SAE; causada debido a que el SI actual est totalmente
inoperativo desde hace dos (2) aos, y este junto con la central telefnica
fueron elaborados en software privativo, dependiendo totalmente de los pro-
pietarios del software; no hay posibilidad de acceso al registro de abonados
de las empresas de telefona fija y mvil, para determinar su procedencia; las
llamadas innecesarias denominadas sabotaje, ocasionan congestionamien-
to de las lneas telefnicas y sobrecarga de trabajo a los operadores que
atienden las mismas; los operadores telefnicos que atienden el nmero 171,
realizan excesivas preguntas a los ciudadanos que demandan de un servicio;
ausencia de mecanismos digitales que permitan acceder al Sistema Nacional
de Registro Delictivo, Emergencias y Desastres (S.I.P.O.L.) y a la informa-
cin meteorolgica, para incrementar la capacidad de respuesta en las
emergencias; no existe un mecanismo alterno de solicitud de atencin de
emergencias para las personas, que permita asumir las fallas en el servicio
telefnico tradicional actual de discado 1-7-1; las unidades de atencin de
76
emergencias no cuentan con un mecanismo diferente de radio transmisores,
para la recepcin de rdenes de atencin de una emergencia; inexistencia de
un mecanismo tecnolgico de ubicacin fsica de las unidades de atencin de
emergencias, a fin de monitorear la ubicacin exacta de dichas unidades.
Modelado de Datos del SIAE
En funcin del diagnstico de funcionamiento del actual SI del SAE 171

Mrida, se dise el modelado de datos del SIAE, el cual contiene las estruc-
turas de la base de datos, sus restricciones de integridad, y las operaciones
de manipulacin de los datos, integrndose los diferentes actores pblicos y
privados vitales para desarrollar un efectivo SI para los SAE en Venezuela
(ver Figura 24).
De esta forma es posible la incorporacin tanto de empresas privadas de
telefona y Proveedoras de Servicios de Internet (ISP), deben aportar esfuer-
zos para contribuir con la seguridad de la nacin, y para el caso de esta in-
vestigacin, se requiere que las mismas compartan sus registros de suscrip-
tores para ser utilizados en el SAE, a los fines de determinar su ubicacin en
los casos que establezca las leyes de la Repblica, tales como, llamadas de
sabotaje, delitos electrnicos, entre otros.
Para desarrollar el Modelado de Datos, se aplic el Lenguaje Unificado
de Modelado (UML), segn Rumbaugh y otros (2000), con el cual se hizo un
modelado visual del SIAE; de acuerdo a las tcnicas de Modelado de Datos
formuladas por Silberschatz y otros (2002).
Documento de Definicin de Requisitos (DDR)
Del mismo modo que se realiz con el Modelo de Datos, diseado a par-
tir del diagnstico de funcionamiento del actual SI del SAE 171 Mrida, se
77
Figura 24: Esquema conceptual del Modelado de Datos del SIAE
Autor: Propio (2010)
78
elabor el DDR para desarrollar el SIAE, cuya funcin principal es integrar
tecnolgicamente todos los rganos de Seguridad Ciudadana de los Gobier-
nos Nacional, Estadales y Municipales, conjuntamente con el Ministerio del
poder popular para las Relaciones Interiores y Justicia (MppRIJ).
El DDR que se presenta entre las pginas 83 al 183 de este Trabajo de In-
vestigacin, est conformado por el Documento de Requisitos de Usuario
(DRU); en el cual se escriben las funciones que son necesarias definidas por
los usuarios; y el Documento de Requisitos de Software (DRS), contentivo
de la construccin de el modelo lgico del SIAE diseado en esta investiga-
cin; con estimaciones de costes y recursos; cuyo DDR est elaborado con
la metodologa de desarrollo de Software denominada Proceso Unificado de
Racional (RUP) (2001), junto a la representacin grfica del software y su
arquitectura, mediante los diagramas de modelado de sistemas del Lenguaje
Unificado de Modelado (UML).
Fue necesario para la confeccin del DDR, aplicar la metodologa RUP
de IBM (2001), para representar los modelos de desarrollo basados en com-
ponentes que han sido propuestos para el SIAE, utilizando el Lenguaje de
Modelado Unificado (UML), para definir los componentes que se utilizarn
para construir el sistema y las interfaces que conectarn los componentes.
Ingeniera de Requisitos del SIAE
Finalmente, una vez logrado desarrollar el Modelado de Datos y el Do-

cumento de Definicin de Requisitos (DDR), se puede determinar el logro del
objetivo principal de esta investigacin, el cual fue desarrollar una Ingeniera
de Requisitos para el desarrollo del SIAE; con el cual, segn Len (1996), el
objetivo de este instrumento de Ingeniera de Software, es obtener una clara
comprensin del problema a resolver, extraer las necesidades del usuario y
derivar de ellas las funciones que debe realizar el sistema (ver Figura 25).
79
80
El DDR, constituye el documento final objeto de la presente investiga-
cin, contentiva de la Ingeniera de Requisitos objeto de la presente investi-
gacin, mediante el cual, se desarroll un Sistema de Informacin para los
Servicios de Atencin de Emergencias (SIAE), el cual se muestra en el ante-
rior esquema conceptual, como solucin a la problemtica planteada en el
SAE.
Esta Ingeniera de Requisitos ha sido guiada por las investigaciones rea-
lizadas por los autores Jurez (2007) y Dvila (2009); en sus Trabajos Espe-
ciales de Grado del Instituto Universitario Politcnico Santiago Mario, ex-
tensin Mrida, denominado Ingeniera de Requerimientos y Modelado de
Datos para el Sistema de Informacin de Caudales en Acueductos Urbanos.
Propuesta del Proyecto
De acuerdo a lo mencionado, la Ingeniera de Requisitos para el Sistema

de Informacin de Atencin de Emergencias (SIAE), es de vital importancia
para el logro de los objetivos, por lo que se presenta el siguiente Documento
de Definicin de Requisitos (DDR) que proporcionar los insumos necesarios
para la siguiente fase de Ingeniera de Software segn RUP (2001), de anli-
sis y diseo del Sistema de Informacin para la Atencin de Emergencias
(SIAE). El DDR, tal como se visualiza en la Figura 26, est conformado inte-
gralmente por los siguientes documentos:
El Documento de Requisitos de Usuario (DRU) que constituir el do-
cumento aceptado por el usuario del SIAE.
El Documento de Requisitos de Software (DRS), el cual contendr el
modelo lgico del SIAE, incluyendo su modelado de datos que descri-
bir los datos, sus relaciones y semntica, as como las ligaduras de
consistencia.
81
Figura 26: Esquema conceptual del DDR
Autor: Propio (2010)
82
Centro de Investigaciones y Altos Estudios en Ciencias Sociales
DOCUMENTO DE DEFINICIN DE REQUISITOS DEL

SISTEMA DE INFORMACIN DE ATENCIN
DE EMERGENCIAS (SISTE)
Organismo de aplicacin:
Servicios Telefnicos de Atencin de Emergencia
Proyecto realizado como Trabajo de Especial de Grado para optar al Ttulo
de Ingeniero de Sistemas en el IUP Santiago Mario
Ing. Richard Rodrguez Salazar

Mrida, Venezuela, agosto de 2.010
Revisado: Noviembre, 2011
DOCUMENTO DE DEFINICIN DE REQUISITOS
INGENIERA DE REQUISITOS DEL
SISTEMA DE INFORMACIN PARA LA ATENCIN DE EMERGENCIAS (SISTE)
Fecha: 06/08/2010. Pgina 1 de 107
NDICE DE LA PROPUESTA
P.p.
1. INTRODUCCIN ........................................................................................ 3
2. INFORMACIN GENERAL .................................................................................. 4
2.1. Sistema de Informacin para la Atencin de Emergencias (SISTE) ........... 4
2.2. Mdulos de SISTE........................................................................................... 4
2.3. Objetivo general ............................................................................................... 8
2.4. Objetivos especficos ....................................................................................... 8
2.5. Alcance ............................................................................................................. 8
2.6. Delimitacin ...................................................................................................... 9
3. INGENIERA DE REQUISITOS (IR) ................................................................... 10
Documento de Requisitos de Usuario (DRU) ................................................ 12
3.1. Documento visin: Modelado de negocios (MN) ........................................ 13
3.1.1. Objetivos del sistema de negocios ........................................... 13
3.1.1.1. Misin ........................................................................... 14
3.1.1.2. Visin ........................................................................... 14
3.1.2. Procesos del negocio ............................................................... 15
3.1.2.1. Cadena de valor ........................................................... 15
3.1.2.2. Procesos vitales ........................................................... 16
3.1.3. Objetos del sistema de negocio ............................................... 20
3.1.4. Actores/unidades organizacionales .......................................... 21
3.1.5. Regla de negocios.................................................................... 24
3.2. Especificacin de requisitos de usuario .............................................. 24
Documento de Requisitos de Sistema (DRS) ................................................ 29
3.3. Especificacin de requisitos de sistema ............................................. 30
3.4. Desarrollo de la baseline de la arquitectura .............................................. 38
3.5. Construccin del producto .................................................................. 70
Elaborado por: Revisado por: Aprobado por:
Firma y sello Firma y sello Firma y sello

Fecha: 06/08/2010. Pgina 2 de 107
3.5.1. Modelado de datos ................................................................... 70

3.5.1.1. Diccionario de datos ..................................................... 70
3.5.1.2. Diagrama de clases ...................................................... 81
3.5.1.3. Modelo de datos Entidad-Relacin (E-R) ..................... 81
3.5.2. Modelo de dominio ................................................................... 81
3.5.3. Mapa de comportamiento a nivel de hardware ........................ 84
3.6. Producto final ................................................................................................. 87
3.6.1. Plan de gestin de desarrollo............................................................. 95
3.6.1.1. Factibilidad social .................................................................. 95
3.6.1.2. Factibilidad tcnica ................................................................ 95
3.6.1.3. Factibilidad de Recursos humanos .............................. 97
3.6.1.4. Factibilidad econmica.......................................................... 98
4. Autor del Proyecto .......................................................................................... 102

Fecha: 06/08/2010. Pgina 3 de 107
1. INTRODUCCIN
El presente Documento de Definicin de Requisitos (DDR) del SISTE,

permitir resolver la problemtica originada por la ausencia del Sistema de
Informacin de Atencin de Emergencias actual, conformando un efectivo y
eficiente Sistema de Informacin, ayudando a mejorar la calidad de cualquier
Servicio de Atencin Estadal de Emergencia en el pas; por consiguiente, una
mejora sustancial en la calidad de vida de la poblacin, por cuanto obtendrn
respuestas ms rpidas y efectivas ante las emergencias presentadas. Este
Sistema de Informacin ayudar a descargar parte del trabajo que realiza el
personal que labora en cualquier SAE de Venezuela, incrementando la cali-
dad de la atencin de las llamadas que se realicen, y brindando el envo de
las unidades de los organismos de seguridad, lo cual redundar positivamen-
te en el desempeo de sus funciones. Finalmente, este trabajo podr ser uti-
lizado para referencias en futuros proyectos de Ingeniera de Requisitos.
A lo largo del presente DDR, se ha explanado el logro del desarrollo de la
Ingeniera de Requisitos para el Sistema de Informacin en cualquier Servicio
Estadal de Atencin de Emergencias de Venezuela, mediante el cumplimien-
to de una serie de fases.

Fecha: 06/08/2010. Pgina 4 de 107
2. INFORMACIN GENERAL
2.1. Sistema de Informacin para la Atencin de Emergencias (SISTE)
Es un software libre de tecnologa web, diseado para ser implementado

en los Servicios de Atencin de Emergencias (SAE) de cualquier Estado de
Venezuela, bajo la coordinacin del Ministerio del Poder Popular para las
Relaciones Interiores y Justicia, como rgano rector de la seguridad del pas;
el cual se activa al momento de que una persona solicita, va telefnica o In-
ternet, que se le ayude a resolver una emergencia presentada; funcionando
como un mecanismo tecnolgico de integracin con los Organismos de Se-
guridad del Estado, a los fines de que acudan a los sitios de sucesos, los
ms rpido posible y sin retrasos innecesarios, y atiendan efectivamente la
emergencia presente.
As mismo, el SISTE deber ser codificado bajo las siguientes caracters-
ticas:
Aplicaciones Web:
Software: Libre licencia GNU GPL.
Plataforma: web cliente-servidor
Sistemas operativos: Microsoft Windows 9x, NT, 2000, XP, Vista, 7,
Server, GNU Linux.
Web Apache Server.
Lenguaje de programacin tecnologa Web PHP.
Sistema de Gestin de base de datos:
PostgreSQL Server
MySQL Server
Central telefnica:
DIGIUM-Asterix

Fecha: 06/08/2010. Pgina 5 de 107
Servidores de red:
GNU Linux Debian Server
Redes telemticas:
Protocolo TCP/IP.
Red WAN con enlace satelital, red de telefona pblica, Internet y/o
WI-FI frecuencia 5.8 Ghz.
Red local de cableado estructurado categora 6e, en cada SAE.
Red troncalizada de Seguridad Ciudadana regional.
Otros servicios:
Sistema de posicionamiento global (GPS).
Aplicaciones y Mdulos del SISTE:
Para dar cumplimiento a las funciones antes indicadas, se disearon tres

aplicaciones con sus respectivos mdulos, para conformar el ambiente orien-
tado a objetos del SISTE. La primera es la Aplicacin Reporte de Emer-
gencias disponible a travs de Internet; la segunda, es la aplicacin Apli-
cacin Servidor que estar alojada en la sede principal de los SAE; y la
tercera, es la aplicacin Aplicacin SAE para ser utilizada por cada SAE, a
los fines de atender las llamadas y prestar el servicio al ciudadano solicitante.
A continuacin se describen las anteriores aplicaciones y sus mdulos:
a. Aplicacin para el Reporte de Emergencias: al momento de hacer el con-

tacto, el ciudadano solicita ayuda, y el servidor del SISTE revisa inmediatamente
un historial de las llamadas realizadas desde el nmero de telfono direccin Ip.
Nota: En lo sucesivo, a los fines de generalizacin, entindanse como llama-
das de emergencia el contacto que realizan las personas con el SAE, bien

Fecha: 06/08/2010. Pgina 6 de 107
sea a travs de una llamada telefnica al discado 171, por va VoIp o me-
diante el llenado del formulario mediante la pgina Web.
a.1. Primer Mdulo: Discado al nmero 171: se hace el contacto con el
SAE a travs del uso tradicional del discado 171, desde cualquier telfono
pblico, fijo o celular; enlazndose a la central telefnica VoIp, para iniciar
un enlace directo de voz directo con el operador.
a.2. Reportar una emergencia va Internet: a travs de este mdulo, los
ciudadanos contactan al SAE para solicitar le atiendan en su emergencia,
mediante dos mtodos haciendo uso del Internet, a travs de una llamada
VoIp de un servicio Web.
a.2.1. Segundo Mdulo: Llamada VoIp: se hace el contacto con
el SAE a travs del uso de la tarjeta de sonido de un computador
conectado a Internet; enlazndose a la central telefnica VoIp, para
iniciar un enlace directo de voz directo con el operador
a.2.2. Tercer Mdulo: Servicio Web: es la pgina web accesible
desde cualquier navegador, mediante la cual, las personas pueden
acceder a los servicios del SAE, con la misma efectividad que una
llamada telefnica. Los ciudadanos podrn reportar la emergencia
bien sea con un formulario de reporte de emergencia, o a travs de
una llamada de voz basada en Internet (VoIp), similar a las que se
realizan mediante messenger.
b. Aplicacin para el Servidor: Es el sistema contentivo de los algoritmos y
rutinas de programacin confidenciales del software SISTE, siendo el cere-
bro o la aplicacin principal de monitoreo nacional, y estara alojado en los
servidores del MppRIJ, accesibles por cualquier SAE en Venezuela a travs
de medios de transmisin fsicos o inalmbricos dispuestos para tal fin (sate-
lital, Internet, Telefona). El software tendr acceso on line con diversas ba-
ses de datos de otros Organismos del Estado, que aportarn informacin

Fecha: 06/08/2010. Pgina 7 de 107
importante para la Seguridad Ciudadana, tales como SIPOL, Meteorologa y

todos los suscriptores de telefona e Internet.
c. Aplicacin para los SAE: Es el sistema contentivo de los algoritmos y
rutinas de programacin no confidenciales del software SISTE, y es la aplica-
cin que tendr acceso a la aplicacin principal del servidor anteriormente
indicada con el No. 2; y estara alojado en los servidores de cada SAE, acce-
sibles por cualquier sucursal del SAE y unidades mviles de los Organismos
de Seguridad, ubicados en el mismo Estado, a travs de medios de transmi-
sin fsicos o inalmbricos dispuestos para tal fin (satelital, Internet, Telefo-
na). Igualmente, en cada SAE estaran alojadas las bases de datos de uso
local, generadas en cada uno de estos, para su monitoreo, tabulacin, y de-
ms medicin de control de gestin propio de cada organismo 171 de cada
Estado.
c.1. Cuarto mdulo, Atender reporte de emergencia: el operador
del SAE, recibe la emergencia reportada y canaliza la misma para resol-
verla mediante un ticket de emergencia.
Mediante este mdulo recibe los datos bsicos de la emergencia aporta-
dos por el ciudadano mediante el primer mdulo, a travs de una llama-
da telefnica al discado 171; tales como nombre y cdula de quien llama,
direccin, nmeros de telfono, direccin de la emergencia y una descrip-
cin breve y precisa de la misma. Luego, genera inmediatamente el ticket
de emergencia una vez auditada la llamada, para que sea atendida por el
rgano de Seguridad correspondiente, y contina la entrevista ampliando
la informacin y dando apoyo y asesora para brindar calma y tratar de so-
lucionar el problema mientras llegan al sitio, los rganos de Seguridad en-
viados.
La auditora de la llamada de emergencia es un sub-mdulo que corres-
ponde al mdulo de atender el reporte de una emergencia, mediante el

Fecha: 06/08/2010. Pgina 8 de 107
cual se van a revisar los datos de origen de la llamada, su histrico y el re-

gistro delictivo del ciudadano que llama. En este sub-mdulo, el operador
evaluar y deducir si la llamada es confiable, o presenta indicios de ser
una llamada de sabotaje, generando un ticket de acuerdo a los resultados
c.2. Quinto Mdulo, Despachar el servicio: es la funcin del SIS-
TE mediante el cual el despachador enva al rgano de Seguridad com-
petente.
El despachador recibe digitalmente el ticket de emergencia emitido por el
operador, y genera el ticket de despacho que se distribuye en todos los
rganos de Seguridad y las unidades mviles que les corresponden a es-
tos, para divulgar ampliamente la emergencia, apoyando el uso tradicional
de radiocomunicaciones. Inmediatamente se comunica con las unidades
mviles ms apropiadas para atender la emergencia, previamente ubica-
das por GPS.
c.3. Sexto Mdulo, Atender emergencia: est creado para que el
rgano de Seguridad preste el servicio correspondiente a lo indicado por
el despachador.
El rgano de seguridad recibe la llamada por radio telfono, e igualmen-
te recibe digitalmente el ticket de despacho, y posteriormente acude al si-
tio de la emergencia y la atiende, registrando en el SISTE cada accin
realizada. Asimismo, el SISTE pone a la disposicin del rgano de Segu-
ridad la base de datos de Registros Delictivos (S.I.P.O.L.), como instru-
mento de consulta.
Cada mdulo contiene funciones propias de estos, entre las cuales tenemos
la impresin de reportes, consulta de bases de datos, funciones de crear, modifi-
car, eliminar y consultar registros. El actor Supervisor, es un ente con funciones

Fecha: 06/08/2010. Pgina 9 de 107
de super-usuario en todos los mdulos del SISTE y sus funciones, el cual puede
acceder libremente a todos los mdulos.
Por tcnicas de diseo, se busca la simplificacin al mximo del SISTE, evi-
tando al mximo la creacin de complejas ventanas y atajos; es por lo que se
determin la creacin de solo estos cuatro mdulos del SISTE, con el uso de ha-
bilitacin y deshabilitacin de mdulos, funciones y botones, segn sea el nivel
de privilegios y permisologas del usuario que opera el SISTE.
Inclusive, los mdulo cuatro y cinco del SISTE pueden ser accesibles a los
dems mdulos de la aplicacin cliente-servidor, a travs de Internet, para los
casos de que funcionarios de alto nivel de confianza, Consejos Comunales, Pre-
fecturas, Juntas Parroquiales, Asociaciones de Vecinos, o colaboradores volunta-
rios del SAE; puedan apoyar como ramificaciones y sucursales de ese servicio
las 24 horas del da, permitiendo que no estn limitadas las tareas de atender
emergencias, nicamente al personal que labora en la reas operacionales del
SISTE.
2.3. Objetivo General
Desarrollar el Documento de Definicin de Requisitos (DDR) que propor-

cione los insumos necesarios para el siguiente flujo de trabajo de la metodo-
loga de Ingeniera de Software RUP (2001), de implementacin del Sistema
de Informacin para la Atencin de Emergencias (SISTE).
2.4. Objetivos Especficos
Crear el Documento de Requisitos de Usuario (DRU) que constituye el

documento aceptado por el usuario del SISTE.

Fecha: 06/08/2010. Pgina 10 de 107
Elaborar el Documento de Requisitos de Software (DRS), el cual con-

tiene modelo lgico del SISTE, incluyendo su modelado de datos y
plan de gestin del desarrollo del SISTE.
2.5. Alcance
El SISTE est diseado para brindar cobertura en todo el territorio de la Re-

pblica Bolivariana de Venezuela, mediante los recursos tecnolgicos con que en
la actualidad cuenta la nacin, los cuales son los equipos de telecomunicaciones
y procesamiento de datos existentes en el MppRIJ y cada SAE en Venezuela,
as como el satlite de comunicaciones Simn Bolvar VENESAT1.
Asimismo, por ser un software que aborda las necesidades del ciudadano
como un ser humano, sin distinciones de ningn tipo, puede ser aplicado en
cualquier pas del mundo, con normas jurdicas similares a la de nuestro pas,
que orienten las polticas pblicas de seguridad, tendientes al mejoramiento inte-
gral de la calidad de vida de las personas; y por otro lado, que sean naciones con
alta disposicin en inversin en Ciencia, Tecnologa e Innovacin, ya que el SIS-
TE requiere de amplia disponibilidad en la referida rea del conocimiento.
2.6. Delimitacin
El SISTE, por ser un software elaborado para abordar temas de materia

de Seguridad de Estado, se delimita a su aplicacin y rango de accin exclu-
sivo para los SAE en Venezuela, por lo que no puede ser divulgado pblica-
mente, a pesar de que se basa en filosofa de Software Libre, en virtud de
que posee algoritmos que revelan estrategias confidenciales, los cuales no
pueden hacerse pblicos ya que pondran en riesgo la soberana nacional.
En tal sentido el cdigo fuente del software del SISTE deber ser almacena-

Fecha: 06/08/2010. Pgina 11 de 107
do en salas de servidores adscritos nicamente al MppRIJ, disponibles con

altsimo grado de confidencialidad; y las bases de datos de igual forma, de-
bern ser almacenado en salas de servidores adscritos nicamente a los
SAE de cada Estado, as como en los entes privados correspondientes, se-
gn sea el caso de la naturaleza de su contenido, con igual grado de confi-
dencialidad al del SISTE.

Fecha: 06/08/2010. Pgina 12 de 107
3. INGENIERA DE REQUISITOS (IR)
Len (1996), indica que el objetivo de la fase de IR (especificacin de-

finicin de requisitos), es obtener una clara comprensin del problema a re-
solver, extraer las necesidades del usuario y derivar de ellas las funciones
que debe realizar el sistema.
Posiblemente con anterioridad a esta fase ha existido algn estudio de
factibilidad que permite asegurar que el software a realizar es realizable, res-
ponde a un mercado potencial o real, etc. La fase de IR suele subdividirse en
dos sub-fases:
La primera sub-fase de anlisis de requisitos de usuario, la cual tiene
como objetivo conocer las necesidades de los usuarios y cules deben ser
los servicios que un SI debe ofrecerles para satisfacerlas. La fase implica la
creacin del Documento de Requisitos de Usuario (DRU) que constituye el
documento base para que, al final del desarrollo, el sistema sea aceptado por
el usuario. Esta sub-fase se aprovecha tambin para generar el plan de
desarrollo con una estimacin de costes y recursos.
La segunda sub-fase de anlisis de requisitos del sistema, consiste en la
construccin de un modelo lgico del SI, describiendo las funciones que sean
necesarias (sin tomar ninguna decisin sobre cmo implementarlas) y las
relaciones entre ellas suponiendo que no existen limitaciones de recursos.
Por modelo lgico se entiende la identificacin de las funciones de soft-
ware requeridas para satisfacer los requisitos del usuario. Esta identificacin
se suele realizar en varios niveles de detalle, hasta llegar a uno en el que las
funciones identificadas estn suficientemente claras, de tal forma que no exi-
ja un refinamiento posterior.
El producto generado en esta sub-fase es el Documento de Requisitos
de Software (DRS). Tambin se genera en esta sub-fase, el plan de gestin

Fecha: 06/08/2010. Pgina 13 de 107
del desarrollo con estimaciones de costes y recursos ms ajustados que en

la primera sub-fase.
A continuacin, en la Figura 27, se procede a desarrollar la Ingeniera de
Requisitos del SISTE, definiendo las fases de su desarrollo aplicando la me-
todologa de desarrollo de software Proceso Unificado de Racional (RUP)
(2001), la cual, tal como se indic en las bases tericas del Captulo II, est
definido por los cuatros principios o fases, las cuales son: inicio, elaboracin,
construccin y transicin).
Figura 27: Estructura de la Ingeniera de Requisitos segn RUP (2001)


Fecha: 06/08/2010. Pgina 14 de 107
DOCUMENTO DE REQUISITOS DE USUARIO (DRU)

Fecha: 06/08/2010. Pgina 15 de 107
3.1. Documento Visin: Modelado de negocios (MN).
La Ingeniera de Requisitos necesita del MN para lograr eficientemente el

levantamiento de requisitos de software. Es por lo que debe realizarse pre-
viamente el MN, tal como se estructura en la siguiente Figura 28.
Figura 28 Estructura del Modelo de Negocio segn RUP (2001)

Con este flujo de trabajo pretendemos llegar a un mejor entendimiento

del (SAE), organismo en donde se va a implantar el producto. A continuacin
se representaran algunos aspectos del SAE del Estado Mrida, vlidos para
los dems Estados del pas, sus caractersticas y relaciones entre sus ele-
mentos. Este modelado se orient a la Actividad/Rol, es decir se representa-
r la estructura y funcionamiento del Servicio.
3.1.1. Modelado de objetivos del sistema de negocios.
Por este modelo, se puede observar el resultado al que se quiere llegar,

refleja el modo de pensar de la organizacin, orienta el desempeo empresa-
rial y permitir evaluar la continuidad del departamento.

Fecha: 06/08/2010. Pgina 16 de 107
A continuacin se muestra la Figura 29 la cual representa el modelo de

objetivos del SAE.
Figura 29 Modelo de objetivos del sistema de negocios

3.1.1.1. Misin.
Operar como instrumento tecnolgico para salvar vidas, evitar agrava-

mientos de emergencias, tragedias y muertes innecesarias; contribuyendo
ampliamente con la disminucin de los ndices de inseguridad del pas.
3.1.1.2. Visin.
Ser el instrumento tecnolgico preferido por la poblacin venezolana, pa-

ra ser utilizado en cualquier caso de emergencia, contando con un eficiente y

Fecha: 06/08/2010. Pgina 17 de 107
efectivo servicio pblico que les garantizar la mejor atencin, como modelo
de gestin pblica en materia de Seguridad Ciudadana para Venezuela y el
mundo.
3.1.2. Modelado de procesos del negocio
El modelado de procesos de negocio, se utiliz por tres objetivos princi-

palmente:
Documentar: Los procesos son parte fundamental de la organizacin

de una empresa y un elemento primordial cuando se intenta imple-
mentar Sistemas de Informacin.
Mejorar: Las empresas que buscan una mayor eficiencia en sus pro-
cesos, localizar cuellos de botella en su gestin, identificar rea de
oportunidad o mejora, recurren al modelado y la simulacin de proce-
sos.
Agilizar: En un nivel de mayor sofisticacin, las empresas requieren el
modelado de procesos como articuladores de los servicios de Tecno-
logas de informacin, para poder reaccionar con mayor agilidad a los
constantes cambios que exige la competencia actual.
3.1.2.1. Cadena valor.
A continuacin, en la Figura 30 se representa mediante la cadena de va-

lor, todos los procesos que se realizan en el SAE, as como tambin los pro-
cesos de apoyo.

Fecha: 06/08/2010. Pgina 18 de 107
Figura 30: Cadena valor

3.1.2.2. Procesos vitales
Cada uno de los modelos de los procesos vitales de la cadena de valor,

se presenta a continuacin:
Reportar una emergencia:
En la figura 31, se muestra el proceso mediante el cual las personas

contactarn al SAE para solicitar le atiendan en su emergencia, a travs de
medios telefnicos, Web telefona VoIp. Se visualiza que el actor principal
es el ciudadano que reporta la emergencia ocurrida, y es apoyado en el SAE
por la empresa telefnica (CANTV) que provee el discado 171, la empresa
proveedora de Internet (ISP), que provee de Internet al ciudadano. El objetivo
de este proceso es entregar los datos de la emergencia al SAE.

Fecha: 06/08/2010. Pgina 19 de 107
Figura 31: Proceso reportar una emergencia

Atender reporte de emergencia:
El operador recibe la emergencia reportada, e inicia un proceso de dia-

logo gil, para obtener rpidamente los datos de la emergencia, revisando
los mismos con bases de datos de apoyo, obtenidas va on line de los regis-
tros delictivos del MppRIJ, las empresas de telefona e ISPs del pas, a fin de
obtener informacin delictiva del ciudadano en el primer caso; y su proce-
dencia en el segundo y tercer caso; as como determinar que el reporte de
emergencia, est descartada como llamada de sabotaje, lo cual tambin ser
revisado mediante el anlisis de las bases de datos propias del SISTE; e in-
mediatamente canaliza la emergencia para resolverla, generando el ticket de
la emergencia (ver Figura 32). En este estado contina el dialogo, para am-
pliar la informacin de la emergencia, la cual es anexada al ticket de emer-
gencia, de manera complementaria.

Fecha: 06/08/2010. Pgina 20 de 107
Figura 32: Proceso atender reporte de emergencia

Despachar el servicio:
Como se visualiza en la Figura 33, el despachador recibe el ticket de e-
Figura 33: Proceso despachar el servicio


Fecha: 06/08/2010. Pgina 21 de 107
emergencia, e inmediatamente procesa el mismo, determinando mediante

GPS la ubicacin de las unidades mviles correspondientes a los organismos
competentes necesarios para atender la emergencia, generando un ticket de
despacho, y ordenando va radio o telefona VoIp a las unidades que se en-
cuentren ms cerca del evento, a acudir a atenderla, poniendo en cuenta a
los organismos de seguridad involucrados, para que coordinen las acciones
de sus unidades.
Atender emergencia:
En la Figura 34, se evidencia que las unidades mviles notificadas y los

rganos de seguridad a que corresponden, reciben el ticket de despacho, y
acuden al sitio de la emergencia, y atienden la misma, haciendo contacto
personal con las personas agraviadas, los cuales son sometidas a una revi-
sin rutinaria en los registros delictivos del MppRIJ, a los fines legales consi-
Figura 34: Proceso atender emergencia


Fecha: 06/08/2010. Pgina 22 de 107
guientes; registrando detalladamente en la computadora de la unidad mvil,

las acciones realizadas mientras atiende la emergencia, y cualquier novedad
presente de inters. El Despachador del SAE, mantiene contacto permanen-
te, auditando y monitoreando el caso, y atento para prestar cualquier apoyo
adicional.
3.1.3. Modelado de objetos del sistema de negocio
Los objetos del negocio son de gran importancia para el desarrollo del
SISTE, ya que cada uno de ellos tiene asociado propiedades (atributos) que
determinaran la estructura del objeto; adems, tiene asociada una dinmica
de comportamiento.
En la figura 35 se identifican los objetos correspondientes al SAE, los
cuales sern consideradas como entidades en el desarrollo del modelo de
Figura 35: Procesos SISTE


Fecha: 06/08/2010. Pgina 23 de 107
datos del SISTE, algunos de los cuales sern accesibles por medios de co-
nexiones remotas, apoyadas por enlaces inalmbricos o Internet.
Los usuarios conforman a todas las personas que manipularn el SISTE,
limitando el acceso a ciertos mdulos, segn sea el caso de su nivel de atri-
buciones, mediante polticas de restriccin de acceso, diferencindose entre
sper usuario, supervisor, operador, despachador y organismo de seguridad.
Los objetos de colaboradores, empresas de telefona e ISPs, meteoro-
lga y registros delictivos solo podrn ser accedidos por el objeto de llama-
das de emergencias. Igualmente, el objeto GPS solo ser accedido mediante
el objeto de despacho de servicios.
En el caso del objeto unidades mviles, sern accedidos a travs del ob-
jeto institucin de seguridad, el cual ser administrado por cada Organismo
competente para su control y monitoreo.
3.1.4. Modelado de actores/unidades organizacionales
Dentro de un modelo de negocio o empresarial, los actores son aquellas

personas, mquinas o software que ejecutan los procesos de una organiza-
cin o empresa. Cada uno de estos actores se organizan en estructuras de
trabajo, llamadas unidades organizativas. El conjunto de unidades organizati-
vas clasificadas en divisiones, departamentos o secciones, conforman la es-
tructura organizativa jerrquica de una organizacin o empresa, en este caso
el SAE.
Con la finalidad de definir a los diferentes actores que participan en la
ejecucin del conjunto de procesos del SAE, se presenta en el siguiente
Cuadro 18 una lista detallada de sus actores y unidades organizacionales,
as como tambin los roles y responsabilidades que desempean cada uno
de estos.

Fecha: 06/08/2010. Pgina 24 de 107
Cuadro 18: actores y unidades organizacionales del SISTE
Actor Rol Responsabilidades

Supervisor Coordinador del SAE Garante de los servicios del SAE Estadal
Coordinar e inspeccionar los eventos y
servicios del SAE
Evaluar los datos estadsticos
Presentar los informes de gestin
Ciudadano Cliente Reportar emergencias
Suministrar los datos de la emergencia
Operadores Atender la llamada de Registrar las llamadas de emergencias
emergencia Ampliar los datos de las llamadas confia-
bles
Auditar las llamadas
Emitir ticket de emergencia
Despachadores Despachar a los organismos Emitir ticket de despacho
de seguridad para atender Ubicar las unidades de atencin ms
las emergencias apropiadas.
Canalizar la atencin de la emergencia
Monitorear constantemente la prestacin
del servicio que realiza el organismo de
seguridad
Organismos de Atender las emergencia re- Canalizar la atencin de la emergencia
seguridad portadas por el despachador Enviar el apoyo necesario a las emer-
gencias presentadas
Registrar las acciones realizadas en la
prestacin de los servicios
Resolver la emergencia
Central de Sistema de telecomunica- Establecer el enlace entre el SAE y las
telefona VoIp ciones de voz y datos lneas entrantes de discado 171 telefo-
na VoIp
Proveer de comunicaciones entre los
ciudadanos y los operadores del SAE,
as como entre todos los actores. Enviar
los registros de voz al grabador de voz
Empresas de Proveer informacin Proveer de las lneas telefnicas gratui-
Telefona tas para el sistema nacional de emer-
gencias
Suministrar los datos de los suscriptores
de telefona pblica, residencial y mvil
Determinar la ubicacin del origen del
contacto
Grabador de Registrador de llamadas de Crear registros digitales de todas las
voz voz conversaciones realizadas en el SAE
asociadas con cada evento

Fecha: 06/08/2010. Pgina 25 de 107
Continuacin del Cuadro 19:
ISPs Proveer informacin Proveer de medios gratuitas de acceso

va Internet para el sistema nacional de
emergencias
Suministrar los datos de los suscriptores
de Internet
Determinar la ubicacin del origen del
contacto
MppRIJ Coordinar el SISTE a nivel Proveer el software SISTE para ser utili-
nacional zado por la poblacin y los SAE en Ve-
nezuela.
Garantizar el funcionamiento SISTE
Establecer los convenios interinstitucio-
nales para acceder a las tecnologas y
datos de los organismos pblicas y pri-
vadas requeridos para el SISTE
Coordinar el Sistema Nacional de Regis-
tros Delictivos y/o S.I.P.O.L. disponible
para el SISTE.
Colaboradores Voluntariado del SAE Participar en el SISTE de cada Estado,
como fuerzas vivas comunales
Conformar red de expansin del SAE
GPS Rastreo satelital Ubicar a las unidades mviles de los
organismos de seguridad que participan
en el SISTE.
Meteorologa Informacin meteorolgica Mantiene informado al SISTE sobre los
datos actualizados del Servicio de Me-
teorologa de la Aviacin
Personas con Ciudadanos presentando Son las personas que reciben los servi-
emergencia emergencias cios del SISTE, para resolver sus emer-
gencias. Son considerados los clientes
del SAE

Fecha: 06/08/2010. Pgina 26 de 107
3.1.5. Modelado de regla de negocios:
Se modela la declaracin que rige el funcionamiento de algn aspecto

del negocio, tales como polticas, condiciones, restricciones; as como tam-
bin los tipos de requisitos de operacin del negocio; y son revisadas y defi-
nidas por el grupo de proyectos, usuarios y clientes.
En el caso del SAE, se encuentran las leyes de la Repblica, decretos
Presidenciales, resoluciones Ministeriales y el manual de normas y procedi-
mientos del SAE Mrida (ver Cuadro 36).
Figura 36: Modelado de reglas de negocio SAE

3.2. Especificacin de requisitos de usuario.
Esta seccin tiene como finalidad conocer las necesidades de los

usuarios y cules deben ser los servicios que un SI debe ofrecerles para
satisfacerlas.

Fecha: 06/08/2010. Pgina 27 de 107
Los requisitos de los usuarios especifican lo que corresponde a los

servicios que el sistema de software que se pretende construir, le debe
proporcionar (ver Cuadro 19), los cuales se describen a continuacin:
Cuadro 19: Especificacin de requisitos de usuario
No Descripcin Cdigo Tipo Prioridad

Activar el Sistema de
No
1 Informacin en el SAE RU001 Alta
funcional
Mrida
Contar con diversos
2 mecanismos para el RU002 Funcional Baja
reporte de emergencias
Ampliar las
3 comunicaciones con los RU003 Funcional Media
organismos de seguridad

Fecha: 06/08/2010. Pgina 28 de 107
Cuadro 20: Requisitos de usuario activar el Sistema de Informacin en el SAE Mrida
No
# de Requisito: RU-001 Tipo de Requisito:
Funcional
Descripcin: Activar el Sistema de Informacin en el SAE
Existencia de amplios retrasos y cierta
descoordinacin de los organismos de seguridad
en la atencin de emergencias; tiempo perdido
mientras se espera ayuda ante una emergencia;
dificultades de las poblacin para contactar a los
Justificacin:
organismos de seguridad; incremento en los
ndices de inseguridad; tragedias, enfermedades
agravadas y muertes innecesarias ocurridas ante
los retrasos de los organismos de seguridad;
insatisfaccin y crticas en las personas
Cada SAE y sus componentes externos debern
Criterio de Aceptacin / estar unidos al dominio de red del Sistema
Validacin: SISTE ubicado en el MppRIJ, debidamente
validados como usuarios autorizados
Prioridad: Alta Requisitos en Conflicto: ---
ltima Modificacin: Modificado 06/08/2010

Fecha: 06/08/2010. Pgina 29 de 107
Cuadro 21: Requisitos de usuario contar con diversos

mecanismos para el reporte de emergencias
# de Requisito: RU-002 Tipo de Requisito: Funcional

Contar con diversos mecanismos para el reporte
Descripcin:
de emergencias
no existe un mecanismo alterno de solicitud de
atencin de emergencias para las personas, que
permita asumir las fallas en el servicio telefnico
Justificacin:
tradicional actual de discado 1-7-1;
disminuyendo las posibilidades de atencin y
respuestas ms oportunas a emergencias reales
Llamadas y reportes web provenientes de
Criterio de Aceptacin /
usuarios certificados por los proveedores de
Validacin:
telefona e Internet
Prioridad: Baja Requisitos en Conflicto: ---

Fecha: 06/08/2010. Pgina 30 de 107
Cuadro 22: Ampliar las comunicaciones con los organismos de seguridad
# de Requisito: RU-003 Tipo de Requisito: Funcional

Ampliar las comunicaciones con los organismos
Descripcin:
de seguridad
Las unidades de atencin de emergencias no
cuentan con un mecanismo diferente de radio
transmisores, para la recepcin de rdenes de
Justificacin: atencin de una emergencia, enlazados por la
troncal de radiocomunicaciones, que al caerse
deben hacer uso de los telfonos celulares para
comunicarse
Estaciones de unidades fijas y mviles
debidamente registradas y validadas con la base
Validacin:
de datos del SISTE
Prioridad: Media Requisitos en Conflicto: ---

Fecha: 06/08/2010. Pgina 31 de 107
DOCUMENTO DE REQUISITOS DE SISTEMA (DRS)

Fecha: 06/08/2010. Pgina 32 de 107
3.3. Especificacin de requisitos de sistema.
En este apartado, se tratan las limitaciones existentes en la operacin

del sistema SISTE (ver Cuadro 23), las cuales, son las siguientes:
Cuadro 23: Especificacin de requisitos de sistema
No Descripcin Cdigo Tipo Prioridad

Elaborar el SISTE en
1 RS 001 No funcional Alta
Software libre
Determinar la ubicacin
2 RS002 Funcional Alta
de las llamadas entrantes
Advertir al operador sobre
llamadas de sabotaje
Agilizar la atencin de las
llamadas de emergencias
Acceder a los datos del
S.I.P.O.L.
Contar con la informacin
6 meteorolgica de la RS006 Funcional Media
AMBV
Rastrear ubicacin de las
7 unidades mviles de los RS007 Funcional Baja
Organismos de Seguridad

Fecha: 06/08/2010. Pgina 33 de 107
Cuadro 24: Requisito de sistema elaborar el SISTE en Software libre
No
# de Requisito: RS-001 Tipo de Requisito:
funcional
Descripcin: Elaborar el SISTE en Software libre
El actual Sistema de Informacin est totalmente
inoperativo desde hace dos (2) aos, el cual se
encargaba de gestionar las emergencias
reportadas con los organismos encargados de
atenderlas. Este sistema aparte de que no est
funcionando, fue elaborado en software privativo,
dependiendo totalmente de los propietarios del
Justificacin:
software, cuyas contrataciones estn prohibidas
por ley. Esto imposibilita el acceso al cdigo
fuente de la central telefnica existente,
desarrollado igualmente mediante sistema
privativo, que imposibilita su reprogramacin
libre e integracin a cualquier sistema de
informacin.
Criterio de Aceptacin / El cdigo fuente deber estar elaborado bajo
Validacin: licencia GNU-GPL

Fecha: 06/08/2010. Pgina 34 de 107
Cuadro 25: Requisito de sistema determinar la ubicacin de las llamadas entrantes
# de Requisito: RS-002 Tipo de Requisito: Funcional

Determinar la ubicacin de las llamadas
Descripcin:
entrantes
No hay posibilidad de acceso al registro de
abonados de las empresas de telefona pblica,
Justificacin: residencial y mvil; para llevar el control de las
llamadas telefnicos reales innecesarias; junto
con su procedencia
Se realizar la validacin con los datos de
empresas proveedoras de telefona publica,
Validacin:
residencial y mvil; y de Internet (ISPs)

Fecha: 06/08/2010. Pgina 35 de 107
Cuadro 26: Requisito de sistema advertir al operador sobre llamadas de sabotaje

Descripcin: Advertir al operador sobre llamadas de sabotaje
Las llamadas innecesarias denominadas
sabotaje, ocasionan congestionamiento de las
Justificacin: lneas telefnicas y sobrecarga de trabajo a los
operadores que atienden las mismas, retardando
la atencin efectiva de emergencias reales
Se revisar el historial de llamadas provenientes
de cada nmero telefnico o direccin ip de
Validacin:
origen

Fecha: 06/08/2010. Pgina 36 de 107
Cuadro 27: Agilizar la atencin de las llamadas de emergencias

Agilizar la atencin de las llamadas de
Descripcin:
emergencias
Los operadores telefnicos que atienden el
nmero 171, realizan excesivas preguntas a los
ciudadanos que demandan de un servicio, ante
Justificacin:
situaciones que ameritan urgente atencin, al
momento de la toma de datos del reporte de
dichas emergencias
La aceptacin de cada llamada deber
determinada mediante el anlisis humano de
estas, para lo cual solo el operador determinar
si es una llamada de sabotaje o no. Se deber
Validacin:
procesar cada llamada aunque existan altas
probabilidades de ser llamada falsa o de
sabotaje.

Fecha: 06/08/2010. Pgina 37 de 107
Cuadro 28: Acceder a los datos del S.I.P.O.L.

Descripcin: Acceder a los datos del S.I.P.O.L.
Existe una ausencia de mecanismos digitales
que permitan acceder al Sistema Nacional de
Registro Delictivo, Emergencias y Desastres,
para consultar inmediatamente va on line los
registros policiales, delictivos y judiciales de las
Justificacin: personas, del sistema S.I.P.O.L. llevado por el
Cuerpo de Investigaciones Cientficas Penales y
Criminalsticas (C.I.C.PC.); lo cual reduce
ampliamente el tiempo de consulta a los
referidos datos, mediante las vas de
radiocomunicaciones o telefnicas.
Se revisar el registro de delitos de ciudadano
Criterio de Aceptacin / que requiera atencin de emergencia validando
Validacin: el nmero de cdula de los mismos, o las placas
de los vehculos

Fecha: 06/08/2010. Pgina 38 de 107
Cuadro 29: Requisito de sistema contar con la informacin meteorolgica de la AMBV

Contar con la informacin meteorolgica de la
Descripcin:
AMBV
Existe una ausencia de mecanismos digitales
que permitan acceder al Sistema Meteorolgico
de la Aviacin Militar Bolivariana de Venezuela,
para consultar inmediatamente va on line los
Justificacin: datos de desastres naturales ocurridos o que
estn por ocurrir; lo cual reduce ampliamente el
tiempo de consulta a los referidos datos,
mediante las vas de radiocomunicaciones o
telefnicas.
Criterio de Aceptacin / Se revisar peridicamente la situacin
Validacin: meteorolgica de todo el territorio regional
Prioridad: Media Requisitos en Conflicto: ---

Fecha: 06/08/2010. Pgina 39 de 107
Cuadro 30: Requisito de sistema rastrear ubicacin

de las unidades mviles de los Organismos de Seguridad

Rastrear ubicacin de las unidades mviles de
Descripcin:
los Organismos de Seguridad
Hay inexistencia de un mecanismo tecnolgico
de ubicacin fsica de las unidades de atencin
de emergencias, que permita monitorear la
ubicacin exacta de dichas unidades,
disminuyendo la posibilidad de evitar que se
encuentren en lugares inapropiados, adems de
determinar la disponibilidad de unidades y las
ms prximas a los eventos presentados,
Justificacin:
atendindose menos oportunamente las
emergencias; pudiendo utilizarse la red
inalmbrica externa en aplicaciones tecnolgicas
de atencin de emergencias, la cual est en
desuso, lo que ocasiona el desaprovechamiento
de los recursos existentes de la Direccin del
Poder Popular Estadal para las
Telecomunicaciones
Se determinar la ubicacin geogrfica de cada
unidad mvil disponible para atender
Validacin:
emergencias de cualquier ndole
Prioridad: Baja Requisitos en Conflicto: ---

Fecha: 06/08/2010. Pgina 40 de 107
3.4. Desarrollo de la baseline de la arquitectura.
En esta fase se abarcan ms los flujos de trabajo de requisitos, modelo

de negocios (refinamiento), anlisis, diseo y una parte de implementacin
orientado a la baseline de la arquitectura del SISTE.
Las vistas de caso de uso que se mostrarn en esta seccin, modelarn la
funcionalidad del SISTE segn lo perciben los usuarios externos, llamados acto-
res. Un caso de uso, es una unidad coherente de funcionalidad, expresada como
transaccin entre los actores y el sistema. El propsito de la vista de casos de uso
es enumerar a los actores y los casos de uso, y demostrar cuales actores partici-
pan en cada caso de uso.
As mismo, las vistas de Interaccin describirn las secuencias de intercam-
bios de mensajes entre los roles que implementan el comportamiento del SISTE.
Un rol de clasificador, es la descripcin de un objeto, que desempea un determi-
nado papel dentro de una interaccin, distinto de los otros objetos de la misma
clase. Esta visin proporcionar una vista integral del comportamiento del siste-
ma; es decir, muestra el flujo de control a travs de muchos objetos. La vista de
interaccin se exhibir en dos diagramas centrados en distintos aspectos: dia-
gramas de secuencia y colaboracin.
De igual forma, las vistas de mquina de estados modelan las posibles
historias de vida de un objeto de una clase. Una mquina de estados contie-
ne los estados conectados por transiciones. Cada estado modela un perodo
de tiempo, durante la vida de un objeto, en el que satisface ciertas condicio-
nes. Cuando ocurre un evento, se puede desencadenar una transicin que
lleve el objeto a un nuevo estado. Cuando se dispara una transicin, se pue-
de ejecutar una accin unida a la transicin. Las mquinas de estados se
muestran como diagramas de estados.

Fecha: 06/08/2010. Pgina 41 de 107
A continuacin se muestra la representacin del SISTE, de manera general

en
la siguiente Figura 37, mediante la cual se evidencia que el SISTE es el interme-
diario entre el ciudadano y el SAE.
Figura 37: Diagrama general de caso de uso del SISTE


Fecha: 06/08/2010. Pgina 42 de 107
Men Principal del SISTE:
En la siguiente Figura 38, se encuentra la representacin grfica del men

principal del SISTE, el cual se explica en el Cuadro 31, identificndose los dife-
rentes mdulos existentes en el SISTE, con cada uno de los actores que partici-
pan, los cuales proveen de mecanismos automatizados a cada unidad organiza-
cional del SAE.
Figura 38: Diagrama de caso de uso del men principal SISTE

Los mdulos del men principal del SISTE son el reporte de emergencia por
parte del ciudadano; la atencin del reporte; el despacho de servicio de atencin;
la atencin de la emergencia y la supervisin a todo el sistema.

Fecha: 06/08/2010. Pgina 43 de 107
Cuadro 31: descripcin del diagrama de caso de uso del men principal SISTE
Caso de uso Men principal del SISTE
Actores participan- Ciudadano, central telefnica, operador, despachador,
tes servidor de Organismo de Seguridad, supervisor
Condicin de En- Existencia de un reporte de una emergencia
trada
Flujo de Eventos 1. Reportar una emergencia
2. Atender el reporte de una emergencia
3. Despachar el servicio
4. Atender emergencia
5. Supervisar y Controlar la Calidad del Servicio
Condiciones de Disponibilidad de unidades de atencin de emergen-
Salida cia
Requisitos espe- Debe existir subordinacin de organismos de seguri-
ciales dad al SAE
Notas Representa el men principal del SISTE

Fecha: 06/08/2010. Pgina 44 de 107
En la siguientes Figuras 39, 40 y 41, se presentan los diagramas de secuen-

cias, estados y colaboracin del men principal del SISTE, correspondientes a la
Figura 38.
Figura 39: Diagrama de secuencia del men principal SISTE


Fecha: 06/08/2010. Pgina 45 de 107
Figura 40: Diagrama de estados del men principal SISTE


Fecha: 06/08/2010. Pgina 46 de 107
Figura 41: Diagrama de colaboracin del men principal SISTE


Fecha: 06/08/2010. Pgina 47 de 107
Mdulo Reportar una Emergencia
En la siguiente Figura 42, se presenta el primer mdulo del SISTE denomi-

nado reportar una emergencia, el cual se explica en el Cuadro 32, a travs de
cuyo mdulo Las personas contactan al SAE para solicitar le atiendan en su
emergencia, mediante tres mtodos, el de discado 171, haciendo una llamada
VoIp y a travs de un servicio Web.
Figura 42: Diagrama de caso de uso del mdulo reportar emergencia


Fecha: 06/08/2010. Pgina 48 de 107
Al momento de hacer el contacto, el ciudadano solicita ayuda, y el servidor

del SISTE revisa inmediatamente un historial de las llamadas realizadas desde el
nmero de telfono direccin Ip.

Fecha: 06/08/2010. Pgina 49 de 107
Cuadro 32: descripcin del diagrama de caso de uso del mdulo reportar emergencia
Caso de uso Reportar una emergencia
Actores Ciudadano, central telefnica VoIp, Servidor Web, Su-
participantes pervisor
Condicin de El ciudadano har el contacto con el SAE va web o
Entrada telefnica
Flujo de Eventos 1. Reportar va web
1.1. ir a 4
2. Hacer llamada al discado 171
2.1. ir a 4
3. Hacer llamada VoIp
3.1. ir a 4
4. Verificar listado de llamadas
5. Solicitar atencin a emergencia
Condiciones de Solicitud de atencin a emergencia
Salida
Requisitos Disponibilidad de lnea 171 de CANTV
especiales
Notas Representa los procesos que se realizan en el mdulo
reportar una emergencia

Fecha: 06/08/2010. Pgina 50 de 107
Mediante la Figuras 43, 44 y 45, se exponen la construccin del mdulo de

reportar una emergencia, a travs de los diagramas de secuencias, estados y
colaboracin.
Figura 43: Diagrama de secuencia del mdulo reportar emergencia


Fecha: 06/08/2010. Pgina 51 de 107
Figura 44: Diagrama de estados del mdulo reportar emergencia


Fecha: 06/08/2010. Pgina 52 de 107
Figura 45: Diagrama de colaboracin del mdulo reportar emergencia


Fecha: 06/08/2010. Pgina 53 de 107
Mdulo Atender el Reporte de una Emergencia
En la siguiente Figura 46, se hace la representacin grfica del mdulo

Atender el Reporte de una Emergencia, mediante el cual, el operador del SAE,
el operador recibe la emergencia reportada y canaliza la misma para resolverla
con procesos giles, y con la intencin de inmediatamente emitir la orden de ser-
vicio. En el cuadro 33 se explica la referida figura.
Figura 46: Diagrama de caso de uso del mdulo atender el reporte de una emergencia
El operador recibe los datos bsicos de la emergencia, tales como nombre y

cdula de quien llama, direccin, nmeros de telfono, direccin de la emergen-

Fecha: 06/08/2010. Pgina 54 de 107
cia y una descripcin breve y precisa de la misma. Luego, genera inmediatamen-

te el ticket de emergencia una vez auditada la llamada, cuyo caso de uso est
explicado posterior a este mdulo, para que sea atendida por el rgano de Segu-
ridad, y contina la entrevista ampliando la informacin y dando apoyo y asesora
para brindar calma y tratar de solucionar el problema sin dilacin.

atender el reporte de una emergencia
Caso de uso Atender el Reporte de una Emergencia

Actores Ciudadano, operador, despachador, supervisor
participantes
Condicin de El ciudadano reporta una emergencia
Entrada
Flujo de Eventos 1. Aportar datos personales y de emergencia
2. Establecer comunicacin con el despachador
3. Generar ticket de emergencia
3.1. Ampliar datos de la emergencia y el ciudadano
3.2. Asesorar y apoyar para enfrentar la emergencia al
ciudadano.
Condiciones Ticket de emergencia
de Salida
Requisitos Auditar la llamada de emergencia
especiales
atender el reporte de una emergencia

Fecha: 06/08/2010. Pgina 55 de 107
A continuacin, se presentan los diagramas de secuencias, estados y cola-

boracin del mdulo atender el reporte de una emergencia, conformando los
esquemas de construccin del mismo en las Figuras 47, 48 y 49.
Figura 47: Diagrama de secuencia del mdulo atender el reporte de una emergencia

Fecha: 06/08/2010. Pgina 56 de 107
Figura 48: Diagrama de estados del mdulo atender el reporte de una emergencia

Fecha: 06/08/2010. Pgina 57 de 107
Figura 49: Diagrama de colaboracin del mdulo atender el reporte de una emergencia

Fecha: 06/08/2010. Pgina 58 de 107
Sub-Mdulo Auditar la Llamada de Emergencia
La auditora de la llamada de emergencia es una funciones vitales del SIS-

TE, y es un sub-mdulo que corresponde al mdulo de atender el reporte de una
emergencia, mediante el cual se van a revisar los datos de origen de la llamada,
su histrico y el registro delictivo del ciudadano que llama (ver Figura 50).
Figura 50: Diagrama de caso del mdulo auditar la llamada de emergencia


Fecha: 06/08/2010. Pgina 59 de 107
En este sub-mdulo, el operador evaluar y deducir si la llamada es con-

fiable, o presenta indicios de ser una llamada de sabotaje, generando un ticket de
acuerdo a los resultados. En el Cuadro 34 se describe la anterior Figura 50.
Cuadro 34: descripcin del diagrama de caso del mdulo

auditar la llamada de emergencia
Caso de uso Auditar la llamada de emergencia

Actores Operador, colaborador, proveedor de telefona, ISP,
participantes MppRIJ, ciudadano, supervisor
Condicin de Datos bsicos de la llamada, nmero de contacto y de
Entrada cdula
Flujo de Eventos 1. Revisar datos de la llamada
2. Evaluar histrico del contacto orgen
3. Determinar status del ciudadano
3.1. Si es confiable la llamada entonces
3.1.1. Generar ticket llamada confiable
De lo contrario
3.2. Si no es confiable la llamada entonces
3.2.1. Generar ticket llamada no confiable
3.2.2. Hacer cuestionario de preguntas adicional
Fin del si 3.1
3.3. Si el ciudadano tiene delitos entonces
3.3.1. Generar ticket de alerta delito
3.3.2. Hacer cuestionario de preguntas adicional
Fin del si 3.3
Condiciones Ticket de llamada y de alerta delito
de Salida
Requisitos Enlace on line a empresas proveedoras de telefon e
especiales ISPs; y a los Registros delicitivos de S.I.P.O.L.
Notas Representa los procesos que se realizan en el sub-
mdulo auditar la llamada de emergencia

Fecha: 06/08/2010. Pgina 60 de 107
En las prximas Figuras 51, 52 y 53, se desarrollan los diagramas corres-

pondientes a la construccin de la anterior vista de caso de auditora de la lla-
mada de emergencia.
Figura 51: Diagrama de secuencia del mdulo auditar la llamada de emergencia


Fecha: 06/08/2010. Pgina 61 de 107
Figura 52: Diagrama de estados del mdulo auditar la llamada de emergencia


Fecha: 06/08/2010. Pgina 62 de 107
Figura 53: Diagrama de colaboracin de la vista del mdulo auditar la llamada de emergencia

Fecha: 06/08/2010. Pgina 63 de 107
Mdulo Despachar el Servicio
La prxima vista de caso de uso del mdulo Despachar el Servicio, es la

funcin del SISTE mediante el cual el despachador recibe el ticket de emergencia
y enva inmediatamente al rgano de seguridad competente.
Figura 54: Diagrama de caso de uso del mdulo despachar el servicio

Como se observa en la Figura 54, la cual se describe en el Cuadro 35, el

despachador recibe el ticket de emergencia emitido por el operador, y genera el
ticket de despacho que se distribuye en todos los nodos del SISTE, para divulgar
la emergencia. Inmediatamente se comunica con las unidades mviles ms
apropiadas para atender la emergencia, previamente ubicadas por GPS.

Fecha: 06/08/2010. Pgina 64 de 107
Cuadro 35: descripcin del diagrama de caso de uso del mdulo despachar el servicio
Caso de uso Despachar el Servicio
Actores Ciudadano, central telefnica, operador, despachador,
participantes servidor de Organismo de Seguridad, supervisor
Condicin de Ticket de emergencia
Entrada
Flujo de Eventos 1. Ubicar unidades mviles de servicios de atencin
2. Generar ticket de despacho
3. Establecer contacto con unidades mviles y orga-
nismos de seguridad competentes
Condiciones Ticket de despacho
de Salida
Requisitos Operatividad de los radio enlaces troncalizados wi-fi
especiales
despachar el servicio

Fecha: 06/08/2010. Pgina 65 de 107
Ahora, los diagramas de secuencia, estados y colaboracin que correspon-

den al mdulo anterior, se muestran en las siguientes Figuras 55, 56 y 57.
Figura 55: Diagrama de secuencia del mdulo despachar el servicio


Fecha: 06/08/2010. Pgina 66 de 107
Figura 56: Diagrama de estados del mdulo despachar el servicio


Fecha: 06/08/2010. Pgina 67 de 107
Figura 57: Diagrama de colaboracin del mdulo despachar el servicio


Fecha: 06/08/2010. Pgina 68 de 107
Mdulo Atender Emergencia
El ltimo mdulo del SISTE llamado Atender Emergencia, que se presenta

en la Figura 58 y explicado en el Cuadro 36, est creado para que el rgano de
Seguridad preste el servicios correspondiente a lo indicado en el ticket de despa-
cho.
Figura 58: Diagrama de caso de uso del mdulo atender emergencia

El rgano de seguridad recibe el ticket de despacho, y posteriormente acude

al sitio de la emergencia y la atiende, registrando en el SISTE cada accin reali-
zada. Igualmente. El SISTE pone a la disposicin del rgano de Seguridad la
base de datos de Registros Delictivos, como instrumento de consulta.

Fecha: 06/08/2010. Pgina 69 de 107
Cuadro 36: descripcin del diagrama de caso de uso del mdulo atender emergencia
Caso de uso Atender emergencia
Actores Despachador, servidor de organismos de seguridad,
participantes personas con emergencia, MppRIJ, Supervisor
Condicin de Ticket de despacho
Entrada
Flujo de Eventos 1. Atender emergencia
2. Registrar todos los detalles del servicio prestado
3. Auditar y hacer seguimiento al servicio prestado
Condiciones Registros digitales de los servicios realizados en el
de Salida sitio de la emergencia
Requisitos Operatividad de los radio enlaces troncalizados wi-fi
especiales
atender emergencia

Fecha: 06/08/2010. Pgina 70 de 107
Finalmente, a continuacin se encuentran la Figuras 59, 60 y 61,contentivas

de los diagramas de secuencias, estados y colaboracin del mdulo de atencin
de emergencias.
Figura 59: Diagrama de secuencia del mdulo atender emergencia


Fecha: 06/08/2010. Pgina 71 de 107
Figura 60: Diagrama de estados del mdulo atender emergencia


Fecha: 06/08/2010. Pgina 72 de 107
Figura 61: Diagrama de colaboracin del mdulo atender emergencia


Fecha: 06/08/2010. Pgina 73 de 107
3.5. Construccin del producto.
Esta es la fase en que se lleva a cabo la construccin del producto por

medio de una serie de iteraciones, los cuales son el modelo de datos; los
diagramas de secuencias, estados y colaboracin (ya expresados anterior-
mente junto a los diagramas de casos de uso); modelo de dominio y mapa de
comportamiento a nivel de hardware; cuyas iteraciones est representadas,
representadas mediante las vista esttica lgica, vista de interaccin, vista
conceptual y vistas fsicas.
3.5.1. Modelado de datos.
Mediante la vista esttica o lgica, se ha modelado los conceptos del domi-

nio del SISTE, as como los conceptos internos inventados como parte de la im-
plementacin de dicha aplicacin. Esta visin es esttica porque no describe el
comportamiento del sistema dependiente del tiempo, que se describe en otras
vistas. Una clase es la descripcin de un concepto del dominio de la aplicacin o
de la solucin de la aplicacin. Las clases son el centro alrededor del cual se or-
ganiza la vista de clases; otros elementos pertenecen o se unen a las clases. La
visin esttica se exhibe en los diagramas de clases, llamados as porque su ob-
jetivo principal es la descripcin de clases
La estructura lgica general de la base de datos del SISTE se expresar
grficamente mediante el diagrama de clases, y un diagrama de Entidad-
Relacin (E-R), posterior al diccionario de datos.
3.5.1.1. Diccionario de datos:
En esta seccin se expondr el conjunto de metadatos que contiene las

caractersticas lgicas y puntuales de los datos que se van a utilizar en el
SISTE, los cuales se describen a continuacin.

Fecha: 06/08/2010. Pgina 74 de 107
Entidad: Llamadas de emergencia:
Registra todos los contactos realizados, almacenando cualquier llamada

realizada, diferencindose las llamadas de emergencia reales con las de sa-
botaje, mediante la designacin de un ticket de emergencia, que sern trans-
feridas al siguiente objeto.
Cuadro 37: Entidad Llamadas
Nombre de tabla Llamadas

Campo clave IdLlamada
Descripcin Registro de llamadas de emergencia
Descripcin
Atributo Tipo/longitud descripcin
*IdLlamada Entero ndice autonumrico (ticket de
emergencia)
IdUsuario Entero Usuario del SISTE que registr la
informacin
NumeroContacto Texto (15) Nmero telefnico o direccin Ip del
ciudadano
Cedula Texto (9) Nmero de identificacin del ciuda-
dano
NombreSolicitante Texto (30) Nombres completos del ciudadano
DireccionEmergencia Texto (50) Direccin en donde ocurre emer-
gencia
TelefonosContacto Texto (50) Nmeros telefnicos del ciudadano
IdTipoEmergencia Entero Tipo de emergencia que report
Prioridad Carcter Nivel de urgencia de la emergencia
Hora Hora Hora del ticket de despacho
Fecha Fecha Fecha del ticket de despacho
Sabotaje S/no Bandera de confiabilidad de la lla-
mada

Fecha: 06/08/2010. Pgina 75 de 107
Entidad: Despachos:
El siguiente objeto es el de despachos de servicios, los cuales son las

llamadas que han sido determinadas como emergencia real, y deben ser ca-
nalizadas inmediatamente sus acciones de atencin.
Cuadro 38: Entidad Despachos
Nombre de tabla Despachos
Campo clave IdDespacho
Descripcin Registro de despacho de servicios
Descripcin
*IdDespacho Entero ndice autonumrico
IdLlamada Entero Cdigo del ticket de emergencia
IdInstitucionDespachada Entero Organismo de seguridad despa-

chado
IdUsuario Entero Usuario del SISTE que registr

la informacin
Descripcion Memo Informacin ampliada de la

emergencia
Hora Hora Hora del ticket de despacho
Fecha Fecha Fecha del ticket de despacho

Fecha: 06/08/2010. Pgina 76 de 107
Entidad: AtencionEmergencia:
En esta entidad, se crean registros relacionados con el anterior objeto de

despacho, mediante los cuales los organismos de seguridad que atienden las
emergencias, registran detalladamente las acciones que realizan en cada
emergencia, as se obtiene una bitcora de servicio por cada emergencia.
Cuadro 39: Entidad AtencionEmergencia
Nombre de tabla AtencionEmergencia
Campo clave IdAtencion
Descripcin Registro de atencin de emergencias
Descripcin
Atributo Tipo/ descripcin

longitud
*IdAtencion Entero ndice autonumrico
Descripcion Memo Informacin detallada de servicio
Fecha Fecha Fecha de la atencin
Hora Hora Hora de la atencin
IdUnidad Entero Unidad que atendi la emergencia
IdUsuario Entero Usuario del SISTE que registr la informa-

cin
IdDespacho Entero Cdigo del ticket de despacho

Fecha: 06/08/2010. Pgina 77 de 107
Entidad: Usuarios:
Los usuarios conforman a todas las personas que manipularn el SISTE,

limitando el acceso a ciertos mdulos, segn sea el caso de su nivel de atri-
buciones, mediante polticas de restriccin de acceso definidas por el super
usuario supervisor del SISTE.
Cuadro 40: Entidad Usuarios
Nombre de tabla Usuarios
Campo clave IdUsuario
Descripcin Registro de usuarios con acceso al SISTE
Descripcin
*IdUsuario Entero ndice autonumrico
Usuario Texto (50) Nombres del usuario
Grado Carcter Cargo en la organizacin
Nivel Carcter Nivel de acceso al SISTE

Fecha: 06/08/2010. Pgina 78 de 107
Entidad: InstitucionesSeguridad:
Se registran los datos de los Organismos de Seguridad y dems institu-

ciones que participan en la atencin de emergencias, tales como, Policas,
Bomberos, Trnsito, Fuerza Armada, Grupos de Rescate, entre otros.
Cuadro 41: Entidad InstitucionesSeguridad
Nombre de tabla InstitucionesSeguridad
Campo clave IdInstitucion
Campo clave Registro de Instituciones que

prestan el servicio de atencin de Emergencias
Descripcin
Atributo Tipo/longitud Descripcin
*IdInstitucion Entero ndice autonumrico
Institucion Texto (50) Nombre del Organismo de Seguridad
Direccion Texto (50) Direccin de domicilio
Telefonos Texto (50) Telfonos de la Institucin
Contacto Texto (50) Persona contacto

Fecha: 06/08/2010. Pgina 79 de 107
Entidad: UnidadesAtencion:
Por medio de este objeto, cada Organismo de Seguridad indica las uni-
dades mviles y fijas de atencin de emergencia disponibles para que el SAE
pueda disponerlas para sus servicios. El campo coordenadas es alimentado
automticamente por el dispositivo GPS que tenga cada unidad.
Cuadro 42: Entidad UnidadesAtencion
Nombre de tabla UnidadesAtencion
Campo clave IdUnidad

Descripcin Registro de unidades mviles adscritas a or-
ganismos de seguridad que prestan servicio
de atencin de Emergencias
Descripcin
*IdUnidad Entero ndice autonumrico
Unidad Texto (50) Identificacin de la unidad mvil
IdInstitucion Entero Organismo de Seguridad al que corres-

ponde
Responsable Texto (50) Nombre de la persona responsable de

la unidad
Telefonos Texto (50) Nmero telefnicos para contactarla
Coordenadas Texto (10) Coordenadas geogrficas de posicio-

namiento

Fecha: 06/08/2010. Pgina 80 de 107
Entidad: Colaboradores.
En este recipiente digital, el supervisor del SAE registrar a todas las

personas, instituciones pblicas privadas, ONGs, Concejos Comunales,
Asociaciones de Vecinos, u otras formas de organizacin social, que sirvan
como entes voluntarios de expansin del SAE.
Cuadro 43: Entidad Colaboradores
Nombre de tabla Colaboradores
Campo clave NumeroContacto
Descripcin Registro de colaboradores voluntarios del SAE
Descripcin
Atributo Tipo/longitud Descripcin
*NumeroContacto Texto (9) ndice y Nmero telefnico
Colaborador Texto (30) Nombres completos
Cedula Texto (9) Nmero de Identificacin personal
Direccin Texto (30) Direccin de habitacin
Telfonos Texto (20) Otros nmeros de contactos adiciona-

les

Fecha: 06/08/2010. Pgina 81 de 107
Entidad: TipoEmergencia.
Con esta entidad, se almacenan los tipos de emergencia que pueden

ocurrir, lo que permitir al SISTE agilizar el ingreso de datos, ya que cada
tipo sugerir automticamente datos que deban ingresarse en otros campos.
Cuadro 44: Entidad TipoEmergencia
Nombre de tabla TipoEmergencia
Campo clave IdTipoDenuncia
Descripcin Registro de tipos de emergencias
Descripcin
* IdTipoDenuncia Entero ndice autonumrico
TipoDenuncia Texto (50) Nombre del tipo de emergencia
IdInstitucion Texto (50) Organismo de seguridad competente

Fecha: 06/08/2010. Pgina 82 de 107
Entidad: RegistrosDelicitivos.
Esta entidad permite consultar inmediatamente va on line los registros

policiales, delictivos y judiciales de las personas, del sistema S.I.P.O.L. lleva-
do por el Cuerpo de Investigaciones Cientficas Penales y Criminalsticas
(C.I.C.PC.), as como cualquier otro que el MppRIJ establezca.
Cuadro 45: Entidad RegistrosDelictivos
Nombre de tabla RegistrosDelictivos
Campo clave *Cedula
Descripcin Registros delictivos del S.I.P.O.L. y otros
Descripcin
*Cedula Texto (9) ndice y nmero de identificacin per-

sonal
Nombres Texto (30) Nombres completos
Solicitante Texto (30) Institucin o instancia que lo solicita

Fecha: 06/08/2010. Pgina 83 de 107
Entidad: GPS.
Permite ubicar a las unidades mviles de los organismos de seguridad

que participan en el SAE, la cual sera actualizada automticamente median-
te rastreos constantes a todas las referidas unidades.
Cuadro 46: Entidad GPS
Nombre de tabla GPS
Campo clave Coordenadas
Descripcin Registro de sistema de posicionamiento global (GPS)
Descripcin
*Coordenadas Texto (10) Coordenadas geogrficas de posicio-

namiento
Localizacion Texto (50) Localizacin fsica de ubicacin

Fecha: 06/08/2010. Pgina 84 de 107
3.5.1.2. Diagrama de clases.
El diagrama de clases de la Figura 62, describir la estructura del SISTE

sistema mostrando sus clases, atributos y las relaciones entre ellos. Este
diagrama ha sido utilizado para crear el diseo conceptual de la informacin
que se manejar en el sistema, y los componentes que se encargarn del
funcionamiento y la relacin entre uno y otro.
3.5.1.3. Modelo Entidad-Relacin (E-R)
La Figura 63 del modelo E-R es para facilitar el diseo de la bases de

datos del SISTE, permitiendo la especificacin de un esquema del SAE que
representa la estructura lgica completa de la base de datos. El modelo de
datos E-R es uno de los diferentes modelos de datos semnticos que radica
en el intento de representar el significado de los datos.
3.5.2. Modelo de dominio.
El SISTE se puede dividir en unidades ms pequeas mediante la vista

conceptual de gestin de modelo, de modo que los trabajadores del SAE
puedan trabajar con una cantidad de informacin limitada, a la vez y de mo-
do que los equipos de trabajo no interfieran con el trabajo de los otros. Aqu
se representar el SISTE en paquetes y relaciones de dependencia entre
paquetes, a travs del diagrama de paquetes de la siguiente Figura 64.

Fecha: 06/08/2010. Pgina 85 de 107
Figura 62: Diagrama de Clase de la Base de Datos del SISTE


Fecha: 06/08/2010. Pgina 86 de 107
Figura 63: Diagrama E-R del SISTE


Fecha: 06/08/2010. Pgina 87 de 107
Figura 64: Diagrama de paquetes del SISTE

3.5.3. Mapa de comportamiento a nivel de hardware.
Con las vistas fsicas se modelarn la estructura de implementacin del SIS-

TE por s mismo, su organizacin en componentes, y su despliegue en nodos de
ejecucin. Estas vistas proporcionan una oportunidad de establecer correspon-
dencias entre las clases y los componentes de implementacin y nodos.

Fecha: 06/08/2010. Pgina 88 de 107
Ms adelante, se representar el SISTE con dos vistas fsicas; la primera se-

r la vista de despliegue, y la segunda con la vista de implementacin.
La vista de despliegue a nivel de descriptor, que se encuentra en la Figura
65, representa la disposicin de las instancias de componentes de ejecucin del
SISTE en instancias de nodos.
Figura 65: Diagrama de despliegue (nivel de descriptor) del SISTE.


Fecha: 06/08/2010. Pgina 89 de 107
Por otro lado, la vista de implementacin representada en la Figura 66, mode-

la los componentes del SISTE, a partir de los cuales se construir dicha aplica-
cin, as como las dependencias entre los componentes, para poder determinar el
impacto del Sistema de Informacin. Tambin modela la asignacin de clases y
de otros elementos del modelo de componentes.
Figura 66: Diagrama de componentes del SISTE


Fecha: 06/08/2010. Pgina 90 de 107
Estas vistas permiten determinar las consecuencias de la distribucin y de la

asignacin de recursos que sern aplicados al momento de implementar el SIS-
TE.
3.6. Producto final
Para presentar los resultados correspondientes a cada uno de los objetivos

especficos planteados en el presente DDR, como resultados del modelado reali-
zado; se proceder a exponer los argumentos y razonamientos lgicos, que expli-
can el cumplimiento de cada uno de los objetivos especficos y general, a que se
contrae el presente documento.
Creacin de DRU:
El primero objetivo especfico textualmente dice Crear el Documento de
Requisitos de Usuario (DRU) que constituye el documento aceptado por el
usuario del SISTE, para lo cual se realiz la fase primera de inicio de la me-
todologa RUP (2001), el Modelado de Negocios a travs del lenguaje unifi-
cado de modelado (UML), y se determin la especificacin de requisitos de
usuario.
Este objetivo fue alcanzado completamente, con la obtencin del DRU el
cual contiene los requisitos de usuario definiendo claramente los objetos y
actores que fueron considerados en el DRS, para el desarrollo del modelo
lgico del SISTE (ver Figura 67),
Creacin de DRS:
Seguidamente, el segundo objetivo especfico est formulado como Ela-
borar el Documento de Requisitos de Software (DRS), el cual contiene el
modelo lgico del SISTE, incluyendo su modelado de datos y plan de gestin

Fecha: 06/08/2010. Pgina 91 de 107
del desarrollo del SISTE; a cuyos efectos se desarrollaron las fases segunda
de elaboracin, tercera de construccin y cuarta de transicin de la metodo-
loga RUP (2001), aplicando en dichas fases, igual que la creacin del DRU
el lenguaje unificado de modelado (UML).
Figura 67: Procesos SISTE con actores

La vista de implementacin representada en la Figura 68, modela los compo-

nentes del SISTE, a partir de los cuales se construir dicha aplicacin, as como
las dependencias entre los componentes, para poder determinar el impacto del
Sistema de Informacin. Tambin modela la asignacin de clases y de otros ele-
mentos del modelo de componentes.

Fecha: 06/08/2010. Pgina 92 de 107
Figura 68: Diagrama de despliegue (nivel de instancia) del SISTE.

Creacin de DDR:
Finalmente, el objetivo principal de este proyecto, es el de Desarrollar el

Documento de Definicin de Requisitos (DDR) que proporcione los insumos
necesarios para el siguiente flujo de trabajo de la metodologa de Ingeniera
de Software RUP (2001), de implementacin del Sistema de Informacin para
la Atencin de Emergencias (SISTE), contiene los Documentos de Requisi-
tos de Usuario (DRU) y Documento de Requisitos de Sistema (DRS), presen-
tados con los anteriores objetivos especficos.
Se ha completado totalmente el cumplimiento del objetivo principal, mediante
el desarrollo del DDR, contentivo del diseo del Sistema de Informacin para
la Atencin de Emergencias (SISTE) (ver Figura 69), el cual se activa al mo-
mento de que una persona solicita, va telefnica o Internet, que se le ayude
a resolver una emergencia presentada; funcionando como un mecanismo
tecnolgico de integracin con los Organismos de Seguridad del Estado, a

Fecha: 06/08/2010. Pgina 93 de 107
los fines de que acudan a los sitios de sucesos, los ms rpido po sible y sin
retrasos innecesarios, y atiendan efectivamente la emergencia presente.
Figura 69: Esquema conceptual del SISTE

El SISTE Contar con una red Extranet de tipo Wide Access Network
(WAN) con nodos enlazados por Internet y por medio de enlaces inalmbri-
cos terrestres y satelitales, como mtodos de enlace redundantes y alternos;
de topologa mixta; plataforma cliente-servidor; bajo protocolo TCP/IP; con
estaciones fijas en cada sede fsica de cada organismo que integra el SIG, y
sus unidades mviles; provistas de todos los mecanismos de software y
hardware para la seguridad de voz y datos; tendr como funciones lo siguien-
te:

Fecha: 06/08/2010. Pgina 94 de 107
1) El cdigo fuente y todas las rutinas y procedimientos del SISTE esta-

rn alojados en el Servidor Principal del MppRIJ, accesibles va Web por to-
dos los SAE Estadales del pas; con sus bases de datos alojados en Servido-
res Secundarios anidados al Servidor Principal; enlazar va on line a las ba-
ses de datos correspondientes a los Organismos de Seguridad, los registros
de abonados de telefona mvil o fija, los Registros Nacionales de Delitos,
S.I.P.O.L.; y los datos del Servicio de Meteorologa de la Aviacin; las cuales
estarn disponibles a todas las estaciones fijas y mviles de la WAN (3.2 y
3.3). Tendr la capacidad de determinar la procedencia exacta de todos los
ciudadanos que reportan emergencias, combatiendo las llamadas de sabota-
je; as como devolver la ubicacin de las unidades de atencin de emergen-
cias por satlite va GPS;
1.1 y 1.2) Tendr a la disposicin del pblico tres mecanismos de reporte
de emergencias vas discado de telefona tradicional mvil, fija y pblica (dis-
cado 171 cualquier otro que se establezca por el SAE); VoIp y World Wide
Web (www).
2) El cdigo fuente, las rutinas y procedimientos del SISTE de uso local,
estarn alojados en los Servidores Secundarios de cada SAE, accediendo on
line al Servidor Principal y a las bases de datos a que este accede; con sus
bases de datos de los registros locales.
3) Proveer de un sistema de telefona VoIp privada, conectados a las
unidades de enlace E1 que poseen las lneas telefnicas enlazadas al nme-
ro 171, y a Internet; para comunicarse mediante auriculares con todos los
ciudadanos que reportan emergencias, va telefona tradicional y VoIp; as
como a todos las estaciones fijas y unidades mviles que integran la WAN.
Crear registros digitales de voz y datos de todos los reportes de emergen-
cias realizados por los ciudadanos y las emergencias atendidas por los Or-
ganismos de Seguridad que forman el SISTE;

Fecha: 06/08/2010. Pgina 95 de 107
Ofrecer tres mecanismos de despacho de unidades de los Organis-

mos de Seguridad, va telefona VoIp, digital o de radio-comunicaciones tra-
dicional, haciendo uso de la Red Troncal y enlaces inalmbricos terrestres y
satelitales, con generacin de datos de monitoreo y seguimiento de las
emergencias atendidas.
3.6.1. Plan de gestin de desarrollo.
3.6.1.1. Factibilidad social.
El desarrollo del SISTE impactar ampliamente a la sociedad venezolana, en

virtud de que los ciudadanos encontrarn en el SAE de cada Estado una efectiva
solucin a sus emergencias, al lograr disminuir considerablemente la capacidad
de respuesta de los Organismos de Seguridad, los cuales se podrn responder
en menos tiempo la emergencia presente, considerando que cada segundo es
importante para la vida humana, ya que en ese segundo o ms, puede fallecer
una persona, siendo de muy importantsimo valor la considerable inversin que
se realizara, adems de que es imprescindible mostrar el respeto a los ciudada-
nos, hacer uso de los fondos pblicos invertidos en enormes cantidades en el
pas y en cada Estado, tal como el satlite VENESAT1 Simn Bolvar, los cua-
les, si son aprovechados con el SISTE, se lograrn disminuir los tiempos de res-
puesta de los SAE, redundando en una disminucin de los ndices de seguridad
y una mejor calidad de vida de los venezolanos.
3.6.1.2. Factibilidad tcnica.
En virtud de que el SISTE es un proyecto coordinado por el MppRIJ, con

proyeccin nacional para ser instalado en todos los SAE de Venezuela, se realiza

Fecha: 06/08/2010. Pgina 96 de 107
el estudio tcnico, para ser aplicado en tres etapas. La primera la que correspon-
de a la sala central de servidores del SISTE ubicada en las oficinas del MppRIJ.
La segunda, la correspondiente a las plataformas tecnolgicas de accesos remo-
tos al SISTE, ubicadas en cada SAE adscrito a las Direcciones de Seguridad
Ciudadana de cada Entidad Regional. Y La tercera etapa, es la conformacin de
una Wi-Fi nacional que integrara a todos los SAE de Venezuela, incluyendo a
todos los Organismos de Seguridad.
Primeramente, para la primera etapa, se requiere del siguiente inventario DE
aplicando en la medida de lo posible tecnologas libres:
Sala Central de Servidores del SISTE:

Una sala de servidor con amplia seguridad de acceso y aire acondiciona-
do.
Un (1) escritorio de oficina modular 2 x 2 mts.
Dos (2) Racks torre verticales con patch panel y cableado estructurado
UTP nivel 6.
Dos (2) switch 12 pts Cisco Systems 1000 bps anidables.
Cuatro (4) servidores HP Proliant. 4Gb Ram. disco duro SATA 1 TB con
fuente de poder redundante cada uno (servidor principal de archivos e im-
presin, servidor auxiliar mirror, servidor Proxy Firewall, central VoIp).
Un (1) software de central de telefona VoIp Digium Asterix.
Una (1) telfono VoIp Avaya.
Tres (3) kit de enlace satelital.
Un (1) satlite de comunicaciones VENESAT1 Simn Bolvar.
Materiales y Suministros.
Seguidamente, se pasa a describir la plataforma tecnolgica necesaria en

cada SAE Estadal, junto con la conformacin de una Wi-Fi que integrara al SAE

Fecha: 06/08/2010. Pgina 97 de 107
con todos los Organismos de Seguridad, la cual se presenta de la siguiente for-

ma las cuales requieren de lo siguiente:
Un (1) computador de escritorio ltima generacin.

Una (1) computadora porttil ltima generacin.
Una (1) Tarjeta DIGIUM 2fx / 2fo para telefona Voip
Un (1) dispositivo de rastreo satelital GPS.
Un (1) software de central de telefona VoIp Digium Asterix.
Dos (2) telfonos VoIp Avaya consola de escritorio.
Un (1) Router Avaya inalmbrico.
3.6.1.3. Factibilidad de Recursos Humanos
El desarrollo del proyecto comprende doce (12) meses, correspondientes al

desarrollo del cdigo fuente del SISTE, y su correspondiente validacin con el
Proyecto Nacional 171 del MppRIJ, y los SAE de cada Estado.
Para lograr lo mencionado, se requiere la conformacin de un equipo multi-
disciplinario por doce (12) meses, integrado por profesionales de Sistemas e In-
formtica, que utilizarn el presente Documento de Definicin de Requisitos
(DDR) (Ingeniera de Requisitos), para continuar los flujos de trabajo siguientes
correspondiente a la metodologa de Ingeniera de Software RUP (2001), a sa-
ber, implementacin, prueba y despliegue.
El grupo multidisciplinario, debe estar conformado por:
Jefe de Proyecto:
Un (1) Jefe de Proyecto,
Perfil: Ingeniero de Sistemas, Ingeniero de Informtica Licenciado en
Computacin.

Fecha: 06/08/2010. Pgina 98 de 107
Ingeniera de Software:
Un (1) arquitecto de Software Libre.
Perfil: Ingeniero de Sistemas, Ingeniero de Informtica Licenciado en
Computacin afines.
Dos (2) analistas programadores en Software Libre.
Perfil: Tcnicos Superiores en Informtica afines.
Un (1) documentador tcnico.
Perfil: Tcnicos Superiores en Informtica afines.
Un (1) traductor espaol ingls.
Perfil: Licenciado en Idiomas mencin Ingls afines.
Gastos varios
Gastos de transporte, alojamiento y alimentacin.
3.6.1.4. Factibilidad Econmica.
En virtud de los estudios tcnicos y de Recursos Humanos anteriormente

planteados, ahora se plantea el plan de inversin y costos necesarios para el
desarrollo del proyecto SISTE.
En el Cuadro 47 se expone el estudio econmico correspondiente a la im-
plementacin del SISTE, el cual presenta la inversin a realizar para la validacin
del prototipo del SISTE (versin beta), que pondr a disposicin de todos los SAE
del pas la versin final definitiva del Sistema de Informacin. Se requiere la ob-
tencin de activos fijos que formen parte sustancial de un desarrollo tecnol-
gico. Las necesidades mayores u ocasionales de equipos se podrn financiar
a travs de la partida de servicios. Estn excluidos los inmuebles que sirvan
de sede y los equipos de oficina. En la fase de evaluacin debern consig-
narse cotizaciones y para la fase de seguimiento, anexar facturas de los
equipos adquiridos

Fecha: 06/08/2010. Pgina 99 de 107
Cuadro 47: Factibilidad econmica del SISTE.
Descripcin Cantidad Precio Unitario IVA 12% Total
Computadora porttil 1 3.500,00 420,00 3.920,00

Computadora de escritorio 1 3.500,00 420,00 3.920,00
GPS 1 1.000,00 120,00 1.120,00
Tarjeta DIGIUM 2fx - fo 1 2.000,00 240,00 2.240,00
Telfono Vo-IP 2 500,00 120,00 1.120,00
Router inalmbrico 1 300,00 36,00 336,00
TOTAL EQUIPOS 12.656,00
Ahora, se procede a determinar los costos de personal (ver Cuadro 49), tanto
los que corresponden al equipo de desarrollo del Software, como al que se encar-
gar de instalar la plataforma tecnolgica de telecomunicaciones. Cabe destacar
que se proyecta el desarrollo del SISTE y la instalacin de los equipos de radio-
frecuencia y satelitales en un perodo de doce (12) meses, incluyendo implemen-
tacin, puestas a prueba, deteccin y correccin de fallas.
Cuadro 49: Factibilidad econmica recursos humanos del SISTE

Monto
Perfil Actividades a desempear Cantidad Meses Total
Mensual
Ingeniero Arquitecto de software libre 1 12 4.300,00 51.600,00
TSU Diseador de software libre 2 10 3.600,00 72.000,00
Licenciado Traduccin de Documentacin 1 2 4.300,00 8.600,00
TOTAL PERSONAL 132.200,00
Como materiales y suministros (ver cuadro 50), se podrn financiar los

insumos requeridos para el desarrollo tecnolgico. Quedan excluidos los
equipos, papelera, implementos destinados a labores administrativas y
cualquier material que no est involucrado directamente en la realizacin del
proyecto.

Fecha: 06/08/2010. Pgina 100 de 107
Cuadro 50: Factibilidad econmica materiales y suministros del SISTE.

Blocks de notas 6 15,00 10,80 100,80
Bolgrafos 12 15,00 21,60 201,60
Lpices No. 2 12 8,00 11,52 107,52
TOTAL MATERIALES 409,92
En cuanto a servicios y validacin (ver Cuadro 51), que son los gastos
generados por la contratacin de trabajos particulares generados por alguna
empresa o institucin para el logro del proyecto, quedan excluidos los
servicios pblicos tales como electricidad, telfono, etc.
Cuadro 51: Factibilidad econmica servicios y validacin del SISTE.
Servicios de impresin y repoduccin 1200 0,50 0,06 600,06

Servicios de empastado 6 80,00 9,60 489,60
Servicio de almacenamiento de Sotware en CD 6 15,00 1,80 91,80
Servicio de elaboracin de diapositivas 1 500,00 60,00 560,00
TOTAL SERVICIOS 71,46 1.741,46
Ahora, se exponen los gastos ocasionados por viticos y pasajes (ver

Cuadro 52), estn estipulados aquellos traslados a nivel nacional que sean
justificados para la elaboracin del proyecto.
Cuadro 52: Factibilidad econmica viticos y pasajes del SISTE.

UT Autorizada
Numero UT Autorizada para
Descripcin Destino para Trasporte y UT ao 2011 Total
de das alojamiento y comida
Traslado S/Tabla
Richard Rodrguez Caracas-Mrida-Caracas 2 5,5 5,5 76,00 1.672,00

Richard Rodrguez Valencia-Mrida-Valencia 1 5,5 5,5 76,00 836,00
Total Pasajes y Viticos 2.508,00
IVA 300,96
TOTAL 2.808,96

Fecha: 06/08/2010. Pgina 101 de 107
Para concluir, una vez revisados los anteriores estudios econmicos, a los fi-
nes de implementar el SISTE, de acuerdo al objetivo general planteado con ante-
rioridad, se requiere de una inversin total correspondiente a lo indicado en el si-
guiente Cuadro 53, de Bs. 149.816,34.
Cuadro 53: Resumen general de factibilidad econmica del SISTE.

Rubros Total Bs.
Equipos 12.656,00
Personal 132.200,00
Material y Suministros 409,92
Viticos 2.808,96
Servicios 1.741,46
Total 149.816,34
Ahora bien, a los fines de preservar los resultados financieros de la factibi-

lidad econmica, se proceder a continuacin a reflejar su equivalente en unida-
des tributarias (U.T.), la cual, en la actualidad est en Bs. 76,00 cada una; y en
divisa norteamericana, la cual, en su precio oficial est determinado en Bs. 4,30
por dlar.
Bs. 149.816,34 76,00 = 1.972 U.T.

Bs. 149.816,34 4,30 = USD $ 34.841,00
De los cmputos anteriormente realizados, se puede concluir que el pro-

yecto de desarrollo del SISTE, se podr ejecutar en primera fase, por el equiva-
lente en moneda nacional por 1.972 U.T., en su equivalente en divisa norteame-
ricana, por USD $ 34.841,00.

Fecha: 06/08/2010. Pgina 102 de 107
4. Autor del Proyecto:
Apellidos y Nombres: Rodrguez Salazar, Richard Jos.

Profesiones: Ingeniero de Sistemas y TSU en Informtica.
Ocupacin: Innovador en Ciencia, Tecnologa e Innovacin ONCTI y Asis-
tente de Tribunal de la Direccin Ejecutiva de la Magistratura TSJ, Mrida
Experiencia: 23 aos en Tecnologas de Informacin y Comunicacin.
Edad: 38 aos.
FORMACIN ACADMICA:
Superior pregrado:
2003 2010: IUP Santiago Mario. Ingeniero de Sistemas. Mrida Edo.
Mrida.
1995 1998: IUT Juan Pablo Prez Alfonso IUTEPAL. TSU en Informtica.
Valencia Edo. Carabobo.
Bachillerato:
1983 1989: Liceo Bolivariano Libertador. Mrida Edo. Mrida.
EXPERIENCIA PROFESIONAL:
Ejercicio libre de la profesin de Ingeniero de Sistemas. Actualmente desde
ao 1988.
Consultora de Tecnologas de Informacin y Comunicacin.
Innovador acreditado por el Observatorio Nacional de Ciencia y Tecnologa
ONCTI.
Investigador adjunto ad honorem acreditado por el Centro de
Investigaciones y Altos Estudios en Ciencias Sociales (CIAECIS-CS),
Universidad de Carabobo.
Desarrollo de proyectos de innovacin para el Programa de Estmulo a la
Investigacin e Innovacin (PEI).
Propuestas tecnolgicas para la Gobernacin del Estado Mrida.
Comerciante e importador de equipos tecnolgicos.
Docente del IUP Santiago Mario, Mrida Edo. Mrida. Actualmente desde
septiembre 2011.
Profesor de materias de Ingeniera de Sistemas.
Pasante de Ingeniera de Sistemas. Aviacin Militar Bolivariana, Divisin Centro
de Investigaciones y Desarrollo Aeronutico (CIDAE), Maracay edo. Aragua.
Sep - Nov 2009.

Fecha: 06/08/2010. Pgina 103 de 107
Participacin en el desarrollo de software del prototipo de simulador de tiro

de combate.
Contribucin en el funcionamiento de la Coordinacin de Informtica.
Tcnico de Redes del Servicio Autnomo de Telecomunicaciones de Mrida
(SATEM), Gobernacin del Estado Mrida. Mrida edo. Mrida. Mayo 2005 a
Enero 2006.
Ingeniera y desarrollo de redes de cableado estructurado e inalmbricas,
para el servicio telefnico de atencin de emergencias 171 y la
Gobernacin del Estado Mrida.
Help Desk del servicio telefnico de atencin de emergencias 171.
Jefe del Departamento de Informtica de la Instituto de Bibliotecas (IBIME),
Gobernacin del Estado Mrida. Mrida edo. Mrida. Enero 1999 Mayo 2005.
Desarrollo del proyecto de Bibliotecas Virtuales y Servicios de Informacin
Digital.
Coordinador de Infocentros y Bibliotecas Virtuales,
Miembro del equipo tcnico de la Presidencia y Direccin de la Institucin.
Participacin en los planes de Ciencia, Tecnologa e Innovacin del Estado
Mrida.
Facilitador del personal de los Infocentros de los Estados Mrida y Trujillo.
Creacin del Departamento de Informtica.
Instructor comunitario de cursos de alfabetizacin tecnolgica.
Ingeniera y desarrollo de redes de cableado estructurado, para las
Bibliotecas Pblicas.
Help Desk de la red de Bibliotecas Pblicas del Estado Mrida.
Docente del IU de Nuevas Especialidades (IUNE), La Azulita Edo. Mrida. Ao
2004.
Profesor de materias de TSU en Informtica.
CURSOS PROFESIONALES:
Ingls Books 0 y 1. CFP La Parroquia. Mrida. Actualmente en proceso
desde 2011.
Congreso Primera Escuela Internacional sobre Aplicaciones Biomdicas del
Lser, Instituto Venezolano de Investigaciones Cientficas IVIC, Mrida
Edo. Mrida. 2010.
Introduccin a la Geomtica. Fundacin Instituto de Ingeniera FII.
Caracas. 2009.
Liderazgo y Oratoria. Asesoramiento Comunicacional c.a. Mrida Edo.
Mrida 2008.

Fecha: 06/08/2010. Pgina 104 de 107
Comunicaciones niveles bsico y medio. AV Banda Ciudadana. Mrida

Edo. Mrida 2005.
Software Libre Nivel 0. Fundacite Mrida. Mrida Edo. Mrida, 2004.
Gestin Participativa Organizacional. IBIME, Gobernacin Mrida. Edo.
Mrida. 2003.
Redes CCNA-CISCO NIVEL I. Fundacite. Mrida Edo. Mrida. 2002
Formacin de Anfitriones para Infocentros. Gobernacin Mrida Edo.
Mrida. 2001.
Redes Locales. C-Matic. Mrida Edo. Mrida. 2000.
Microsoft Access 2000. C-Matic. Mrida Edo. Mrida. 2000.
Sistema operativo Linux. C-Matic. Mrida Edo. Mrida. 2000.
Microsoft Visual Basic. C-Matic. Mrida Edo. Mrida. 2000.
Ingls Niveles I y II. Venusa C.P.S. Mrida Edo. Mrida. 1999.
Teleinformcin en Venezuela - Alejandra. Hacer ULA. Mrida Edo. Mrida
1999.
Normas COVENIN ISO 9000. Papelera Venepal c.a. Mrida Edo. Mrida
1997.
Autocad y MS-DOS. Centro de Enseanza Integral. Valencia Edo.
Carabobo 1996.
Organizacin del Trabajo y Administracin del Tiempo. Ince. Mrida 1991.
Aprendiz Bancario: Auxiliar Bancario en Operaciones de Caja y Depsitos.
Ince Bancario. Mrida Edo. Mrida. Febrero 1989 hasta Febrero 1991.
Relaciones Humanas. Ince Mrida Edo. Mrida. 1990.
PROYECTOS DE INVESTIGACIN E INNOVACIN:
Propuesta de conformacin del Centro de Investigaciones y Altos Estudios
para la Universidad Politcnica Territorial de Ejido (UPT Ejido). Ao 2011.
Proyecto de desarrollo de Programa de Formacin para la Formulacin de
Proyectos de Consejos Comunales en el Estado Mrida. Ao 2011.
Propuesta de conformacin de una extensin del Centro de Investigaciones
y Altos Estudios en Ciencias Sociales (CIAECIS-CS) de la Universidad de
Carabobo, en Mrida. Ao 2011.
Proyecto de innovacin Tecnologa Socialista al Rescate del Pueblo para
la automatizacin de los servicios de atencin de emergencias 171. Ao
2011.
Trabajo especial de Grado Ingeniera de requisitos para el desarrollo de un
sistema de informacin en los Servicios de Atencin de Emergencia 171,
Julio 2010.
Trabajo de investigacin Propuesta de Creacin de la Direccin de
Telecomunicaciones e Informtica para la Gobernacin del Estado Mrida,
Febrero 2009.

Fecha: 06/08/2010. Pgina 105 de 107
Trabajo de investigacin Propuesta de reestructuracin de la Gobernacin

del Estado Mrida. Diciembre 2008.
Trabajo de investigacin plan de trabajo de la red de Bibliotecas Pblicas
de la Gobernacin del Estado Mrida. Septiembre 2008.
PUBLICACIONES:
Ponencia arbitrada Sistema organizacional de Ciencia y Tecnologa para la
optimizacin de la gestin gubernamental venezolana. Congreso Andaluz
de Sociologa, Universidad Pablo de Olavide, Espaa. Nov. 2008.
RECONOCIMIENTOS:
2011: Reconocimiento Tribunal Supremo de Justicia de Venezuela.
2011: Respaldo a estudios de posgrado Concejo Comunal El Central,
Mrida - Mrida.
2009: Reconocimiento por participacin como Pasante en CIDAE.
2008: Respaldo a ponencia internacional del CIAECIS-CS, Universidad de
Carabobo.
2008: Respaldo a ponencia internacional del Ministerio del pp para la
Cultura.
2007: Becario de FUNDAYACUCHO, para estudios de pregrado.
2007: Reconocimiento a la labor en el Tribunal Supremo de Justicia de
Venezuela.
1997: Reconocimiento como equipo de trabajo en la empresa Papelera
Venepal.

Fecha: 06/08/2010. Pgina 106 de 107

Fecha: 06/08/2010. Pgina 107 de 107
Copyleft Ing. Richard Rodrguez Salazar

Elaborado: Agosto, 2.010
Revisado: Noviembre, 2011
Se autoriza la copia, distribucin y/o modificacin de este documento bajo los trminos de la
Licencia de documentacin libre GNU, versin 1.2 o cualquier otra que posteriormente publi-
que la Free Software Foundation; sin secciones invariables, textos de portada,
ni textos de contraportada

CONCLUSIONES
La investigacin que se presenta en las anteriores pginas, abord el

Servicio de Atencin de Emergencias (SAE) de cada Estado del pas, cada
uno de los cuales deben funcionar como un rgano de coordinacin entre los
organismos de seguridad en cualquier parte del pas, a fin de acudir a los
sitios de emergencias en general, los ms rpido posible, sin muchas dilacio-
nes salvando vidas, evitando agravamientos de emergencias, tragedias y
muertes innecesarias por retardos de servicios; lo que se traducira en la
disminucin de los ndices de inseguridad.
Actualmente se presentan una serie de aspectos que indican la presen-
cia de una problemtica en el SAE caso del presente estudio, y de casi la
mayora del pas, y que inspiraron el desarrollo de una investigacin integral
de sistematizacin, como lo es la existencia de amplios retrasos y cierta des-
coordinacin de los organismos de seguridad en la atencin de emergencias;
tiempo perdido mientras se espera ayuda ante una emergencia; dificultades
de las poblacin para contactar a los organismos de seguridad; incremento
en los ndices de inseguridad; tragedias, enfermedades agravadas y muertes
innecesarias ocurridas ante los retrasos de los organismos de seguridad; in-
satisfaccin y crticas en las personas.
Se abord el caso Estado Mrida, en el extinto Servicio Autnomo de Te-
lecomunicaciones del Estado Mrida (SATEM), hoy Direccin del Poder Po-
pular Estadal para la Teleinformtica (DppTI), adscrita a la Direccin del Po-
der Popular Estadal de Seguridad Ciudadana (DppSS) del Ejecutivo Regio-
nal; funciona el SAE 171 de esta entidad.
Los diagnsticos de la investigacin, como primero objetivo especfico,
se realizaron a finales del ao 2.008, estando presentes en la actualidad la
misma problemtica detectada para ese momento, en el SAE 171 Mrida, y
185
realizndose inicialmente el registro de los datos de la observacin directa en
las oficinas del SAE, para conocer el funcionamiento de los equipos de pro-
cesamiento de datos, mtodo de trabajo, normas y procedimientos, y cual-
quier elemento que fuera necesario considerar en el desarrollo de la Investi-
gacin; utilizando como instrumento la hoja de observacin, la cual consisti
en prestar atencin acuciosa al funcionamiento en caliente de las reas ope-
rativas y administrativas del SAE 171 Mrida y registrar todo lo observado.
Igualmente se registraron los datos de las entrevistas realizadas a los
trabajadores del SAE, concernientes al funcionamiento del actual Sistema de
Informacin inoperativo desde hace dos (2) aos, aplicndose un cuestiona-
rio adaptativo; cuyas preguntas estaban relacionadas con los procesos que
se llevan a cabo en dicho SAE 171.
Se obtuvieron los requisitos necesarios para el desarrollo de los modelos de
datos y sistema del SIAE, aprecindose notablemente que el actual SI del SAE,
presenta una tendencia ms pronunciada tanto en las debilidades como en las
oportunidades en igual proporcin; quedando con menor relevancia las fortalezas
y amenazas, lo que refleja que el actual SI, est mayormente caracterizado por
sus debilidades, pero con igual grado en las oportunidades que tiene para ser
nuevamente, un mecanismo tecnolgico efectivo para el SAE.
En funcin del diagnstico de funcionamiento del actual SI del SAE 171
Mrida, se cumpli con el segundo objetivo especfico, mediante el cual se
dise el modelado de datos del SIAE, el cual contiene las estructuras de la
base de datos, sus restricciones de integridad, y las operaciones de manipu-
lacin de los datos, integrndose los diferentes actores pblicos y privados
vitales para desarrollar un efectivo SI para los SAE en Venezuela.
De esta forma es posible la incorporacin tanto de empresas privadas de
telefona y Proveedoras de Servicios de Internet (ISP), deben aportar esfuer-
zos para contribuir con la seguridad de la nacin, y para el caso de esta in-
186
vestigacin, se requiere que las mismas compartan sus registros de suscrip-
tores para ser utilizados en el SAE, a los fines de determinar su ubicacin en
los casos que establezca las leyes de la Repblica, tales como, llamadas de
sabotaje, delitos electrnicos, entre otros.
As mismo, se elabor el DDR para desarrollar el SIAE, como tercer obje-
tivo especfico, cuya funcin principal es integrar tecnolgicamente todos los
rganos de Seguridad Ciudadana de los Gobiernos Nacional, Estadales y
Municipales, conjuntamente con el Ministerio del poder popular para las Re-
laciones Interiores y Justicia (MppRIJ).
El DDR que se present en este Trabajo de Investigacin, est conforma-
do por el Documento de Requisitos de Usuario (DRU); en el cual se escriben
las funciones que son necesarias definidas por los usuarios; y el Documento
de Requisitos de Software (DRS), contentivo de la construccin de el modelo
lgico del SIAE diseado en esta investigacin; con estimaciones de costes
y recursos, junto a la representacin grfica del software y su arquitectura.
Para el logro del desarrollo del DDR, inicialmente, se cre el modelo de
negocios, para posteriormente proceder al anlisis de requisitos de usuario,
la cual tiene como objetivo conocer las necesidades de los usuarios y cules
deben ser los servicios que un SI debe ofrecerles para satisfacerlas. La fase
implic la creacin del Documento de Requisitos de Usuario (DRU) que cons-
tituye el documento aceptado por el usuario del SIAE.
Seguidamente, se gener el Documento de Requisitos de Software
(DRS), el cual contiene el anlisis de requisitos del sistema consistente en la
construccin del modelo lgico del SIAE, describiendo las funciones que son
necesarias; las relaciones entre ellas y el modelado de base de datos.
Como complemento al DRS, se elabor el plan de gestin del desarrollo
con estimaciones de costes necesarios para la implementacin del SIAE.
Con el desarrollo de los anteriores objetivos especficos, se cumpli con
el objetivo principal, el cual es el desarrollo de la Ingeniera de Requisitos
187
representada en el Documento de Definicin de Requisitos (DDR) que se ha
desarrollado en esta Investigacin; e igualmente contiene los anteriormente
indicados Documentos de Requisitos de Usuario (DRU) y Documento de Re-
quisitos de Sistema (DRS).
Es con esta Ingeniera de Requisitos que se permite cumplir un papel
primordial en el proceso de produccin del SIAE, ya que enfoca un rea fun-
damental: la definicin de lo que se desea producir. Su principal tarea consis-
te en la generacin de especificaciones correctas que describen con claridad,
sin ambigedades, en forma consistente y compacta, el comportamiento del
sistema; de esta manera, se odr minimizar los problemas relacionados a su
desarrollo en cdigo fuente.
De los anteriores resultados obtenidos los cuales fueron realizados bajo
el espritu de desarrollo de nuevas tecnologas para la administracin pblica
nacional, rompiendo todos los tabes de aplicacin sincera de la Ciencia,
Tecnologa e Innovacin para los procesos de Gobierno, buscando crear ms
productividad y eficiencia, combatiendo la excesiva burocracia, y fomentando
el cambio de cultura del venezolano.
Se considera en la Ingeniera de Requisitos realizada, es un desarrollo
exponencial de servicios tecnolgicos de ltima generacin para dar mejor
calidad de vida a los venezolanos, aunque esto implique incrementar la in-
versin del Estado para lograr dicho cometido, que como accin Socialista,
bandera del actual Gobierno Nacional expresados en las leyes de la Repbli-
ca; los planes nacionales sociales, polticos y econmicos; y los que corres-
ponden a la Ciencia, Tecnologa e Innovacin; deben ser consideradas tales
inversiones, sin escatimar en costos ni esfuerzos humanos.
188
RECOMENDACIONES
Es importante realizar una seria de recomendaciones como consejos y

sugerencias a los organismos pblicos y privados que de una u otra forma
participan o participarn en el SIAE, objeto de la presente Ingeniera de Re-
quisitos.
En tal sentido, a la Institucin DppTI (antes SATEM), organismo encar-
gado del SAE en el Estado Mrida, se le recomienda implementar un Sistema
de Informacin, en virtud de que por cada segundo de retraso, se podran
agravar las emergencias, y en el peor de los casos perder vidas humanas,
que pueden evitarse ante la aplicacin de mecanismos tecnolgicos para la
atencin de emergencias. Este organismo cuenta con un excelente equipo
humano y tecnolgico, que con una mejor administracin de dichos recursos,
podrn contar con muchos mejores resultados.
Asimismo, se le recomienda al referida organizacin de seguridad pbli-
ca en Mrida, promover modificaciones en la razn social de la misma la cual
hoy da es la Direccin del Poder Popular para las Telecomunicaciones e
Informtica (DppTI), en el sentido de adecuar su misin y visin orientada
nica y exclusivamente en el logro de objetivos cnsonos con la atencin
de emergencias; ya que su razn social est omitiendo a esta ltima, y
abarca un rea del conocimiento correspondiente a la Ciencia, Tecnologa e
Innovacin, que si bien es cierto, puede ser aplicada perfectamente en el
desempeo de acciones de Seguridad Ciudadana; ambas reas de polticas
pblicas y sociales, estn encaminadas en diferentes objetivos, y deben se-
pararse ambas para no causar incompatibilidad ni incompetencia de funcio-
nes, lo que implica, ineficiencia en la Administracin Pblica.
De la misma forma, la Gobernacin del Estado Mrida, ente a la que co-
rresponde gestionar las polticas de Seguridad Ciudadana en esta Entidad,
189
debe reestructurar ms efectivamente las acciones de Ciencia, Tecnologa e
Innovacin, y de Seguridad Ciudadana, en la forma de permitir ms amplia-
mente la participacin de otros Organismos pblicos y privados, en las referi-
das reas de polticas de gobierno, tales como, FUNDACITE Mrida, CEN-
DITEL Mrida, Universidad de Los Andes, IUP Santiago Mario, entre otras
Instituciones que han visto de alguna forma limitada sus acciones, en virtud
de que la DppTI (antes SATEM) es un Organismo de Seguridad Ciudadana.
El Estado Venezolano, a travs del Ministerio del Poder Popular para las
Relaciones Interiores y Justicia (MppRIJ), como rgano garante de la Seguri-
dad Nacional, el cual, si bien es cierto ha venido impulsando crecientes es-
fuerzos para disminuir los ndices de inseguridad en el pas, se le recomien-
da, incorporar ms agresiva y profesionalmente a la Ciencia, Tecnologa e
Innovacin en sus procesos y mtodos, ya que la referida rea del conoci-
miento, con una visin social y humanista, provee un enorme potencial en el
desarrollo de la calidad de vida del ser humano.
Cualquier inversin, inclusive la del desarrollo del SIAE, por ms consi-
derable que sea, nunca ser ms grande comparado con la cantidad de per-
sonas que podrn recibir una ms efectiva atencin al momento de que ocu-
rra cualquier emergencia en territorio de la Repblica Bolivariana de Vene-
zuela.
190
REFERENCIAS
Bibliogrficas
Arias, F. (2006). El Proyecto de Investigacin. Introduccin a la Metodologa
cientfica. (5. Ed.). Caracas, Venezuela: Episteme
Blanchard, B.S. (1995). Ingeniera de Sistemas, Serie de monografas de in-
geniera de sistemas. Madrid, Espaa: Isdefe.
Centro Nacional de Tecnologas de Informacin y comunicacin (2005). Gua
para el plan de migracin a Software Libre en la Administracin Pblica
Nacional (APN) de la Repblica Bolivariana de Venezuela. Caracas:
CNTI.
Constitucin de la Republica Bolivariana de Venezuela. (1999, Diciembre 20).
Gaceta Oficial Extraordinaria de la Repblica Bolivariana de Venezuela,
5.453, Marzo, 24, 2.000.
Decreto para el uso de Software Libre en la Administracin Pblica Nacional.
(Decreto No. 3.390). (2004, Diciembre 23). Gaceta Oficial de la Repbli-
ca Bolivariana de Venezuela, 38.095, Diciembre, 28, 2004.
Decreto para el uso prioritario de internet por la Administracin Pblica Na-
cional. (Decreto No. 825). (2000, Mayo 10). Gaceta Oficial de la Repbli-
ca Bolivariana de Venezuela, 36.955, Mayo, 22, 2000.
Ginest M. y Gonzlez, A. (2005). Ingeniera del software en entornos de SL.
Barcelona, Espaa: Universitat Oberta de Catalunya Formacin de Pos-
grado.
Hurtado, I y Toro, J. (2001). Paradigmas y Mtodos de Investigacin en tiem-
pos de Cambio. Valencia, Carabobo: Universidad de Carabobo.
Instituto Universitario Politcnico Santiago Mario (2006). Manual de trabajo
especial de grado. (4 ed.). La Urbina, Venezuela: IUPSM.
Jacobson, i.; Booch, G. y otro (2000). El Proceso Unificado de Desarrollo de
Software. Madrid, Espaa: Pearson Addisson-Wesley.
191
Len, G. (1996). Ingeniera de Sistemas de Software. Madrid, Espaa: Idefe.
Ley de Coordinacin de Seguridad Ciudadana. (2001, Septiembre 20). Gace-
ta Oficial de la Repblica Bolivariana de Venezuela, 37.318, Noviembre,
6, 2001.
Ley Orgnica de Ciencia, Tecnologa e Innovacin. (2001, Agosto 30). Gace-
ta Oficial de la Repblica Bolivariana de Venezuela, 37.291, Septiembre,
26, 2001.
Ley Orgnica de la Administracin Pblica. (2001, Septiembre 18). Gaceta
Oficial de la Repblica Bolivariana de Venezuela, 37.305, Octubre, 17,
2001.
Ley Orgnica de Telecomunicaciones. (2000, Junio 1). Gaceta Oficial de la
Repblica Bolivariana de Venezuela, 36.920, Marzo, 28, 2000.
Oberg, R., Probasco L. y otro (1998). Aplicacin de gestin de requisitos con
casos de uso. California, U.S.A.: Rational Software Corporation.
Pressman, R. (2001). Ingeniera del software. Un enfoque prctico. (5 ed.).
Madrid, Espaa: McGrawHill.
Rodrguez, Y. y Pineda, M. (2003). La experiencia de investigar. Recomen-
daciones precisas para realizar una investigacin y no morir en el inten-
to, (2 ed.). Valencia, Venezuela: Papiro Predios.
Resolucin del Ministerio del Poder Popular para la Ciencia y Tecnologa,
normativas de adquisicin de Hardware de Tecnologas Libres por parte
los Entes de la Administracin Pblica Nacional. (Decreto No. 321).
(2006, Enero 2). Gaceta Oficial de la Repblica Bolivariana de Venezue-
la, 38.418, Abril, 17, 2006.
Rumbaugh, J., Jacobson, I. y otro. (2000). El leguaje unificado de modelado.
Manual de referencia. Madrid, Espaa: Addison Wesley.
Sabino, C. (2000). El proceso de investigacin. Caracas, Venezuela: Panaco
Silberschatz A., Korth, H. y otro (2002). Fundamentos de bases de datos, (3
ed.). Madrid Espaa: McGraw Hill.
192
Tamayo y Tamayo, Mario (2003). El Proceso de la Investigacin Cientfica. (4
ed). Mxico,D.F., Mxico: Limusa.
No Bibliogrficas:
Colmenares, E. (2005). Optimizacin de los ndices de gestin y operatividad
en el servicio 1-7-1 de SATEM. Trabajo Especial de Grado para optar al
Ttulo de Ingeniero de Sistemas no publicado, Universidad de Los An-
des, Mrida.
Consejo Nacional de Tecnologas de Informacin (CNTI). (2010). [Pgina
web en lnea]. Disponible: http://www.cnti.gob.ve [Consulta: 2010, Mayo
17]
Dvila, Y. (2009). Ingeniera de Requerimientos y Modelado de Datos para el
Sistema de Informacin de caudales en acueductos urbanos. Trabajo
Especial de Grado para optar al Ttulo de Ingeniero de Sistemas no pu-
blicado, Instituto Universitario Politcnico Santiago Mari, Mrida.
Jurez, A. (2007). Ingeniera de Requerimientos para el desarrollo de un
software que permita mejorar el control de inventario en el Departamento
de Datos de una empresa de telecomunicaciones. Trabajo Especial de
Grado para optar al Ttulo de Ingeniero de Sistemas no publicado, Uni-
versidad de Los Andes, Mrida.
Plan Nacional de Ciencia, Tecnologa e Innovacin 2005 2030. Ministerio
del Poder Popular para la Ciencia y Tecnologa. 2005.
Plan Nacional de Telecomunicaciones y Servicios Postales 2007 2013. Mi-
nisterio del Poder Popular para la Ciencia y Tecnologa. 2004.
Proyecto nacional Simn Bolvar, primer plan socialista (PPS), desarrollo
econmico y social de la nacin 2007-2013. Presidencia de la Repblica
Bolivariana de Venezuela. 2004.
193
Electrnicas
Agencia Bolivariana de Actividades Espaciales (ABAE). (2010). [Pgina web
en lnea]. Disponible: www.abae.gob.ve [Consulta: 2010, Mayo 17]
Direccin del Poder Popular Estadal para la Teleinformtica del Estado Mri-
da, Mrida Estado Mrida. (2010) [Pgina web en lnea]. Disponible:
http://www.teleinformatica.gob.ve [Consulta: 2010, Mayo 5]
Fundacin para el Desarrollo e Investigacin de Ciencia y Tecnologa Mrida
(FUNDACITE-Mrida). (2010). [Pgina web en lnea]. Disponible:
www.fundacite.gob.ve [Consulta: 2010, Mayo 17]
Fundacin para la Investigacin y Desarrollo de Ciencia, Tecnologa e Inno-
vacin, Organizacin No Gubernamental (FUNDATICS-Mrida). (2010).
[Pgina web en lnea]. Disponible: www.fundatics.org.ve [Consulta:
2010, Mayo 17]
IBM Rational Unified Process (RUP). (2001) [Pgina web en lnea]. Disponi-
ble: http://www-01.ibm.com/software/awdtools/rup/ [Consulta: 2010, Mar-
zo 15]
Instituto Autnomo de Proteccin Civil y Administracin de Desastres del Es-
tado Carabobo (IAPCAD) (2009) [Pgina web en lnea]. Disponible:
http://www.pc-adcarabobo.gob.ve/sistema171.htm [Consulta: 2009, Oc-
tubre 15]
Instituto de Ingenieros Electricistas y Electrnicos (IEEE). (2010) [Pgina web
en lnea]. Disponible: http://standards.ieee.org [Consulta: 2010, Junio 10]
Ministerio del Poder Popular para la Ciencia y Tecnologa (MPPCT). (2010)
[Pgina web en lnea]. Disponible: http://www.mct.gob.ve [Consulta:
2010, Mayo 4]
Software Libre en la Administracin Pblica Nacional. (2010). [Pgina web en
lnea]. Disponible: www.softwarelibre.gob.ve [Consulta: 2010, Mayo 17]
194
Universidad Politcnica de Valencia (UPV). (2009). Rational Unified Process
(RUP) [Documento en lnea]. Disponible: https://pid.dsic.upv.es [Consul-
ta: 2010, Marzo 1]
Wikipedia enciclopedia digital. (2010). Sistemas de Informacin. [Documento
en lnea]. Disponible: https://www.wikipedia.com [Consulta: 2010, Julio 1]
195
ANEXOS
196
Anexo A: Gua de observacin en SATEM Mrida
197
198
Anexo B: Entrevista a Trabajador de SATEM.
199
200
201
202
203
RESUMEN CURRICULAR DEL AUTOR
204
Datos personales
Apellidos y Nombres: Rodrguez Salazar, Richard Jos
Lugar y fecha Nacimiento.: Valencia Edo. Carabobo, 28-12-1.972
Estado civil: Casado
Edad: 37 aos
E-mail: richard@c-matic.com.ve
URL: www.c-matic.com.ve
Profesiones: Graduando Ingeniero de Sistemas y TSU en Informtica
Educacin Formal
Superior:
Instituto Universitario Politcnico Santiago Mario. Mrida Edo. Mrida.
Graduando de Ingeniera de Sistemas. Ao 2.009.
Instituto Universitario Tecnolgico Juan Pablo Prez Alfonso IUTEPAL. Va-
lencia Edo. Carabobo. Graduado como Tcnico Superior Universitario en
Informtica. Ao 1.998.
Secundaria:
Liceo Libertador. Mrida Edo. Mrida. Graduado de Bachiller en Ciencias. Ao
1.989.
Experiencia Profesional
Pasanta Profesional Ingeniera de Sistemas. Aviacin Militar Bolivariana
de Venezuela, Centro de Investigaciones y Desarrollo Aeronutico CI-
DAE. Desde Septiembre a Noviembre 2.009.
Ponencia internacional Sistema organizacional de ciencia y tecnologa pa-
ra la optimizacin de la gestin gubernamental venezolana. IV Congreso
Andaluz de Sociologa, Carmona, Espaa. Universidad de Olavide de
Sevilla. Noviembre 2.008.
205
Registrado como actor de Tecnologa de Mrida, Fundacin para el Desa-
rrollo de la Ciencia y Tecnologa, Fundacite Mrida. Septiembre 2.008.
Investigador libre de la Coordinacin de Investigacin de la Facultad de In-
geniera de la Universidad de Carabobo. Desde junio 2.008.
Desarrollo e implementacin del proyecto de red local de computadoras
plataforma cliente-servidor, del servicio Unidad de Atencin al Ciuda-
dano UACI, Gobernacin del Estado Mrida. Ao 2.005.
Desarrollo e implementacin de los proyectos de Bibliotecas Digitales y
Servicios de Informacin Digital, para el Instituto de Bibliotecas de M-
rida IBIME, Gobernacin del Estado Mrida. Ao 2.004.
Integrante de las mesas de trabajo de los planes de Ciencia, Tecnologa
e Innovacin basadas en TIC, representante del Instituto de Bibliotecas
e Informacin de Mrida IBIME, Gobernacin del Estado Mrida. Ao
2.004.
Facilitador de Infocentros Estados Mrida y Trujillo, representante de
Fundacite Mrida y al Centro Nacional de Tecnologas - CNTI. Ao
2.000.
Desarrollo de un Sistema de Informacin para la Formulacin y Ejecucin
de Presupuesto de Gastos para Instituciones Pblicas, desarrollado con
normativas ajustadas a la ONAPRE. Ao 2.004.
Conformacin del Departamento de Informtica. Instituto Autnomo de
Servicios de Bibliotecas Pblicas e Informacin del Estado Mrida IBI-
ME, Gobernacin del Estado Mrida. Ao 1.999.
Trabajos de Investigacin y Publicaciones

Participacin en Proyecto de simulador de tiro en la Aviacin Militar
Bolivariana de Venezuela, Centro de Investigaciones y Desarrollo Aero-
nutico CIDAE. Noviembre 2.009.
206
Propuesta de Reformulacin de la Estructura Organizacional de la Go-
bernacin del Estado Mrida, Diciembre 2.008.
Trabajo de investigacin Creacin de la Direccin de Telecomunica-
ciones e Informtica en la Gobernacin del Estado Mrida. Diciem-
bre 2.008 (http://www.fundacite-merida.gob.ve).
Dos Ponencias en IV Congreso Andaluz de Sociologa. Universidad Pablo
de Olavide, Espaa Sistema organizacional de ciencia y tecnologa para
la optimizacin de la gestin de la administracin pblica venezolana.
Noviembre 2.008.
Trabajo de investigacin Plan de trabajo de la red de bibliotecas pblicas
de la Gobernacin del Estado Mrida. Septiembre 2.008.
Manuales de Organizacin y de Normas y Procedimientos para el Centro
de Control, Salud y Proteccin de Animales del Municipio Libertador del
Estado Mrida. Julio 2.008.
Reconocimientos:
Reconocimiento por participacin como Pasante en el Centro de
Investigaciones y Desarrollo Aeronutico CIDAE. Noviembre 2.009.
Aval suscrito por la Coordinacin de Investigacin de la Facultad de
Ingeniera de la Universidad de Carabobo, de las ponencias a presentar
en el IV Congreso Andaluz de Sociologa. Ao 2.008.
Aval suscrito por el Gabinete Ministerial del Estado Mrida del Ministerio del
Poder Popular para la Cultura, de las ponencias a presentar en el IV
Congreso Andaluz de Sociologa. Ao 2.008.
Reconocimiento a la labor en el Tribunal Supremo de Justicia. Ao 2.007.
Reconocimiento por la participacin en la actividad Seguridad Apoyo a la
Mrida Preciosa de la Gobernacin de Mrida. Ao 2.005.
Reconocimiento por la participacin en la actividad Mrida Preciosa de la
Gobernacin de Mrida. Ao 2.004.
207
Reconocimiento por la colaboracin en planes vacacionales de la Red de
Bibliotecas de la Gobernacin del Estado Mrida, aos 2.001, 2.002,
2.003, 2.004 y 2.005.
Reconocimiento a la destacada actuacin como equipo de trabajo en la
empresa Papelera Venepal, Ao 1.997.
208

Tesis de Grado Ingeniería de Sistemas - Richard Rodríguez Salazar

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tesis de Grado Ingeniería de Sistemas - Richard Rodríguez Salazar

Hochgeladen von

Copyright:

Verfügbare Formate

REPBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR

INGENIERA DE REQUISITOS PARA EL DESARROLLO DE UN

Trabajo Especial de Grado presentado como requisito parcial

Autor: Rodrguez, Richard

Mrida, Agosto de 2.010

En mi carcter de Tutora del Trabajo Especial de Grado titulado: INGE-

En mi carcter de Asesor Metodolgico del Trabajo Especial de Grado ti-

INGENIERA DE REQUISITOS PARA EL DESARROLLO DE UN

Autor: Rodrguez, Richard

Trabajo Especial de Grado APROBADO en nombre del Instituto Universi-

Ing. William Snchez Ing. Edgar Achong

Ing. Mayela Uzctegui

A mis padres, Aid y Ely Sal

Porque he aqu que yo creo cielos nuevos y tierra nueva.

A mi Dios, que me ha dado la fuerza, felicidad, salud y paz.

A mi mam, que diste todo por m hasta que te fuiste.

A mi pap, a quien no conoc porque temprano se fue con Dios;

A toda mi familia, que nunca dejaron de creer en m.

Al Politcnico Santiago Mario, y sus Profesores, en donde

A las Profesoras Yudit, Alexis, Alix y al Profesor Mximo,

A mis amigos y compaeros de trabajo,

INGENIERA DE REQUISITOS PARA EL DESARROLLO DE UN

Lnea de Investigacin: Tecnologa Web, Modelado de Sistemas

Autor: Rodrguez, Richard

Descriptores: Ingeniera de Requisitos, Sistema de Informacin, Servicios

Un Sistema de Informacin en los Servicios de Atencin de Emergencias

Contextualizacin del Problema

El Servicio de Atencin de Emergencias (SAE) debe funcionar como un

Desarrollar una Ingeniera de Requisitos para Sistema de Informacin en

Diagnosticar el funcionamiento del actual Sistema de Informacin del Ser-

Segn Len (1996), el trmino Ingeniera de Sistemas de Software, fue

Los antecedentes de la investigacin realizados por algunos autores, as

Servicio de Atencin de Emergencias (SAE)

El Servicio de Atencin de Emergencias (SAE) en Mrida, se inici con el

Figuras 1 y 2: Sala de Operadores SAE Mrida en funciones de atencin de llamadas de

Fue creado en respuesta a las necesidades de la colectividad, con la fi-

Figuras 3 y 4: Sala de Despachadores SAE Mrida en funciones de despacho de

Todos estos organismos funcionan bajo la coordinacin del SAE 171 M-

Sistemas de Informacin (SI)

Para Blanchard (1995), es una combinacin de recursos, tales como se-

Figura 5: Elementos de un Sistema de Informacin

Bases de Datos (BD)

Para Silberschatz y otros (2002), una base de datos o banco de datos, es

Modelado de Datos (MD)

Silberschatz y otros (2002) lo define como una coleccin de herramien-

Modelo Entidad-Relacin (E-R)

Para, Silberschatz y otros (2002), es el que est basado en una percep-

Figura 6: Diagrama Entidad-Relacin

Figura 7: Ligadura de correspondencia uno a uno.

Uno a varios: Una entidad en A se asocia con cualquier nmero de

Figura 8: Ligadura de correspondencia uno a varios.

Figura 9: Ligadura de correspondencia varios a uno.

Varios a varios: Una entidad en A se asocia con cualquier nmero de

Figura 10: Ligadura de correspondencia varios a varios.

Ingeniera de Software (IS)

Para la IEEE, el software es el conjunto de los programas de cmputo,

Modelos de Ingeniera de Software

Para Pressmar (2001), un modelo de IS es una estrategia de desarrollo

Modelo Basado en Componentes:

Para Jacobson y otros (2000), el Proceso Unificado (RU) representa un

Figura 11: Esfuerzo en actividades segn fase del proyecto

Fase de Inicio: Las iteraciones ponen mayor nfasis en actividades mo-

Modelado de Negocios (MN)