CAPÍTULO IV

RESULTADOS

Fase Diagnóstico

El análisis de los datos fue procesado basándose en una recolección simple. Los
mismos se representaron en términos de frecuencias absolutas y porcentuales. La
tabulación se realizó manualmente en cuadro y gráficos.
Presentación y Análisis de los Resultados
El Manual de la UPEL (2000) señala que en la investigación de campo:

Se representan, describen, analizan e interpretan en forma ordenada

los datos obtenidos en el estudio en función de preguntas o hipótesis de la
investigación, con el apoyo de cuadro y grafico del ser el caso, y se
discuten con base en la fundamentación teórica del trabajo o tesis y los
supuestos de la metodología. (p. 18).

Los datos son presentados en tablas o datos estadísticos de frecuencia relativa y

frecuencia absoluta. Para Hernández y otros (1997) frecuencia relativa es “el
porcentaje de casos en cada categoría” (p. 352). González (1990) señala que la
frecuencia absoluta “es el numero de repetición de una observación, bien se trate de
una variable o de un atributo” (p. 77) los mismos serán presentados en gráficos. Para
el análisis de los resultados se toma en cuenta el valor de la frecuencia relativa. Según
Sabino (1992) “una manera natural con toda información numérica resultante de la
investigación, Esta luego se representa con un conjunto de tablas, cuadros y medida
de las cuales se han calculado su porcentaje y presentado convenientemente” (p. 54).

43
 A continuación se presenta el análisis e interpretación de las preguntas que
conformaron la encuesta aplicada a la muestra de la investigación.
Ítem 1. ¿Considera usted que se debe mejorar la forma en que se reciben los
requerimientos en la CSML?
Cuadro 3
Respuesta al Ítem 1.
Alternativas Respuestas Porcentaje

SI 9 90 %

NO 1 10 %
Fuente: Martell, Mayckool (2011)

Grafico 1 Respuesta al Ítem 1.

Fuente: Martell, Mayckool (2011).

Se puede apreciar por medio de esta pregunta que los empleados están de
acuerdo en hacer cambios en pro de mejorar la recepción de requerimientos en la
Corporación de Servicios Municipales Libertador.

44
 Ítem 2. ¿Está usted de acuerdo con la manera cómo se procesan los
requerimientos en la CSML?:
Cuadro 4
Respuesta al Ítem 2.
Alternativas Respuestas Porcentaje

SI 7 70 %

NO 3 30 %
Fuente: Martell, Mayckool (2011)

Grafico 2 Respuesta al Ítem 2.

Fuente: Martell, Mayckool (2011)

Tal y como se muestra en el gráfico, un gran porcentaje de la población indicó

que no están de acuerdo con la manera en cómo se procesan los requerimientos
dentro de la Corporación de Servicios Municipales Libertador, a pesar que existe un
grupo considerable de empleados que opina lo contrario.

45
 Ítem 3. ¿Cree usted que sería necesario tener un sistema para el control de
gestión al ciudadano y almacenar sus casos para solventar posibles problemas en el
futuro?
Cuadro 5
Respuesta al Ítem 3.
Alternativas Respuestas Porcentaje
SI 10 100 %

NO 0 0%

Fuente: Martell, Mayckool (2011)

Grafico 3: Respuesta al Ítem 3.

Fuente: Martell, Mayckool (2011)

El resultado reflejado en la grafica muestra que las personas encuestadas en su

totalidad están de acuerdo con la creación de un sistema para el control de gestión al
ciudadano, manteniendo los resultados de los mismos como soporte para la solución
de posibles problemas en el futuro dentro del Municipio Libertador.

46
 Ítem 4. ¿Considera usted que es aceptable el tiempo de respuesta a los
requerimientos?
Cuadro 6
Respuesta al Ítem 4.
Alternativas Respuestas Porcentaje
SI 4 40 %

NO 6 60 %

Fuente: Martell, Mayckool (2011)

Grafico 4: Respuesta al Ítem 4.

Fuente: Martell, Mayckool (2011)

En la grafica Nº 4 se puede observar que hay una opinión dividida con respecto
al tiempo de repuesta de los requerimientos recibidos, sin embargo, se aprecia que
más de la mitad de los encuestados no están de acuerdo con los tiempos de respuestas
en la gestión de denuncias.

47
 Ítem 5. ¿Considera usted que los retrasos en los tiempos de respuesta a los
requerimientos se debe a la falta de planificación y control de las actividades?
Cuadro 7
Respuesta al Ítem 5.
Alternativas Respuestas Porcentaje

SI 9 90 %

NO 1 10 %

Fuente: Martell, Mayckool (2011)

Grafico 5 Respuesta al Ítem Nº 5.

Fuente: Martell, Mayckool (2011)

En base a los resultados se observa que la mayoría de las personas coinciden en

el hecho de que hay una mala planificación y control al momento de procesar los
requerimientos en la Corporación de Servicios Municipales Libertador.

48
 Ítem 6. ¿Existe algún procedimiento establecido para la recepción y gestión de
los requerimientos en la CSML?

Cuadro 8
Respuesta al Ítem 6.
Alternativas Respuestas Porcentaje
SI 0 0%

NO 10 100 %

Fuente: Martell, Mayckool (2011)

Grafico 6: Respuesta al Ítem 6.

Fuente: Martell, Mayckool (2011)

Todas las personas entrevistadas estuvieron de acuerdo que en la actualidad no

existe procedimiento alguno para la recepción y gestión de requerimientos en la
Corporación de Servicios Municipales Libertador, por lo que existe lineamiento
alguno al momento de la solución de los mismos.

49
 Ítem 7. ¿Tiene usted alguna manera de consultar el estatus en línea de los
requerimientos que ha procesado en el pasado?
Cuadro 9
Respuesta al Ítem 7.
Alternativas Respuestas Porcentaje
SI 10 100 %

NO 0 0%

Fuente: Martell, Mayckool (2011)

