CAPÍTULO IV RESULTADOS DE LA INVESTIGACIONvirtual.urbe.edu/tesispub/0094997/cap04.pdf · 2013. 4....

CAPÍTULO IV

RESULTADOS DE LA INVESTIGACION

164

CAPÍTULO IV

RESULTADOS DE LA INVESTIGACION

En este capítulo se presentan los hallazgos de la investigación

producto del trabajo de observación directa y la aplicación de diferentes

instrumentos diseñados para cumplir exitosamente con los objetivos de la

investigación, así como también el estudio de la factibilidad y el análisis de la

información recopilada. Confirmándose o no los objetivos propuestos; se

evidencia el alcance del proyecto. En él se procede a presentar una serie de

procesos hasta la aplicación del mismo.

1 ANÁLISIS Y DISCUSIÓN DE LOS DATOS Y RESULTADOS

Una vez aplicados los instrumentos se procede al análisis de la

información de manera cualitativa.

1.1 DESARROLLO DE LAS FASES DE LA METODOLOGIA

Para darle cumplimiento al primer objetivo especifico, Identificar los

procesos que se realizan en la gestión de bienes para la administración pública,

en correspondencia con la primera fase I de la metodología referente a la

Planeación y Elaboración, se logro constatar a través de la visita a dos entes

municipales (contraloría Municipal y Alcaldía), que la labor que desarrollan

165

estas instituciones en relación a los Bienes Municipales es totalmente

manual, siendo una de estas, órgano rector en materia de control de bienes.

Esta fase está basada en los resultados que se obtuvieron por la

aplicación de los instrumentos de recolección de datos, los cuales se

encuentran constituidos por la Guía de Observación Directa y la Entrevista.

Ver Anexos, B y C.

Del mismo modo se mostrará los resultados durante la visita donde se

consiguió conocer a través de una guía de observación, que en cuanto a

hardware las instituciones cuentan con computadores de última generación en su

mayoría. Mientras que al referirse a Software se puede afirmar que las mismas

cuentan con: Windows y no con Linux, de la misma forma que posee personal

calificado para la implantación y mantenimiento de todos los procesos

relacionados a los portales de los entes gubernamentales de control.

En este mismo orden de ideas, se realizo una entrevista no

estructurada al Contralor del Municipio Lagunillas del Estado Zulia, Econ.

Albenis Arrieta Moreno, documento que contiene ocho (8) preguntas abiertas

acerca de los procesos actuales llevados por la institución, evidenciando la

problemática actual, en su primera pregunta:

¿Usted considera que el Control de Bienes actual es eficiente, porque?

Contesto: Es poco eficiente, porque cumple con las exigencias

requeridas por la contraloría General de la República, sin embargo es

repetitivo y de insuficiente control ya que no se puede revisar manualmente

166

que no estén repetidos los mismos, no es fácil cruzar la información de los

bienes de distintas dependencias y mantener su historial.

En su segunda pregunta:

¿Cuáles son los procesos que se llevan acabo actualmente en Bienes? Contesto: Realización de: Incorporaciones, Desincorporaciones,

Transferencias. Resumen de Actas para incorporar, desincorporar y transferir

entre una serie de formatos como BM1, BM2, BM3, BM4, entre otras

En su tercera pregunta:

¿Cuáles son las fallas que Usted encuentra en cada uno de los

procesos mencionados?

Contesto: La mayoría de los procesos mencionados en la respuesta

anterior se deben llenar desde cero y con expediente en mano restando

rapidez y confianza al mismo.

En su cuarta pregunta:

¿Cree usted que a través de un sistema de control de bienes se permita

automatizar dichos procesos permitiendo lograr mayor productividad y

mejores tiempo de respuesta ¿(explique su respuesta).

Contesto: Si, porque con un programa con una base de datos con los

bienes y sus movimientos estos procesos se podrían entregar con mayor

efectividad y rapidez a las partes interesadas y acortaría el tiempo de trabajo

aprovechando más el computador.

En su quinta pregunta:

167

¿Cuál considera usted es punto crítico en sus procesos de control de

bienes actuales? (Explique su respuesta).

Contesto: El manejo de transferencias y movimientos de bienes, ya que

no tenemos un sistema digital que nos permita hacer el mismo de forma

rápida y segura.

En su sexta pregunta:

¿Cuentan las instituciones públicas con equipos e infraestructura para

implantación del nuevo sistema propuesto?

Contesto: Hoy día los entes públicos (Alcaldías, Gobernaciones y otras

instituciones) cuentan con equipos de computación, unos con mas recursos

que otros, pero en líneas generales deben tener estos equipos ya que con el

decreto 3390 fueron aprobados recursos para la compra de los mismos y la

mayoría de los informes que se deben entregar a los organismos de control

se hacen a través de la web.

En su séptima pregunta

¿Está dispuesto (a) a recibir entrenamiento para manejar un nuevo

sistema? ¿Cómo desearía que fuese dicho entrenamiento?

Contesto: Si, me gustaría aprender a manejar un sistema, y me gustaría

que este se lleve a cabo en la institución donde otras personas que están a

mí alrededor y que me ayudan en estos procesos también puedan aprender y

familiarizarse con el nuevo sistema.

En su octava pregunta:

¿Desea hacer alguna observación adicional que no esta contemplada

en las preguntas realizadas en esta entrevista?

168

Contesto: No, solo espero que el sistema del cual hablan nos ayude a

agilizar nuestros procesos de control de bienes.

Con esta serie de preguntas claves acerca del proceso actual llevado,

sus puntos críticos así como el planteamiento de la automatización de los

procesos actuales y la aceptación de entrenamiento y adiestramiento con un

sistema eficiente.

A continuación se presentan los resultados a la entrevista realizada en la

institución. La entrevista se inicio con la descripción de la situación actual de la

institución en cuanto al manejo de la información a lo cual se respondió que se

lleva a cabo de forma manual. Se recopiló toda la información acerca de los

procesos para el control de bienes a través de la observación directa, se

determinaron las fallas que presenta entre las cuales se pueden mencionar:

- Alto retraso con respecto a la actividades que se realizan en la

institución, estas actividades pueden identificarse como: Incorporación de

Bienes, Desincorporación de Bienes y Transferencia de Bienes, control de

