Marilú Ruiz Peña - Repositorio Institucional de la Universidad

UNIVERSIDAD VERACRUZANA
Facultad de Contaduría y Administración
“Reingeniería del sistema control de
obras de la secretaria de
comunicaciones del estado de Veracruz”
TESINA
Para obtener el Título de:
Licenciado en Sistemas
Computacionales Administrativos
Presenta:
Marilú Ruiz Peña
Asesor:
M.A. Héctor Guzmán Coutiño
Xalapa-Enríquez, Veracruz
Noviembre 2013
UNIVERSIDAD VERACRUZANA
Facultad de Contaduría y Administración
“Reingeniería del sistema control de
obras de la secretaria de
comunicaciones del estado de Veracruz”
TESINA
Para obtener el Título de:
Licenciado en Sistemas
Computacionales Administrativos
Presenta:
Marilú Ruiz Peña
Asesor:
M.A. Héctor Guzmán Coutiño
Xalapa-Enríquez, Veracruz
Noviembre 2013
AGRADECIMIENTOS
A mis padres: Marilú Peña y Antonio Ruiz que hicieron posible este sueño, por
creer en mí en todo momento, por su amor, paciencia, pero sobre todo gracias
por enseñarme una lección de vida.
A mis hermanas y mejores amigas: Adriana y Josefina por su apoyo, compañía
y ánimo en todo momento haciendo más fácil la vida.
A mis hermanos por ser un ejemplo en mi vida.
A mi novio: Fernando por estar a mi lado en todo momento, gracias por tus
porras y consejos.
A quienes me recibieron en su casa sin conocerme ofreciéndome un hogar.
A la maestra: Ari Ady Montes Ortega por alentarme a realizar este proyecto de
vida.
A mi director de trabajo: por su apoyo profesional.
ÍNDICE
AGRADECIMIENTOS ................................................................................................................. I
RESUMEN ................................................................................................................................... 1
INTRODUCCIÓN ........................................................................................................................ 2
CAPITULO I. MARCO REFERENCIAL .................................................................................. 6
1.1
JUSTIFICACIÓN DE LA INVESTIGACIÓN............................................................ 7
1.2 USO DE SOFTWARE LIBRE ...................................................................................... 11
1.3 ANTECEDENTES ......................................................................................................... 13
1.4 OBJETIVOS .................................................................................................................... 13
1.4.1 OBJETIVO GENERAL ........................................................................................... 13
1.4.2 OBJETIVOS ESPECÍFICOS ................................................................................ 14
CAPITULO II MARCO TEÓRICO .......................................................................................... 15
2.1 REINGENIERÍA DE SISTEMAS INFORMÁTICOS .................................................. 16
2.2 ¿QUÉ ES REINGENIERÍA DEL SOFTWARE? ........................................................ 16
2.3 PROPÓSITO .................................................................................................................. 17
2.4 ETAPAS DE LA REINGENIERÍA ................................................................................ 18
2.5 VENTAJAS ..................................................................................................................... 21
CAPITULO III. REINGENIERÍA DEL SISTEMA CONTROL DE OBRAS. ....................... 22
3.1 ANÁLISIS DE INVENTARIO DEL SISTEMA: Control de Obras ............................ 23
3.1.1 FORMULACIÓN DEL PROBLEMA. .................................................................... 36
3.1.2 ANÁLISIS FODA.................................................................................................... 41
3.1.3 ANÁLISIS GENERAL DEL SISTEMA ................................................................. 42
3.2 RESTRUCTURACIÓN DE DOCUMENTOS ............................................................. 44
3.3 INGENIERÍA INVERSA ................................................................................................ 44
3.3.1 UML .......................................................................................................................... 46
3.3.2 MODELO FISICO DE DATOS.............................................................................. 48
CAPITULO IV. REINGENIERÍA HACIA ADELANTE DEL SISTEMA CONTROL DE
OBRAS ....................................................................................................................................... 51
4.1 CAPTURA DE REQUERIMIENTOS. ......................................................................... 52
II
4.2 REQUERIMIENTOS FUNCIONALES DEL SISTEMA CONTROL DE OBRAS. . 52
4.3 REQUERIMIENTOS NO FUNCIONALES. ................................................................ 53
4.4 RESTRUCTURACIÓN DE CASOS DE USO ............................................................ 53
4.4.1 ESPECIFICACIÓN DE CASOS DE USO ........................................................... 55
4.5 MODELO FÍSICO DE DATOS ..................................................................................... 61
4.5.1 NORMALIZACIÓN. ................................................................................................ 61
CAPITULO V. PRUEBAS ........................................................................................................ 66
5.1 Requerimientos de hardware y software.................................................................... 67
5.2 Migración de base de datos. ........................................................................................ 69
5.3 PROCESO DE IMPLEMENTACIÓN .......................................................................... 70
CONCLUSIONES ..................................................................................................................... 72
REFERENCIAS ........................................................................................................................ 76
GLOSARIO ................................................................................................................................ 77
ÍNDICE DE FIGURAS .............................................................................................................. 79
ÍNDICE DE TABLAS ................................................................................................................ 80
III
RESUMEN
El proyecto de reingeniería del sistema Control de Obras de la secretaria de
comunicaciones del estado de Veracruz, consta en la realización de la
reingeniería del sistema, a fin de optimizar su funcionamiento en cada
proceso, así como actualizar la plataforma del mismo, con el propósito de
brindar información, en forma adecuada a los usuarios encargados de
administrar las diferentes etapas que conlleva la gestión de una obra en el
estado de Veracruz.
El sistema control de obras es el encargado de administrar toda la
información general, financiera y estado de cada obra que se ejecuta en el
estado de Veracruz, el sistema está a cargo de la Dirección general de
telecomunicaciones (DGT), dichos módulos se encuentran desarrollados
baso el lenguaje de Delphi y el SGBD Firebird.
Los módulos del sistema presentan dificultades desde su creación, debido
a la falta de conocimientos respecto a los requerimientos que solicitaba la
secretaría de comunicaciones, así como de una visión a futuro, frenando la
apertura o posibilidad de realizar cambios al sistema
La reingeniería del software es la restructuración o modificación
del
software o sus componentes a partir del análisis de su rendimiento, a fin de
mejorar aquellos puntos débiles del sistema actualizando y reforzando su
funcionamiento mediante la aplicación de tecnologías y prácticas modernas.
Por consiguiente la reingeniería del software nos permite emigrar el sistema
Control de obras de la plataforma de Delphi y Firebird
a una nueva
plataforma, en este caso es java y postgres, con el propósito de reutilizar el
sistema Control de obras existente, aplicando los beneficios de las nuevas
tecnologías.
1
INTRODUCCIÓN
La reingeniería aparece de la misma forma en que las empresas han ido
evolucionando en cuanto a sus procesos, y a consecuencia de estos sucesos,
se presentan una serie de anomalías en el funcionamiento de los sistemas,
provocando un gran impacto en ellos, al paso de estos fenómenos, se pudo
examinar que era imposible realizar las nuevas peticiones de los usuarios en
forma oportuna y eficiente, debido a que el sistema presenta las siguientes
animalias:

Confiabilidad cuestionable

Tiempo y presupuesto excedido para realizar cambios.

Altos requerimientos de personal para poder realizar el mantenimiento
o modificación.

A menudo el sistema es imposible de modificar o mejorar.

falta de adaptabilidad

insuficiente portabilidad y carencia de documentación
Estos problemas son efecto de proyectos gestionados con un sobrepresupuesto, gestionados con sobre tiempo, software de baja calidad y
proyectos con código difícil de mantener.
Los sistemas de software más grandes requieren de mayor esfuerzo de
mantenimiento que los sistemas pequeños. Cuando una aplicación lleva siendo
usada años, es fácil que se vuelva inestable y a fin de solucionar los problemas
que presentan, surge la reingeniería del software que es:
La modificación de un producto software, o de ciertos componentes, usando
para el análisis del sistema existente técnicas de reingeniería inversa y, para la
etapa de reconstrucción, herramientas de ingeniería directa, de tal manera que
se oriente este cambio a optimizar el mantenimiento, reutilización o
comprensión.
Existen diferentes tipos de metodologías a seguir en la aplicación de la
reingeniería del software, a continuación se muestra cada una, así como su
breve descripción.
3
EL
MÉTODO
DE
ANÁLISIS
DE
OPCIONES
PARA
LA
REINGENIERÍA (OAR):
Es un método sistemático de arquitectura central y de toma de decisiones para
la identificación y extracción de componentes dentro de amplio y extensos
sistemas del software. OAR identifica componentes de la arquitectura y analiza
los cambios requeridos para usarlos en la creación de nuevos software, sus
actividades a realizar son las siguientes:

Establecimiento del contexto de extracción (ECE).

Inventario de Componentes (IC).

Análisis de componentes candidatos (ACC)

Plan de opciones de extracción (POE)

Selección de opciones de extracción (SOE)

EL MODELO HERRADURA
HERRADURA
El modelo herradura tiene como base los tres procesos básicos, análisis de un
sistema existente, transformación lógica y desarrollo de un nuevo sistema. El
primer proceso sube al extremo izquierdo de la herradura, el segundo atraviesa
la parte superior y el tercero baja por el extremo derecho de la herradura. Lo
que este modelo muestra son los niveles de abstracción que pueden ser
adecuados a los requerimientos lógicos, sus actividades a realizar son las
siguientes:
El primer proceso retoma la arquitectura mediante la extracción del código
fuente. La estructura es analizada y se revisa si es posible adaptarla a una
arquitectura anterior. También se evalúan diferentes características.
Transformar la arquitectura es el segundo proceso. Se recupera la arquitectura
antes echa y se le aplica reingeniería para hacerla como se quiere.
El tercer modelo de herradura usa el ¨Architecture-Based Development (ABD) ¨.
En esta parte, se juntan las estrategias seleccionadas. Los artefactos a nivel de
4
código del sistema de información heredados son normalmente tapados o
reescritos para adaptarlos dentro de la nueva arquitectura.
EL MODELO CÍCLICO
Este modelo refiere seis actividades, estas seis actividades ocurren de manera
secuencial y lineal, pero en ocasiones no es así. Por ejemplo la reingeniería
inversa podría requerirse antes de la reestructuración de documentos, La forma
de este modelo muestra que cualquier actividad puede repetirse varias veces.
Para un caso particular el ciclo podría comenzar y/0 acabar en cualquiera de
sus elementos.
El siguiente trabajo consiste en:
La realización de la reingeniería del sistema Control de Obras en la Secretaria
de Comunicaciones del Estado de Veracruz, dicho sistema se encuentra
actualmente dividido en tres módulos llamados:
 Control de obras
 Control de proyectos
 Cuentas liquidadoras
El sistema de Control de Obras se encuentra disponible en la página de
Aplicaciones de la Intranet, aplicaciones de la SECOM con la URL siguiente:
http://database-a/obras
El sistema Control de Obras es el encargado de almacenar, capturar y
consultar información referente a las obras que llevan a cabo en el estado de
Veracruz. El sistema está bajo plataformas obsoletas, las cuales no permiten
realizar ajustes con exactitud, la reingeniería al sistema nos permite reconstruir
el sistema a fin de obtener un sistema actualizado.
Las actividades a realizarse dentro del desarrollo del proyecto son bajo la
metodología cíclica de reingeniería de software, las actividades son las
siguientes:
Análisis del inventario
Restructuración de documentos
Ingeniería inversa
Reconstrucción de código
Restructuración de datos
Ingeniería directa
5
CAPITULO I. MARCO REFERENCIAL
1.1 JUSTIFICACIÓN DE LA INVESTIGACIÓN
La
dirección
general
de
telecomunicaciones
de
la
Secretaría
de
Comunicaciones del Estado de Veracruz es encargada de almacenar e
administrar las obras que se realizan en el estado de Veracruz, para su
administración cuenta con la asistencia del sistema Control obras, dicho
sistema actualmente se encuentra compuesto por los siguientes módulos:

Control de proyectos

Control de obras

Cuentas liquidadoras
El sistema están desarrollados bajo la plataforma de Delhi y el SGBD firebird
adecuado para pc de 32 bits, por este motivo se deriva el origen de esta
reingeniería, ya que el sistema es requerido en pc de 64 bits, esta plataforma
no permite realizar cambios de manera fácil y rápida por lo que en ocasiones
imposibilita realizar verdaderos ajustes.
Estos módulos son controlados, almacenados y distribuidos en distintos
sistemas, así mismo, en diferentes bases de datos, por lo que es
difícil
recopilar información, así como proveerla en tiempo y forma a los encargados
de autorizar las obras y brindar apoyos para su gestión, de igual forma bridar
información de manera adecuada a la petición de jefatura.
El módulo Control de proyectos almacena los datos de las obras POA en la
base de datos institucional, debido al complejo estado de dicha base de datos
es necesario exportar e importar los datos de las obras POA a la base de datos
COMPARE que maneja el sistema Control de Obras que está a cargo de la
Dirección General de Telecomunicaciones (DGT), para poder reunir y
finalmente administrar así la información de todas las obras.
7
Cada año en el mes de noviembre se realiza la comparecencia de las obras
llevadas a cabo en un año, por lo que reunir la información de todas las obras
significa un caos y redundancia de datos, se pretende unificar toda la
información para su fácil manipulación y presentación.
Debido al estado actual del sistema la toma de decisiones se ve altamente
afectada, complica tener un amplio conocimiento de las obras que se están
llevando a cabo en cada región del estado de Veracruz así como el estado en
el que se encuentra la obra.
El proceso de la reingeniería del software nos permite entender el
funcionamiento del sistema de Control de Obras con el fin de mejorar su
desempeño. Permite reutilizar el código de los módulos existentes, ajustándolo
a los nuevos requerimientos e implementando una nueva plataforma de
desarrollo así como un eficiente y novedoso reporteador que permita visualizar
de manera dinámica, resumida, eficiente la información referente a las obras
que gestiona la Secretaria de Comunicaciones del Estado de Veracruz.
Una vez realizada la investigación de lenguajes de programación en la
actualidad, para encontrar el lenguaje que se ajuste a las necesidades del
sistema Control de Obras, se halló los siguientes lenguajes:

Java

Visual Basic .NET

Php
De acuerdo a la investigación de los lenguajes más actuales y utilizados en el
mercado, el equipo de trabajo de la DGT se concluyó que el lenguaje más
apropiado es java, ya que se adapta a las peticiones requeridas para el sistema
en cuanto al hardware, costo, acceso de información, entre otros aspectos que
más adelante se muestran.
A continuación se muestra la información recabada de a investigación realizada
sobre el lenguaje de java.
8
DESCRIPCIÓN
VENTAJAS
DESVENTAJAS
a
Código reutilizable, un solo
En manejo a bajo nivel deben usarse
objeto, de una plataforma
código funciona para todos
métodos nativos, lo que limita la
independiente.
los browsers compatibles con
portabilidad.
-
Lenguaje
orientado
Java
-Similitudes con el lenguaje C
y C++.
El diseño de interfaces gráficas con
Java
es
un
programación
-Entorno
de
desarrollo
lenguaje
de
orientado
a
objetos
integrado eclipse.
awt y swing no es simple.
Existen herramientas como el JBuilder
que
permiten
generar
interfaces
-Distribuido
El JDK es una herramienta
gráficas de manera sencilla, pero
- Robusto
libre de licencias.
tienen un costo adicional.
- Portable
- Multihebra o Multihilos
- Es software libre.
Tabla 1.1. Descripción de java. Elaboración propia basada en (César Llamas Bello. 2013)
Como podemos darnos cuenta en la tabla anterior, Java es un lenguaje de
programación muy estable que ofrece una gran ventaja en comparación a otros
lenguajes utilizados en la actualidad.
Pero no solo el lenguaje es un punto importante para el desarrollo de esta
reingeniería, sino también el SGBD que se utilizará para almacenar los datos
procedentes del sistema Control de Obras, que en este caso se trabajara con
PostgreSQL, debido a que la DGT está siendo apoyada por una universidad de
la cuidad, la cual se encuentra trabajando conjuntamente con la SECOM en
cuanto a la parte de georeferenciación del sistema Control de Obras y de otros
más.
Uno de los inconvenientes que presenta el sistema actual es la elaboración y la
exportación de los reportes, con base al lenguaje de java y el SGBD
PostgreSQL el reporteador que se adapta a las necesidades de jefatura y del
lenguaje de java es JasperReports.
9
A continuación se muestra los elementos de JasperReports.
Descripción
Es un servidor de informes independiente y enrasado. Ofrece
información y análisis que se pueden incrustar en una web o aplicación
móvil, así como funcionar como un centro de información central para
la empresa mediante la entrega de información de misión crítica sobre
una base de tiempo real o programado para el navegador.
JasperReports es la mejor herramienta de código libre en Java para
generar reportes. Puede entregar ricas presentaciones o diseños en la
pantalla, para la impresora o para archivos en formato PDF, HTML,
RTF, XLS, CSV y XML. Está escrito completamente en Java.
Compatibilidad
Ventaja
Java, MySQL, PostgresSQL

código libre

Usuario define completamente el reporte, describiendo donde
colocar texto, imágenes, líneas, rectángulos, cómo adquirir los
datos, como realizar ciertos cálculos para mostrar totales, etc.
Desventaja

Es muy sencillo

JasperReports no maneja directamente gráficos: estos deben
crearse independientemente como Imágenes, La creación de
un gráfico se basa en una librería muy conocida de código libre
llamada JFreeCharts.

Requiere programas adicionales para la generación de los
documentos
Requerimientos
Tener instalado en el equipo el JDK, Driver JDBC Y AGREGAR LAS
SIGUIENTES LIBRERÍAS:
bsh-1.x.x.jar itext-1.x.x.jar commons-digester.jar commonscollections.jar commons-login-1.x.x.jar commons-beanutils.jar
commons-javaflow-20060411.jar
Tabla 1.2. Descripción de JasperReports. Elaboración propia basada en (Gabriel García
Márquez 2000)
JasperReports funciona correctamente en el ambiente de netbeans gracias a
la ayuda del plugin ireport, que es un diseñador visual de informes para
JasperReports, puede manejar gráficos, imágenes, informes integrados y
tablas de referencias cruzadas, los datos pueden ser retrived usando JDBC, es
compatible con PDF, RTF, XML, XLS, CSV, HTM.
10
1.2 USO DE SOFTWARE LIBRE
La opción para la realización de esta reingeniería, es la utilización de software
libre o también conocido como código abierto, tanto para el lenguaje de
programación, Sistema gestor de base de datos (SGBD), reporteador y para su
entorno de desarrollo, esta decisión principalmente es porque la secretaria de
comunicaciones no cuenta con los fondos y apoyo económico para llevar a
cabo un proyecto de software en estos momentos.
El beneficio de utilizar código abierto es que proporciona la libertad de:

Ejecutar el programa, para cualquier propósito.

Estudiar el funcionamiento del programa, y adaptarlo a sus necesidades.

Redistribuir copias.

Mejorar el programa, y poner sus mejoras a disposición del público, para
beneficio de toda la comunidad.
Software de fuente abierta. Sus términos de distribución cumplen los criterios
de:

Distribución libre.

Inclusión del código fuente.

Permitir modificaciones y trabajos derivados en las mismas condiciones
que el Software original.

Integridad del código fuente del autor, pudiendo requerir que los trabajos
derivados tengan distinto nombre o versión.

No discriminación a personas o grupos.

Sin uso restringido a campo de actividad.

Los derechos otorgados a un programa serán válidos para todo el
software redistribuido sin imponer condiciones complementarias.

La licencia no debe ser específica para un producto determinado.

La licencia no debe poner restricciones a otro producto que se distribuya
junto con el software licenciado.

La licencia debe ser tecnológicamente neutral.
11
Estándar abierto: según Bruce Perens, el basado en los principios de

Disponibilidad.

Maximizar las opciones del usuario final.

Sin tasas sobre la implementación.

Sin discriminación de implementador.

Permiso de extensión o restricción.

Evitar prácticas predatorias por fabricantes dominantes.
.
Software de dominio público: aquél que no está protegido con copyright
.
Software con copyleft: software libre cuyos términos de distribución no permiten
a los redistribuidores agregar ninguna restricción adicional cuando lo
redistribuyen o modifican, o sea, la versión modificada debe ser también libre
.
Software semi libre: aquél que no es libre, pero viene con autorización de usar,
copiar, distribuir y modificar para particulares sin fines de lucro
.
Freeware: se usa comúnmente para programas que permiten la redistribución
pero no la modificación (y su código fuente no está disponible)
.
Shareware: software con autorización de redistribuir copias, pero debe pagarse
cargo por licencia de uso continuado.
Software privativo: aquél cuyo uso, redistribución o modificación están
prohibidos o necesitan una autorización.
Software comercial: el desarrollado por una empresa que pretende ganar
dinero por su uso.
Permitiendo realizar sistemas de información, el software libre soluciona la
limitación de la secretaria de comunicaciones para realizar el proyecto, además
de ajustarse adecuadamente al proyecto se decide desarrollar la reingeniería
del sistema, con la ayuda de java. postgrest, jasperReport y Netneans.
12
1.3 ANTECEDENTES
El sistema de Control de Obras se encuentra disponible en la Página
de
Aplicaciones de la Intranet de la secom , por lo tanto los usuarios autorizados
de cualquier Dirección tienen acceso a ella para capturar y consultar la
información referente a las obras que llevan a cabo.
Cada módulo que conforma el sistema Control de Obras fue creado en el
departamento de tecnologías de la información de la SECOM.
El primer módulo del sistema fue creado en el año 2006 en la plataforma de
Delphi y Firebird es llamado control de proyectos, como un ajuste, surgió en el
mismo año el segundo sistema llamado cuentas liquidadoras, a pesar de su
ajuste era necesario contar con otro sistema que manejara y procesara la
información de manera adecuada, fue entonces creado el tercer sistema en el
año 2008 en las mismas plataformas que los anteriores llamado Control de
obras.
Al paso del tiempo surgieron nuevas necesidades, una de las primordiales fue
ampliar los reportes del sistema ajustándolos a las necesidades de jefatura, a
pesar de estos ajustes no se ha logrado maximizar el rendimiento del sistema.
Al llevar acabo el análisis de la situación actual del sistema se propone realizar
nuevamente el sistema, pero ahora con la plataforma de java y POSGRETST,
siguiendo un análisis más detallado se llega a un acuerdo, los módulos del
sistema realizan sus funciones adecuadamente, solo que es necesario cambiar
de plataformas, así como unificar los módulo, llegando a la misma conclusión
de retomar el sistema, partiendo de las funciones que realiza adecuadamente e
sistema con el fin de realizar una reingeniería del sistema.
1.4 OBJETIVOS
1.4.1 OBJETIVO GENERAL
Desarrollar la actualización del sistema Control de Obras aplicando la
reingeniería del software, Unificando las bases de datos en el SGBD
PostgreSQ desarrollando la aplicación en la plataforma de java e implementado
13
JasperReports para consultar información, de esta forma adaptar el sistema a
nuevos cambios.
1.4.2 OBJETIVOS ESPECÍFICOS

Analizar la situación actual del sistema de obras.

Identificar opciones de mejora en el servicio que brinda el sistema.

Rediseñar la interfaz del sistema.

Unificar el sistema de obras.