Grafico 7 Respuesta al Ítem 7.

Fuente: Martell, Mayckool (2011)

Referente a esta pregunta se registró que no existe mecanismo en línea que

permita verificar el estatus de los requerimientos procesados y por consiguiente, no se
puede hacer seguimiento alguno de los mismos.

50
 Ítem 8. ¿Estaría de acuerdo en utilizar un sistema de gestión de atención al
ciudadano para la CSML?
Cuadro 10
Respuesta al Ítem 8.
Alternativas Respuestas Porcentaje

SI 10 100 %

NO 0 0%

Fuente: Martell, Mayckool (2011)

Grafico 8 Respuesta al Ítem 8.

Fuente: Martell, Mayckool (2011)

La población total indico que es muy importante que se tenga un sistema o

registro de todos los requerimientos que reciben diariamente para que sirva de apoyo
en novedades futuras, y de esta forma mejorar la calidad de servicio al Municipio
Bolivariano Libertador.

51
 Análisis Global de los Resultados
Mediante este análisis se puede decir que, la respuesta del personal de la
Corporación de Servicios Municipales Libertador al cual se le aplicó el cuestionario
sobre la gestión de denuncias, así como la posibilidad de la implementación de un
sistema de control de gestión al ciudadano, se pudo constatar que en su totalidad ,el
personal encuestado está consciente de las novedades que ocurren diariamente, y de
la mala gestión y planificación que se llevaba a cabo en dicho organismo, asimismo,
se evidenció que no se tiene mecanismo alguno de registro, seguimiento y control de
las actividades realizadas. Para la mayoría de las personas encuestadas es de su
agrado la implementación de un Sistema de Gestión al Ciudadano, el cual tiene como
función aliviar su carga de trabajo y lograr dar respuestas rápidas para proporcionar la
solución de la falla y a la vez tener un respaldo de esos eventos para soluciones
futuras.

Fase Alternativas de Solución

Con el fin de atacar la problemática de la organización y dada la situación actual

de la Corporación de Servicios Municipales Libertador, se pudo confirmar la
necesidad real que existe de un Sistema de Control de Gestión, es por lo
anteriormente expuesto en esta fase, que se procedió a dar una serie de alternativas de
solución que sea más accesible y se adapte a las necesidades de los empleados.
Alternativa 1: Dejar el escenario actual
Consiste en no alterar o modificar las funciones actuales en el proceso.
Ventajas
1. Al no haber inversión, no representa gasto para la corporación
Desventajas
1. Fallas a nivel de integridad de datos, seguridad, y manejo de la información.
2. Continuarían los mismos problemas ya planteados.

52
 Alternativa 2: Utilizar hojas de cálculo
Consiste en registrar los requerimientos y actividades en hojas de cálculo.
Ventajas
1. Se reducirían los costos de desarrollo y de operaciones.
2. El personal no tendría que adiestrarse, o adaptarse a una nueva herramienta.
Desventajas
1. Fallas a nivel de integridad de datos, seguridad, y manejo de la información.
2. Continuarían los mismos problemas que en la situación actual, ya que no es
una herramienta confiable.
Alternativa 3: Diseñar el Sistema de Control de Gestión de Atención al
Ciudadano en Plataforma Web 2.0 de la Corporación de Servicios Municipales
Libertador.
Consiste en registrar los requerimientos y denuncias en una aplicación en
plataforma Web 2.0, en la cual se podrá visualizar el estatus de las mismas en tiempo
real, permitiendo conocer que unidad realizara un trabajo especifico y manteniendo
un histórico de todas las actividades para de esta manera, poder dar aportes a una
problemática en el futuro.
Ventajas
1. Mayor control en cuanto al manejo de recurso humano.
2. Reducción de costos Horas Hombre.
3. Mejor planificación de las actividades a realizar.
4. Información confiable y siempre actualizada que permite tomar decisiones
en tiempo real.
5. Uso de tecnologías confiable y estable.
Desventajas
1. Es necesario adiestrar al personal que interactuara con el nuevo sistema.
2. Se deberán tomar previsiones necesarias para los cambios de
procedimientos.

53
 Rango para evaluar las alternativas de solución
Los rangos utilizados para calificar la modificación y el sistema actual como tal,
están contenidos en los siguientes parámetros:
1. Efectividad en los procesos: corresponde al resultado obtenido en cada
uno de los procesos durante la ejecución del sistema
2. Procesos manuales: son los procesos no automatizados del sistema.
3. Rapidez: Corresponde a la agilidad con que se realizan los procesos
4. Detección de fallas: se refiere a la facilidad con que se pueden detectar los
posibles errores contenidos en los procesos del sistema
5. Veracidad de información: corresponde al estudio de la información
procesada en el sistema
6. Almacenamiento de la información: se relaciona a la efectividad de
manejo, y acceso a la información del sistema
En base a lo anterior, se seleccionó como alternativa de solución la número tres,
la cual es el Diseño de un Sistema de Gestión de Atención al Ciudadano en
Plataforma Web 2.0 de la Corporación de Servicios Municipales Libertador; ya que
es la mejor opción que se adapta a la resolución de las necesidades detectadas y
cumple con los rangos de veracidad, rapidez, efectividad, manejo y costos
Fase de la Propuesta
Esta fase tiene como propósito definir el alcance y las actividades para la
ejecución de servicios profesionales en materia del desarrollo del sistema de gestión
de atención al ciudadano en plataforma Web 2.0 de la Corporación de Servicios
Municipales Libertador la propuesta está enmarcada bajo la modalidad de proyecto
factible bajo los aspectos que a continuación se presentan.

Objetivo General
Diseñar el Sistema de Control de Gestión de Atención al Ciudadano en
Plataforma Web 2.0 de la Corporación de Servicios Municipales Libertador.

54
 Objetivo Específicos