recaudos de Bienes, captación de toda la información de los Bienes, es decir,

Incorporación, datos del Bien, Proveedor, Historial del Bien y observaciones

que se realicen; procesado dicha información y su almacenamiento.

- En lo que se refiere a las estadísticas que se lleva, la manejan de

manera muy rudimentaria en formatos en papel y Hojas de Excel, informes

estadísticos tales como: Incorporaciones, Desincorporaciones, cantidad de

bienes por dependencia, Transferencias, entre otros. Lo que genera tiempo

de retraso en la presentación de informes.

169

- Lleva todo de manera escrita en formatos ya existentes, colocándolo

en carpetas y llevándolos a un archivo común donde, con el tiempo, esta

base de datos física puede traspapelarse, deteriorarse o sencillamente

perderse.

En cuanto a las actividades realizadas se obtuvieron los escenarios

básicos en los cuales se llego a la conclusión de que en el mejor escenario

con el sistema los resultados estarán disponibles cuando se les necesite,

proporcionando claridad y precisión. Lo cual aumentará las capacidades de

respuesta, y se logrará la satisfacción del usuario y el órgano rector

permitiéndole llevar un mejor seguimiento. Asimismo se analizo el peor de

los escenarios, que sería que el sistema falle y se tenga que recurrir

temporalmente a realizar el procedimiento de forma manual, mientras se

solucione el problema.

La Entrevista, arrojó que la planificación, organización, incorporación,

desincorporación, transferencia e inventario de los bienes, toma un tiempo

excesivo y las instituciones no cuenta con la tecnología adecuada

actualmente para poder satisfacer adecuadamente estos procesos de

manera que se ejecuten los tiempos de gestión dando eficiencia y seguridad

a toda su información procesada.

Los requerimientos son una descripción de las necesidades o deseos

de un producto, los requerimientos pudieron ser identificados claramente

gracias a la aplicación de las técnicas de recolección de datos mencionadas

anteriormente, la utilización de ellas permitió alcanzar la meta primaria que

170

es identificar y documentar lo que en realidad se necesita; para definir los

requerimientos se crearon los siguientes artefactos, siguiendo con lo

expuesto en la metodología de Larman (1999), descrita en el capítulo

anterior:

Así que luego de la aplicación de estos instrumentos surgen los

siguientes requerimientos de información:

- diseño de un sistema que permita mejorar la gestión de los bienes en

la administración publica

- generación de reportes y actas.

- Diseño de claves de acceso al sistema de información

- Un entorno amigable al usuario

Requerimientos Funcionales:

- Estadísticas en tiempo real de los bienes.

- Reportes efectivos de bienes y actas.

- Control total de todas las gestiones de bienes llevadas a cabo por la

administración publica.

En un Panorama General este proyecto tiene como objetivo desarrollar

SISTEMAS DE INFORMACION BAJO AMBIENTE WEB PARA LA GESTION

DE BIENES EN LA ADMINISTRACION PUBLICA, facilitando de este modo

sus procesos actuales tales como: control de los bienes en la administración

publica (incorporación, desincorporación, clasificación, proveedor, libro de

bienes y actas), control de las desincorporación-incorporación (traslado) y

171

todos aquellos procesos administrativos que estén de cierta forma ligados a

estos dos principales objetos dentro del sistema.

Luego del estudio y asimilación de los datos obtenidos, producto de la

recolección de información resultó que los bienes son el principal personajes

de información que debe procesar el sistema, utilizando sistemas elaborados

con tecnologías de vanguardia bajo software libre (como lo dice el decreto

3390), como son las técnicas orientadas a objetos, que permiten un fácil

mantenimiento y actualización de los sistemas.

Como producto de la interpretación de los datos obtenidos se definió que la

meta, es el desarrollo de un Sistemas De Información Bajo Ambiente Web Para

La Gestión De Bienes En La Administración Publica, para que las tareas

ejecutadas con los bienes, sean más rápidas, eficaces y den óptimos resultados.

FUNCIONES DEL SISTEMA

Como resultado del estudio de los flujos de información presentes en los

Procesos de gestión de bienes en la administración publica, se pudo

determinar que las funciones del sistema son lo que éste habrá de hacer,

estas funciones se clasifican para establecer prioridades entre ellas e

identificar las que pasarán desapercibidas (pero que consumen tiempo y

recursos), y las que no, todo esto en correspondencia con los criterios de

Larman (1999), expuestos en el capítulo anterior. Las categorías son:

• Evidente: Debe realizarse, y el usuario debería saber que se ha

realizado.

172

• Oculta: debe realizarse aunque no es visible para los usuarios.

• Superflua: Opcionales.

Como resultado se determinó que las funciones básicas que debe

cumplir el sistema son las siguientes (con su respectiva categoría):

a) Registro o Incorporación de Bienes, información básica, proveedor,

clasificación funcional del bien, transferencia o procedencia de alguna otra

institución, actas de incorporación, entre otros datos con la finalidad de

identificar los listados y estadísticas que luego se requieran. (Evidente)

b) Control de modificación de datos de los Bienes, usuarios con claves

de acceso. (Evidente)

c) Generar reportes de diferentes ámbitos, con criterios de selección

según la consulta. (Evidente)

d) Consultas de dependencias, Coordinaciones, bienes por

dependencias. (Evidente)

e) Desincorporación de Bienes y observaciones. (Evidente)

f)Creación de estadísticas de diferentes ámbitos, con criterios de

selección según la consulta. (Evidente)

g) Controlar la duplicidad de seriales de bienes. (Oculto)

h) Definir el numero de bien que se debe asignar. (Oculto)

i) Calculo de las estadísticas diversas disponibles para consulta.

(Oculto)

j) Validar tipos de datos de entrada para los reportes.

173

DESCRIPCIÓN DE LOS PROCESOS

Para formar la descripción de los procesos es necesario crear una

serie de diagramas los cuales siguen a continuación, en concordancia con

los pasos de la metodología de Larman (1999) descrita anteriormente, para

elaborar estos diagramas fue preciso el análisis de los datos recopilados

anteriormente producto de la aplicación de las técnicas de recolección de

datos, esto sirvió para definir claramente los procesos, y obtener como

producto los diagramas concernientes.

IDENTIFICAR Y ESCRIBIR CASOS DE USO

