CHAPTER TWO
2.4 Grey Documents and Ethnographic Encounters
Los requerimientos finales solicitados para el desarrollo del software fueron ilustrados en los siguientes casos de uso, y cada uno de estos fue descrito con su ficha técnica.
Figura 5. Caso de uso validación de datos entrada para Sedes y periodos
RF- 01 Ingreso de Sedes y periodo
Requisitos asociados RI–02 Información de las sedes y los periodos académicos
Descripción
El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando alguien ingrese una nueva sede o periodo.
Precondición El solicitante no es un usuario autenticado y tiene acceso a la herramienta Postcondición Las sedes aparecerán en todas las interfaces del sistema mencionadas en el paso 2 y se podrán relacionar a cualquier
periodo académico creado.
Excepciones
Paso Acción
1 Si el usuario intenta agregar una sede que ya se encuentra en el sistema, este mostrara un error y tendrá que ser modificada la sede.
2 Si el usuario intenta agregar un periodo académico cuya fecha está fuera del rango de fechas proporcionadas por el sistema, este mostrara un error y le pedirá que lo ingrese de nuevo.
Figura 6. Caso de uso generar reporte extendido
RF- 02 Generar reporte
Requisitos asociados RI–02 Generar todos los cálculos previos en cada modulo
Descripción
El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando alguien intente generar un reporte.
Precondición El solicitante no es un usuario autenticado y tiene acceso a la herramienta Postcondición Se generaran archivos en tipo .DOCX de los reportes que se generen por modulo.
Excepciones
Paso Acción
1 Si el usuario intenta generar un reporte de un módulo que no haya realizado los cálculos correctamente, este no se generara correctamente y le pedirá al usuario que realice los cálculos directamente en la aplicación primero.
Figura 7. Caso de uso. Validación de datos extendido.
RF- 03
Validación de datos extendido
Requisitos asociados RI–03 Revisión de los datos ingresados para cada modulo
Descripción
El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario intente editar, agregar o eliminar datos de la herramienta.
Precondición El solicitante no es un usuario autenticado y tiene acceso a la herramienta Postcondición Los datos serán editados, agregados o eliminados según corresponda a la acción que haya realizado.
Excepciones
Paso Acción
1 Se validaran todos los datos ingresados y ya sea por falla de tipo, sobreescritura o datos repetidos, esta información no se guardara de manera correcta y se le pedirá al usuario ingresarla nuevamente.
8.5) Diagramas de clases
Pasando al modelado del proyecto después de tener todos los casos de uso y validaciones que tiene que realizar el software, pasamos a la creación dorecta del proyecto, a las reglas de modelado y por ende a la construcción de las clases que harán el proyecto, a continuación, se mostraran los diagramas de clases empaquetados.
Figura 11. Diagramas de clases empaquetado del modulo de energía
Figura 13. Diagrama de clases empaquetado del modulo de residuos
8.6) Cuaderno de cargas para Informatica
En esta etapa se diseñó y ajustó el cronograma de actividades. Se establecieron fechas límite para la muestra de cada módulo por separado que compone la aplicación y también las entrevistas a cada operario de la misma para complementar los requerimientos del programa.
8.7) Análisis Orgánico
En esta etapa se parte del análisis previo elaborado en las etapas anteriores para derivar en un análisis funcional, en el cual se describe que el programa debe funcionar con ventanas sencillas, intuitivas, que le permitan al usuario la fácil digitalización de los datos tomados de las facturas de recibos públicos y de las tablas en formato Microsoft Excel emanados de la oficina de recursos físicos de la Universidad Distrital Francisco José de Caldas. En cuanto a los inventarios hidráulicos y eléctricos, se decidió hacer una interfaz que permita elegir el tipo y subtipo de dispositivo y que solo se ingrese la cantidad de los mismos. Todos los registros almacenados se pueden seleccionar de una tabla visible para cada ventana.
Para el análisis estadístico de los datos, se decidió hacer la generación de las gráficas con un solo botón para cada caso específico. Estas imágenes se podrán almacenar en formato BMP para su manejo en procesadores de texto como Microsoft Word, o en formato PDF a gusto del usuario. La aplicación además contará un generador automático de reportes en formato Microsoft Word, que contendrán las tablas con los datos y sus respectivas gráficas estadísticas.
8.8) Programación y Pruebas
De acuerdo al plan previo se decidió utilizar Java como lenguaje de programación para el diseño de dicha interfaz, dada que su orientación a objetos, practicidad y portabilidad la convirtieron en la herramienta adecuada para el desarrollo. Para la persistencia de los datos nos decantamos por usar PostgreSQL, por su facilidad de montaje, facilidad de pruebas a través del controlador de persistencia Java. Además ambas herramientas son gratuitas, y brindan portabilidad.
Por otra parte, Java nos permite la fácil implementación del MVC (Modelo-Vista-Controlador). Para este caso específico, se implementó una sola clase que permite la conexión con la base de datos PostgreSQL, y nos permite separar los formularios (vista) de la lógica de programación (archivos .java).
Se usaron también herramientas de apoyo que no están en el producto final. Para el diseño de los modelos Entidad-Relación de la base de datos se utilizó Power Designer, el cual permite hacer cambios para pruebas de desarrollo. Para el desarrollo de la aplicación se utilizó la Java API
Documentation y el texto “Como programar en Java” de Deitel y Deitel, para solventar los
problemas propios de cualquier desarrollo de software.
A medida que se fueron desarrollando los módulos de la aplicación, se fueron implementando en la oficina PIGA para su respectiva retroalimentación y corrección si hubiere lugar.
Para el diseño e implementación de los reportes, se utilizaron las herramientas de apoyo iReports y JasperReports para su visualización final en formato Microsoft Word, pensando en que el reporte final puede estar sujeto a cambios. El almacenamiento el archivo se efectúa a través de una sencilla interfaz gráfica que permite almacenar el documento en la ubicación deseada por el usuario.
Finalmente, su reunió en pleno el comité PIGA para la presentación e implementación final de la aplicación con todos los usuarios y se da paso a las primeras pruebas completas de la misma.
8.9) Recepción Provisional
Una vez completadas las pruebas por parte del usuario, se procedió a elaborar el manual del usuario final, el cual es fácilmente accesible desde la ventana principal de la aplicación, con procedimientos detallados paso a paso y con capturas de panatalla, fácilmente entendible para cualquier usuario.
8.10) Puesta en marcha
Una vez finalizada la documentación pertinente al usuario, se realiza la implementación final de la aplicación en cada ordenador de la oficina PIGA. El programa consta de un ejecutable .jar (previa
instalación del JDK), y sus respectivos archivos de generación de reportes completamente compilados (. jasper). Se crea un acceso directo ejecutable en el escritorio de cada PC.
En un ordenador que hará las veces de servidor, se instala la versión 9.5 de PostgreSQL, se cargan los esquemas de la base de datos generados en archivos .SQL. Se concede al servidor PostgreSQL los permisos a través del firewall de Windows para conexiones entrantes y salientes, y se configura estática la dirección IP del servidor para evitar problemas de enrutamiento. Se efectúan pruebas de conectividad desde las terminales y se procede a una carga de información para verificar la integridad de la Base de Datos. La aplicación entra a producción, siendo un total éxito hasta el momento.
C
C
A P Í T U L O9
9)
RESULTADOS Y ANÁLISIS
omo resultado principal se diseño e implemento una herramienta de software que les permitiera al Sistema de Gestión Ambiental (SGA) de la Universidad Distrital Francisco Jose de Caldas, esto de manera que se cumplieran todos los requerimientos dados por la entidad y agregando la flexibilidad que debe brindar una herramienta tecnológica, la usabilidad y su adaptación a posibles nuevos lineamientos político-estrategicos del SGA de acuerdo a todo lo mencionado en estructura de la herramienta y construcción de la misma.
Verificando la implementación de la herramienta se demostró que todos los aspectos relevantes y necesarios se agregaran a esta de acuerdo a su importancia y alineados por todos los requerimientos del SGA.
De acuerdo a la implementación final de la herramienta SGA-PIGA, se obtendría la siguiente información:
1. La realización de los reportes en el SGA se da por cada modulo, sea: Acueducto, Energía, Implementación de practicas sostenibles, Gestión integral de residuos, etc.. 2. Los tiempos de creación de reportes cambian drásticamente como se muestra a