1. Elaborar un estudio de factibilidades técnicas, económicas y operacionales
para el sistema propuesto.
2. Desarrollar el análisis y diseño de la propuesta planteada.
3. Desarrollar una base de datos dinámica bajo el ambiente de MySQL, que se
ajuste a los requerimientos de funcionamiento de los procesos para la elaboración de
los reportes de gestión de denuncias.
4. Diseñar una Interfaz Web Dinámica del Sistema Propuesto.
5. Mejorar el tiempo de efectividad de respuesta para la resolución de las
denuncias de la Corporación de Servicios Municipales Libertador.
6. Establecer un nivel de seguridad óptimo que garantice la privacidad y
seguridad de los datos.
7. Proveer a la dirección de gestión de operaciones y a la Corporación de
Servicios Municipales Libertador en general, información útil, rápida y precisa.

Justificación

El desarrollo del Sistema de Control de Gestión de Atención al Ciudadano en

Plataforma Web 2.0 de la Corporación de Servicios Municipales Libertador (CSML)
permite alcanzar beneficios a los empleados del ente, facilitándoles una herramienta
amigable y sencilla de utilizar. Logrando adquirir, para los trabajadores,
conocimientos mínimos para poder manejar un Software que permita la rapidez y
eficiencia en las direcciones involucradas, aunado al alcance de los objetivos trazados
por la institución. El aporte de este estudio consiste en obtener el control total de las
funciones llevadas a cabo en forma cotidiana en los mencionados ámbitos. El
desarrollo del proyecto considera la viabilidad técnica y económica teniendo como
destinatario a cualquier usuario de redes de computadoras.

Alcance
El alcance que tiene el Sistema de Control de Gestión de Atención al
Ciudadano en Plataforma Web 2.0 de la Corporación de Servicios Municipales
55
Libertador, llega hasta el diseño del sistema, no así su implantación. Ya que ello será
decisión de la Presidencia de la Corporación, una vez que los resultados del presente
estudio le sean presentados a la misma
El software utilizado en el desarrollo del sistema automatizado fue mediante el
lenguaje de programación PHP (HiperTextPreprocessor); este lenguaje es un
procesador de hipertexto que permite generar contenido de páginas Web sobre la
marcha y el framework de desarrollo JQuery, el cual permite realizar aplicaciones
dinámicas orientadas a la plataforma Web 2.0. En cuanto al manejo de la base de
datos se empleó MySQL, siendo este un lenguaje declarativo de acceso y
administración de la base de datos permitiendo gran variedad de operaciones sobre
las mismas.
Desarrollo de la Propuesta
El desarrollo de la propuesta que se presenta a continuación se realizo siguiendo
los procesos, actividades y tareas de la metodología RUP y a su vez los objetivos
planteado en el trabajo especial de grado denominado diseño el sistema de control de
gestión de atención al ciudadano en plataforma Web 2.0 de la Corporación de
Servicios Municipales Libertador, con la finalidad de poder contar con una
herramienta de trabajo que permita optimizar el proceso de atención de
requerimientos y denuncias de dicha institución. A continuación, se detallan las fases
para el desarrollo de la metodología anteriormente descrita: RUP que se divide en
cuatro fases para el manejo de los procesos:
1. Fase de Inicio
2. Fase de Elaboración
3. Fase de Construcción
4. Fase de Transición, esta última fase no se llevo a cabo en el trabajo especial de
grado debido a que como se indicó en el alcance, dependerá de la presidencia de la
CSML su instalación y puesta en producción.
RUP es un proceso de Ingeniería de Software, cuya virtud principal es incorporar
al desarrollo de software un proceso confiable y ya utilizado en diferentes ámbitos. Es
uno de los procesos más generales de los existentes actualmente, ya que en realidad
56
está pensado para adaptarse a cualquier tipo de proyecto. A continuación se muestra
el desarrollo del mismo:
Fase de Inicio
Tiene como prioridad establecer el objetivo y el alcance del proyecto de
software, determinar requerimientos y casos de uso, dar una primera aproximación de
la arquitectura en la cual se desarrollará el proyecto de software, estimar los costos y
el cronograma del proyecto de software, estimar los riesgos potenciales del proyecto
de software, preparar un ambiente de soporte para el proyecto, en la primera fase de
desarrollo de la metodología RUP que fue descrita en el capitulo anterior, se obtuvo
lo siguiente:

Visión de los requerimientos del sistema de control de gestión

Al evaluar la situación se obtuvo como deficiencia que el tiempo de desarrollo
tomaría más tiempo de lo previsto, debido a que el trabajo fue realizado desde cero,
sin embargo, se encontraron algunas ventajas como:
1. La corporación cuenta con los recursos informáticos necesarios para la
realización de este desarrollo
2. Debido a que se estudiarían los procesos actuales y seguiría la metodología
existente de trabajo, se diseñaría a la medida de las necesidades.
3. Los costos de desarrollo estaría cubiertos debido a que se realizaría con
herramientas disponibles de desarrollo y de base de datos, así como los
servidores y equipos personales necesarios.

Estudio de Factibilidad
El estudio de factibilidad examina la viabilidad del proyecto, la posibilidad de
que el sistema sea de utilidad en la Corporación de Servicios Municipales Libertador
(CSML). Para Kendall & Kendall (1997) “la factibilidad es valorada en tres formas
principales: operacional, técnicas y económicas. Un proyecto debe ser factible en las
tres formas para merecer un desarrollo posterior”. (p.51). A continuación, se
presentan los elementos que fueron considerados, desde el punto de vista técnico,

57
económico y operativo, para que la CSML implemente un sistema para el control de
gestión al ciudadano en plataforma Web 2.0.