Para identificar y escribir los casos de uso, fue necesario analizar los

datos, gracias al seguimiento de la metodología de Larman (1999), luego de

identificarlos se comprobó que hay concordancia con lo expuesto en el

Capítulo II, donde se manifiesta que los casos de uso ayudan a identificar los

requerimientos del sistema y a describir los procesos, los casos de uso

obtenidos para el sistema son los siguientes:

CASOS DE USO DE ALTO NIVEL

Caso de uso: Gestión Bienes.

Actores: Jefe de Bienes

Propósito: Incorporar un Bienes.

Tipo: Primario.

174

Descripción: El jefe de bienes toma los datos del bien y los ingresa al

sistema, verificando que estos pertenezcan a la base de datos, en caso

contrario los mismos serán incorporados.


Actores: Jefe de bienes.

Propósito: Consultar los datos un Bien.

Tipo: Primario.

Descripción: El jefe de bienes realiza una consulta de los datos de un

Bien para verificar el estado del mismo.


Actores: Jefe de bienes

Propósito: Modificar los datos un Bien.

Tipo: Primario.

Descripción: El jefe de bienes toma los datos del Bien requerido y los

ingresa en el sistema, verificando que estos estén registrados en la base de

datos. Si el jefe de bienes observa algún cambio en los datos suministrados,

este pasa a modificar los datos del mismo.


Actores: Jefe de Bienes.

Propósito: Desincorporar un Bien.

Tipo: Primario.

175

Descripción: El Jefe de Bienes realiza la Desincorporación un Bien y

entrega un Acta de Desincorporación con toda la información del Bien

desincorporado.

DIAGRAMAS DE CASOS DE USO

Teniendo como base, los datos obtenidos del paso anterior, se obtuvo

los diagramas de casos de uso, todo esto siguiendo la metodología de

Larman (1999); de igual forma se comprueba que estos diagramas se

utilizan para representar la funcionalidad del sistema tal y como se expone en

el Capitulo II.

Gráfico 1. Diagrama parcial de casos de uso. (Gestión Bienes).

Fuente: Bracho, Mocleton y Montero (2012).

En este gráfico se puede observar que el caso Gestión de Bienes se

realizan, opcionalmente, los procedimientos de Incorporar, Consultar,

Modificar, o Desincorporar hecho que se representa con la utilización de la

176

relación “Extend”, ajustándose a la metodología seleccionada y en

concordancia con lo expuesto en Capitulo II.

CASOS DE USO EXPANDIDOS

Los casos de uso expandidos, son resultado de la aplicación de los

pasos de la metodología, y se realizaron siguiendo los lineamientos de la

misma, luego de su elaboración se demostró que coinciden con lo expuesto

en Capitulo II donde se afirma que los casos de uso expandidos son aquellos

más descriptivos donde se explica el curso de los eventos.



Tipo: Primario y esencial.





177

CUADRO 1 CURSO NORMAL DE LOS EVENTOS

ACCIÓN DEL ACTOR 1.1.1 RESPUESTA DEL SISTEMA

1. El jefe de bienes incorpora los datos del bien.

2. El sistema verifica si el bien solicitado ya está incorporado y carga los datos del bien.

3. El jefe de bienes transcribe los datos que se requieran. 6.- El jefe de bienes imprime el Acta de Incorporación del bien.

4. El sistema actualiza la base de datos y devuelve mensajes de error en caso de que alguna de las peticiones no pueda ser realizada. 5. El sistema devuelve un mensaje de registro exitoso.


Caso de uso: Gestionar Bien.


Tipo: Primario.

Propósito: Modificar los datos de un Bien.





178



1. El jefe de bienes selecciona el Bien a modificar.

2. El sistema muestra los datos del Bien seleccionado.

3. El jefe de bienes carga al sistema los datos a modificar. 6.- El jefe de bienes confirma la modificación y se imprime el acta de Incorporación nuevamente.

4. El sistema actualiza la base de datos y devuelve mensajes de error en caso de que alguna de las peticiones no pueda ser realizada. 5. Modificación exitosa.




Tipo: Primario.


Descripción: El jefe de bienes realiza una consulta de los datos de un Bien

para verificar el estado del mismo.

179



1. El jefe de bienes selección el Bien a ser consultado.


3.- El jefe de bienes da respuesta al requerimiento del sistema informando sobre el resultado de la consulta y espera hasta que éste esté conforme.

Fuente: Bracho, Mocleton y Montero (2012). Caso de uso: Gestionar Bien.


Tipo: Primario.




desincorporado.

180


ACCIÓN DEL ACTOR 1.1.4 RESPUESTA DEL SISTEMA 1. Luego del que el Jefe de Bienes selecciona el Bien.

2. El sistema muestra los datos del Bien seleccionado y pregunta el motivo (Concepto) y fecha de desincorporación de Bien.

3.- El Jefe de Bienes procede a realizar la desincorporación del Bien del sistema. 6.- El Jefe de Bienes Imprime el Acta de Desincorporación del Bien en señal de conformidad.

4. El sistema actualiza la base de datos y devuelve mensajes de error en caso de que alguna de las peticiones no pueda ser realizada. 5. El sistema genera el Acta de Desincorporación.


CLASIFICACIÓN DE LOS CASOS DE USO

Luego de haber definido los casos de uso expandidos, se continua con

la clasificación de los casos de uso, la clasificación de los casos de uso surge

como resultado del análisis de los flujos de información en el ente publico, lo

que permite conocer cuales son los casos de uso mas importantes; los

cuales deben ser desarrollados en primer lugar, también es producto del

análisis de los resultados obtenidos de las fases anteriores.

181

CUADRO 5 CLASIFICACIÓN CASOS DE USO

CLASIFICACIÓN CASO DE USO JUSTIFICACIÓN Alto

Gestión Bienes. Incorporar. Modificar. Consultar. Desincorporar

Corresponde a los criterios de clasificación más altos.

Bajo Inicia. Efecto mínimo en la arquitectura.


PROGRAMACIÓN DE LOS CASOS DE USO

La programación de los casos de uso se obtiene como resultado del

paso anterior luego de haber definido o clasificado los casos de uso se

procede a determinar cual caso de uso va a ser desarrollado y su versión

correspondiente todo esto de acuerdo a los pasos de la metodología de