Optimizar la navegación web del sistema
14
15
CAPITULO II MARCO TEÓRICO
2.1 REINGENIERÍA DE SISTEMAS INFORMÁTICOS
El proceso de Reingeniería, es una teoría comúnmente aplicada en la
actualidad en las empresas, pero independientemente del término que asigne,
modernización, transformación y restructuración; el objetivo perseguido al
aplicarla es el mismo, aumentar la capacidad para competir en el mercado,
mediante la reducción de costos, ya sea en la producción de bienes o
prestación de servicios.
Uno de los reportes más importantes brindados por la reingeniería, es el de
enfatizar la necesidad cada vez mayor de competir, para que una empresa
alcance el éxito y sobreviva en el mundo de los negocios.
2.2 ¿QUÉ ES REINGENIERÍA DEL SOFTWARE?
Reingeniería del software se puede definir como: “modificación de un producto
software, o de ciertos componentes, usando para el análisis del sistema
existente técnicas de Ingeniería Inversa y, para la etapa de reconstrucción,
herramientas de Ingeniería Directa, de tal manera que se oriente este cambio
hacia mayores niveles de facilidad en cuanto a mantenimiento, reutilización,
comprensión o evaluación.”
Cuando una aplicación lleva siendo usada años, es fácil que esta aplicación se
vuelva inestable como fruto de las múltiples correcciones, adaptaciones o
mejoras que han podido surgir a lo largo del tiempo. Esto deriva en que cada
vez que se pretende realizar un cambio se producen efectos colaterales
inesperados y hasta de gravedad, por lo que se hace necesario, si se prevé
que la aplicación seguirá siendo de utilidad, aplicar reingeniería a la misma.
La reingeniería no es una actividad que se lleva a cabo en un corto tiempo ya
que requiere de esfuerzo, tiempo y recursos, es necesario planear una forma
de para ser desarrollar la reingeniería.
16
El desarrollo de la reingeniería del sistema Control de Obras se llevara a cabo
bajo el Modelo cíclico, que a continuación de describe detalladamente.
La reingeniería del software involucra diferentes actividades como son:
Análisis de inventarios
Reestructuración de documentos
Ingeniería inversa
Reestructuración de programas y datos
Ingeniería directa
2.3 PROPÓSITO
Con la finalidad de crear versiones de programas ya existentes que sean de
mejor calidad y los mismos tengan una mayor facilidad de mantenimiento.
La reingeniería ayuda a la evolución y mantenimiento del software para ello
generalmente se siguen los siguientes pasos para aplicar reingeniería:
Figura 2.1 Pasos de la reingeniería del software. Elaboración propia basada en (Verónica De la
Morena. 2009)
17
Metodología cíclica aplicada en la reingeniería
Figura 2.2 Método cíclico. Elaboración propia basada en (Verónica De la Morena. 2009)
2.4 ETAPAS DE LA REINGENIERÍA
La reingeniería basada en la metodología cíclica consta de 6 etapas, las cuales
a continuación se muestran con su breve descripción.
ANÁLISIS DE INVENTARIO
La recopilación de la información existente del sistema como:
Nombre de la aplicación Año en que se creó Cambios efectuados, fecha y
valoración del esfuerzo. Lenguaje y posible sistema (donde fue instalado)
Aplicaciones con las cuales tiene relación. Errores detectados Valoración de la
complejidad Calidad de la documentación, longevidad del proyecto Número
estimado de cambios Tiempo estimado de los cambios.
REESTRUCTURACIÓN DE DOCUMENTOS
La documentación débil es la marca de muchos sistemas heredados. ¿Pero
que se hace acerca de ellos? ¿Cuáles son las opciones? Crear documentación
consume mucho tiempo, si el sistema funciona vivirá con lo que tenga. La
documentación debe actualizarse pero se tiene recursos limitados. Se utiliza un
18
enfoque de “documentar cuando se toque”. El sistema es crucial para el
negocio y debe volver a documentarse por completo incluso en este caso un
enfoque inteligente es recortar la documentación a un mínimo esencial. Cada
una de estas opciones es viable. Una organización de software debe elegir la
más apropiada para cada caso.
INGENIERÍA INVERSA
Este término tiene sus orígenes en el mundo del hardware. Una cierta
compañía desensambla un producto de hardware competitivo en un esfuerzo
por comprender los “secretos” del diseño y fabricación de su competidor. Estos
secretos se podrán comprender más fácilmente si se obtuvieran las
especificaciones de diseño y fabricación del mismo. Pero estos documentos
son privados, y no están disponibles para la compañía que efectúa la ingeniería
inversa. En esencia, una ingeniería inversa con éxito precede de una o más
especificaciones de diseño y fabricación para el producto, mediante el examen
de ejemplos reales de ese producto.
La ingeniería inversa del software es algo similar. En la mayoría de los casos,
el programa del cual hay que hacer una ingeniería inversa no es el de un rival,
sino, más bien, el propio trabajo de la compañía. Los “secretos” que hay que
comprender resultan incomprensibles porque nunca se llegó a desarrollar una
especificación.
Consiguientemente, la ingeniería inversa del software es el proceso de análisis
de un programa con el fin de crear una representación de programa con un
nivel de abstracción más elevado que el código fuente.
La Ingeniería inversa es un proceso de recuperación de diseño. Con las
herramientas de la ingeniería inversa se extraerá del programa existente
información del diseño arquitectónico y de proceso, e información de los datos.
REESTRUCTURACIÓN DE CÓDIGO
El tipo más común de reingeniería es la reestructuración de código, se puede
hacer con módulos individuales que se codifican de una manera que dificultan
19
comprenderlos, probarlos y mantenerlos.
Llevar a cabo esta actividad requiere analizar el código fuente empleando una
herramienta de reestructuración, se indican las violaciones de las estructuras
de programación estructurada, y entonces se reestructura el código (esto se
puede hacer automáticamente). El código reestructurado resultante se revisa y
se comprueba para asegurar que no se hayan introducido anomalías. Se
actualiza la documentación interna del código.
REESTRUCTURACIÓN DE DATOS
La reestructuración de datos es una actividad de reingeniería a gran escala. En
la mayoría de los casos, la reestructuración de datos comienza con una
actividad de ingeniería inversa. La arquitectura de datos actual se analiza con
minuciosidad y se define los modelos de datos necesarios, se identifican los
objetivos de datos y los atributos, y después se revisa la calidad de las
estructuras de datos existentes.
Cuando la estructura de datos es débil (por ejemplo, actualmente se
implementan archivos planos, cuando un enfoque relacional simplificaría
muchísimo el procesamiento), se aplica una reingeniería a los datos.
Dado que la arquitectura de datos tiene una gran influencia sobre la
arquitectura del programa, y también sobre los algoritmos que lo pueblan, los
cambios en datos darán lugar invariablemente a cambios o bien de arquitectura
o bien de código.
INGENIERÍA DIRECTA
En un mundo ideal, las aplicaciones se reconstruyen utilizando un “motor de
reingeniería” automatizado.
En el motor se insertaría el programa viejo, que lo analizaría, reestructuraría y
después regeneraría la forma de exhibir los mejores aspectos de la calidad del
software. Después de un espacio de tiempo corto, es probable que llegue a
aparecer este “motor”, pero los fabricantes de CASE han presentado
20
herramientas que proporcionan un subconjunto limitado de estas capacidades y
que se enfrentan con dominios de aplicaciones específicos. Lo que es más
importante, estas herramientas de reingeniería cada vez son más sofisticadas.
La ingeniería directa no solo recupera la información de diseño a partir del
software existente, también utiliza esta información para alterar o reconstruir el
sistema existente con la finalidad de mejorar su calidad global. En la mayoría
de los casos el software sometido a reingeniería vuelve a implementar la
función del sistema existente y también añade nuevas funciones o mejoras.
2.5 VENTAJAS
Hacer reingeniería de un sistema software, según Ian Sommerville, tiene dos
ventajas clave sobre aproximaciones más radicales a la evolución del sistema:
l. Riesgo reducido. Existe un alto riesgo en volver a desarrollar software crítico
para los negocios. Pueden cometerse errores en la especificación, o puede
haber problemas en el desarrollo. Los retrasos en la introducción del nuevo
software pueden significar pérdidas en el negocio e incurrir en costes
adicionales. Por ejemplo, en 1999 una gran compañía de comida en Estados
Unidos tuvo retrasos en la introducción de un nuevo sistema de pedidos,
lo que condujo a retrasos en las entregas de productos valoradas en 100
millones de dólares en una estación de máxima venta.
2. Coste reducido. El coste de hacer reingeniería es significativamente menor
que el coste de desarrollar nuevo software. Ulrich (Ulrich, 1990) cita un ejemplo
de un sistema comercial en el que los costes de re implementación se
estimaron en 50 millones de dólares. Al sistema se le aplicó reingeniería con
éxito por 12 millones de dólares. Se presume que, con la tecnología moderna
del software, el coste relativo de la re implementación
probablemente sea
menor.
21
CAPITULO III. REINGENIERÍA DEL SISTEMA
CONTROL DE OBRAS.
3.1 ANÁLISIS DE INVENTARIO DEL SISTEMA: Control
de Obras
La forma para recabar información pertinente de los tres módulos del sistema
Control de Obras, se obtuvo mediante la búsqueda en cada archivo acerca del
sistema Control de Obras en la pc de la administradora y creadora del sistema
actual Xochilth Utera, de lo cual se obtuvo los manuales de usuario, minutas,
oficios de juntas realizadas sobre nuevas peticiones y modificación del sistema,
reportes, de cada módulo que conforma el sistema así como el procedimiento
de contratación de las obras, el flujo de información en SISCO y finalmente se
realizó una entrevista con la creadora e administradora del sistema obteniendo
los siguientes documentos:
Figura 3.1 Flujo de información SISCO. (SECOM 2013)
A continuación se muestra la imagen del procedimiento para la contratación de
una obra.
23
Proceso para la contratacion de una obra
Figura 3.2 Procedimiento de contratación. (SECOM 2013)
A continuación se muestra el diseño de los datos del módulo Cuentas
liquidadoras, que se encuentra en la base de datos Institucional.
DIAGRAMA DE RELACIÓN DE TABLAS EN MODULO CUENTAS
LIQUIDADORAS
CTALIQ COMPROMETIDAS
PROYECTOS
CAT DEDUCCIONES
CTALIQ
DEDUCCIONES
Figura 3.3 Relación de tablas del módulo cuentas liquidadoras. ( SECOM 2013)
24
A continuación se muestra el diseño de los datos del módulo Cuentas
liquidadoras, que se encuentra en la base de datos Institucional, la siguiente
figura muestra el esquema en que es almacena la información del módulo.
DIAGRAMA DE RELACIÓN DE TABLAS DEL MODULO CONTROL DE
PROYECTOS
EGAB5
EGAB6
AVANCEFISICO
FONDO
AV_FISAUTO
UNIDAD
EGAB1
PROYECTOS
CTALICQ
OBR_PROYEC
SECTOR
DCTOSPROY
CAT_LOCALIDAD
EGAB3_REGION
EGAB2
EGAB2_GRUPOREGI
O
EPP1_BRUPO_PROG
_PRIOR
EPP2_PROG_PRIOR
EPP3_PROG_PRIOR
_PROY
OBR_HISTORIAL
SUBPROG
SUBSUBPROG
EGAB3
OBR_HISTORIAL_FECHAS
CP_SITUACION_FIN
PROG
EGAB5_REGION_M
UN
PROY_CLASIF
FOTOS_PROY
SUBSEC
EGAB4
CAT_MUN
PARTIDO
CAT_DIST_EST
CAT_DIST_FED
Figura 3.4 Relación de tablas del módulo Control de proyectos (SECOM. (2013)
25
Los datos que continuación se muestran son específicos del módulo Control de
Obras, debido a que es el modulo principal del sistema, la información
encontrada sobre los tres módulos es considerable, así que se opta por solo
mostrar un panorama de los tres módulos y describir detalladamente el módulo
de Control de Obras.
El módulo Control de Obras fue creado en el año 2008 en la plataforma de
Delphi y FirebirdEl, se encuentra disponible en la página de aplicaciones de la
Intranet de esta Dependencia, los usuarios autorizados de cualquier Dirección
tienen acceso para capturar y consultar la información referente a las Obras
que se llevan a cabo.
Los usuarios de cada dirección están capacitados para capturar información
así como el acervo fotográfico de las obras, manipulando únicamente las obras
que les corresponden por diferentes criterios de búsqueda, exportarla a Excel o
imprimir los reportes que ya se encuentran disponibles.
El sistema de Control de Obras cuenta con los submódulos de captura de las
Obras del POA, 2% a la Nómina y Fonden, Módulo de captura de Fotos,
Módulo de Consultas y Reportes.
En el Submódulo de Captura de Obras se almacenan los Datos Generales,
Datos Financieros, Datos de Impacto y situaciones problemáticas que se
pudieran presentar ocasionando el atraso de las obras, el historial de la Obra
cuando es Multianual, las Fichas Técnicas, las Cuentas Liquidadoras, el Fondo,
las obras complementarias y un historial presupuestal. A continuación se
muestra gráficamente un ejemplo de cómo está compuesto este módulo.
SUBMÓDULO DE CAPTURA:
En este submódulo se capturan los datos generales de las obras como: nombre
de la obra, numero de obra, tipo de obra, ubicación de la obra, datos de la
empresa constructora de la obra etc.
La siguiente imagen muestra la pantalla de captura del módulo control de
obras:
26
Figura 3.5 Submódulo captura (SECOM 2013)
En la siguiente pantalla se muestra la captura de los datos financieros de la
obra como lo son el monto cobrado de la obra, el avance de la obra con
respecto a su financiamiento, fondos etc.
Figura 3.6 Submódulo captura2. Fuente: SECOM (2013)
27
SUB MODULO CAPTURA DE FOTOS:
La parte de capturas de fotos nos muestra las fotos que se tienen del estado de
la obra.
Figura 3.7 Submódulo captura de fotos (SECOM 2013)
SUB MODULO DE CONSULTAS Y REPORTES:
En esta parte del sistema se pueden realizar búsquedas a través de diferentes
criterios como se muestra en la siguiente imagen, se puede exportar la
información consultada a Excel, visualizar las fotos que contenga la obra e
imprimir los reportes disponibles en el listado.
Figura 3.8 Submódulo de consultas y reportes SECOM (2013)
28
REPORTES:
Listado de los reportes disponibles en el sistema de Control de Obras.
Figura 3.9 Listado de reportes ( SECOM 2013)
MODULO CONTROL DE OBRAS
OBJETIVO:
Llevar un registró detallado de todas las obras que realizan las diferentes
direcciones de la secom.
DESCRIPCIÓN:
Esta aplicación consta de una pantalla de acceso de usuario, la pantalla de
captura donde se carga y actualiza la información de cada contrato, así como
una pantalla para la captura de contratistas, los proveedores y los convenios
realizados.
PREFIJO: COMPA
MANUAL: \\database-a\sii\manuales sistemas en pdf\obras
29
A continuación se muestra el diseño de los datos que almacena el módulo
Control de Obras, esta información se encuentra en la base de datos compare,
a cargo de la DGT, al comparar la siguiente estructura del módulo, con las
anteriores, se puede observar que existen tablas repetidas en varias ocasiones,
datos desusados, esto es a falta de un registro de las modificaciones que ha
sufrido este diseño, así como de la modificación de este , además de una
estructura que carece de información.
DIAGRAMA DE RELACIÓN DE TABLAS DEL MODULO CONTROL DE OBRAS
CONTRA_CONTRATISTAS
COMPA_OBRAS
SUBSEC
COMPA_FONDEN
PROG
COMPA_CONTRATISTAS
COMPA_CAT_EVEN
TOS
COMPA_FONDOS_OBRA
COMPA_FONDEN_ESTIMA
SUBPROG
COMPA_HIST_PRES
UPUESTAL
COMPA_CAT_TIPO_OBRA
CAT_MUN
COMPA_SUSTITUCI
ON
COMPA_FOTOS
COMPA_CAT_CONT
RATISTAS
COMPA_USUARIOS
COMPA_REFRENDO
COMPA_MODALIDA
D
Figura 3.10 Relación de tablas del módulo control de obras. Fuente: SECOM (2013)
La siguiente figura nos muestra la relación de tablas del módulo control de
obras y su breve descripción, podemos observar que el diseño y la relación no
concuerdan, esto es debido a que no se actualizo la información de los
cambios que se le realizaron al sistema durante su periodo de vida,
30
Orden
Nombre
Descripción
0
SUBSEC
Tabla de Direcciones.
0
PROG
Catálogo de Programas.
0
SUBPROG
Catálogo de Subprogramas.
0
EG_ESTADOS
Catálogo de Estados
0
CAT_MUN
Catálogo de Municipios
0
CONTRA_CONTRATISTAS
Catálogo de contratistas.
1
COMPA_USUARIOS
Tabla que contiene los usuarios del sistema.
2
COMPA_CAT_CONTRATISTA
Catálogo de origen de los recursos.
3
COMPA_CAT_TIPO_OBRA
Catálogo que contiene los diferentes tipos de obra.
4
COMPA_CONC_TIPO
-
5
COMPA_CONTRATISTAS
Catálogo de contratistas, se utiliza en la captura de las obras
del 2%
6
COMPA_REFRENDO
Catálogo de valores que toman las obras refrendadas.
7
COMPA_OBRAS
Tabla donde se almacenan las obras pertenecientes al POA,
PRODEPI y 2%.
8
COMPA_FOTOS
Tabla donde se almacenan las fotos de todas las obras.
9
COMPA_FONDOS_OBRA
Tabla donde se guarda la información en caso de que las
obras tengan más de un fondo.
10
COMPA_HIST_PRESUPUEST
AL
Tabla donde se almacena la información de las
ampliaciones, reducciones y sustituciones que se aplican en
el presupuesto de las obras.
11
COMPA_SUSTITUCION
Tabla donde se detallan las sustituciones.
12
COMPA_EVENTOS
Catálogo de eventos que se ocupara exclusivamente en la
captura de obras del FONDEN.
13
COMPA_FONDEN
Tabla donde se almacenan las obras del FONDEN.
14
COMPA_FONDEN_ESTIMA
Tabla donde se guardan los datos referentes a las
estimaciones de las obras del FONDEN.
15
COMPA_ MODALIDAD
Catálogo de las combinaciones que existen de los campos
tipo y modalidad.
Tabla. 3.1 Relación y descripción de cada tabla del módulo control de obras (SECOM 13)
Las siguientes tablas nos muestran los datos que componen cada tabla de la
base
de
datos
COMPARE
del
Sistema
Control
de
Obras
31
TABLE
COMPA_CAT_CONTRATISTA
TABLA COMPA_CONTRATISTAS
NOMBRE
NOMBRE
ID
ID_CONTRA
CLV_PROY
CONTRATISTA
REPRESENTANTE_LEGAL
DOMICILIO
EMPRESA
NO_CONTRATO
TELEFONOS
NO_FIANZA
CIUDAD
IMPORTE
ESTADO
FECHA_INI
RFC
FECHA_FIN
TIPO_EMPRESA
Tabla 3.5 Contratista (SECOM 2013)
REGION
Tabla 3.2 Catalogo contratista (SECOM
(2013)
TABLE COMPA_USUARIOS
NOMBRE
TABLE
COMPA_CAT_TIPO_OBRA
NOMBRE
ID_TIPO
DESCRIPCION
Tabla 3.3 Catalogo tipo obra (SECOM
2013)
USUARIO
CLAVE
CLV_SUBSEC
CAPTURA
BUSQUEDA
CONSULTA
SUPER
TABLA COMPA_CONC_TIPO
FONDEN
NOMBRE
Tabla 3.6 usuarios
CVETIPO
(SECOM (2013)
CVE_CONC_TIPO
DESCRIPCIÓN
Tabla 3 4 Ccompa conc tipo (SECOM
2013)
32
CREATE TABLE COMPA_OBRAS
CLV_PROY
FONDO
IMPACTO8
TITULAR
NO_OBRA
BENEFICIARIOS
DESC8
SUPERVISOR
NOMBRE_OBRA
AUDITADA
IMPACTO9
TIPO_ADJUDICACIÓN
LONGITUD
AUDITOR
DESC9
PROBLEMATICA10
EMPRESA
VIDA_UTIL
IMPACTO10
TIPO_EMPRESA
AV_FIS
SOLICITUD
DESC10
OBSERV_BENEFICIOS
AV_FIN
IMPACTO1
IMPACTO11
FECHA_SOLIC
F_I_PROG
DESC1
DESC11
REGION
E_T_PROG
IMPACTO2
IMPACTO12
DISTRITO
F_I_REAL
DESC2
DESC12
PROG
F_T_REAL
IMPACTO3
PROBLEMATICA1
SUBPROG
CVEMUN
DESC3
PROBLEMATICA2
SUBSUBPROG
MUNICIPIO
IMPACTO4
PROBLEMATICA3
NUM_CONTRATO
CLV_SUBSEC
DESC4
PROBLEMATICA4
TIPO
DESCRIP_SUBSEC
IMPACTO5
PROBLEMATICA5
MODALIDAD
TRAMO
DESC5
PROBLEMATICA6
NO_ACUERDO
OF_TOTAL
IMPACTO6
PROBLEMATICA7
EJERCIDO
OF_FEDERAL
DESC6
PROBLEMATICA8
POR_EJERCER
OF_ESTATAL
IMPACTO7
PROBLEMATICA9
MONTO_REFRENDO
OF_MUNICIPAL
DESC7
OBSERVACIONES
MONTO_CONTRATADO
AUDITOR2
ANTICIPO
AMORTIZACIÓN
PORC_AMORT
META
CLV_UNIDAD
CATEGORÍA
ESTATUS
CLV_PROY2
TIPO_OBRA
NO_OBRA2
MONTO_GLOBAL
FECHA_MODIF.
USUARIO_MODIF.
CLV_PROY3
EJERCICIO
REFRENDO
CONTRATADA
NUM_FOTOS
OBSERVACIONES_OB
RA
AREA
ANTI_FACT
ANTI_FOLIO
ANTI_STATUS
CVE_TIPO
MONTO_PAGADO
MONTO_POR_PAGAR
ANTI_DOCUMENTAC
IÓN
PERIODO_EJEC
PRESUP_AUTORIZAD
O
ACCIONES
NO_EVENTO
MONTO_CONVENIO
DIAGNOSTICO
PEF
ANO_EVENTO
NO_OBRA_FONREGIO
N
PORC_AMORT_EST
POBLACIÓN
MONTO_MULTIANUA
L
DISTRITO_FEDERAL
NO_OBRA_ADICIONAL
MONTO_SIN_CONTRAT
AR
COMENTARIO
PARTIDO_PRES
DESCRIP_PROG
OF_TOTAL_EST
MONTO_CONTRATAD
O_EST
POR_EJERCER_EST
MONTO_SIN_CONTRAT
AR_EST
MONTO_CONVENIO_ES
T
FONDO_SUSTI
EJERCIDO_EST
MONTO_REFRENDO_ INV_ACUM
EST
Tabla 3.7 Compa obras (SECOM 2013)
MONTO_ACUM
33
TABLA COMPA_FOTOS
NOMBRE
CLV_PROY
NUM_OBRA
ID_FOTO
DESCRIP
FOTO
ESTATUS
FECHA
MARCA
ORDEN
Tabla 3.8 Compa fotos (SECOM 2013)
TABLA
COMPA_HIST_PRESUPUESTAL
NOMBRE
ID_MOVTO
FOLIO
NO_OFICIO
FECHA
NO_TRANS
STATUS
CLV_PROY
TIPO_MOVTO
TIPO_OBRA
MONTO_MOVTO
MONTO_HISTORIAL
Tabla 3.10 Compa presupuestal (SECOM
2013)
TABLA COMPA_FONDOS_OBRA
NOMBRE
TABLE COMPA_SUSTITUCION
CLV_PROY
NOMBRE
FONDO
ID
FECHA_INI
CLV_PROY
FECHA_FIN
FONDO
SALDO
MONTO
ID
ID_MOVTO
Tabla 3.9 Compa fondos obra (SECOM
2013)
FONDO_ANT
Tabla 3.11 Compa sustitución (SECOM
2013
34
TABLA COMPA_FONDEN
ID
EMPRESA
ANTI_FOLIO
EJERCICIO
NO_CONTRATO
PROG
CLV_SUBSEC
MONTO_CONTRATO
SUBPROG
DESCRIP_SUBSEC
AV_FIS
SUBSUBPROG
NO_EVENTO
AV_FIN
DIST_ELECTORAL
NO_OBRA
CAMINO
TRAMO
MUNICIPIO
ANTI_FACT
AREA
CVE_TIPO
INV_AUTORIZADA
PRESUP_AUTORIZADO
MONTO_PAGADO
MONTO_POR_PAGAR
FECHA_CONT_INI
FECHA_CONT_FIN
FECHA_DIF_INI
FECHA_DIF_FIN
ANTI_MONTO
MONTO_EJERCIDO
STATUS
ANTI_DOCUMENTACION
ACCIONES
POBLACIÓN
DIAGNOSTICO
PERIODO_EJEC
CVEMUN
REGION
ANTI_STATUS
Tabla 3.12 Cumpa fonden ( SECOM 2013)
TABLA COMPA_MODALIDAD
TABLA COMPA_CAT_EVENTOS
NOMBRE
NOMBRE
TIPO
EJERCICIO
MODALIDAD
NO_EVENTO
DESC_TIPO
NOMBRE
DESC_MODALIDAD
PERIODO
Tabla 3.13 Compa modalidad( SECOM 2013)
Tabla 3.14 Catalogo eventos (SECOM 2013)
TABLA COMPA_FONDEN_ESTIMA
ID_ESTIMA
ID
MONTO
FOLIO
STATUS
FACTURA
ETAPA
MONTO_ETAPA
CANCELADO
RENUNCIA_ANTI
LICITA
NO_PRESENTA
FALTA_DOCU
NO_ESTIMA
Tabla 3.15 Fonden estima ( SECOM 2013)
35
3.1.1 FORMULACIÓN DEL PROBLEMA.
La plataforma de Delphi y Firebird en la que fue desarrollado cada módulo del
sistema Control de Obras es antiguo, requiere de un amplio conocimiento en su
manejo y cabe señalar que actualmente existe muy poca información sobre
este lenguaje , por lo que complica el manejo del sistema.
Otro rasgo importante de mencionar es que el sistema fue desarrollado
únicamente para pc de 32 bits lo que imposibilita instalar el sistema en pc de 64
bits, al pretender cambiar componentes para ajustar el sistema a pc de 64 bits
se estimó un tiempo aproximado a 3 meses para dicha realización esto significa
mucho tiempo perdido ya aunque este cambio se realice el sistema sigue
teniendo diversos problemas.
Los módulos se encuentran en distintas ubicaciones, pero lo más complejo no
son los módulos distribuidos, sino que la información se maneja en diversas
bases de datos, por lo tanto la información que se reúne en los módulos de
Control de proyectos y cuentas liquidadoras alimentan la base de datos
institucional, así que para alimentar el módulo de Control de Obras se recurre a
exportar e importar los datos a la base de datos institucional a la base de datos
Compare. Este proceso complica tener la misma información de las obras en
los 3 módulos del sistema y facilita sobre todo la duplicidad de los datos,
utilizando recursos innecesarios en cuanto al almacenamiento en la base de
datos.
Con respecto a los reportes del sistema son estáticos, la plataforma complica la
modificación de su contenido y formato.
La información obtenida de minutas y reuniones es la siguiente:

Se acordó que es necesario homologar el tipo de reporte q las
ejecutoras entregan a Fonden y a Jefatura.

El nombre de la obra se va a homologar de acuerdo a la información con
la que cuenta Fonden.

Las ejecutoras deberán enviar el reporte impreso a Fonden, Fonden
alimentara el sistema con la información de los reportes y validará que
sea la misma que están en el sistema.
36

Las ejecutoras subirán avances físicos, financieros y fotos.

Se almacenaran 6 fotos por cada obra, una de las cuales debe mostrar
el anuncio con la información de la obra.

En los formatos del sistema deberá tener los logos y tipo de letra de la
imagen institucional.

Se deberá integrar las obras de Maver y de la JEC.

Adecuar el sistema para que cada área meta la información que le
corresponde y validar las restricciones por usuario para que se guarde el
usuario que actualizo la información.

La Dirección Jurídica y U. de Licitaciones deberán integrarse para la
captura de obras 2011.

Adecuar el sistema para que dé el número de contrato de manera
automática. Validar en el sistema que el monto contratado sea menor al
monto autorizado, así como los avances físico y financiero debe ser
mayor al anterior.

Las ejecutoras deberán capturar las estimaciones.

Validar en el sistema que el monto contratado sea menor al monto
autorizado, así como los avances físico y financiero debe ser mayor al
anterior.

Almacenar en el sistema la carátula del contrato de obra y el
presupuesto, y licitaciones debería de digitalizar el documento donde fue
contratado.

Al revisar filtros quedaron pendientes:
DISTRITO FEDERAL
FECHA INICIO, TERMINO PROGRAMADA (RANGO)
FECHA INICIO, TERMINO REALES (RANGO)
PARTIDO POLÍTICO
BUSCAR REPORTEADOR que lo mande a PDF.

Todas las direcciones tendrán acceso al sistema de control de obra
(SISCO).

En las estimaciones que no se han pagado en estatus poner que están
en dirección.

Ordenar dependiendo de la celda que le des clic.
37

Tipo de letra Stone.

Que se imprima la búsqueda principal, exportar a pdf y poner logotipos.

Acomodado alfabéticamente por municipio y luego por camino.

Monitorear periódicamente la información almacenada en la Base de
Datos de manera correcta para tenerla actualizada.
La información relevante de la entrevista que se realizó con los Enlaces
(usuarios) del sistema es la siguiente:
1.- ¿Cuáles son los problemas más frecuentes que presenta su sistema de
obras?

Difícil de acceder al sistema debido a la red.

Salir y entrar de un módulo a otro (Consulta-módulo de obras).

Pasar de una ficha a la otra(no es dinámico)

Los reportes contienen información insuficiente.

Es lento.

Problemas al Exportar a Excel.

Es lento al cargar fotos.

Complejo en su navegación

No actualiza cambios realizados.

No es visible toda la información de la obra en captura de fotos, cuando
esta es extensa.
2.- De los problemas mencionados anteriormente, ¿cuál es el que se presenta
con mayor frecuencia?

Complejo en su navegación.

La poca visibilidad de la información en captura de fotos.
3.- ¿Cuáles son las frustraciones más grandes que ha experimentado durante
el uso del sistema de obras?

Las observaciones de la obras no están de acuerdo con la información
de la obra.

Enumerar las obras.

Los reportes omiten datos solicitados.
38

Su lentitud.

Realizar cambio de fecha.
4- ¿Cuántas veces por semana utiliza el sistema de obras?

2

Toda la semana, pero debido a la red solo 2 días de pudo acceder

Diario

2 consultas por semana

En caso de captura 3 días seguidos
5.- Tiene quejas sobre el sistema de obras? ¿Cuáles?

Las obras no están enumeradas.

El funcionamiento de las fichas.

La Información de estimaciones está incompleta.
6.- ¿Está de acuerdo con el funcionamiento del sistema?

Si
7.- ¿Cuánto tiempo lleva utilizando el sistema de obras?

Mes y medio.

Más de 6 meses.

Un año
8.- ¿Necesita información que el sistema no te ofrece?

Filtrar nombre de los caminos

Filtrar distritos federales

Si, cuando no está actualizada la información.
9.- ¿Qué opinas de la apariencia del sistema de obras?

La información está muy amontonada.
10.- Dígame un poco de los resultados que le gustaría ver

Informar en qué dirección se encuentra el contrato de obra.

Mejor elaboración de las consultas.
39

La información del sistema este adecuada para los cargos superiores,
así como adaptar el sistema para estos cargos.

Actualización de facha automática.

Ajustar fichas de acuerdo a las peticiones de jefatura.

Reportes ajustados a sus necesidades y con imagen más amigable
11.- ¿Hay alguna decisión acerca de la cual usted necesite más información en
el sistema de obras para tomarla? ¿Cuál?

Situación actual del contrato.

Si, los resultados totales de las obras
12.- ¿Qué información en tu opinión es irrelevante en el sistema de obras?

Avances físicos y financieros (dirección de caminos rurales)

Mensaje de confirmación al guardar.

Los estatus de los pagos de estimaciones (para coordinación de
Fonden)

Reportes por contratista, por empresas, existen una cantidad de
reportes que no se utilizan.(para unidad administrativa)
13.- ¿Tienes problemas al imprimir reportes o importar en Excel?

Las importaciones en Excel no son de manera correcta, exporta
información que no se utiliza y en desorden.

Si, los documentos en Excel muestran datos no solicitados.

Lento.
14.- ¿En promedio cuantos reportes utilizas?

Cuatro

2
15.- ¿Cómo te gustaría que fueran los reportes?

Ajustados a los reportes propuestos-Contraloría

Reportes ajustados a sus necesidades y con imagen más amigable.
40
3.1.2 ANÁLISIS FODA
El análisis FODA Permite resolver dos preguntas: ¿qué tenemos? ¿en dónde
estamos?
Así que se realizó el siguiente análisis de acuerdo a la situación del sistema
Control de Obras, para contar con un panorama de las ventajas y desventajas
con las que cuenta el sistema, este análisis es de gran ayuda para visualizar el
funcionamiento del sistema.
FORTALEZAS
OPORTUNIDADES
DEBILIDADES
AMENAZAS










Registro de datos generales de obras las obras de manera correcta.
Operaciones efectuadas de manera correcta.
Contiene amplia información de cada obra.
Disponibilidad de manuales del sistema para los usuarios.
Requerimientos proporcionados por los usuarios.
Interés por el servicio de parte de los usuarios y de la empresa.
Trabajo de trabajo.
Comunicación con los usuarios del sistema.
Facilidad de recursos para su funcionamiento.
Personal con conocimientos adecuados para su administración.







Apoyo de parte de jefatura para su desarrollo tecnológico e novador.
Capacitación de personal en herramientas actuales de tecnología.
Personal con iniciativa al cambio.
Recursos para su desarrollo.
Recursos para su implementación.
Posibilidad de migración de datos.
Personal capacitada para diseñar tanto las modificaciones del
sistema, como a diseñar el formato de los reportes.


Información distribuida en diversas fuentes de datos.
Plataforma de desarrollo sin actualizaciones de desarrollo
tecnológico.
Poca información del lenguaje de desarrollo.
La base de datos no es un SGBD innovador y actualizado.
Los usuarios no tienen conocimientos informáticos.
El sistema es administrado solo por una persona.
Solo una persona comprende ampliamente el Funcionamiento total
del sistema.








Solo una persona está capacitada para realizar cambios en el
sistema.
No se cuentan con recursos económicos.
Información distribuida.
Tabla 3.16 Análisis FODA (Elaboración propia)
41
3.1.3 ANÁLISIS GENERAL DEL SISTEMA
La información obtenida del DGT nos permite realizar el siguiente análisis
general del sistema control de obras, este análisis nos admite tener un
perspectiva de la realidad en la que se halla el sistema, sus puntos débiles, así
como su buen funcionamiento, este análisis es a fin de definir los nuevos
requerimientos:
ASPECTO
Tamaño
Interfaz
Complejidad
APRECIACIÓN
DESCRIPCIÓN
Grande
El sistema es algo extenso, abarca todos los
ámbitos de cada obra.
Regular
Alta
Documentación
Adecuada
Tamaño de BD
Muy grande
Funcionalidad de
BD
Información
verídica
Ambiente de
errores o
modificaciones
Mala
Muy Confiable
Malo
Registro de
actualizaciones
No existe
Soporte
Casi siempre
Desempeño
Bueno
La interfaz contiene mucha información en cada
pantalla y a su vez esta información está muy
acumulada, además de no ser nada dinámica
.
El sistema maneja demasiada información, de
manera que es necesario tener conocimiento de la
información que se maneja para poder entender el
sistema.
La cantidad de información es apropiada para
tener conocimiento sobre el funcionamiento del
sistema.
La estructura de la base de datos de los tres
módulos es demasiado extensa.
La base de datos publica mucha información casi
en un 50%, además de que existen datos que no
tienen ninguna funcionalidad dentro de la base de
datos y sobre todo en el sistema.
La información en algunos casos no es actual,
pero si verídica ya que la información es
procesada antes de ser capturada.
Realizar cambios al sistema significa tiempo y
esfuerzo debido a la plataforma en que se
encuentra, es muy complejo realizar cambios
esperados.
No se lleva un registro de los cambios que se le
realizan al sistema por parte de la administradora
del sistema.
Continuamente los usuarios requieren de soporte
base al poco conocimiento en tecnología que se
tiene.
El desempeño en general del sistema es bueno
realiza las funciones adecuadamente, el único
42
inconveniente es el tiempo
dichas funciones.
El sistema permite el
dependiendo del perfil del
las acciones que puede
sistema.
que tarda en realizar
acceso al sistema
usuario, restringiendo
realizar dentro del
Seguridad
Muy bueno
Interfaces
Regular
La apariencia del sistema es poco amigable,
dinámica e incluso suele ser rígida.
Susceptible al
cambio(código)
Regular
El procedimiento para realizar un cambio a nivel
código es posible aunque complejo.
Tiempo de
respuesta
Malo
Frecuencia de
errores
Regular
Al realizar una modificación o alguna petición
demorada mucha la respuesta para el usuario
.
Los errores se presentan continuamente al
mostrar cambios realizados pero sobre todo en
los reportes y exportaciones.
Importancia para la
SECOM
Alta
La importancia de este sistema para la SECOM es
vital, es el punto de referencia hacia la toma de
decisiones por parte del secretario, además de
administrar los recursos de cada obra en el
estado.
Respaldos de
información
Mala
No se cuenta con un respaldo en caso de estar en
riesgo ante la pérdida de información o afectación
al sistema.
Regular
Los reportes son estáticos, así que no permite que
el usuario personalice reportes el usuario tiene
que realizar manualmente los reportes que no
brinda el sistema, además de presentar
información obsoleta
Mala
La exportación que brinda el sistema es
únicamente a Excel, carece de exportación en
diversos formatos, además de mostrar información
no solicitada.
Mala
La carga de las fotos de la obra son muy tardadas
tanto al ser almacenarlas como al ser consultadas
y sobre todo exportadas.
Reportes
Exportación
Carga y consulta
de fotos
El acceso a la aplicación se realiza de manera
adecuada, sin embargo cuando el internet falla es
poco probable poder acceder a ella.
Acceso al sistema
Regular
Aplicación de
estándar (código)
Malo
El código no tiene un estándar en cuando a
declaraciones de variables lo que complica su
comprensión.
Malo
Los campos que se refieren a la misma
descripción, en ocasiones son utilizados con
diferentes nombres, ocasionando ambigüedad en
los datos.
Aplicación de
estándar (DB)
Tabla 3.17 Análisis general (Elaboración propia)
43
Con la anterior evaluación se puede observar que el funcionamiento del
sistema es adecuado, el
inconveniente que se presenta, es el tiempo de
respuesta, reportes, exportaciones y base datos.
Por lo que se llega al acuerdo de realizar una reingeniería principalmente en la
base de datos, interfaz, reportes, accesibilidad y una nueva plataforma de
desarrollo que brinde mejores oportunidades de cambio a fin de tener un
sistema actual en cuanto a tecnología, además de ser capaz de ofrecer
información en tiempo y forma. Ayudando así a tener un panorama amplio
desde cualquier punto las actividades que se realizan en todo el estado.
3.2 RESTRUCTURACIÓN DE DOCUMENTOS
Partiendo de la información recabada sobre el sistema Control de Obras, se
concluye que el sistema cuenta con los documentos necesarios para el
conocimiento de cada módulo en específico, pero no existe ningún documento
que generalice la información, no existe información del panorama de todo el
sistema.
Es necesario realizar diagramas UML y casos de uso para visualizar tanto el
funcionamiento del sistema en general, como el intercambio de datos entre los
módulos del sistema.
3.3 INGENIERÍA INVERSA
La información obtenida del inventario del sistema es la base del diseño del
siguiente caso de uso, el cual nos muestra los personajes que interactúan en el
sistema, así como su función dentro del mismo.
El diagrama Casos de uso permite visualizar las funciones de cada usuario
dentro del sistema a fin de obtener un panorama y comprensión completa del
funcionamiento del sistema.
El siguiente caso de uso muestra cómo se encuentra el sistema, como
interactúan los diferentes módulos en el sistema, así como las funciones que
dependen de otros usuarios.
44
Figura 3.11. Casos de uso Ingeniería inversa (Elaboración propia)
45
En el caso de uso anterior se muestran las funciones y permisos de cada
usuario del sistema. Asi mismo muestra el rol de los modulos cuentas
liquidadoras y control de proyectos el en momento en que el modulo de control
de obras requiere informacion de obras POA Y 2%, a fin de que el usuario final
pueda consulta todas las obras que requiera.
3.3.1 UML
Aun que se tenga conocimiento del funcionamiento del sistema, otro punto
importante son los datos que maneja el sistema y el estado en el que se
encuentran, asi que se recabo el siguiente diseño UML.
UML es un lenguaje unificado de modelado (uml) es un lenguaje gráfico para
visualizar, especificar, cnstituir y documentar los artecfactos de un sistema de
software intencivo.
El UML ofrece una forma estándar de escribir los planos de un sistema,
incluyendo conceptuales cosas tales cmo los procesos de negocio y funciones
del sistema, asi como cosas concretas, como las declaraciones del lenguaje de
progracion, esquemas de bases de
datos y software reutilizables
componentes.
Algunos de los beneficios que nos brinda UML son los siguientes:

Mejores tiempos totales de desarrollo (de 50 % o más).

Modelar sistemas (y no sólo de software) utilizando conceptos
orientados a objetos.

Establecer conceptos y artefactos ejecutables.

Encaminar el desarrollo del escalamiento en sistemas complejos de
misión crítica.

Crear un lenguaje de modelado utilizado tanto por humanos como por
máquinas.

Mejor soporte a la planeación y al control de proyectos.

Alta reutilización y minimización de costos.
46
El diseño UML obtenido en la figura siguiente es el diseño que actualmente
representa el funcionamiento del sistema control de obras, como el
funcionamiento del sistema marcha correctamente no se
le realizaran
modificaciones. El siguiente UML, nos muestra la infromacion de los atributos
de cada usuario, las funciones que puede realizar, la clasificacion de obras, los
permisos de cada usuario asi como los datos generales de las obras.
Figura 3.12 Modelo unificado de objetos (Elaboración propia)
47
3.3.2 MODELO FISICO DE DATOS.
Es una reprensentación de la estructura de los datos que se almacenan en el
SGBD Firebird, con respecto a los tres modulos del sistema y a las dos bases
de datos en la que estas se almacenan.
Con los datos obtenidos de la base de datos institucinal y Compare se pudo
realizar el siguiente Modelo fisico de datos, con el fin de visualizar el estado en
el que se encuentran los datos, como interaccionan las dos bases de datos,
cabe señalar que las tablas se relacionan entre sí en cada base de datos, se
realizo dos modelos fisicos de datos para posteriormente analizar a fondo el
funcionamiento de cada dato que se almacenan en las tablas, así como la
forma de relacionarse.
Gracias a este modelo podemos observar los datos que se duplican, los datos
que no tienen ninguna funcion y determinar el nuevo funcionamiento de los
datos en la base de datos COMPARE bajo el sistema gestor de base de datos
posgrest.
El primer modelo es sustraido gracias a la lic. xochitlh Utera Administradora de
la base de datos COMPARE, donde se muestran los datos que maneja el
modulo de control de obras, en el cual participan los siguientes usuaios:

COORDINACION FONDEN

JEFATURA

DIRECCION GENERAL DE PLANEACION

DIRECCION GENERAL DE COMUNICACIONES

DIRECCION EJECUTORA
El segundo modelo fisico
muestra del los modulos control de proyectos y
cuentas liquidadoras que maneja unicamente el usuario Unidad administrativa,
tambien son los datos que son exportados de la base de datos institucional a
COMPARE, en esta estructura nos muestra las incurrecias que se tienen y el
origen de la saturacion del sistema al realizar una consulta de las obras, la
informacion que se muestra no cuenta con actualizacion y veraciodad al ser
presentada al usuario y el principal problemas se puede constatar en las
siguientes estructuras.
48
Figura 3.13 Modelo COMPARE (Elaboración propia)
49
Figura 3.14 Modelo institucional (Elaboración propia)
50
CAPITULO IV. REINGENIERÍA HACIA ADELANTE
DEL SISTEMA CONTROL DE OBRAS
4.1 CAPTURA DE REQUERIMIENTOS.
Los requerimientos son declaraciones que identifican atributos, capacidades,
características y/o cualidades que necesita cumplir el sistema para el usuario.
Los requerimientos muestran qué elementos y funciones son o no son
necesarias para un proyecto.
Los requerimientos puedes dividirse
en requerimientos funcionales
y
requerimientos no funcionales. Los requerimientos funcionales definen las
funciones
que
el
sistema
será
capaz
de
realizar.
Describen
las
transformaciones que el sistema realiza sobre las entradas para producir
salidas.
Los requerimientos no funcionales tienen que ver con características que de
una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento
(en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares,
etc.
4.2 REQUERIMIENTOS FUNCIONALES DEL SISTEMA
CONTROL DE OBRAS.

Los reportes deben presentar una interfaz dinámica para el usuario.

se podrá realizar exportación de reportes en los siguientes formatos:
PDF, HTML, RTF, XLS, CSV Y XML.

El usuario general podrá obtener reportes personalizados con el formato
establecido por jefatura.

El sistema será visible desde el ambiente web.

El sistema mostrara el listado de todas las comunidades de estado de
Veracruz.

El sistema debe registrar todos los cambios que realiza el usuario.

El sistema debe reflejarse los cambios efectuados por los usuarios.

El usuario de jefatura debe realizar su observación de la obra siempre.

El sistema coloca la fecha del registro de cada obra.
52

El usuario de jefatura debe tomar y capturar la foto de la obra que
realiza.

Todos los usuarios deben localizar el sistema en la misma dirección.
4.3 REQUERIMIENTOS NO FUNCIONALES.

El acceso al sistema es restringido.

las modificaciones son realizadas únicamente por la administradora del
sistema.

Los usuarios tendrán un lapso de tiempo para realizar sus funciones
como máximo.
4.4 RESTRUCTURACIÓN DE CASOS DE USO
Anteriormente se mostró el caso de uso del sistema Control de Obras,
compuesto por los tres módulos como parte de la ingeniería inversa, así pues
una vez obtenido su diseño y analizar en funcionamiento que muestra referente
al sistema, se procede a brindar una nueva estructura que proporciona la
unificación del sistema.
En la figura siguiente se muestra los nuevos casos de usos del sistema Control
de Obras, podemos observar como desaparecen los módulos y se unifica todo
el comportamiento del sistema en uno solo. Los datos que se tenía que
exportar de los módulos cuentas liquidadoras y control de proyectos, ahora se
almacenan en la misma base de datos facilitando la consulta de obras y
principalmente evita la redundancia de los datos almacenados de las obras.
La unificación de los módulos beneficia principalmente las consultas, reportes y
exportaciones de datos de interés de las obras que se interesan.
En el siguiente caso de uso se muestra a cada actor o usuario que participa en
el sistema cuenta con una clave única para su acceso al sistema, así mismo la
restricción de las operaciones que puede realizar dentro del sistema control de
obras.
53
Figura 4.1 Nuevos casos de uso (Elaboración propia)
54
4.4.1 ESPECIFICACIÓN DE CASOS DE USO
Continuación se muestra los actores que intervienen en el sistema Control de
Obras.
ACTOR
DIRECCIÓN GENERAL DE TELECOMUNICACIONES.
Es el departamento encargado de crear servicios tecnológicos a
beneficio de la SECOM, la DGT es el departamento donde se realizó
el
DESCRIPCIÓN
sistema y por lo tanto es el
departamento
encargado de
supervisar el funcionamiento del sistema, así como de realizar
modificaciones, privilegios etc.
RESPONSABILIDADES
FUENTES

Administrar el sistema.

Otorgar privilegios a los usuarios

Brindar soporte a los usuarios

Realizar cambios.

Capacitas a los usuarios.
Claudia Flores Sariaga, Xóchitl Utera, DIRECCIÓN GENERAL DE
COMUNICACIONES.
Tabla 4.1 Actor Dirección general de telecomunicaciones. (Elaboración propia)
ACTOR
COORDINACIÓN FONDEN
Encargado de actualizar las obras de fonden, este actor tiene todos
permisos con respecto a las obras fonden de todas las dirección así
DESCRIPCIÓN
RESPONSABILIDADES
como de todas las ejecutoras.

Consulta únicamente la información de las obras de fonden
de todas las direcciones.

Imprime reportes únicamente de la información de las obras
de fonden de todas las direcciones

Editar e actualizar toda la información referente a las obras
de todas las ejecutoras.
FUENTES
Claudia Flores Sariaga, Xóchitl Utera, DIRECCIÓN GENERAL DE
COMUNICACIONES.
Tabla 4.2 Actor Coordinación FONDEN (Elaboración propia)
ACTOR
JEFATURA
Departamento principal de la SECOM, es uno de los usuarios
principales del sistema considerando que en este departamento se
encuentra el secretario de la SECOM, por lo tanto el sistema brinda
DESCRIPCIÓN
información para tener un panorama sobre las actividades que se
55
llevan a cabo en cada obra del estado de veracruz, a fin de tomar
decisiones adecuadas si así se requiere.

RESPONSABILIDADES
Consultar e imprimir reportes de todas las obras
Fonden, POA y de 2% sin restricción alguna.
FUENTES
Claudia Flores Sariaga, Xóchitl Utera, DIRECCIÓN GENERAL DE
COMUNICACIONES.
Tabla 4.3. Actor Jefatura (Elaboración propia)
ACTOR
DIRECCIÓN GENERAL DE PLANEACIÓN.
Encargado de modificar informacion de las obras POA y 2% de
DESCRIPCIÓN
todas las ejecutoras.

RESPONSABILIDADES
FUENTES
Edita toda la informacion de las obras 2% y poa de
todas las ejecutoras y direcciones.
Claudia Flores Sariaga, Xóchitl Utera, DIRECCIÓN GENERAL DE
COMUNICACIONES.
Tabla 4.4 Actor Dirección de planeación. (Elaboración propia)
ACTOR
UNIDAD ADMINISTRATIVA
Responsable de administrar la SECOM, pero además de eso es que
recibe una copia de la información de obras autorizadas por
finanzas, siendo así el primer usuario en poseer datos generales de
DESCRIPCIÓN
RESPONSABILIDADES
FUENTES
la obra.

Ingresar datos de obras POA.

Ingresa datos financieros de obras POA.

Ingresa fondos de la obra.

Consulta el listado de las obras POA.

Ingresa cuentas liquidadoras de obras POA.

Imprime reportes de obras.
Claudia Flores Sariaga, Xóchitl Utera, DIRECCIÓN GENERAL DE
COMUNICACIONES.
Tabla 4.5 Actor Unidad Administrativa (Elaboración propia)
56
ACTOR
DIRECCIÓN EJECUTORA
Encargado de asignar la obra a una ejecutora para que realice la
DESCRIPCIÓN
obra.

Ingresa datos financieros del 2%

Ingresa datos fonden

Ingresa datos de problemática presentada en la obra de su
ejecutora

Ingresa el avance físico de las obras POA, 2% y Fonden.

Ingresa el estatus de la obra.

Ingresa datos de impacto que se presente en la obra de su
ejecutora
RESPONSABILIDADES

Captura los datos generales de las obras del 2% y Fonden.

Ingresa comentarios referentes a la obra de su ejecutora.

Ingresa obras multianuales

Eliminar dato de obras del 2% y Fonden

Modificar datos del 2% y Fonden.

Consulta cuentas liquidadoras de 2% y Fonden.

Consulta e imprime información de las obra POA, y Fonden
de su ejecutora.
FUENTES

Consulta historial presupuestal

Ingresa estimaciones de las obras.

Captura fotos del estado de las obras de su ejecutora

Ingresa fehas.

Ingresa información anual de 2%.
Claudia Flores Sariaga, Xóchitl Utera, DIRECCIÓN GENERAL DE
COMUNICACIONES.
Tabla 4.6 Actor Dirección Ejecutora (Elaboración propia)
Las siguientes tablas muestran la especificación de casos de usos del sistema,
se describe cada caso que se realiza en el sistema, así como el usuario que lo
lleva a cabo, la precondición para que pueda realizarse el caso, la secuencia
que sigue al realizarse dicho caso, excepciones, comentarios y las pos
condiciones al llevarse cabo el caso, estas especificaciones son realizadas a
fin de tener conocimiento de todas las funciones que ejecuta el sistema y quien
realiza dicha función.
57
Caso de uso
Administra sistema
Fuentes
Xochitl utera, Claudia flores
Actor
UNIDAD ADMINISTRATIVA
Precondición

Debe ser el usuario con todos los permisos del sistema.

Amplio conocimiento sobre el sistema.
El caso de uso permite al administrador crear, modificar y borrar tanto
a usuarios del sistema, como procesos o componentes del mismo.
Descripción
El administrador se encarga de supervisar el funcionamiento del
sistema.
Brinda soporte técnico a los usuarios de ser necesario.
Secuencia normal
1.-
Ingresa nombre de usuario.
2.-
Ingresa contraseña.
3.-
Supervisa funcionamiento del sistema.
4.-
Crea, modifica o elimina componentes del sistema que son
requeridos.
5.Pos condición
Brinda soporte técnico a los usuarios que lo requieren.
El administrador puede acceder y transformar el sistema. Actualiza los
cambios para que sean reflejados en el sistema.
Tabla 4.7. Caso de Uso Administra sistema (Elaboración propia)
Caso de uso
Administrador de obras Fonden de todas las ejecutoras.
Fuentes
Xochitl utera, Claudia flores
Actor
COORDINACIÓN FONDEN.
Precondición
Contar con usuario y contraseña para acceder al sistema.
Descripción
El caso de uso de coordinación Fonden edita información de todas las
ejecutoras que llevan a cabo una obra clasificada como fonden, de
igual manera realiza consultas e imprime reportes de obras fonden.
Secuencia normal
Pos condición
1.-
Ingresa nombre de usuario.
2.-
Ingresa contraseña.
3.-
Consulta información de obra Fonden.
4.-
De ser necesario modifica información delas obras Fonden.
5.-
Imprime reportes de las obras interesadas
Coordinación tiene acceso para supervisar las obras fonden de todas
las ejecutoras.
Excepciones
Ninguna
Comentarios
El usuario de coordinación fonden tiene únicamente acceso a las obras
antes de Fonden.
Tabla 4.8 Caso de uso Administrador de obras Fonden de todas las ejecutoras.(Elaboración
propia)
58
Caso de uso
Solicita información.
Fuentes
Xochitl utera, Claudia flores
Actor
Jefatura
Precondición
Contar con usuario y contraseña para acceder al sistema.
Descripción
El caso de uso de Jefatura es uno de los principales usuarios finales
del sistema, consulta e imprime reportes de todas las obras de 2%,
POA y Fonden.
Secuencia normal
Pos condición
1.-
Ingresa nombre de usuario.
2.-
Ingresa contraseña.
3.-
Consulta información de todas las obras 2%, POA Y Fonden.
4.-
Imprime reportes de las obras enteradas.
Accede al sistema.
Visualiza toda la información de las obras que maneja el sistema.
Excepciones
Ninguna
Comentarios
Jefatura está limitada, no puede realizar ningún cambio a la
información de las obras, solo puede consultar e imprimir reportes.
Tabla 4.9 Caso de uso Solicita información (Elaboración propia)
Caso de uso
Edita y solicita.
Fuentes
Xochitl utera, Claudia flores
Actor
DIRECCIÓN GENERAL DE PLANEACIÓN
Precondición
Contar con usuario y contraseña para acceder al sistema.
Descripción
El caso de uso de DIRECCIÓN GENERAL DE PLANEACIÓN consulta
e imprime reportes referentes a las obras de POA Y 2% de todas las
direcciones, así mismo edita la información de todas las ejecutoras.
Secuencia normal
1.-
Ingresa nombre de usuario.
2.-
Ingresa contraseña.
3.-
Consulta información de todas las obras 2% y POA de todas las
4.-
direcciones.
5.-
Modifica información sobre obras 2% y POA de todas las
ejecutoras de las obras.
6.-
Imprime reportes de las obras 2% y POA de todas las
Direcciones y ejecutoras.
Pos condición
Accede al sistema.
Excepciones
Ninguna
Comentarios
Dirección general de planeación solo visualiza y modifica información
de obras POA Y 2%.
Tabla 4.10 Caso de uso Edita y solicita. (Elaboración propia)
59
Caso de uso
Ingresa datos de obras poa.
Fuentes
Xochitl utera, Claudia flores
Actor
UNIDAD ADMINISTRATIVA
Precondición
Contar con usuario y contraseña para acceder al sistema.
Descripción
El caso de uso de UNIDAD ADMINISTRATIVA ingresa datos
generales, financieros, fondos y cuentas liquidadoras de obras POA.
Secuencia normal
1.-
Ingresa nombre de usuario.
2.-
Ingresa contraseña.
3.-
Ingresa datos generales de las obras POA.
4.-
Ingresa datos financieros de obras POA.
5.-
Ingresa fondos de las obras POA.
6.-
Consulta información de obras POA.
7.-
Edita información sobre obras POA.
8.-
Imprime reportes de las obras POA .
Pos condición
Accede al sistema.
Comentarios
UNIDAD ADMINISTRATIVA solo visualiza y modifica información de
obras POA.
Tabla 4.11 Casos de uso Ingresa datos. (Elaboración propia)
Caso de uso
Ingresa datos obras 2% y Fonden.
Fuentes
Xochitl utera, Claudia flores
Actor
DIRECCIÓN EJECUTORA.
Precondición
Contar con usuario y contraseña para acceder al sistema.
Descripción
El caso de uso DIRECCIÓN EJECUTORA ingresa todos los datos
referentes a las obras de 2% y Fonden, es el encargado de alimentar la
base de datos del estado de la obra ya que es la dirección ejecutora
encargada de realizar la obra y por lo tanto la encargada de reportar el
estado en el que se encuentra la obra.
Secuencia normal
1.-
Ingresa nombre de usuario.
2.-
Ingresa contraseña.
3.-
Captura datos generales de las obras del 2% y Fonden.
4.-
Captura datos financieros de las obras del 2% y Fonden.
5.-
Captura fotos de su ejecutora.
6.-
Consulta información de todas las obras 2% Fonden.
7.-
Modifica información sobre obras 2% y Fonden
8.-
Imprime reportes de las obras 2% , Fonden y POA de su
ejecutora.
Pos condición
Accede al sistema.
Comentarios
Dirección ejecutora solo imprime reportes de obras de su ejecutora.
Tabla 4.12 Caso de uso Ingresa datos obras 2% y Fonden. (Elaboración propia)
60
4.5 MODELO FÍSICO DE DATOS
Una vez obtenidos los modelos físicos de las bases de datos en la
reconstrucción de documentos, se analizó cada dato a fin de tener un
adecuado, que sea una guía de almacenamiento.
El análisis arrojó datos repetidos y mal declarados entre otras anomalías, así
que se aplicó una normalización a la base de datos a fin de obtener un modelo
con físico de datos correcto, que se punto de partida en la programación del
sistema.
4.5.1 NORMALIZACIÓN.
Para obtener el anterior modelo se limpió la base de datos aplicando la
normalización.
La normalización es el proceso mediante el cual se transforman datos
complejos a un conjunto de estructuras de datos más pequeñas, que además
de ser más simples y más estables, son más fáciles de mantener. También se
puede entender la normalización como una serie de reglas que sirven para
ayudar a los diseñadores de bases de datos a desarrollar un esquema que
minimice los problemas de lógica. Cada regla está basada en la que le
antecede. La normalización se adoptó porque el viejo estilo de poner todos los
datos en un solo lugar, como un archivo o una tabla de la base de datos, era
ineficiente y conducía a errores de lógica cuando se trataban de manipular los
datos.
La normalización también hace las cosas fáciles de entender. Los seres
humanos tenemos la tendencia de simplificar las cosas al máximo. Lo hacemos
con casi todo, desde los animales hasta con los automóviles. Vemos una
imagen de gran tamaño y la hacemos más simple agrupando cosas similares
juntas. Las guías que la normalización provee crean el marco de referencia
para simplificar una estructura de datos compleja.
Otra ventaja de la normalización de base de datos es el consumo de espacio.
Una base de datos normalizada ocupa menos espacio en disco que una no
61
normalizada. Hay menos repetición de datos, lo que tiene como consecuencia
un mucho menor uso de espacio en disco.
El proceso de normalización tiene un nombre y una serie de reglas para cada
fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va
entendiendo el proceso, así como las razones para hacerlo de esta manera.
Grados de normalización
Existen básicamente tres niveles de normalización: Primera Forma Normal
(1NF), Segunda Forma Normal (2NF) y Tercera Forma Normal (3NF). Cada
una de estas formas tiene sus propias reglas.
Cuando una base de datos se conforma a un nivel, se considera normalizada a
esa forma de normalización. No siempre es una buena idea tener una base de
datos conformada en el nivel más alto de normalización, puede llevar a un nivel
de complejidad que pudiera ser evitado si estuviera en un nivel más bajo de
normalización.
Normalización de bases de datos

Primera Forma Normal (1FN) Incluye la eliminación de todos los grupos
repetidos.

Segunda Forma Normal (2FN) Asegura que todas las columnas que no
son llave sean completamente dependientes de la llave primaria (PK).

Tercera Forma Normal (3FN) Elimina cualquier dependencia transitiva.
Una dependencia transitiva es aquella en la cual las columnas que no
son llave son dependientes de otras columnas que tampoco son llave.
Se aplicó la normalización a los datos de las bases de datos COMPARE y la
institucional, al eliminar muchos datos repetidos, así como desusados entre
otros muchos más, nos dio como resultado el siguiente modelo físico de datos,
el cual nos muestra un diseño unificado de las dos bases de datos que tenía el
sistema, de esta manera la información que se maneje en el sistema y en la
base de datos es funcional y verídica, facilitando y estableciendo los datos que
el sistema manejara.
62
MODELO FÍSICO DE DATOS
Figura 4.2 Nuevo modelo físico (Elaboración propia)
63
A continuación se muestra la RELACIÓN DE TABLAS del nuevo modelo físico
de datos establecido.
NO
NOMBRE DE TABLA
DESCRIPCIÓN
1
COMPA_OBRAS
Tabla donde se almacenan los datos generales de las
obras POA, 2% Y FONDEN.
2
CTALIQ
Tabla de cuentas liquidadoras
3
COMPA_CAT_TIPO_OBRA
Catalogo que contiene los diferentes tipos de obra.
4
ANTI
Catálogo de anticipaciones
5
MONTO
Tabla que almacena todos los montos que maneja el
sistema.
6
DOCTOS
Tabla que almacena los documentos de las obras, así
como el croquis
7
FONDO
Catálogo de fondos
8
COMPA_CAT_EVENTOS
Catálogo de eventos
9
CONTRA_CONTRATISTA
Catálogo de contratistas
10
AFIANZA
Tabla con datos de afianzadora
11
UNIDAD
Catálogo de unidades
12
COMENTARIO
Catálogo de comentarios
13
CAT_MUN
Catálogo de los municipios del estado de Veracruz.
14
CAT_DIST_EST
Catálogo de distritos estatales
15
CAT_DIST_FED
Catálogo de distritos federales
16
PROBLEMÁTICA
Tabla que almacena la problemática de las obras.
17
COMPA_FONDOS_OBRA
Tabla que almacena los fondos, fechas de inicio y fin, así
como el saldo de las obras.
18
NO
Tabla con los números de acuerdos, eventos, obra,
contrato etc.
19
PROG
Catálogo de programas
20
SUBPROG
Catálogo de subprogramas
21
SUBSUBPROG
Catálogo de subsubprogrmas
22
SECTOR
Catálogo de sectores
64
23
SUBSEC
Catálogo de subsectores
24
COMPA_USUARIOS
Tabla que almacena los usuarios del sistema
25
F_PROG
Tabla que almacenan las fechas de inicio y termino de un
programa
26
COMPA_MODALIDAD
Catálogo de las combinaciones que existen de los
campos tipoy modalidad.
27
COMPA_AV_FISICO
Tabla que almacena el avance de la obra, fecha y usuario
que modifica.
28
FECHA
Tabla que almacena fechas de modificación.
29
OBR_HISTORIAL
Tabla que almacena el historial de la obra.
30
FOLIO
Tabla que almacena el folio y anexos de las obras.
31
F_REAL
Tabla que almacena la fecha real de inicio t termino de
cada obra.
32
TIPO
Tabla que almacena el tipo de obra, adjudicación.
33
IMPACTO
Tabla que almacena el impacto y su descripción de cada
obra.
34
EJERCIDO_CL
Tabla que almacena lo ejercido de una obra.
35
COMPA_FOTOS
Tabla que almacena las fotos de las obras.
Tabla 4.13. Nueva relación de tablas (Elaboración propia)
65
CAPITULO V. PRUEBAS
5.1 Requerimientos de hardware y software
Partiendo de los diseños creados anteriormente, tanto de las funciones del
sistema, como de los datos, que empieza a plasmar estos diseños en la
plataforma de java, posgrest y jaspereports.
Componentes de Postgresql
VERSIÓN
SISTEMA
OPERATIVO
ESPACIO
DISPONIBLE
EN DISCO
MEMORIA
PostgreSQL 9.2.1
Windows (Todas
las versiones)
70 MB (mínimo)
Componentes de JasperReports
VERSIÓN
SISTEMA
OPERATIVO
NETBEANS
JDK
3.5
Windows
7.2
jdk 1.7.0_09
Memoria: 256 MB
Tabla 5.1 posgresql (Elaboración propia)
propia)
Tabla 5.4 JasperReports (Elaboración
Componentes de JAVA
VERSIÓN
SISTEMA
OPERATIVO
ESPACIO
DISPONIBLE
EN DISCO
JDK
Java 7
Windows
124 MB
jdk 1.7.0_09
Tabla 5.2 java (Elaboración propia)
Componentes de NETBEANS
VERSIÓN
SISTEMA
OPERATIVO
ESPACIO
DISPONIBLE
EN DISCO
RAM
JDK
7.2
Windows
750 MB
512 MB
jdk 1.7.0_09
Tabla 5.3 Netbeans (Elaboración propia)
67
Una vez instalado Postgresql, se crea la base de datos y tablas, siguiendo
como referencia el Modelo físico de datos.
A continuación se muestra la base de datos creada.
Figura 5.1 Prueba Postgres (Elaboración propia)
68
5.2 Migración de base de datos.
Se denomina migración de datos, al proceso que tiene por objeto tanto la
importación como la exportación de una determinada información almacenada
en un sistema de bases de datos, para llevar a cabo su traspaso.
La migración de datos tiene su fundamento en la ampliación un sistema de
gestión de base. En este contexto, se trata de exportar los datos a un nuevo
sistema con mayor capacidad o más funciones adicionales. Estos cambios
llevan consigo una adaptación de todos los datos de una base de datos a otra.
Por tanto siempre que se producen cambios de un sistema de gestión a otro,
se habla inevitablemente de los procesos de migración de datos.
La migración de los módulos del sistema Control de Obras, se llevó a cabo de
la siguiente manera:

Se exporto a Excel los datos, tabla por tabla.

Se depuraron los datos.

Se adaptaron los datos a la estructura propuesta.

se importaron a la nueva base de datos creada en Postgresql.
INSTALACIÓN DE NETBEANS, JDK Y JASPERREPORTS
Una vez instalado JDK, se precede a instalar netbeans. NetBeans IDE es un
entorno
de
desarrollo
integrado
(IDE),
modular,
de
base
estándar
(normalizado), escrito en el lenguaje de programación Java. El proyecto
NetBeans consiste en un IDE de código abierto y una plataforma de aplicación,
las cuales pueden ser usadas como una estructura de soporte general
(framework) para compilar cualquier tipo de aplicación.
Cuando se tiene JDK, Netbeans, se agregaran en netbeans las librerías de
jasperreports, de esta manera podremos ejecutar reportes desde la aplicación
a la base de datos.
A continuación se muestra una imagen del uso de JasperReports en Netbeans,
realizando consultas de la base de datos COMPARE que se encuentra en
Postgrest.
69
Uso de jasperReports
Figura 5.2 Prueba Netbeans (Elaboración propia)
jasperreports cuenta con un data source eficiente que facilita la conexión de
netbeans con la base de datos, de esta manera las consultas y reportes se
realizan de manera rápida y fácil.
5.3 PROCESO DE IMPLEMENTACIÓN
Scrum es un proceso en el que se aplican de manera regular prácticas
para trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección
tiene origen en un estudio de la manera de trabajar de equipos altamente
productivos.
En Scrum se realizan entregas parciales y regulares del producto final,
priorizadas por el beneficio que aportan al receptor del proyecto. Por ello,
Scrum está especialmente indicado para proyectos en entornos complejos,
donde se necesita obtener resultados pronto, donde los requisitos son
cambiantes o poco definidos, donde la innovación, la competitividad, la
flexibilidad y la productividad son fundamentales.
70
El proceso:
En Scrum un proyecto se ejecuta en bloques temporales cortos y
fijos (iteraciones de un mes natural y hasta de dos semanas, si así se
necesita).
Cada iteración tiene que proporcionar un resultado completo, un incremento de
producto final que sea susceptible de ser entregado con el mínimo esfuerzo al
cliente cuando lo solicite
Nombre de tarea
Nombre de tarea
captura de obras 2% a la
nómina
Programacion del
sistema
logueo del sistema
captura de obras
REUNION AVANCES/DUDAS
Fondos
REUNION AVANCES/DUDAS
ficha técnica
REUNION AVANCES/DUDAS
Estimaciones
REUNION AVANCES/DUDAS
historial presupuestal
REUNION AVANCES/DUDAS
Tabla 5.5 scrum1 (Elaboración propia)
REUNION AVANCES/DUDAS
Fondos
REUNION AVANCES/DUDAS
ficha técnica
REUNION AVANCES/DUDAS
historial presupuestal
REUNION AVANCES/DUDAS
Tabla 5.6 scrum2 (Elaboración propia)
Nombre de tarea
Nombre de tarea
ingreso de datos
generales de poa
captura deobras del
fonden
REUNION AVANCES/DUDAS
ingreso de datos
financieros de poa
REUNION AVANCES/DUDAS
Reportes
REUNION AVANCES/DUDAS
Estimaciones
REUNION AVANCES/DUDAS
ingeso de fondos
ficha técnica
REUNION AVANCES/DUDAS
REUNION AVANCES/DUDAS
listado de obras poa
captura de fotos
REUNION AVANCES/DUDAS
REUNION AVANCES/DUDAS
Consultas
Reportes
REUNION AVANCES/DUDAS
REUNION AVANCES/DUDAS
Reportes
Consultas
REUNION AVANCES/DUDAS
REUNION AVANCES/DUDAS
Tabla 5.7 scrum3 (Elaboración propia)
Tabla 5.8 scrum4 (Elaboración propia)
71
CONCLUSIONES
La secretaria de comunicaciones tiene un número considerable de sistemas
realizados por la DGT a fin de sistematizar ciertos procesos, pero un punto muy
importante es la estructura física bajo la cual funcionan actualmente, ya que es
casi imposible modificar un sistema sin afectar a los demás y el sistema control
de obras también se encuentra en la base de datos donde todos estos
sistemas se almacén, pero en cambio es el único sistema que se localiza con
otra replica de información, además de que su complemento de módulos se
ubica otra base de datos, siendo así, posible realizar cambios, mejoras o en su
efecto una reingeniería de software sin afectar a terceros sistemas de la
secretaria, por lo que el sistema control de obras es el idóneo para ser el primer
sistema al que se le aplique una reingeniería.
Ahora bien el sistema Control de obras, es un sistema importante para la
secretaria ya que dicho sistema almacena, pero sobre todo administra los datos
referentes a las obras que se realizan en todo el estado de Veracruz, sin duda
alguna el sistema es de gran ayuda tanto para su administración, como para la
comparecencia que se lleva cada año, como cierre de año, el cual básicamente
muestra todo lo realizado durante un año, es cierto que el sistema presenta
muchas incongruencias de datos por la expansión de información en cuanto a
su almacenamiento, pero esta propuesta de reingeniería muestra una opción
muy importante para que la información fluya de forma eficiente, facilitando la
consulta de toda la información requerida de las obras.
La reingeniería básicamente soluciona todo o casi todos los problemas que se
presentan en el sistema, debido a que las fallas que podría tener, son por parte
del proceso que los usuarios deben realizar y en esa cuestión el sistema no
pueden hacer nada.
Es evidente que las plataformas que no han progresado en su desarrollo
tecnológico se han desusado, convirtiendo a los sistemas desarrollados bajo su
plataforma obsoletos en comparación a las nuevas tecnologías , y con respecto
a las nuevas tecnologías, java nos presenta un lenguaje sofisticado y sobre
todo actual, con ayuda de netbeans nos facilita realizar aplicaciones eficientes,
dinámicas ya que netbeans cuenta con una gran gama de librerías a fin de
73
facilitar el desarrollo de estas, permitiendo realizar cambios al sistema de
manera rápida y apropiada.
Jasperreports es creado bajo java y se ajusta perfectamente a netbeans, facilita
la realización, modificación de reportes, con estas herramientas se puede
realizar una conexión de java con netbeans y para sus reportes Jasperreports,
además proporciona la conexión con Postgres, en efecto estas herramientas
nos brinda la facilidad de realizar un sistema de manera eficiente, actual, donde
los usuarios tienen acceso a ella en el ambiente web, pero sobre todo el
funcionamiento del sistema ubicado presenta una funcionalidad perfecta.
Las ventajas de utilizar java y postgres son muchas gracias sus avances
tecnológicos que han tenido en los últimos años, proporcionan una estabilidad
al sistema ofreciendo la actualización del sistema Control de Obras y por
consiguiente su reingeniería, algunas de sus ventajas son:

son software libre

Java cuenta con JasperReports que es la mejor herramienta de código libre
de java para generar reportes.

Es multiplataforma

Cuenta con muchas librerías para desarrollar aplicaciones empresariales.

Fácil acceso a información sobre el lenguaje.

Postgres está orientado a objetos.
La metodología a seguir en este proyecto, es el método cíclico como su nombre
lo dice, consta de una serie de pasos consecutivos formando un ciclo y
presentándose de manera periódica, esta metodología es una guía en la
realización de la reingeniería del sistema Control de Obras.
Los pasos a llevar a cabo para cumplir el método cíclico de la reingeniería del
software del sistema Control de Obras son los siguientes:

Recopilación
y análisis del inventario que almacena la secretaria de
comunicaciones sobre el sistema Control de Obras.
74

Reestructuración de documentos: analiza la cantidad y calidad de la
información obtenida del inventario y se procede a realizar los documentos
necesarios para facilitar su comprensión.

Reingeniería inversa: se extrae del sistema Control de obras información del
diseño arquitectónico y de proceso, e información de datos.

Restructuración de datos: análisis de los modelos obtenidos con la
reingeniería inversa que se obtuvo con el objetivo de definir nuevos modelos
de datos.

Ingeniería directa: Reconstrucción del sistema.
A fin de llevar a cabo las actividades de reconstrucción del sistema se Control
de Obras de manera organizada, calendarizada, se aplica Scrum, que ejecuta
en bloques temporales y cortos el sistema, organizando, pero también
controlando y verificando los avances que se realizan sobre el sistema, de esta
manera el equipo puede estar seguro del correcto funcionamiento del sistema y
de no serlo, optimarlo.
El resultado final obtenido de la reingeniería del sistema Control de Obras es a
fin de proporcionar un sistema que procese fácil y rápido las peticiones de los
usuarios tanto en consultas, como en operaciones, además de contar son su
fácil y dinámico acceso tanto al sistema como a los reportes, de manera que
sea posible visualizar el estado en que se encuentran las obras en todo el
estado de Veracruz en tiempo real.
Cabe mencionar que el sistema como tal, aun no se tiene, pero si se está
trabajando en él, por el momento la secretaria mantiene ocupado su personal
en otros labores, aunque un punto importante ya está realizado, los diseños a
seguir ya están, así como la base de datos ya se encuentra actualizada, con
datos unificados, el código se reutilizara, así que solo falta realizar la parte de
la programación por que se encuentra inconcluso.
Sin duda alguna la reingeniería del software da paso a la actualización de
sistemas obsoletos, abriendo paso a nuevas oportunidades tecnológicas y
ayudando sin duda alguna a la economía del país.
75
REFERENCIAS
(Secretaria de comunicaciones del estado de Veracruz 2013)
Marcos, Esperanza. Diseño de bases de datos relacionales. España:
Alafaomega za-ma.
Fower, Martin y Scott, Kendall (1999). Gota a Gota. Mexico: Addison Wesley
longman.
Gabriel García Márquez. JasperReports Server. 2000.[consulta septiembre de
2013]. Disponible en: http://community.jaspersoft.com/
Verónica De la Morena. ¿Qué es Reingeniería del Software?.2009 [consulta
septiembre de 2013]. Disponible en: http://cnx.org/content/m17438/latest/
Gonzalez Dana. Metodología en Sistemas Reingeniería. 2010 .[consulta agosto
de 2013]. Disponible en:
http://epetushuaia.files.wordpress.com/2011/06/reingenieria-de-soft.pdf
Xavier Albaladejo. Qué es SCRUM. 2012.[consulta octubre de 2013]. está
disponible e n http://www.proyectosagiles.org/que-es-scrum
Gomez Vega, Medardo. (2012) Reingenieria de administración de datos de la
red manual y pasiva de la REMMAQ, Universidad tengológica Israel
César Llamas Bello.Una breve descripción de java. 2003.[consulta septiembre
de 2013]. Disponible en:
http://www.infor.uva.es/~cllamas/sd/temasPDF/Java.pdf
Segundo Madardo Gómez Vega (2012). Reingeniería del sistema de
adimintracion de datos de a red manual y pasiva de la REMMAQ. (Tesis
doctoral inédita).Universidad Tecnologica ISRAEL.
76
GLOSARIO
C.FONDEN: Coordinación FONDEN.
CASE: son diversas aplicaciones informáticas destinadas a aumentar la
productividad en el desarrollo de software reduciendo el costo de las mismas
en términos de tiempo y de dinero.
COMPARE: Nombre de la base de datos que maneja la DGT para el sistema
Control de Obras.
D.G.P: Dirección general de planeación.
DGT: DIRECCION GENERAL DE COMUNICACIONES.
FONDEN: Fondo de desastres Naturales.
OAR: Análisis de opciones para reingeniería.
POA: Obras del Plan Operativo Anual.
SECOM: Secretaría de Comunicaciones del Estado de Veracruz.
SISCO: El Sistema de Información de Sitios Contaminados (SISCO) formara
parte de un sistema de información de la SEMARNAT para apoyar en la
formulación, aplicación y seguimiento de políticas e instrumentos para el
manejo y la gestión ambiental de sitios contaminados, en temas como
ordenamiento territorial, monitoreo ambiental, manejo de cuencas hidrográficas,
estudios, investigaciones y remediaciones específicas.
78
ÍNDICE DE FIGURAS
Figura 2.1 Pasos de la reingeniería del software…………………………….…..17
Figura 2.2 Método cíclico…………...…………………………….………………..18
Figura 3.1 Flujo de información SISCO………………………………………......23
Figura 3.2 Procedimiento de contratación………………………………..………24
Figura 3.3 Relación de tablas del módulo cuentas liquidadoras…………...…..24
Figura 3.4 Relación de tablas del módulo control de proyectos……………..…25
Figura 3.5 Submódulo Captura……………………………………………………..27
Figura 3.6 Submódulo captura2………………………………..…………………27
Figura 3.7 Submódulo captura de fotos…………………….…………………..…28
Figura 3.8 Submódulo de consultas y reportes………………..…………………28
Figura 3.9 Listado de reportes……………………………………..………………29
Figura 3.10 Relación de tablas del módulo control de obras……….………….30
Figura 3.11 Casos de uso Ingeniería inversa………………………………….…45
Figura 3.12 Modelo unificado de objetos………………………………..……….47
Figura 3.13 Modelo COMPRE…………………………………………………….49
Figura 3.14 Modelo institucional………………………………………………..…..50
Figura 4.1 Nuevos Casos de uso………………………………………..……...…54
Figura 4.2 Nuevo modelo físico…………………………………….…………...…63
Figura 5.1 Prueba Posgrest…………………………………………………………68
Figura 5.2 Prueba Netbeans…………………………………………..……………70
79
ÍNDICE DE TABLAS
Tabla 1.1 Descripción de java………………………………………………………9
Tabla 2.1 JasperReports…………………….……………………………………..10
Tabla. 3.1 Relación y descripción de cada tabla del módulo control de
obra……………………………………………………………………………….…...31
Tabla 3.2 Catalogo contratista……………………………………………………...32
Tabla 3.3 Catalogo tipo obra……………………………………………………….32
Tabla 3.4 Compa conc tipo……………………………………..………….……….32
Tabla 3.5 Contratista……………………..………………….……..………………..32
Tabla 3.6 Usuarios…………………………………..……………..………………..32
Tabla 3.7 Compa obras…………………….……………………………………….33
Tabla 3.8 Compa fotos…..………………………………………..…………………34
Tabla 3.9 Compa fondos obra……………………….…………………..…………34
Tabla 3.10 Compa presupuestal…………………………………..……………….34
Tabla 3.11 Compa sustitución………………………………………..………….…34
Tabla 3.12 Compa fonden……………………………………….………………….35
Tabla 3.13 Modalidad…………………………………………………………….…35
Tabla 3.14 Catalogo eventos…………………………………………………….…35
Tabla 3.15 Fonden estima………………………………………………………..…35
Tabla 3.16 Análisis FODA…………………………………….…………………….41
Tabla 3.17 Análisis general…………………………………………..……………..43
Tabla 4.1 Actor Dirección general de comunicaciones…………………………..55
Tabla 4.2 Actor Coordinación general FONDEN…………………………..….….55
80
Tabla 4.3 Actor Jefatura…………………………………………………….…...….56
Tabla 4.4 Actor Dirección de Planeación………………………….…………..…56
Tabla 4.5 Actor Unidad Administrativa…………………………….………………56
Tabla 4.6 Actor Dirección Ejecutora…………………………..……….….…….…57
Tabla 4.7 Caso de Uso Administra sistema………………………..….….………58
Tabla 4.8 Caso de Uso Administrador de obras FONDEN de todas
las ejecutoras…………………………………………………………….…………..58
Tabla 49 Caso de Uso Solicita información……..…………..……….……………59
Tabla 4.10 Caso de Uso Edita y solicita………….………………………………..59
Tabla 4.11 Caso de Uso Ingresa datos…………………………………………....60
Tabla 4.12 Caso de Uso Ingresa datos de obras 2% y FONDEN……………..60
Tabla 4.13 Nueva relación de tablas………………………………………….…...65
Tabla 5.1 Postgrest…………………………………………………………………..67
Tabla 5.2 Java…………..……………………………………………………………67
Tabla 5.3 Netbeans…………………………………………………………………..67
Tabla 5.4 JasperReports……………………………………………..……………..67
Tabla 5.5 Scrum1…………………………………………………………………….71
Tabla 5.6 Scrum2…………………………………………………………………….71
Tabla 5.7 Scrum3…………………………………………………………………….71
Tabla 5.8 Scrum4…………………………………………………………………….71
81