Factibilidad Técnica
Este sistema cuenta con una viabilidad técnica amplia, ya que la Corporación de
Servicios Municipales Libertador (CSML), posee la arquitectura necesaria para el
manejo del sistema. Es factible además porque las personas que trabajan en esta
empresa ya están dispuestas a participar en el manejo y control del sistema.
Cumpliendo también con las exigencias técnicas mínimas requeridas por el Decreto
Número 3390, referente al uso prioritario de Software Libre en organismos de
administración pública y entes adscritos, publicado en Gaceta Oficial Nº 38.095, de
fecha 23 de Diciembre de 2004. Con esto presente, se procedió a realizar la
evaluación del hardware, software y capital humano para el desarrollo del sistema. En
ese sentido podemos decir que se cuenta con:
Cuadro 11
Factibilidad técnica - Hardware
CANT. DESCRIPCION USO ESTATUS
Base de datos,
1 Servidor Disponible
Aplicación
Computador Conexión de los usuarios
10 Disponible
Personal (PC) con la aplicación.
1 Impresora Reportes Disponible
Interconexión del
1 Switch Disponible
Servidor a las PC.
Fuente: Martell, Mayckool (2011)

Cuadro 12
Características técnicas - Hardware
CANT. DESCRIPCION ADQUISICIÓN
HP Proliant ml 100, Intel 3GHz ,4GB RAM, HD
1 2009
350 GB, tarjeta 10/100 PCI express 133.
HP Desktop dx2400 Intel Pentium E5200 2,5 GHz,
10 2009
2 GB RAM , 150 GB HD de 800 MHz, USB .
1 Impresora HP Laser Jet 4050 2008
1 Switch 2008
Fuente: Martell, Mayckool (2011)

58
Cuadro 13
Factibilidad técnica - Software
PRODUCTO /
CANT. USO ESTATUS
DESCRIPCION
Sistema operativo para
10 Linux Ubuntu 9.10 uso de estaciones de Disponible
trabajo
Lenguaje de
1 PHP 5 Disponible
programación.
1 JQuery Framework de desarrollo Disponible
Servidor de aplicaciones
1 Apache Disponible
Web HTTP
Manejador de Base de
1 MySQL Disponible
datos
1 PHPMyAdmin Gestor de Base de datos Disponible
Herramientas para el
1 NetBeans Disponible
desarrollo web
Fuente: Martell, Mayckool (2011)

Cuadro 14
Características técnicas – Capital humano
CANT. DESCRIPCION ESTATUS
1 Gerente de Proyecto Disponible
1 Administrador de Base de Datos Disponible
1 Analista Programador Disponible
Fuente: Martell, Mayckool (2011)

Factibilidad económica
Este sistema es viable financieramente puesto que la empresa posee la capacidad
y la disposición en cuanto a los recursos financieros requeridos para su desarrollo, no
obstante, la corporación cuenta con la mayoría de los elementos necesarios para el
correcto funcionamiento del software, es por esta razón que no se generó gastos por la
adquisición de hardware, software o licencia, necesarios para cumplir con los
objetivos propuestos. Sin embargo, se debe analizar los costos relacionados con el
capital humano, el cual se detalla a continuación:

59
Cuadro 15
Características económica - Hardware
COSTO COSTO
CANT. DESCRIPCION ADQUISICIÓN
UNITARIO TOTAL
HP Proliant ml 100,
Intel 3GHz, 4GB RAM,
1 2009 Bs. 9.600,00 Bs. 9.600,00
HD 350 GB, tarjeta
10/100 PCI express 133.
HP Desktop dx2400 Intel
Pentium E5200 2,5 GHz,
10 2009 Bs. 5.800,00 Bs. 58.000,00
2 GB RAM, 150 GB HD
de 800 MHz, USB.
Impresora HP
1 2008 Bs. 1.500,00 Bs. 1.500,00
Laser Jet 4050
1 Switch 2008 Bs. 1.350,00 Bs. 1.350,00
Fuente: Martell, Mayckool (2011)

Cuadro 16
Factibilidad económica - Software
PRODUCTO / COSTO
CANT. ADQUISICIÓN
DESCRIPCION TOTAL
10 Linux Ubuntu 9.10 2010 Bs. 0,00
1 PHP 5 2010 Bs. 0,00
1 JQuery 2010 Bs. 0,00
1 Apache 2010 Bs. 0,00
1 MySQL 2010 Bs. 0,00
1 PHPMyAdmin 2010 Bs. 0,00
1 NetBeans 2010 Bs. 0,00
Fuente: Martell, Mayckool (2011)

Cuadro 17
Factibilidad económica – Capital Humano
HORAS COSTO COSTO
CANT. DESCRIPCION
ESTIMADAS HORA TOTAL
1 Gerente de Proyecto 80 Bs. 61,00 Bs. 4.880,00
Administrador de
1 500 Bs. 50,00 Bs. 2.500,00
Base de Datos
Analista
1 500 Bs. 50,00 Bs. 2.500,00
Programador
Fuente: Martell, Mayckool (2011)

60
Cuadro 18
Costo total del proyecto
DESCRIPCION COSTO TOTAL
Hardware Bs. 70.450,00
Software Bs. 0,00
Capital Humano Bs. 9.880,00
TOTAL Bs. 80.330,00
Fuente: Martell, Mayckool (2011)

Factibilidad operativa
A través de la factibilidad operativa se logra saber si el sistema, por el cual se
lleva a cabo este proyecto, puede ser utilizado por el usuario, es decir; si éste cumple
con las funciones por las cuales es desarrollado. El sistema de control de gestión al
ciudadano, está formado por una interfaz gráfica que le facilita al usuario el
entendimiento y uso del mismo, que es lo más cercano a las necesidades de los
operadores, ya que esto es un factor importante para que el sistema sea operativo,
después de ser creado. Del mismo modo se debe promover charlas informativas a los
usuarios del sistema, e inducción al personal que trabajará directamente con éste, que
les permita conocer la funcionalidad y así resolver posibles dudas que presente éste
serían los aspectos más importantes a cubrir en relación a aspectos operativos.

Factibilidad Psico – Social

Al introducir el sistema tecnológico se toma en cuenta que éste debe ser de
manejo fácil, con una interfaz visual agradable, amigable y con instrucciones claras.
Permitiendo así que el personal que lo va a manejar se adapte y no ponga resistencia.