Larman (1999) descrita en el capitulo II.

Después de todo lo anterior se pudo determinar que los casos de uso,

serán desarrollados en el Ciclo de Desarrollo 1, en su versión 1.

• Gestión Bienes: versión 1 (Incorporar Bienes, modificar Bienes,

consultar Bienes y Desincorporar Bienes).

182

• Gestión de Jefe de Bienes: versión 1 (Incorporar Jefe de Bienes, modificar

Jefe de Bienes, consultar Jefe de Bienes y Desincorporar Jefe de Bienes).

• Incorporar: versión 1: (incorporar de Bienes y/o Jefe de Bienes).

• Modificar: versión 1: (modificar de Bienes y/o Jefe de Bienes).

• Consultar: versión 1: (consultar datos de: Bienes y/o Jefe de Bienes).

• Desincorporar: versión 1: (Desincorporar datos de: Bienes y/o Jefe de

Bienes).

ASIGNACIÓN DE LOS CASOS DE USO.

Después de programar los casos de uso, y usando como base los

resultados anteriormente obtenidos, se asignarán los casos de uso al ciclo

de desarrollo, siguiendo los parámetros de Larman (1999).

En virtud de esto se creó la asignación de los casos de uso:

Gráfico 2. Asignación de Casos de Uso


183

Para darle consecución y cumplimiento al segundo objetivo Determinar

los requerimientos de la estructura del sistema de Información bajo ambiente

web para la gestión de bienes en la administración pública. En

correspondencia con la segunda fase II de la metodología referente al

Análisis.

En esta fase es donde se definen los requerimientos del usuario y

establecen las funciones, restricciones y atributos que el sistema de

información debe satisfacer.

Esta fase está basada en los resultados que se obtuvieron por la

aplicación de los instrumentos de recolección de datos, los cuales se

encuentran constituidos por la Guía de Observación Directa y la Entrevista.

Ver Anexos B y C.

La observación se realizó durante la visita a la institución pública, donde

se pudo observar como llevan a cabo los procesos de gestión de bienes

manuales, estadísticas, actas, reportes generales, entre otros. Observando el

tiempo que toma realizar esos procesos ocasionando lentitud al proceso

diario de trabajo.

En el mismo orden, la Entrevista, arrojó que el inventario, clasificación,

incorporación, desincorporación de bienes, toma un tiempo excesivo y las

instituciones públicas no cuentan con un sistema actualmente para poder

satisfacer adecuadamente estos procesos de manera que se ejecuten los

tiempos de gestión dando eficiencia y seguridad a toda su información

procesada.

184

Así que luego de la aplicación de estos instrumentos surgen los

siguientes requerimientos de información:

Diseño de un sistema que permita mejorar la gestión de los bienes

públicos, Generación de reportes, actas de incorporación, desincorporación.

Diseño de claves de acceso al sistema de información

Un entorno amigable al usuario

Requerimientos Funcionales:

Estadísticas en tiempo real de la gestión de bienes

Reportes efectivos de actas de incorporación y desincorporación.

Control total de todas las gestiones de bienes llevadas a cabo por la

institución.

De los resultados obtenidos en las fases y pasos anteriores se tuvo

como resultado la creación de una serie de artefactos que se expondrán a

continuación, todos ellos enmarcados dentro de los pasos que define la

metodología seleccionada, descritas en la fase anterior.

CONSTRUCCIÓN DE UN MODELO CONCEPTUAL

En este paso se produjo un estudio y comprensión de los objetos

existentes, así como también el análisis de los resultados de los pasos

anteriores, esto originó como producto el modelo conceptual.

CREAR UN MODELO CONCEPTUAL PRELIMINAR Luego de analizar e interpretar los datos obtenidos usando las técnicas

de recolección y con la aplicación de las fases anteriores dio como resultado,

el modelo conceptual preliminar, con él se demostró lo expuesto en el fase II

185

donde se sostiene que el modelo conceptual identifica las entidades

presentes en el contexto del sistema, es decir, conceptos reales y no

conceptos de software.

Gráfico 3. Modelo Conceptual Preliminar. Fuente: Bracho, Mocleton, Montero (2012).

AGREGACIÓN DE LAS ASOCIACIONES

Basado en los resultados obtenidos de los pasos, fases anteriores y

además de la información investigada, se continuó con lo presentado por la

metodología, agregando asociaciones.

IDENTIFICAR LAS ASOCIACIONES DE UN MODELO CONCEPTUAL

Como resultado del estudio de los datos obtenidos, durante la

recaudación de información y de la aplicación de los pasos y fases se

obtuvieron las asociaciones del modelo conceptual, comprobándose lo

186

mostrado en el marco teórico donde se confirma que las asociaciones

revelan como se relacionan las diferentes entidades, empleando conceptos

como la cardinalidad.

Gráfico 4. Asociaciones del Modelo Conceptual.

Fuente: Bracho, Mocleton, Montero (2012).

ASOCIACIONES QUE NECESITAN CONOCERSE

Una vez ya conocidas las asociaciones entre las entidades y como

producto del estudio de las mismas, siguiendo además las leyes de Larman

(1999), se establecieron las asociaciones que requieren conocerse, es decir

las mas significativas, mostrándose a continuación.

187

Asociación A Asociación Desde

Elemento : bbien (Bienes) Multiplicidad : 8

Asociación Hasta Elemento : bgrupo (Grupo de Bienes) Multiplicidad : 1

Asociación B Asociación Desde


Asociación Hasta Elemento : bsubgrupos (Sub Grupo de Bienes) Multiplicidad : 1

Asociación C Asociación Desde


Asociación Hasta Elemento : btipo (tipo) Multiplicidad : 1

Asociación D Asociación Desde


Asociación Hasta Elemento : busuarios(usuarios) Multiplicidad : 1

Asociación E Asociación Desde


Asociación Hasta Elemento : bcorrelativos(correlativos) Multiplicidad : 8

Asociación F Asociación Desde

188


Asociación Hasta Elemento : btipos (tipos) Multiplicidad : 1

Asociación G Asociación Desde


Asociación Hasta Elemento : bseccion(Secciones) Multiplicidad : 1

Asociación H Asociación Desde


Asociación Hasta Elemento : bmodelos (Modelos) Multiplicidad : 1

Asociación I Asociación Desde