Análisis Costos y beneficios

En cuanto al costo, es toda aquella inversión necesaria para el desarrollo del
sistema. Por otra parte hay que contar que los beneficios que se obtendrán se deben
tomar en relación con los costos pues estos estarán íntimamente ligados.

61
Cuadro 19
Cuadro relación costo - beneficio
DESCRIPCION COSTO TOTAL
Hardware Bs. 70.450,00
Software Bs. 0,00
Capital Humano Bs. 9.880,00
TOTAL Bs. 80.330,00
BENEFICIOS
1. Ahorro de tiempo y esfuerzo del personal que se puede utilizar
para otras tareas.
2. Mayor confiabilidad en la información manejada.
3. Clientes con mayor satisfacción.
4. Los informes estarán siempre actualizados.
5. Personal entenderá el manejo del sistema fácilmente ya que está
entrenado en sistemas informáticos.
Fuente: Martell, Mayckool (2011)

El sistema tendría costos bajos una vez que se realice su instalación, ya que
estaría cubierta por todos los recursos actualmente disponibles en la corporación. El
diseño de este sistema es justificado ya que los beneficios se verán a mediano y largo
plazo, de igual forma con la alternativa de desarrollar la aplicación permite optimizar
los procesos operativos y el desempeño del capital humanos, y a su vez, se contaría
con una solución que se adapte el cien por ciento a las necesidades y requerimientos
de la empresa.
Fase de elaboración
En esta fase se realiza la captura de la mayor parte de los requerimientos
funcionales, manejando los riesgos que interfieren con los objetivos del sistema,
acumulando la información necesaria para el plan de construcción y obteniendo así,
suficiente información para hacer realizable el caso del negocio, en este sentido, se
tomo en cuenta toda la información recopilada en la fase previa para el punto de
partida del proyecto.

62
 Fase de Construcción

En la presente fase se realizara para cada caso de uso pruebas de validación para
la implementación de los casos de usos, para así obtener la versión final del sistema,
para la realización de las pruebas se realizaron las siguientes consideraciones:
Un caso de prueba es aquel que tiene alta probabilidad de detectar errores, no
aquel que simplemente demuestra que un programa funciona, los casos de prueba se
establecieron y planificaron cuidadosamente con el fin de que se detectara el número
máximo de errores.
Para las pruebas efectuadas se tomaron las siguientes consideraciones:
1. Probar que se cumplan las especificaciones de los casos de uso sin prestar
cuidado alguno al código interno de los programas.
2. Probar cada rutina y cada instrucción sin tomar en cuenta las especificaciones.

Los tipos de pruebas realizadas al sistema de control de gestión en plataforma

Web 2.0, fueron las siguientes:

1. Pruebas de unidad: Tipo de prueba que se enfoca primero en los módulos,

independientes uno de otros, para localizar errores, posibles mejoras diseño de
entrada que permitiera una mejor interacción usuario-sistema, la validación de
los datos a los que se hace referencia en cada módulo.

2. Pruebas de integración: Finalizadas las pruebas individuales se procede a

aplicar pruebas de integración para comprobar la compatibilidad de los
módulos inherentes al sistema. De esta manera se destacaron posibles errores
cometidos en la definición de aspectos tales como: la seguridad del flujo de la
información y la uniformidad en diseños de entrada en todos los módulos.

3. Pruebas del sistema: Esta prueba está constituida con el propósito primordial
de verificar que se han integrado adecuadamente todos los elementos de
sistema (Casos de Uso), introduciéndose datos reales tal y como si estuviera

63
 ya implantado y los resultados fueron verificados a través de consultas y
reportes.
Diagrama de Caso de Uso
A continuación se muestran los diagramas de casos de uso:

Figura 2 Diagrama de Caso de Uso – Ciclo de un requerimiento

Fuente: Martell, Mayckool (2011)

Para el uso del Sistema se ha visto conveniente la creación de 4 tipos de usuarios

con diferentes niveles de acceso, los cuales son:
1. Actor Habitante: representa la persona que formula un requerimiento a la
corporación.
2. Actor Operador: representa la persona que se encargará registrar a los
habitantes, registrar sus requerimientos y de gestionar los mismos.
3. Actor Direcciones: representa la persona que se encargará de realizar las
operaciones que solucionen un requerimiento dado.

64
 4. Actor Supervisor: representa la persona que se encargará de realizar las
operaciones de consultas resumidas o consolidadas referente a la
información que se registra en la base de datos.

Figura 3 Diagrama de Caso de Uso – Creación de un requerimiento

Fuente: Martell, Mayckool (2011)

Los requerimientos son recibidos por el operador, el cual se encarga de buscar

los datos del habitante que está gestionando el caso, una vez confirmada la identidad,
se procede capturar toda la información asociada con el requerimiento , en último
lugar, se verifica la factibilidad del mismo y se le asigna a la dirección encargada de
su solución.
Cuadro 20
Descripción de Caso de Usos. Crear Requerimiento
CASO DE USO: Crear Requerimiento Referencias CR
Descripción: Permite al usuario crear un objeto de tipo requerimiento, para
consultar o eliminar.
Actores: Operador
Referencia
cruzada:
Pre-Condición:
Fuente: Martell, Mayckool (2011)

65
Cuadro 20 (cont’)
Entradas: Datos del habitante, datos del
requerimiento
Salidas: Objeto de tipo solicitud.

Curso Típico de Eventos

Acción del actor Respuesta del sistema

1) El usuario consulta la identidad del
habitante.
2) El sistema verifica el
habitante.
3) El sistema retorna el
numero de cedula del habitante.
4) El usuario ingresa los datos del
requerimiento.
5)El usuario asigna la dirección del
requerimiento
6) El sistema registra la
información.
Curso Excepcional # 2 El habitante no existe
Precondición: El habitante no fue detectado por la Base de Datos.

Acción del actor Respuesta del sistema

1) El sistema detecta que el
habitante seleccionado no existe
2) El sistema informa que el
objeto no existe

3) El operador ingresa los datos del habitante.

4)El sistema guarda los datos del
habitante
5) El sistema continua en el flujo
4 del principal
Fuente: Martell, Mayckool (2011)

66
Cuadro 21.
Descripción de Caso de Usos. Cargar Seguimiento
CASO DE USO: Cargar Seguimiento Referencias CS
Descripción: Permite al usuario cargar un objeto de tipo seguimiento
según el requerimiento.
Actores: Operador
Referencia Cargar requerimiento.
cruzada:
Pre-Condición: Tiene que haber un requerimiento cargado
Entradas: Objeto de tipo requerimiento
Salidas: Objeto de tipo solicitud
Curso Típico de Eventos
Acción del actor Respuesta del sistema
1) El usuario carga el objeto de tipo
requerimiento según el servicio definido.
2) El sistema verifica la
existencia de objetos de tipo
requerimiento

3) El usuario autentica y confirma la carga del

objeto tipo solicitud.
4) El usuario carga la información del
seguimiento.
5) el sistema registra la
información
Curso Excepcional # 1 está cargado el objeto tipo solicitud
Precondición: En el paso 2 el usuario detecta que no existe un objeto tipo
requerimiento
Acción del actor Respuesta del sistema
1) Se detecta que no existe el
requerimiento.
2) Se informa que no existe
requerimiento.
3) El sistema envía a Crear
requerimiento
Fuente: Martell, Mayckool (2011)

67
Diagrama de Clase
En el modelado con objetos, las estructuras estáticas son los objetos y las clases
están compuestas de atributos y métodos. Las relaciones entre objetos y clases
corresponden a las ligas y asociaciones, respectivamente.Las estructuras o
propiedades de la clase se conocen como atributos y el comportamiento como
operaciones. Los diagramas de clase nos ayudaron a entender la estructura de clases
del proyecto, y para visualizar las relaciones entre las clases que involucran al
sistema.
Estudio y Desarrollo de la Base de Datos
El Sistema a desarrollar se basa en el mantenimiento de una base de datos, la cual
almacena toda la información relevante del sistema de gestion de control de atención
al ciudadano en plataforma Web 2.0 de la Corporación de Servicios Municipales
Libertador. Para los requerimientos se almacenará los datos referentes a la persona
que apertura el caso, la descripcion del mismo así como su fecha y hora de
generación, así como cualquier observación de parte de los supervisores, por lo tanto,
para soportar dichos datos se necesita crear la base de datos que permita almacenar y
gestionar dicha información.
En consecuencia, para el desarrollo de dicha base de datos se utilizará un enfoque
de entidad-relación, para posteriormente, convertir el modelo resultante en un modelo
relacional, que será implementado directamente en el sistema gestor de base de datos
elegido. En dicho diagrama se refleja el funcionamiento interno del sistema, la
manera en cómo carga la data, asimismo, muestra el proceso de de carga, consulta,
modificación y eliminación de registros, la data no es eliminada totalmente se realiza
una eliminación lógica mas no física ya que esta información debe estar respaldada
para futuras acciones.

68
Figura 4 Diagrama de Clases.
Fuente: Martell, Mayckool (2011)

Diagrama de Secuencia

El diagrama de secuencias es el núcleo de modelo dinámico, y muestra todos

los cursos alternos que pueden tomar los casos de uso.

Figura 5 Diagrama de secuencia.

Fuente: Martell, Mayckool (2011)

69
 INICIO

Habitante coloca un requerimiento

Operador lo atiende

Habitante otorga sus datos

Operador verifica datos

NO ¿Esta Registrado? SI

Solicita Información
Registrar
de Requerimiento
Habitante
Nuevo

¿Es factible el
NO
Requerimiento?

SI

Informar
novedad al
habitante
Asignar caso

Solventar
Requerimiento

FIN

Figura 6 Diagrama de actividades.

Fuente: Martell, Mayckool (2011)

70
Figura 7 Diagrama Entidad-Relación.
Fuente: Martell, Mayckool (2011)

Diccionarios de Datos

Los diccionarios de datos son el segundo componente del análisis del flujo de
datos. En sí mismos los diagramas de flujo de datos no describen por completo el
objeto de la investigación. Proporcionan información adicional sobre el sistema. Un
diccionario de datos es una lista de todos los elementos incluido en el conjunto de los
diagramas de flujo de datos que describen un sistema. Se desarrollan durante el
análisis de flujo de datos y ayuda al analista involucrado en la determinación de los
requerimientos de sistemas.
Se describen a continuación el siguiente diccionario de datos de los procesos que
se involucrarán en el sistema propuesto:

71
Cuadro 22
Diccionario de datos tabla dbo_cuadrillas
Nombre de la tabla: dbo_cuadrillas
Descripción: Tabla donde se almacenan las cuadrillas
Campo Tipo Nulo Descripción

cua_id int(10) No Código de la cuadrilla

dir_id int(10) No Clave foránea

cua_dsc varchar(75) No Nombre de la cuadrilla

Fuente: Martell, Mayckool (2011)

Cuadro 23
Diccionario de datos tabla dbo_denunciantes
Nombre de la tabla: dbo_denunciantes
Descripción: Tabla donde se almacenan los datos del habitante
Campo Tipo Nulo Descripción

que_id int(10) No Código del denunciante

que_nombre varchar(75) No Nombre y apellido del denunciante

que_cedula int(10) No Cedula del denunciante

que_tlf varchar(12) No Teléfono del denunciante

que_tlf2 varchar(12) No Teléfono 2 del denunciante

Fuente: Martell, Mayckool (2011)

Cuadro 24
Diccionario de datos tabla dbo_prioridad
Nombre de la tabla: dbo_prioridad
Descripción: Tabla donde se almacena las prioridades
Campo Tipo Nulo Descripción