Asociación Hasta Elemento : bmarca (Marcas) Multiplicidad : 1

Asociación J Asociación Desde


Asociación Hasta Elemento : bproveedores(Proveedores) Multiplicidad : 1

Asociación K Asociación Desde

Elemento : bbien_movimientos (Movimientos Bienes) Multiplicidad : 8

Asociación Hasta

189

Elemento : bconcepto (Conceptos) Multiplicidad : 1

Asociación L Asociación Desde


Asociación Hasta Elemento : estados (Estados) Multiplicidad : 1

Asociación M Asociación Desde


Asociación Hasta Elemento : municipios (Municipios) Multiplicidad : 1

Asociación N Asociación Desde


Asociación Hasta Elemento : bbien_movimientos (Movimientos) Multiplicidad : 8

Asociación Ñ Asociación Desde


Asociación Hasta Elemento : btraslados (Traslados) Multiplicidad : 1

Asociación O Asociación Desde


Asociación Hasta Elemento : bsitio (Sitio) Multiplicidad : 1

190

Asociación P

Asociación Desde Elemento : bbien (Bienes) Multiplicidad : 8

Asociación Hasta Elemento : bcoordinacion (Coordinacion) Multiplicidad : 1

Asociación Q Asociación Desde


Asociación Hasta Elemento : bdependencia (Dependencia) Multiplicidad : 1

ATRIBUTOS DEL MODELO DEL SISTEMA

Los atributos del modelo del sistema se obtienen para el estudio como

producto del análisis de la información obtenida en los pasos anteriores,

siguiendo la metodología de Larman (1999). Luego de haber fijado los

atributos se demostró que va acorde con lo mostrado en el marco teórico

donde se confirma que las entidades tienen atributos que permiten

describirlas mucho mejor dentro del argumento del sistema.

191

Gráfico 5. Atributos del Modelo del Sistema. Fuente: Bracho, Mocleton, Montero (2012).

COMPORTAMIENTO DE LOS SISTEMAS

Como resultado del estudio de los flujos de información de los entes

públicos, que se obtuvieron en la recolección de datos, y de los artefactos

elaborados en pasos anteriores se procedió a establecer la conducta del

sistema.

IDENTIFICAR LOS EVENTOS Y OPERACIONES DEL SISTEMA

Producto de la interpretación de las necesidades se procedió a la

personalización de los eventos y operaciones del sistema, siguiendo con la

metodología elegida. Luego se determinó que estos son:

192

• Incorporar_ Bien()

• Incorporar_Datos()

• Verificar_Bien()

• Transcribir_Datos()

• Actualiza_Datos()

• Muestra_Bien()

• Cargar_Datos()

• Mensaje_Sistema()

• Seleccionar_Bien()

• Modificar_ Bien ()

• Consultar_ Bien ()

• Desincorporar_ Bien ()

• Actualizar_base_datos()

• Imprime_acta()

CREAR EL DIAGRAMA DE SECUENCIA DEL SISTEMA, PARA LOS

CASOS DE USO

Un diagrama de secuencia muestra la interacción de un conjunto de

objetos en una aplicación a través del tiempo y se modela para cada caso de

uso. Mientras que el diagrama de casos de uso permite el modelado de una

vista business del escenario, el diagrama de secuencia contiene detalles de

implementación del escenario, incluyendo los objetos y clases que se usan

193

para implementar el escenario, y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para

determinar qué objetos son necesarios para la implementación del escenario.

Si se dispone de la descripción de cada caso de uso como una secuencia de

varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir

qué objetos son necesarios para que se puedan seguir los pasos. Un

diagrama de secuencia muestra los objetos que intervienen en el escenario

con líneas discontinuas verticales, y los mensajes pasados entre los objetos

como flechas horizontales.

Como producto del estudio, y asimilación de los resultados obtenidos

anteriormente se elaboró los diagramas de secuencia del sistema, siguiendo

con la metodología de Larman (1999), evidenciándose lo mostrado en el

marco teórico en el que se señala que los diagramas de secuencia, estos

precisan la conducta del sistema, y se usan para visualizar la comunicación

entre los objetos. Los cuales se exponen a continuación.

194

Gráfico 6. Diagrama de Secuencia Gestión Bienes (Incorporar)


Gráfico 7. Diagrama de Secuencia Gestión Bienes (Modificar)


195

Gráfico 8. Diagrama de Secuencia Gestión Bienes (Consultar)


Gráfico 9. Diagrama de Secuencia Gestión Bienes (Desincorporar)


196

CONTRATOS

Después de ya definidas las operaciones del sistema y los diagramas

de secuencia del sistema, obtenidos producto de las fases anteriores y

siguiendo la metodología de Larman (1999), se empieza a elaborar los

contratos para las operaciones del sistema, basándose en los resultados de

los pasos anteriormente mencionados.

CREAR CONTRATOS PARA LAS OPERACIONES DEL SISTEMA

Después de determinadas las operaciones del sistema resultado del

paso 1.2.4.1, se pasa a realizar los contratos que son descripciones de las

operaciones del sistema, demostrándose con su realización lo mostrado en el

marco teórico, en el que se puede notar que son necesarios para

comprender el comportamiento del sistema. Como resultado se obtiene

entonces los mismos que se muestran a continuación.

197

CONTRATO

Nombre: incorporar().

Responsabilidades: Capturar datos de bienes.

Tipo: Sistema.

Notas: Utilizar el acceso a base de datos.

Excepciones: Si los datos introducidos no son válidos, indicar que se

cometió un error.

Precondiciones: El sistema tiene fases de introducción de datos, y

mecanismos de validación.

Poscondiciones:

- Si se trata de los datos de un bien, el sistema creará un nuevo registro de

Bienes y guardará sus datos en la base de datos.

198

CONTRATO

Nombre: Consultar().

Responsabilidades: Capturar datos de bienes ya existentes en la base de

datos.

Tipo: Sistema.


Excepciones: Si los datos seleccionados no son válidos, indicar que se

cometió un error.

Precondiciones: El sistema posee interfaces para seleccionar las consultas,

y mecanismos de validación.

Poscondiciones:

- Si se trata de los datos de un bien, el sistema procesará la consulta, y

mostrará datos del mismo a través de la interfaz, concurrentes con la

consulta.

199

CONTRATO

Nombre: Modificar().

Responsabilidades: Modifica datos de bienes ya existentes en la base de

datos.

Tipo: Sistema.


Excepciones: Si los datos seleccionados no son válidos, indicar que se

cometió un error.

Precondiciones: El sistema posee interfaces para seleccionar los datos, y

mecanismos de validación.

Poscondiciones:

- Si se trata de los datos de un bien, El sistema posee interfaces para

introducir los datos, y mecanismos de validación.

200

CONTRATO Nombre: Verificar_bien().

Responsabilidades: Validar datos referentes a los bienes a nivel de interfaz

para luego almacenarlas en la base datos.

Tipo: Sistema.

Notas: Utilizar la interfaz de usuario (ventana).


cometió un error.

Precondiciones: El sistema posee interfaces para introducir los datos, y

mecanismos de validación, incrustados en las interfaces.

Poscondiciones:

- Una vez validados los datos a nivel de interfaz estarán listos para

ingresarse en la base de datos disminuyendo los riesgos, de

transacciones inválidas que consumen recursos y que pueden restarle

integridad a los datos.

201

CONTRATO Nombre: Actualizar_base_datos().

Responsabilidades: Validar datos de bienes y Jefe de Bienes para

ingresarlos en la base de datos.

Tipo: Sistema.



cometió un error.

Precondiciones: La base de datos está correctamente diseñada, al igual

que los mecanismos de validación.

Poscondiciones:

- Si se trata de datos de un bien, se validarán los datos de mismo, luego se

procederá a actualizar la base de datos

202

CONTRATO Nombre: Imprime_acta().

Responsabilidades: Generar reportes con información, de bienes, y sus

movimientos.

Tipo: Sistema.


Excepciones: Si no hay datos disponibles no se podrá generar el reporte.

Precondiciones: El sistema posee interfaces para crear el reporte.

Poscondiciones:

- Se generarán reportes de acuerdo a la necesidad del usuario, conteniendo

datos de bienes, en formato digital y/o papel.

CREAR DIAGRAMAS DE ESTADO PARA LOS CASOS DE USO

Los diagramas de estado muestran el conjunto de estados por los

cuales pasa un obje to durante su vida en una aplicación en respuesta a

eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto

con sus respuestas y acciones. También ilustran qué eventos pueden

cambiar el estado de los objetos de la clase. Normalmente contienen:

estados y transiciones. Como los estados y las transiciones incluyen, a su

vez, eventos, acciones y actividades, vamos a ver primero sus definiciones.

Al igual que otros diagramas, en los diagramas de estado pueden

aparecer notas explicativas y restricciones.

203

Hay quienes consideran que los diagramas de estado son naturales,

pero muchos no los consideran así. Preste atención al modo en que los

emplean quienes trabajan con ellos; podría ocurrir que su equipo no

considere útiles los diagramas de estados, debido a su modo de trabajar.

Esto no sería un gran problema; como siempre, deben combinarse las

técnicas que sean de utilidad.

Como resultado del estudio y asimilación de la información obtenida

en el paso anterior se realizaron los diagramas de estado para el sistema,

luego de esto se comprueba que describen el comportamiento de un objeto

individual con varios estados y transiciones entre esos estados tal y como se

refiere en el marco teórico. Los resultados de este paso son los diagramas

mostrados a continuación:

DIAGRAMAS DE ESTADO PARA CASO DE USO GESTIÓN BIENES

Gráfico 10. Diagrama de Estado Gestión Bienes (Incorporar)


204

Gráfico 11. Diagrama de Estado Gestión Bienes (Modificar)


Gráfico 12. Diagrama de Estado Gestión Bienes (Consultar)


205

Gráfico 13. Diagrama de Estado Gestión Bienes (Desincorporar)


Para darle consecución y cumplimiento al tercer objetivo Diseñar lógica

y físicamente el sistema propuesto con base a los requerimientos

previamente establecidos para desarrollar un Sistema de Información bajo

ambiente web para la gestión de bienes en la administración pública. En

correspondencia con la primera fase III y IV de la metodología referente a

Demostrar la funcionalidad del sistema propuesto aplicando las pruebas

respectivas.

Después de finalizada la fase de análisis los resultados se utilizan para

la fase de diseño y construcción, siguiendo la metodología de Larman (1999),

esto facilitó la obtención de las herramientas de la fase de diseño y

construcción que se muestran a continuación.

206

DESCRIPCIÓN DE LOS CASOS REALES DE USO

Basándose en los resultados obtenidos de las fases anteriores se

procede a describir los casos de usos en concordancia con la metodología

seleccionada.

CREAR CASOS REALES DE USO

Apoyándose en la metodología, Larman (1999), y estudiando los

resultados de las otras fases y pasos, se elabora los casos reales de uso,

obteniendo como resultado la siguiente información que se detalla a

continuación:



Tipo: Primario y esencial.





207

Cuadro 1 Curso normal de los eventos


1. El jefe de bienes incorpora los datos del bien.

2. El sistema verifica si el bien solicitado ya está incorporado y carga los datos del bien.

3. El jefe de bienes transcribe los datos que se requieran. 6.- El jefe de bienes imprime el Acta de Incorporación del bien.

4. El sistema actualiza la base de datos y devuelve mensajes de error en caso de que alguna de las peticiones no pueda ser realizada. 5. El sistema devuelve un mensaje de registro exitoso.




Tipo: Primario.

Propósito: Modificar los datos un Bien.





208



1. El jefe de bienes selecciona el Bien a modificar.


3. El jefe de bienes carga al sistema los datos a modificar. 6.- El jefe de bienes confirma la modificación y se imprime el acta de Incorporación nuevamente.

4. El sistema actualiza la base de datos y devuelve mensajes de error en caso de que alguna de las peticiones no pueda ser realizada. 5. Modificación exitosa.




Tipo: Primario.


Descripción: El jefe de bienes realiza una consulta de los datos de un Bien

para verificar el estado del mismo.

209



1. El jefe de bienes selección el Bien a ser consultado.


3.- El jefe de bienes da respuesta al requerimiento del sistema informando sobre el resultado de la consulta y espera hasta que éste esté conforme.

Fuente: Bracho, Mocleton y Montero (2012). Caso de uso: Gestionar Bien.


Tipo: Primario.