pri_id int(10) No Código de la prioridad

pri_dsc varchar(75) No Descripción de la prioridad

Fuente: Martell, Mayckool (2011)

72
Cuadro 25:
Diccionario de datos tabla dbo_denuncias
Nombre de la tabla: dbo_denuncias

Descripción: Tabla donde se almacenan todos los detalles de los requerimientos

Campo Tipo Nulo Descripción

den_id int(10) No Código de la denuncia

den_titulo varchar(150) No Titulo de la denuncia

que_id int(10) No Clave foránea

par_id int(10) No Clave foránea

dir_id int(10) No Clave foránea

dia_id int(10) No Clave foránea

pri_id int(10) No Clave foránea

den_dsc varchar(150) No Detalle de la denuncia

den_fape varchar(12) No Fecha de apertura de la denuncia

ope_idape int(10) No Clave foránea

den_fcie varchar(12) No Fecha de cierre de la denuncia

ope_idcie int(10) No Clave foránea

sta_id int(10) No Clave foránea

Fuente: Martell, Mayckool (2011)

73
Cuadro 26
Diccionario de datos tabla dbo_diracciones
Nombre de la tabla: dbo_diracciones
Descripción: Tabla de definición de las actividades por dirección
Campo Tipo Nulo Descripción

dia_id int(10) No Código de la actividad

dir_id int(10) No Clave foránea

dia_dsc varchar(75) No Descripción de la actividad

Fuente: Martell, Mayckool (2011)

Cuadro 27
Diccionario de datos tabla dbo_direcciones
Nombre de la tabla: dbo_direcciones
Descripción: Tabla de definición de las direcciones
Campo Tipo Nulo Descripción

dir_id int(10) No Código de la dirección

dir_dsc varchar(75) No Nombre de la dirección

Fuente: Martell, Mayckool (2011)

Cuadro 28
Diccionario de datos tabla dbo_estatus
Nombre de la tabla: dbo_estatus
Descripción: Tabla de definición de los estatus
Campo Tipo Nulo Descripción

sta_id int(10) No Código del estatus

sta_dsc varchar(75) No Nombre del estatus

Fuente: Martell, Mayckool (2011)

74
Cuadro 29
Diccionario de datos tabla dbo_denunciantes
Nombre de la tabla: dbo_operador
Descripción: Tabla maestro de operadores
Campo Tipo Nulo Descripción

ope_id int(10) No Código del operador

ope_nombre varchar(75) No Nombre del operador

ope_user varchar(30) No Usuario del operador

ope_pwd varchar(30) No Password del operador

per_id int(10) No Clave foránea

Fuente: Martell, Mayckool (2011)

Cuadro 30
Diccionario de datos tabla dbo_parroquias
Nombre de la tabla: dbo_parroquias
Descripción: Tabla de definición de parroquias
Campo Tipo Nulo Descripción

par_id int(10) No Código de la parroquia

par_dsc varchar(75) No Nombre de la parroquia

Fuente: Martell, Mayckool (2011)

Cuadro 31
Diccionario de datos tabla dbo_permisos
Nombre de la tabla: dbo_permisos
Descripción: Tabla de definición de permisos
Campo Tipo Nulo Descripción

per_id int(10) No Código del permiso

per_dsc varchar(30) No Descripción del permiso

Fuente: Martell, Mayckool (2011)

75
Cuadro 32
Diccionario de datos tabla dbo_seguimiento
Nombre de la tabla: dbo_seguimiento
Descripción: Tabla maestro de seguimientos por casos
Campo Tipo Nulo Descripción

seg_id int(10) No Código del seguimiento

den_id int(10) No Clave foránea

ope_codigo int(10) No Clave foránea

seg_fecha varchar(15) No Fecha del seguimiento

seg_dsc varchar(150) No Descripción del seguimiento

Fuente: Martell, Mayckool (2011)

Diagrama Modular

El diagrama modular permite ver cómo está constituido el sistema, lo que

facilita comprender el funcionamiento del mismo.

Figura 8 Diagrama modular

Fuente: Martell, Mayckool (2011)
76
Manual de Usuario

El propósito del presente documento es proveer una guía práctica para el uso del
Sistema de Control de Gestión en plataforma Web 2.0 de la Corporación de
Servicios Municipales Libertador. Dentro de la aplicabilidad, el mismo está
pensado para ser usado en la etapa de explotación del sistema.
Generalidades:
El Sistema de Control de Gestión en plataforma Web 2.0 de la Corporación de
Servicios Municipales Libertador, fue elaborado para un ambiente web de manera
dinámica, permitiendo el acceso al mismo desde cualquiera de las direcciones
distribuidas en el área metropolitana o desde la sede principal, facilitando a la misma,
la carga, modificación y/o actualización de la información para la Sala de control de
Seguridad, mediante el uso de un esquema de seguridad, donde cada usuario
registrado tendrá un login o código único y una contraseña que verifica su entrada al
sistema.
Ingreso al Sistema:
Para acceder al portal se debe ir directamente desde la barra de direcciones del
explorador o browser, y colocar el siguiente URL: http://10.0.1.2/sgac/ si se encuentra
fuera de las instalaciones de Plaza Venezuela, debe colocar la siguiente ruta:
http://200.82.144.67/sgac/

Grafico 9 Ingreso al Sistema

Fuente: Martell, Mayckool (2011)
77
 La pantalla de autenticación tiene como funcionalidad permitir el acceso al
sistema por parte de los usuarios (operador), la verificación se hace comparando en la
base de datos los datos introducidos por el usuario con los datos que se encuentran
almacenados. Para autenticarse debe escribir su usuario y contraseña en los renglones
correspondiente y a continuación darle click al botón Aceptar. Si la los datos son
inválidos se mostrara un mensaje indicando el error, tal como se muestra a
continuación:

Grafico 10 Error de inicio de sesión

Fuente: Martell, Mayckool (2011)

Si la autenticación fue positiva y el sistema autorizo la entrada al sistema por

parte del usuario, se muestra a continuación la pantalla del menú general, la cual
señala en la parte izquierda la opción que desee, es importante resaltar que las
opciones que poseen los operadores son distintas a los del perfil de supervisor, ya que
este último tiene opciones de modificar y eliminar registros y acceso a las tablas de
mantenimiento.

78
Grafico 11 Vista de perfil de operador
Fuente: Martell, Mayckool (2011)

Grafico 12 Vista de perfil de supervisor

Fuente: Martell, Mayckool (2011)

79
 Registro de habitantes:
Cuando una persona se comunica con la Corporación de Servicios Municipales
(CSML) es debido a que tiene alguna solicitud o inquietud que afecta directamente su
calidad de vida, y el de su comunidad, es por ello que para levantar cualquier
requerimiento es importante que sus datos se almacenen en el sistema. Se puede
verificar si la persona se encuentra registrada al momento de Agregar un
requerimiento, ingresando el nombre o el número de cedula del ciudadano, si el
sistema no devuelve los datos es que la persona debe ser registrada.

Grafico 13 Ciudadanos registrados en el sistema

Fuente: Martell, Mayckool (2011)

Para agregar un habitante, debe posicionarse en el menú a la izquierda de la

pantalla y seleccionar la opción de Agregar Habitante, en el cual se le solicitará al
datos básicos de la persona como nombre y apellido y dos números telefónicos, es
importante señalar que todos los datos recolectados se mantendrán en absoluta
confidencialidad, y que su uso es exclusivamente para la verificación de las
actividades reportadas, en caso de hacer un mal uso de los mismos, el operador esta
sujeto a lo establecido por las leyes de la republica.

80
Grafico 14 Registro de habitantes
Fuente: Martell, Mayckool (2011)

El sistema valida está validado para no registrar 2 personas con un mismo

número de cedula, esto con el fin de mantener una base de datos actualizada y
confiable. En caso de que intente ingresar un registro ya almacenado, el sistema
arrojará un mensaje de error indicando la novedad.

Grafico 15 Cedula duplicada

Fuente: Martell, Mayckool (2011)

81
 Requerimientos:
El requerimiento es el motivo principal por el cual el ciudadano se comunica con
la CSML ya que resolver estos detalles es la razón de ser de la organización, para
agregar un nuevo caso, se debe ubicar en el menú del lado izquierdo de la pantalla y
seleccionar la opción Agregar Requerimiento, es importante resaltar que para
procesar un requerimiento es indispensable que el ciudadano se encuentre registrado
en el sistema.

Grafico 16 Vista registro de requerimientos

Fuente: Martell, Mayckool (2011)

El formulario para registrar un requerimiento está conformado por:

1. Nombre: esta campo cambia el nombre de la persona por el numero de cedula,

para mantener la privacidad de la persona.

2. Parroquia: Localidad perteneciente al Municipio Libertador en donde se

presenta la eventualidad.

3. Dirección: departamento al cual se le asignará la actividad.

4. Actividad: Relacionada con la dirección, son las acciones que pueden realizar
los distintos departamentos adscrito a la CSML.

82
 5. Titulo del requerimiento: breve descripción del problema.

6. Descripción: es donde se detalla en si la novedad planteada, no debe omitir

ningún detalle.

Grafico 17 Registro de requerimientos

Fuente: Martell, Mayckool (2011)

Al guardar un requerimiento, el sistema le dará un mensaje que el registro ha sido

guardado con éxito, y el mismo puede ser visualizado en la opción Consultar
Requerimientos, por esta vía se puede hacer búsquedas de requerimientos por titulo
del requerimiento, estatus, dirección, parroquias, fecha de apertura actividad y cedula
de identidad del ciudadano, asimismo, se puede ajustar la cantidad de registros a
mostrar en la pantalla y se pueden ordenar todos los registros haciendo click sobre
cada uno de los títulos antes mencionados, facilitando aun más la búsqueda y
aportando una herramienta amigable para trabajar.

83
Grafico 18 Consultar requerimiento
Fuente: Martell, Mayckool (2011)

Si se desea saber con más detalle sobre un requerimiento, se debe presionar el

vínculo sobre el campo Título, en esta página se muestra todos los detalles del caso,
asimismo se puede visualizar los seguimientos que tenga el caso para de esta manera
dar una respuesta más clara a los habitantes. A su vez, si se debe agregar un
seguimiento se debe presionar el vinculo Agregar seguimiento que se encuentra en la
parte derecha de la pantalla.

Grafico 19 Detallado de un requerimiento

Fuente: Martell, Mayckool (2011)
84
Grafico 20 Seguimientos
Fuente: Martell, Mayckool (2011)

Para agregar un seguimiento solo se debe colocar la información relacionada con

el caso, ya que el resto de la información es tomada directamente por el sistema, y es
almacenada una vez colocado el registro en el campo seguimiento.
Mantenimiento:
Son las tablas que poseen información complementaria del sistema, en esta se
pueden modificar aquellas opciones como las prioridades, actividades por dirección,
manejos de usuarios y permisología, estatus de casos, parroquias entre otros. En todos
los formularios de mantenimiento se tiene la posibilidad de modificar, eliminar e
insertar registros, ya que son pocas las personas que deberían tener acceso a dicho
modulo, sin embargo es importante destacar que los cambios que se realicen no son
reversibles, es por ellos que se insta a aquellos usuarios que tienen estos privilegios
utilizarlos de manera correcta.

85
Grafico 21 Actividad por dirección
Fuente: Martell, Mayckool (2011)

Grafico 22 Direcciones
Fuente: Martell, Mayckool (2011)

86
Grafico 23 Operadores
Fuente: Martell, Mayckool (2011)

Grafico 24 Parroquias
Fuente: Martell, Mayckool (2011)
87
Grafico 25 Prioridades
Fuente: Martell, Mayckool (2011)

88