desincorporado.

210


ACCIÓN DEL ACTOR 1.1.8 RESPUESTA DEL SISTEMA 1. Luego del que el Jefe de Bienes selecciona el Bien.

2. El sistema muestra los datos del Bien seleccionado y pregunta el motivo (Concepto) y fecha de desincorporación de Bien.

3.- El Jefe de Bienes procede a realizar la desincorporación del Bien del sistema. 6.- El Jefe de Bienes Imprime el Acta de Desincorporación del Bien en señal de conformidad.

4. El sistema actualiza la base de datos y devuelve mensajes de error en caso de que alguna de las peticiones no pueda ser realizada. 5. El sistema genera el Acta de Desincorporación.


CLASIFICACIÓN DE LOS CASOS DE USO

Luego de haber definido los casos de uso expandidos, se continua con

la clasificación de los casos de uso, la clasificación de los casos de uso surge

como resultado del análisis de los flujos de información en el ente publico, lo

que permite conocer cuales son los casos de uso mas importantes; los

cuales deben ser desarrollados en primer lugar, también es producto del

análisis de los resultados obtenidos de las fases anteriores.

211

Cuadro 5 Clasificación Casos de Uso

CLASIFICACIÓN CASO DE USO JUSTIFICACIÓN Alto

Gestión Bienes. Incorporar. Modificar. Consultar. Desincorporar

Corresponde a los criterios de clasificación más altos.

Bajo Inicia. Efecto mínimo en la arquitectura.

Fuente: Bracho, Mocleton y Montero (2012). MAPEO DE LOS DISEÑOS PARA CODIFICACIÓN

Después de realizados los diagramas de clase del diseño y

consignados al ciclo de desarrollo actual, se disponen de suficientes detalles

para generar código que se usará con la finalidad de construir el sistema,

como resultado de esto se escribió código fuente para:

Definiciones de clase.

Definiciones de métodos.

Siguiendo la metodología de Larman (1999).

212

CREACIÓN DE LAS DEFINICIONES DE CLASE A PARTIR DE LOS

DIAGRAMAS DE CLASE DEL DISEÑO

Los datos que generan los diagramas de clase de diseño (nombres de

las clases, etiquetas de los métodos, atributos simples de una clase), es

suficiente para fijar una definición de la clase en un lenguaje orientado a

objetos, se obtuvo como resultado entonces las definiciones de las clases en

un lenguaje orientado a objetos, específicamente Visual Basic 6.0, siguiendo

la metodología Larman (1999).

CREACIÓN DE MÉTODOS A PARTIR DE LOS DIAGRAMAS DE

COLABORACIÓN

Los diagramas de colaboración son los que muestran los mensajes que

se envían como resultado de la llamada a un método, producto de este paso

la sucesión de mensajes se tradujo a una serie expresada en la definición del

método.

En los diagramas de colaboración, los objetos ejemplo se muestran

como iconos. Las flechas indican, como en los diagramas de secuencia, los

mensajes enviados dentro del caso de uso dado. Sin embargo, en esta

ocasión la secuencia se indica numerando los mensajes.

El numerar los mensajes dificulta más ver la secuencia que poner las

líneas verticales en la página. Por otra parte, la disposición espacial del

diagrama permite mostrar otras cosas mejor. Se puede mostrar cómo se

213

vinculan entre ellos los objetos y emplear la disposición para sobre poner

paquetes u otra información.

Se puede usar alguno de los diversos esquemas de numeración para

los diagramas de colaboración. En el pasado, el esquema más utilizado era

el de la numeración simple. El UML utiliza el esquema decimal, pues hace

evidente qué operación llama a otra y cuál es esa otra, aunque pueda ser

más difícil apreciar la secuencia general.

ACTUALIZACIONES DE LAS DEFINICIONES DE CLASES

Producto de este pasó, partiendo de decisiones de codificación se

modificaron las definiciones de clases y se modificaron los diagramas de

clase de acuerdo a los cambios en la codificación.

ORDEN DE IMPLEMENTACIÓN

Como resultado de este paso, se realizaron las clases de la menos

ajustada a la más ajustada; es decir de las más autónomas a las

menos autónomas.

A continuación se presenta el prototipo diseñado, en donde al entrar

al portal se le presentará la siguiente pantalla para el inicio de sesión.

214

Gráfico 14. Acceso al Sistema.


El usuario deberá ingresar sus datos de inicio de sesión, y enviar la

información con el fin de validar la cuenta, y permitirle el acceso al sistema.

En la pantalla de bienvenida se presentarán las opciones en las cuales el

usuario del sistema podrá escoger la función que desea realizar como

gestionar Bienes, Jefe de Bienes, consultas de reportes, entre otros.

215

Gráfico 15. Menú principal.


Haciendo uso de los módulos encontrados el usuario podrá Incorporar,

modificar, consultar y Desincorporar, cualquier información concerniente a las

clases Bienes y Jefe de Bienes.

216

Gráfico 16. Modulo de consulta


Para darle cumplimiento al último objetivo especifico relacionado con

Demostrar la Funcionabilidad del Sistema de Información a través de

pruebas especificas, en correspondencia con la última fase de la

metodología Pruebas del Sistema, propuesta por García (2000); se

realizaron una serie de pruebas escogidas para determinar si el sistema

cumple con los requerimientos propuestos inicialmente y con su función

principal, servicio de manera eficiente y sin fallas o retrasos.

Para la prueba del nuevo sistema se usó la estrategia de la caja negra,

debido a que lo esencial es el que se cumpla con las especificaciones y

requerimientos hechos por los usuarios sin prestar atención al código fuente

de los programas. Como producto de esta fase se determino que se busca

cumplan los siguientes aspectos:

217

a-) Capacidad del sistema para realizar operaciones rápidamente.

b-) Establecer la capacidad de datos que soporta.

c-) Habilidad de realizar operaciones complejas.

d-) Establecer el nivel de adiestramiento necesario para su uso

correcto.

e-) Evaluar la conducta del sistema bajo condiciones diarias del

Departamento Administrativo y los diversos ambientes que se presentan en

el mismo.

f-) Obtener los posibles errores.

Para finalizar los objetivos planteados previamente se establecieron dos

elementos principales:

• Subsistemas.

• El Sistema en su totalidad.

Para este proceso se utilizó el software de programación PHP utilizado

para la construcción del sistema, y se uso el método de prueba Bottom-Up o

de abajo hacia arriba el cual consiste en probar individualmente cada

elemento de nivel inferior, luego se agregan los elementos que los solicitan,

hasta incluir el sistema terminado, en primer lugar se evaluaron los

subsistemas por separado, luego las interacciones, entre ellos, y finalmente

todo el sistema bajo diferentes situaciones, para examinar que

funcionamiento sea efectivo en el ambiente real, los problemas que

presentaba y los puntos fuertes y críticos del mismo.

218

Como siguiente paso se estableció un plan de pruebas conformado de

la siguiente manera:

a-) Prueba Gestión de Bienes.

b-) Prueba Gestión de Jefe de Bienes.

Para la elaboración de los casos de prueba se consideraron los datos

obtenidos durante un periodo de observación dentro de la organización, con

lo cual se obtuvo un mayor entendimiento de los procesos.

PRUEBAS DEL SISTEMA

Para las pruebas de estrés se determinó que la aplicación soporta para

determinar la solidez de la aplicación en los momentos de carga extrema,

esta prueba se utiliza normalmente para romper la aplicación, es decir, se va

aumentando el número de usuarios que se agregan a la aplicación y se

ejecuta una prueba de carga hasta que se rompe. Este tipo de prueba se

realiza y ayuda a los administradores para determinar si la aplicación rendirá

lo suficiente en caso de que la carga real supere a la carga esperada.

De igual forma se realizara una prueba de estabilidad, esta determina si

la aplicación puede aguantar una carga esperada continuamente. Y una

prueba de picos, con la cual se observa el comportamiento del sistema

variando el número de usuarios, tanto cuando bajan, como cuando tiene

cambios drásticos en su carga.

Además se realiza una prueba de integración, para validar que todos

los módulos funcionen bien en conjunto; y una prueba de compatibilidad para

219

asegurar que el portal funciona correctamente en la plataforma de la

empresa.

Para finalizar se hicieron pruebas de seguridad, para certificar que sólo

puedan ingresar al sistema los usuarios existentes, y que sólo puedan

observar la información de sus productos, y no la de los demás proveedores.

PRUEBA DE ACEPTACIÓN

De los resultado obtenidos de la aplicación de este paso se realizó la

prueba de aceptación general, en esta se efectuaron casos de prueba mas

usuales y algunos de los más inseguros, para evidenciar el hecho de que el

sistema cumple con todos y cada uno de las exigencias establecidas en el

inicio de una manera decente y que el sistema se encuentra finalizado y listo

para ser implantado con un mínimo de fallas.

Finalizado el proceso de prueba, se contempló que todas las exigencias

fueron satisfechas y todos los objetivos fueron alcanzados de forma grata,

cumpliendo con las metas del sistema y añadiendo nuevas funciones, las

cuales traen grandes beneficios a la organización, tanto en lo operacional

como en lo económico trayendo menor tiempo y costo de operación.

2. DISCUSION DE LOS RESULTADOS

Para la discusión de los resultados se confrontaron las teorías de la

metodología con los hallazgos obtenidos cumpliendo las actividades del

cuadro en función de los objetivos específicos y de las fases.

220

Para el análisis de la situación actual de los requerimientos del

suministro de información de la institución educativa, se comprobó mediante

la información general de la empresa, que ésta cuenta con los elementos

organizacionales formalmente establecidos, destacando conocimientos

básicos en el uso de equipos computarizados; y que cuenta con los recursos

técnicos requeridos para el desarrollo del portal.

Y para la determinación de los requerimientos funcionales se

conocieron mediante entrevistas, cuestionarios y observación directa las

fallas existentes, y se establecieron los requerimientos, permitiendo describir

los escenarios básicos y los casos de usos básicos del sistema. De esta

forma se dio cumplimiento a la primera fase de la metodología sugerida por

Larman (1999). Como primer requisito para el desarrollo del Sistema de

Información para la gestión de los procesos administrativos.

También, continuando con el objetivo anterior, se constató que los

equipos con la que cuenta la institución se encuentran funcionando de

manera correcta y es compatible con el sistema desarrollado. Además se

recaudó la información necesaria para poder esbozar cuales serian los casos

de uso del sistema.

Y para el diseño del Sistema de Información bajo ambiente web para la

gestión de bienes en la administración pública, se hizo una visita con la que

se pudo clarificar las dudas respecto al diseño del Sistema de Información;

partiendo de ello se elaboró el diagrama entidad-relación que sirvió de

insumo en el diseño para la base de datos. De esta forma se dio

221

cumplimiento a la segunda fase de la metodología sugerida por Larman

(1999), como segundo requisito para el desarrollo del Sistema de Información

bajo ambiente web para la gestión de bienes en la administración pública.

Para el diseño y construcción del portal del “Sistema de Información

bajo ambiente web para la gestión de bienes en la administración pública”, se

completó el diseño de los diagramas de casos de uso, permitiendo la

programación de los módulos del prototipo y su posterior integración. Luego

de finalizado el portal de servicios se elaboró un manual que le servirá de

guía o ayuda a los usuarios en caso de necesitarla. De esta forma se dio

cumplimiento a la tercera y cuarta fase de la metodología sugerida por

Larman (1999), como tercer requisito para el desarrollo del Sistema de

Información para la gestión de los procesos administrativos.

Para la validación del diseño del “Sistema de Información bajo ambiente

web para la gestión de bienes en la administración pública”, se diseñaron las

pruebas, se validaron mediante uso directo por parte del personal de la

institución para comprobar su funcionalidad. Se realizó un registro de los

resultados de dichas pruebas, lo que permitió la realización de un análisis, y

la realización de las correcciones necesarias; obteniendo así el producto final

deseado. De esta forma se dio cumplimiento a la última fase de la

metodología sugerida por García (2000), como el requisito final para el

desarrollo del portal de servicios.

CAPÍTULO IV RESULTADOS DE LA INVESTIGACIONvirtual.urbe.edu/tesispub/0094997/cap04.pdf · 2013. 4....

Documents

Transcript of CAPÍTULO IV RESULTADOS DE LA INVESTIGACIONvirtual.urbe.edu/tesispub/0094997/cap04.pdf · 2013. 4....