Sistema Gestion Documental

DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DOCUMENTAL UTILIZANDO HERRAMIENTAS DE SOFTWARE LIBRE

PARA EL PROGRAMA DE INGENIERÍA DE SISTEMAS DE LA UNIVERSIDAD DE SAN BUENAVENTURA SEDE - BOGOTÁ

ANDRES FELIPE CASTILLEJO ALDANA JUAN MANUEL GÓMEZ CORTES

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C.

2008

DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DOCUMENTAL UTILIZANDO HERRAMIENTAS DE SOFTWARE LIBRE

PARA EL PROGRAMA DE INGENIERÍA DE SISTEMAS DE LA UNIVERSIDAD DE SAN BUENAVENTURA - SEDE BOGOTÁ

ANDRES FELIPE CASTILLEJO ALDANA JUAN MANUEL GÓMEZ CORTES

Proyecto de grado presentado como requisito para optar al título de Ingeniero de Sistemas

Asesora

Claudia Milena Rodríguez Ingeniera de Sistemas

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C.

2008

Nota de aceptación:

_____________________________________ _____________________________________ _____________________________________ _____________________________________ _____________________________________ _____________________________________ _____________________________________

_____________________________________

Firma del presidente del jurado

_____________________________________ Firma del jurado

_____________________________________ Firma del jurado

Bogota, 04 de Junio de 2008

A Dios, nuestros padres, hermanos y amigos,

que con su apoyo incondicional hacen posible la realización

de este sueño (Dedicatoria)

AGRADECIMIENTOS

A portas de culminar nuestro proyecto de grado, que ha requerido de sacrificio y dedicación vemos con mayor claridad que durante este periodo se han tenido dificultades pero de igual manera momentos que han aportado experiencias edificantes para nuestras vidas, es importante contar con este espacio para expresar nuestros mas profundos agradecimientos y gratitud para con todas las personas e instituciones que han hecho posible la realización de este proyecto. En primera medida agradecerle a nuestro creador por la oportunidad de estar en este mundo y gozar de buena salud. Queremos decirle a nuestros padres, hermanos y a todos nuestros seres queridos gracias, que siempre estarán en nuestros corazones y que esperamos seguir contando con todos ustedes para seguir cosechando juntos nuevos logros. En segundo lugar agradecerle a la Ingeniera Claudia Rodríguez, que ha hecho las veces de nuestra tutora pero más que esto, se ha comportado como una amiga, Queremos resaltar la ayuda que nos ha brindado e incentivarla para que siga realizando esta difícil labor y dándole a la sociedad colombiana mejores profesionales. A la Caja de Retiro de las Fuerzas Militares (CRAMIL) que nos permitió el acceso a sus instalaciones y al sistema de gestión documental que ellos manejan, fue de gran ayuda para aclarar algunas dudas que se tenían sobre el funcionamiento de un sistema de este tipo. Por ultimo agradecerle a los docentes de la facultad de ingeniería que intervinieron en nuestro proceso de aprendizaje y nos formaron como profesionales durante estos 5 años de permanencia en las instalaciones de la Universidad de San Buenaventura Sede - Bogota.

CONTENIDO

Pág.

INTRODUCCIÓN 11 1. PLANTEAMIENTO DEL PROBLEMA 13

1.1 ANTECEDENTES 13

1.2 DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA 15

1.3 JUSTIFICACIÓN 15

1.4 OBJETIVOS DE LA INVESTIGACIÓN 15

1.4.1 Objetivo General 15

1.4.2 Objetivos Específicos 15

1.5 ALCANCES Y LIMITACIONES DEL PROYECTO 16

2. MARCO DE REFERENCIA 17

2.1 MARCO TEÓRICO – CONCEPTUAL 17

2.1.1 Gestión Documental 17

2.1.2 Elementos de Análisis y Diseño de un Sistema de Gestión Documental 19

2.1.3 Reconocimiento de Caracteres Ópticos (OCR) 22

2.1.4 Proceso Unificado de Desarrollo de Software 24

2.1.5 Pruebas del Software 28

2.2 MARCO LEGAL O NORMATIVO 30

3. METODOLOGÍA 32

3.1 ENFOQUE DE LA INVESTIGACIÓN 32

3.2 LÍNEA DE INVESTIGACIÓN DE USB/SUB-LÍNEA DE FACULTAD / CAMPO TEMÁTICO DEL PROGRAMA 32

3.3 TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN 32

3.4 HIPÓTESIS 32

3.5 VARIABLES 33

3.5.1 Variables Independientes 33

3.5.2 Variables Dependientes. 33

4. DESARROLLO INGENIERIL 34

4.1 DESARROLLO VERSION 1.0 40

4.1.1 Etapa de Requisitos. 40

4.1.2 Etapa de Análisis 46

4.1.3 Etapa de Diseño 59

4.1.4 Etapa de Implementación 62

4.1.5 Etapa de Pruebas 63


4.2.1 Etapa de Requisitos. 65

4.2.2 Etapa de Análisis. 71





4.3.1 Etapa de Requisitos 94

4.3.2 Etapa de Análisis 94




5. CONCLUSIONES 107

6. RECOMENDACIONES 108

BIBLIOGRAFIA 108 GLOSARIO 109 ANEXOS 110

LISTA DE TABLAS

Pág.

Tabla 1. Cuadro comparativo (Software de Gestión Documental) 14

Tabla 2. Caso de Uso Ingresar al Sistema (Versión 1) 42

Tabla 3. Caso de Uso Administrar Cargo (Versión 1) 43

Tabla 4. Caso de Uso Administrar Unidad Administrativa (Versión 1) 43

Tabla 5. Caso de Uso Administrar Empleado (Versión 1) 44

Tabla 6. Caso de Uso Administrar Procedimiento (Versión 1) 44

Tabla 7. Caso de Uso Administrar Tipo de Documento (Versión 1) 45

Tabla 8. Caso de Uso Administrar Flujo de Documento (Versión 1) 45

Tabla 9. (Análisis) Caso de Uso Administrar Cargo (Versión 1) 47

Tabla 10. (Análisis) Caso de Uso Administrar Unidad Administrativa (Versión 1) 49

Tabla 11. (Análisis) Caso de Uso Administrar Empleado (Versión 1) 51

Tabla 12. (Análisis) Caso de Uso Administrar Tipos de Documento (Versión 1) 53

Tabla 13. (Análisis) Caso de Uso Administrar Usuarios (Versión 1) 55

Tabla 14. (Análisis) Caso de Uso Radicar (Versión 1) 57

Tabla 15. (Análisis) Caso de Uso Distribuir (Versión 1) 58

Tabla 16. Caso de Uso Ingresar al Sistema (Versión 2) 67

Tabla 17. Caso de Uso Administrar Tipo Definición (Versión 2) 68

Tabla 18. Caso de Uso Administrar Valor Definición (Versión 2) 68

Tabla 19. Caso de Uso Administrar Empleado (Versión 2) 69

Tabla 20. Caso de Uso Administrar Procedimiento (Versión 2) 69

Tabla 21. Caso de Uso Administrar Tipo de Documento (Versión 2) 70

Tabla 22. Caso de Uso Administrar Flujo de Documento (Versión 2) 70

Tabla 23. Caso de Uso Administrar Usuario (Versión 2) 71

Tabla 24. (Análisis) Caso de Uso Administrar Tipo Definición (Versión 2) 72

Tabla 25. (Análisis) Caso de Uso Administrar Valor Definición (Versión 2) 74

Tabla 26. (Análisis) Caso de Uso Administrar Empleado (Versión 2) 76

Tabla 27. (Análisis) Caso de Uso Administrar Procedimiento (Versión 2) 78

Tabla 28. Caso de Uso Administrar Tipo Documento (Versión 2) 80

Tabla 29. (Análisis) Caso de Uso Administrar Flujo Documento (Versión 2) 82

Tabla 30. (Análisis) Caso de Uso Administrar Usuario (Versión 2) 84


Tabla 32. (Análisis) Caso de Uso Distribuir (Versión 2) 87


Tabla 34. (Análisis) Caso de Uso Consultar (Versión 3) 98

Tabla 35. Diccionario de datos tabla (Empleados) 99

Tabla 36. Diccionario de datos tabla (Tipos_Definiciones) 100

Tabla 37. Diccionario de datos tabla (Valores_Definiciones) 100

Tabla 38. Diccionario de datos tabla (Flujo_Documentos) 101

Tabla 39. Diccionario de datos tabla (Documentos) 101

Tabla 40. Diccionario de datos tabla (Historicos) 102

Tabla 41. Diccionario de datos tabla (Procedimientos) 103

Tabla 42. Diccionario de datos tabla (Tipos_Documentos) 103

Tabla 43. Diccionario de datos tabla (Usuarios) 104

Tabla 44. Roles del sistema 105

LISTA DE FIGURAS

Pág.

Figura 1. Ciclo vital del documento. 22 Figura 2. El desarrollo del Proceso Unificado 25 Figura 3. Un ciclo con sus fases e iteraciones 26 Figura 4. Modelo del Proceso Unificado 27 Figura 5. Los cinco flujos de trabajo 28 Figura 6. Solicitud de Reintegro de Estudiantes 34 Figura 7. Solicitud de Contenidos Analíticos 35 Figura 8. Solicitud de Aplazamiento o Cancelación de Semestre 35 Figura 9. Solicitud de Transferencia de Programa 36 Figura 10. Inscripción de Asignaturas 36 Figura 11. Solicitud de Adición y Cancelación de Asignaturas 37 Figura 12. Cambio de Plan de Estudios 37 Figura 13. Solicitud de Suficiencia o Validación de Asignaturas 38 Figura 14. Actas de Nodo 38 Figura 15. Solicitud de Requisición de Elementos de Oficina 39 Figura 16. Memorandos 39 Figura 17. Solicitud de Cambio de Proyecto de Grado 40 Figura 18. Modelo de Dominio (Versión 1) 41 Figura 19. Caso de Uso de Requerimientos (Versión 1) 42 Figura 20. Caso de Uso Administrar Cargos (Versión 1) 47 Figura 21. Caso de Uso Administrar Unidad Administrativa (Versión 1) 49 Figura 22. Caso de Uso Administrar Empleado (Versión 1) 51 Figura 23. Caso de uso Administrar Tipo de Documento (Versión 1) 53 Figura 24. Caso de Uso Administrar Usuario (Versión 1) 55 Figura 25. Caso de Uso Radicar (Versión 1) 56 Figura 26. Caso de Uso Distribuir (Versión 1) 58 Figura 27. Modelo de Base de Datos propuesta 60 Figura 28. Modelo Entidad Relación SIGD Versión 1 61 Figura 29. Modelo de Clases SIGD Versión 1 63 Figura 30. Grafica de resultado de pruebas (Versión 1) 65 Figura 31. Modelo de Dominio (Versión 2) 66 Figura 32. Caso de Uso de Requerimientos (Versión 2) 67 Figura 33. Caso de Uso Administrar Tipo Definición (Versión 2) 72 Figura 34. Caso de Uso Administrar Valor Definición (Versión 2) 74 Figura 35. Caso de Uso Administrar Empleado (Versión 2) 76 Figura 36. Caso de Uso Administrar Procedimiento (Versión 2) 78 Figura 37. Caso de Uso Administrar Tipo Documento (Versión 2) 80 Figura 38. Caso de Uso Administrar Flujo Documento (Versión 2) 82 Figura 39. Caso de Uso Administrar Usuario (Versión 2) 84 Figura 40. Caso de Uso Radicar (Versión 2) 85

Figura 41. Caso de Uso Distribuir (Versión 2) 87 Figura 42. Modelo Entidad Relación SIGD Versión 2 90 Figura 43. Modelo de Clases SIGD Versión 2 92 Figura 44. Grafica de resultado de pruebas (Versión 2) 93 Figura 45. Caso de Uso Radicar (Versión 3) 95 Figura 46. Ejemplo de clasificación de documentos electrónicos 97 Figura 47. Ejemplo de ordenación de documentos electrónicos 97 Figura 48. Caso de Uso Consultar (Versión 3) 98 Figura 49. Modelo de Clases del Servlet Adicionado con la Digitalización 105 Figura 50. Grafica de resultado de pruebas (Versión 3) 106

12

INTRODUCCIÓN

Durante la historia reciente de la humanidad la información se ha convertido en el elemento esencial para la construcción del poder, llegando al punto en que se puede afirmar que la persona, empresa o nación que tiene la información tiene el poder. Es por esto la creciente preocupación del mundo por la apropiación tanto material como social de la información. Una forma de hacer apropiación material adecuada es brindar el tratamiento apropiado para la manipulación y conservación de la información que de la actividad realizada se genere. La sociedad actual, genera grandes volúmenes de información que algunos años atrás parecería prácticamente imposible, lo que ha obligado a las empresas a cambiar las antiguas técnicas de almacenamiento de su información. Dando paso a una nueva forma de gestión documental en la cual los sistemas pasan a formar parte esencial de este proceso. En el ámbito interno de la ingeniería del software se ha trabajado arduamente en dar solución a estas inquietudes. Es por eso que aparece la concepción de sistemas de gestión documental, que no es más que un paquete informático que ayuda a las empresas a la correcta recepción, distribución, manipulación y almacenamiento de su información. El programa de Ingeniería de Sistemas de la Universidad de San Buenaventura - sede Bogotá plantea una solución informática para la administración de los documentos internos y externos de este programa, que en el futuro puede ser aplicable a los demás programas de la Universidad. El objetivo esencial de implementar un software de gestión documental en el programa de Ingeniería de Sistemas de la Universidad de San Buenaventura - sede Bogotá, es la optimización de los procesos y disminución de los tiempos de respuesta a solicitudes, tanto a usuarios internos como externos de la institución, además de conservar y evitar la pérdida de documentos. La solución informática que se plantea en este documento, se desarrolla bajo la metodología conocida con el nombre de Proceso Unificado de Desarrollo de Software, y con herramientas de software libre que permitan de esta forma brindarle al programa de Ingeniería de Sistemas, una solución informática óptima de gestión documental y sin ningún costo de licenciamiento.

13

1. PLANTEAMIENTO DEL PROBLEMA

1.1 ANTECEDENTES

El programa de Ingeniería de Sistemas de la Universidad de San Buenaventura sede Bogotá, realiza su gestión documental en forma manual, almacenando sus archivos en carpetas físicas y sin definir un estándar óptimo de sus tiempos de respuestas, a usuarios según el tipo de documento o trámite que se realice. Es por esto, que el programa de Ingeniera de Sistemas dentro de su campo temático de desarrollo de software inició el proyecto Análisis, Diseño e Implementación de un Sistema de Gestión Documental para la USB utilizando herramientas GNU. De igual manera en el primer semestre del 2007 se llevó a cabo un proyecto de grado realizado por dos estudiantes de Ingeniería de Sistemas cuyo titulo es Diseño de un Sistema de Gestión Documental para el Programa de Ingeniería de Sistemas de la Universidad de San Buenaventura - sede Bogotá. En el cual se desarrollo la fase de análisis que requiere el software de gestión documental. En Colombia y en el mundo ya se han desarrollado e implementado con éxito algunos software de gestión documental, desarrollados en diversas herramientas tanto en software libre como en software licenciado y según las necesidades de las empresas que los han adquirido. En la tabla 1 se muestra en detalle estas características.

14

Tabla 1. Cuadro comparativo (Software de Gestión Documental)

SOTWARE EMPRESA FORMATOS LICENCIA SOFTWARE ALMACENAMIENTO SEGUIMIENTO

LiquidOffice Infoviews (México)

xml, html y pdf Perpetua, por

usuario registrado Web

Sql Server 2000 Formato

Electrónico. SI

Docuware Docuware (Alemania)

tiff, pdf, gif Licencia adicional

Sql Server Visual Basic

Sql Server 2000 Escaneado e

Indexado. NO

Gitdoc Gitdoc

(España) tiff, pdf, jpg, bmp,

xls, doc, pps Licencia adicional

Sql Server Visual Basic Sql Server

Escaneado e Indexado.

SI

DocsDB Semántica (España)

tiff Enterprise Php

Sql Server Escaneado e

Indexado. SI

Gestión de Documentos Wilkinsonpc (Colombia)

no se utilizan imágenes

Freeware 4D

Postgres Digitalizado. SI

Orfeo Comu. Orfeo (Colombia)

tiff GPL (General

Public License) php 5

Oracle 10g, MsSql Escaneado e

Indexado. SI

Royal ECM Royal

Technologies tiff, bmp, pcx, dcx, cals, pbf, pda, pdf

Enterprise No se sabe Escaneado e

Indexado. SI

SAD Sysdatec tiff Enterprise Oracle 10g Escaneado e

Indexado. SI

Siam IRS InfoDoc tiff, bmp Enterprise C++, Oracle,

FoxPro, MsSql Escaneado e

Indexado. SI

AAA-Sevenet Lexco tiff No se sabe Oracle, Sql Server, Postgres, MySql

Escaneado e Indexado

SI

Archivos LTDA Microópticos

Archivos LTDA (Colombia)

no se utilizan imágenes

No se sabe Delphi Borland

Interbase Digitalizado. SI

Windows® SharePoint™ Services.

Microsoft (EEUU)

xls, doc, pps Libre Servidor Web

SQL Server 2000 Microsoft Web

Storage. SI

15

1.2 DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA

En la actualidad el programa de Ingeniería de Sistemas de la Universidad de San Buenaventura - sede Bogotá, no cuenta con un sistema de gestión documental que controle el flujo, estado y disposición de los documentos, que regularmente entran y salen de las diferentes dependencias, ocasionando problemas como pérdida de información, tiempos de respuesta lentos a los procesos y deficiencia en la atención al público. ¿Cómo diseñar e implementar el sistema de gestión documental para el programa de Ingeniería de Sistemas de la Universidad de San Buenaventura - sede Bogotá? 1.3 JUSTIFICACIÓN

Con la implementación de un sistema de gestión documental desarrollado con la metodología de El Proceso Unificado de Desarrollo de Software y con herramientas de desarrollo libres, se obtiene un producto software de excelente calidad, con estándares internacionales y sin ningún costo, que dé solución a la perdida de información y a los tiempos de respuesta lentos que afectan el programa de Ingeniería de Sistemas, permitiéndole brindar a sus usuarios un mejor servicio. 1.4 OBJETIVOS DE LA INVESTIGACIÓN

1.4.1 Objetivo General Diseñar e implementar un software de gestión documental para el programa de Ingeniería de Sistemas de la Universidad de San Buenaventura - sede Bogotá, con herramientas de software libre y bajo la metodología del Proceso Unificado de Desarrollo de Software. 1.4.2 Objetivos Específicos

Validar el modelo de base de datos propuesto en el proyecto de grado “Diseño de un Sistema de Gestión Documental para el Programa de Ingeniería de Sistemas de la Universidad de san Buenaventura sede-Bogotá”.

Diseñar las interfaces de usuario y el mapa de navegación del software de gestión documental.

Implementar los módulos de radicación y distribución de documentos para el software de gestión documental.

16

Realizar pruebas del software de gestión documental. 1.5 ALCANCES Y LIMITACIONES DEL PROYECTO

El proyecto culmina con la implementación del sistema de gestión documental en herramientas de software libre, para el programa de Ingeniería de Sistemas de la Universidad de San Buenaventura sede-Bogotá, el cual comprende la digitalización, carga, radicación y distribución de documentos todo esto teniendo en cuenta la disponibilidad de equipos (scanner) para la digitalización de documentos, en el desarrollo de pruebas.

17

2. MARCO DE REFERENCIA

2.1 MARCO TEÓRICO – CONCEPTUAL

2.1.1 Gestión Documental Se define Gestión documental como el Conjunto de actividades administrativas y técnicas tendientes a la planificación, manejo y organización de la documentación producida y recibida por las entidades, desde su origen hasta su destino final, con el objeto de facilitar su utilización y conservación. Un Sistema de gestión documental se puede concebir como el conjunto de instrucciones en las que se detallan las operaciones para el desarrollo de los procesos de la gestión documental al interior de cada entidad, tales como producción, recepción, distribución, trámite, organización, consulta, conservación y disposición final de los documentos. El sistema de gestión documental debe asegurar la asignación de recursos económicos, humanos y físicos que permitan el desarrollo armónico de las distintas fases archivísticas con los criterios operativos del mismo. Con la realización del Sistema de gestión documental se pretende lograr los siguientes aspectos. Resaltar la importancia del papel de los documentos y archivos, como

lenguaje natural de la administración, para el funcionamiento de la misma, elementos de apoyo decisivos para la transparencia y el control de la gestión y garantía de los derechos individuales y colectivos.

La racionalización y la normalización de la documentación desde su

producción hasta su destino final. Normalizar la utilización de materiales, soportes y equipos de calidad y que a

la vez preserven el cuidado del medio ambiente. Lograr una acertada normalización en los procedimientos para el recibo,

radicación y distribución de la correspondencia mediante la utilización de sistemas eficientes.

Regular el manejo y organización del sistema de administración de

documentos y archivos a partir de la noción de Archivo Total y los enunciados de finalidad, responsabilidad, confidencialidad, seguridad y accesibilidad.

18

Implementar el desarrollo de procesos básicos de aplicación de la tabla de Retención Documental, organización, transferencias primarias, recuperación, preservación, conservación de la información y disposición final de los documentos.

Facilitar la recuperación de la información en forma rápida y oportuna. Encaminar los archivos para que sean verdaderos centros de información,

útiles para la administración e importantes para la cultura. El manejo integral de los documentos y de la información como base para la

toma de decisiones y la preservación de la memoria institucional. La integración de los estamentos institucionales en torno a objetivos

comunes y a una política informativa total. La evaluación y valoración de la documentación para evitar la acumulación

innecesaria de información y reducir costos en la producción y conservación del acervo documental.

La simplificación de trámites en los procesos administrativos con miras al

flujo normal y eficaz de la información. La normalización de las tareas archivísticas a la luz de la nueva concepción

del ARCHIVO TOTAL. Dentro del proceso archivístico tradicionalmente las entidades han centrado su atención y preocupación en aquella documentación que se encuentra almacenada en los llamados Archivos Centrales, por otra parte existe el desconocimiento y poca importancia del documento durante su primera fase de formación dentro del sector público y privado de Colombia. Un sistema de gestión documental permite tener una visión exacta y completa de las políticas, funciones, programas y servicios de una entidad, lo cual se ve reflejado en un sistema institucional de archivos plenamente organizado y definido que garantiza el flujo y disposición de la información en forma ágil y oportuna. Para elaborar un Software de gestión documental, se deben considerar los siguientes aspectos. Administrativos: se refiere a contemplar las situaciones administrativas de la

gestión de documentos en aspectos como la transparencia, la simplificación de trámites y la eficiencia de la administración.

19

Económicos: hacen relación al análisis de situaciones de tipo económico de la gestión de documentos, como la reducción de costos derivados de la conservación de documentos innecesarios y la racionalización de los recursos destinados para la gestión documental.

Archivísticos: son considerados la base de un Software; se refieren a la

teoría sobre la gestión de documentos. Estos son: el concepto de archivo total, el ciclo vital del documento, el principio de procedencia y el principio de orden original.

A partir del estudio y análisis de la documentación el sistema de gestión documental normaliza todas las fases de gestión documental: producción o recepción; preservación y disposición final (eliminación o conservación) de la información institucional como recurso indispensable para la toma de decisiones y la reservación del patrimonio documental de la entidad. 1 2.1.2 Elementos de Análisis y Diseño de un Sistema de Gestión Documental

En el análisis y diseño de un sistema de gestión documental los aspectos más relevantes a tener en cuenta son:

o Diagnóstico. El diseño y desarrollo de un Software de gestión documental, obedece a un plan de acción con líneas concretas que facilite su implementación de manera efectiva, contempla la identificación de problemas, oportunidades y objetivos, análisis y determinación de los requerimientos de información, mantenimiento, evaluación y documentación del programa, planes de mejoramiento y planes de contingencia. Debe corresponder a un plan discriminado a corto, mediano y largo plazo, contar con un órgano coordinador de la gestión de documentos que garantice su adecuado desarrollo y que a través del cual se definan las políticas generales de la gestión documental en cada organización y un conjunto de directrices que faciliten la planeación de la documentación. Para realizar este diagnóstico las entidades podrán retomar o actualizar los aspectos metodológicos relacionados con las etapas de investigación preliminar sobre la institución y análisis e interpretación de la información recolectada.

1 Tomado del proyecto de grado “Diseño de un Sistema de Gestión Documental para el

Programa de Ingeniería de Sistemas de la Universidad de San Buenaventura - sede Bogotá”,

p. 27 – 30.

20

o Requisitos Técnicos. Se refieren a las condiciones o instrumentos técnicos previos como: contar con manuales de procesos y procedimientos, con compilación de formas o formatos regulados, manual de funciones y tablas de retención documental, tablas de valoración documental, adopción de normas técnicas y normatividad en general. Para ello, se deberán verificar el cumplimiento de las siguientes condiciones: Centralización de la recepción y envío de los documentos. Definición de procedimientos de distribución de documentos internos

y externos. Contar con el Comité de Archivo respectivo el cual deberá tener definido su

reglamento y funciones. Disponer de un reglamento de archivos para la entidad, que garantice el

cumplimiento de al menos los siguientes aspectos: Fases de formación del archivo, control sobre la entrada y salida de los documentos, acceso a los documentos, ordenación y descripción de los fondos de archivo, conservación de documentos, adopción de las normas técnicas colombianas que se hayan establecido en materia de archivos y documentos, existencia de la coordinación de la función archivística dentro de la estructura administrativa de la entidad de acuerdo con lo establecido por la Legislación Colombiana (Ley 594 del 2000), participación de la dependencia en los comités internos relacionados con la definición de procesos y procedimientos, gestión de calidad, y comités de informática, entre otros.

o Requisitos Administrativos. Hacen relación a la necesidad de integrar el sistema de gestión documental con todas las funciones administrativas de la entidad, así como con los sistemas de información, con los aplicativos y demás herramientas informativas de las que haga uso la entidad, en atención a las siguientes consideraciones: La Gestión de Documentos debe inscribirse como un programa estratégico

de la entidad, con el apoyo de la alta dirección. Tener definido el sistema de administración de archivos de la entidad

(centralizado, o descentralizado). Contar con la participación de las diferentes áreas de la entidad, en especial

con la estructura directiva y aquellas áreas relacionadas con las compras y suministros, la tecnología, el desarrollo organizacional y el presupuesto.

El archivo debe contar con el talento humano debidamente asignado a

funciones de archivo y con dedicación exclusiva para realizar dicha labor.

21

La entidad deberá contar con un programa de capacitación que permita a los funcionarios del archivo ampliar y mejorar sus conocimientos en aspectos de la gestión documental y la organización de los archivos, además formación en el área de la auditoria de información y manejo de procesos.

Las instalaciones de los archivos deben reunir las condiciones mínimas para

el adecuado desarrollo de su función, en relación con las características arquitectónicas y medioambientales, espacio, distribución de áreas de acuerdo con el flujo de los procesos del archivo, ubicación con relación a las dependencias, mobiliario y equipo.

Para efectos de la conceptualización de un Software de gestión documental, se determinan los siguientes procesos que estarán interrelacionados entre sí y se desarrollarán en las unidades de correspondencia. Producción de documentos. Recepción de documentos. Distribución de documentos. Trámite de documentos. Organización de documentos. Consulta de documentos. Conservación de documentos. Disposición final de documentos. Los procesos anteriores se llevarán a cabo durante las etapas del ciclo vital del documento, que se divide en;

Archivo de Gestión En esta fase se desarrollan los siguientes procesos del Programa de Gestión Documental: Producción. Recepción. Distribución. Trámite. Organización. Consulta. Conservación. Disposición final de documentos.

Archivo Central

En esta fase se desarrollan los siguientes procesos del Programa de Gestión Documental:

22

Organización. Consulta. Conservación. Disposición final de documentos.

Archivo Histórico En esta fase se desarrollan los siguientes procesos del Programa de Gestión Documental: Organización. Consulta. Conservación. Disposición final de documentos. 2

La figura 1. Ilustra los procesos mencionados dentro del ciclo vital del documento. Figura 1. Ciclo vital del documento.

Fuente. Diseño de un Sistema de Gestión Documental para el Programa de Ingeniería de Sistemas de la Universidad

de San Buenaventura - sede Bogotá

2.1.3 Reconocimiento de Caracteres Ópticos (OCR)

OCR es un tipo de software que se encarga de reconocimiento óptico de caracteres .Se encarga de extraer de una imagen los caracteres de un texto y los guarda en un formato, cadena de caracteres, que pueda editarse como texto.3 Un ejemplo de la función principal de este tipo de software, es guardar el texto contenido en las imágenes (ya sean de una fotografía o un documento que se haya escaneado), para poder editarlo, reconociéndolo y transformándolo en una cadena de caracteres (ya sea ASCII o Unicode). OCR evita pasar a mano, es decir, carácter por carácter en un editor de texto.

2 Ibid. p. 54 – 58.

3 Web: http://www.alegsa.com.ar/Dic/ocr.php, 27 de noviembre de 2007, 07:10 p.m.

23

En el ejemplo anterior, el proceso de OCR se inicia a partir del análisis de la imagen que se escanea dando como resultado la conversión de los conjuntos de puntos (píxeles que forman la imagen) en caracteres manipulables, como los archivos producidos en cualquier tratamiento de textos. Una vez acabada esta parte, se inicia una fase de chequeo de los resultados para terminar exportando los resultados a otro tipo de aplicación (tratamientos de texto, programas de edición, hojas de cálculo, etc.) Mientras se ejecutan las acciones del reconocimiento de caracteres, las aplicaciones analizan las imágenes de los párrafos escritos para producir el correspondiente texto editable. Después de acabar el proceso, se puede exportar el texto reconocido, mediante los pertinentes formatos, a toda la amplia variedad de aplicaciones El software verifica las imágenes contra un diccionario integrado para encontrar los equivalentes más próximos a la forma del carácter o letra. A muy alta velocidad, el sistema asigna el código de computadora más equivalente y continúa hasta que acaba. Los programas actuales de OCR están basados en el análisis de características de los caracteres en vez de en la coincidencia de las matrices de estos, lo que permite una mayor velocidad en el proceso y el no tener que depender de una limitada base de fuentes. o Características de OCR.

El reconocimiento de caracteres ópticos puede convertir una gran cantidad de información en un corto período de tiempo.

Puede leer diferentes tipos de letras impresas o mecanografiadas y

diferentes clases de caracteres. Permite la entrada directa de información sin necesidad de digitar la

información. Ahorra el tiempo y el esfuerzo de desarrollar una reproducción digital de

cualquier documento. No hay necesidad de mecanografiar caracteres manualmente en un archivo digital

Puede leer un documento con una velocidad de 85 a 150 caracteres por

segundo.

24

Puede convertir un documento en varios formatos electrónicos como - Microsoft Word, Excel, HTML o PDF. Reconocimiento y confidencia de lo resultados son indicados y distribuidos al desarrollador. 4

o Pasos Básicos

Llevar la imagen del documento a la pantalla del Computador. Para ello se ha de utilizar un escáner que recoja las características del documento para convertirlo en una imagen digital. La resolución adecuada para la captura de las imágenes oscila, generalmente, entre los 300 y 400 puntos por pulgada, según la calidad y el tipo de documento. Crear las zonas. Esto debe realizarse para identificar las partes del documento que se quieren reconocer como texto, es decir, retenerse como gráficos. Las zonas de las páginas escaneadas son cajas que incluyen las partes a las que se va a aplicar el reconocimiento. Las áreas no incluidas en estas zonas serán ignoradas en el proceso. Realizar el proceso OCR. Esta operación es la que convierte la información de texto gráfico en texto editadle. Durante el OCR, las aplicaciones definen los caracteres de texto de la imagen y pueden realizar simultáneamente el chequeo del texto que se va identificando. Exportar el documento. La última fase consiste en exportar el texto resultante a la aplicación deseada.5 2.1.4 Proceso Unificado de Desarrollo de Software

o Historia del Proceso Unificado. El proceso unificado está equilibrado por ser el producto final de tres décadas de desarrollo y uso práctico. Desde el Proceso Objectory, pasando por el Proceso Objectory de Rational hasta el Proceso Unificado de Rational. Como se puede observar en la figura 2.

4 WEB: http://www.articuloz.com/article_75255.html, 27 de noviembre de 2007, 07:50 p.m.

5 Web: http://www.idg.es/macworld/content.asp?idart=30730, 28 de noviembre de 2007, 03:10

p.m.

25

Figura 2. El desarrollo del Proceso Unificado

Fuente. IVAR JACOBSON, GRADY BOOCH Y JAMES RUMBAUUUGH. El Proceso Unificado de Desarrollo de

Software, Madrid, Addison Wesley, 2000.

Su desarrollo ha recibido influencia de muchas fuentes. Pero las más fuertes han sido las de los métodos de Ericsson y Rational. o El Proceso Unificado en Pocas Palabras. Es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. Sin embargo, el Proceso Unificado es más que un simple proceso; es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto. El proceso unificado está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes software interconectados a través de interfaces bien definidas. El Proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling Language, UML) para preparar todos los esquemas de un sistema software. UML es una parte esencial del Proceso Unificado. Los verdaderos aspectos definitorios del Proceso Unificado se resumen en tres frases claves – dirigido por casos de uso, centrado en la arquitectura, e iterativo e incremental que es lo que hace único el Proceso Unificado. Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante, los casos de uso representan los requisitos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de

26

uso, el cual describe la funcionalidad total del sistema. Los casos de uso guían su diseño, implementación y prueba. La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado. Debe haber interacción entre los casos de uso y la arquitectura. Por un lado, los casos de uso deben encajar en la arquitectura cuando se llevan a cabo. Por otro lado, la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, ahora y en el futuro. En realidad, tanto la arquitectura como los casos de uso deben evolucionar en paralelo. Es iterativo e incremental ya que trabaja como pequeños proyectos, cada iteración que resulta es un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo y los incrementos al crecimiento del producto. o La Vida del Proceso Unificado. El proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema, cada ciclo concluye con una versión del producto, cada ciclo consta de cuatro fases: inicio, elaboración, construcción y transición. Cada fase se subdivide a su vez en iteraciones como lo muestra la figura 3.

Figura 3. Un ciclo con sus fases e iteraciones



o El Producto. Cada ciclo produce una nueva versión del sistema y cada versión es un producto preparado para su entrega. Consta de un cuerpo de código fuente incluido en componentes que puede compilarse y ejecutarse, además de manuales y otros productos asociados. - Un modelo de casos de uso, con todos los casos de uso y su relación con

los usuarios. - Un modelo de análisis, con dos propósitos: refinar los casos de uso con

más detalle y establecer la asignación inicial de funcionalidad del sistema a un conjunto de objetos que proporcionan el comportamiento.

27

- Un modelo de diseño que define: (a) la estructura estática del sistema en la forma de sub-sistemas, clases e interfaces y (b) los casos de uso reflejados como colaboraciones entre los subsistemas, clases e interfaces.

- Un modelo de implementación, que incluye componentes (que representan al código fuente) y la correspondencia de las clases con los componentes.

- Un modelo de despliegue, que define los nodos físicos (ordenadores) y la correspondencia de los componentes con esos nodos.

- Un modelo de prueba, que describe los casos de prueba que verifican los casos de uso.

- Y, por su puesto, una representación de la arquitectura. El sistema también debe tener un modelo del dominio o modelo del negocio que describa el contexto del negocio en el que se halla el sistema (ver figura 4). Figura 4. Modelo del Proceso Unificado



o Fases dentro de un Ciclo. Cada ciclo se desarrolla a lo largo del tiempo, a su vez, se divide en cuatro fases, durante la fase de inicio, se desarrolla una descripción de producto final a partir de una buena idea y se presenta el análisis de negocio para el producto. Durante la fase de elaboración, se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema. Durante la fase de construcción, se crea el producto, en esta fase la línea base de la arquitectura crece hasta convertirse en el sistema completo. La descripción evoluciona hasta convertirse en un

28

producto preparado para ser entregado a la comunidad de usuarios. Y la fase de transición cubre el perdió durante el cual el producto se convierte en versión beta. En la versión beta un número reducido de usuarios con experiencia prueba el producto e informa de defectos y deficiencias. La figura 5. muestra los cinco flujos de trabajo – requisitos, análisis, diseño, implementación y prueba que tienen lugar sobre las cuatro fases: inicio, elaboración, construcción y transición. 6

Figura 5. Los cinco flujos de trabajo



2.1.5 Pruebas del Software Probar bien un sistema no es una actividad trivial para aprender. Algunos lo consideran un arte y aprender a hacerlo bien requiere práctica y experiencia. El 50% del tiempo y esfuerzo del desarrollo de Software corresponde a la prueba. La prueba de un software se define como el proceso de ejercitar o evaluar el sistema, por medios manuales o automáticos, para verificar que satisface los

6 IVAR JACOBSON, GRADY BOOCH Y JAMES RUMBAUUUGH. El Proceso Unificado de

Desarrollo de Software, Madrid, Addison Wesley, 2000.

29

requerimientos o para identificar diferencias entre los resultados esperados y los que produce el sistema (IEEE). Niveles de Prueba

¨ Prueba de módulo o de unidad ¨ Prueba de integración ¨ Prueba funcional ¨ Prueba del sistema y prueba de aceptación ¨ Prueba de instalación ¨ Prueba de vida Tipos de Pruebas

¨ Pruebas estáticas. ¨ Pruebas dinámicas. Principios de la Prueba de Sistemas

La prueba es el proceso de ejecutar un programa con la intención de encontrar errores (parece un enfoque destructivo. Actitud correcta: una prueba exitosa es aquella que encuentra un error). Es imposible probar completamente cualquier módulo no trivial o cualquier sistema. La prueba implica creatividad y trabajo duro. La prueba puede prevenir posibles errores, cuando se realizan a través de las diferentes etapas del ciclo de vida. Es mejor que las pruebas sean realizadas por personas diferentes a quienes hicieron el desarrollo del sistema. Procedimientos y Técnicas Generales de Prueba

Use siempre datos de entrada bien definidos para los que se conozcan los resultados correctos que deben obtenerse. Detecte primero los defectos obvios (usando datos de prueba muy simples) y luego sí realice pruebas más complejas. Cuando modifique algo mientras prueba realice un solo cambio cada vez y utilice los mismos datos con los que detectó el defecto. Pruebe el programa para verificar si detecta entradas incorrectas.

30

Etapas Involucradas en Todas las Pruebas Seleccionar qué es lo que debe medir la prueba, es decir cuál es su objetivo, para qué exactamente se hace la prueba. Decidir cómo se va a realizar la prueba, es decir qué clase de prueba se va a utilizar para medir la calidad escogida y qué clase de elementos de prueba se deben usar. Desarrollar los casos de prueba. Un caso de prueba es un conjunto de datos o situaciones de prueba que se utilizarán para ejecutar la unidad que se prueba o para revelar algo sobre el atributo de calidad que se está midiendo. Determinar cuáles deberían ser los resultados esperados o correctos de los casos de prueba y crear el documento con los casos y sus resultados esperados, denominado oráculo de prueba, antes de realizar la prueba. Ejecutar los casos de prueba. Comparar los resultados de la prueba con los resultados esperados. Cualquier discrepancia entre ellos significa un error. Típicamente el error está en el sistema o unidad probada, pero también puede ser generado por algún aspecto del mismo proceso de prueba o en el oráculo de prueba. 7 2.2 MARCO LEGAL O NORMATIVO

En Colombia la gestión de documentos se enmarca de acuerdo a las siguientes normas: ISO 15489-1. Gestión de documentos. Generalidades. Declaración de principios dirigida a la alta dirección o altos cargos que toman decisiones. Estrategia, políticas, etc. Esta norma propone como metodología de diseño evaluar las siguientes etapas:

ETAPA A: INVESTIGACIÓN PRELIMINAR

ETAPA B: ANÁLISIS DE LAS ACTIVIDADES DE LA ORGANIZACIÓN

ETAPA C: IDENTIFICACIÓN DE REQUISITOS

ETAPA D: EVALUACIÓN DE LOS SISTEMAS EXISTENTES

ISO 15489-2. Gestión de documentos. Directrices. Explicación de la metodología de diseño.

7 http://eisc.univalle.edu.co/materias/Material_Desarrollo_Software/PRUEBASoftware.pdf, 26 de

Mayo de 2008, 4:42 PM.

31

Esta norma propone como metodología de diseño evaluar las siguientes etapas:

ETAPA E: IDENTIFICACIÓN DE LAS ESTRATEGIAS PARA CUMPLIR LOS REQUISITOS.

ETAPA F: DISEÑO DE UN SISTEMAS DE GESTIÓN

ETAPA G: IMPLEMENTACIÓN DEL SISTEMA

ETAPA H: REVISIÓN POSTERIOR A LA IMPLEMENTACIÓN La legislación Colombiana propone algunas disposiciones atinentes a los archivos de gestión, centrales e históricos, para sustentar la elaboración de proyectos y la definición de acciones archivísticas que hagan que los archivos y centros de información sean útiles para la gestión administrativa y partes fundamentales del patrimonio de cada organización.

Ley 594 del 2000: Ley General de Archivos.

NTC 4095: Norma general para la descripción archivística. ACUERDOS EXPEDIDOS POR EL CONSEJO DIRECTIVO DEL ARCHIVO

GENERAL DE LA NACIÓN

Acuerdo 07 de 1994: Reglamento General de Archivos.

Acuerdo 09 de 1997: Reglamenta el procedimiento para la evaluación de las Tablas De Retención Documental.

Acuerdo 11 de 1996: Establece criterios de conservación y organización de documentos.

Acuerdo 48 de 2000: Desarrolla el articulo 59 del capítulo 7 "Conservación de documentos" del Reglamento General de Archivos sobre conservación preventiva, conservación y restauración documental.

Acuerdo 49 de 2000: Desarrolla el articulo 61 del capítulo 7 "Conservación de documentos" del Reglamento General de Archivos sobre "Condiciones de edificios y locales destinados a archivos".

Acuerdo 50 de 2000: Desarrolla el artículo 64 del título VIl "Conservación de documentos" del Reglamento General de Archivos sobre "Prevención de deterioro de los documentos de archivo y situaciones de riesgo".8

8 Op. Cit. Proyecto de grado, p. 25 - 27

32

3. METODOLOGÍA

3.1 ENFOQUE DE LA INVESTIGACIÓN

Según los enfoques de investigación que define la Universidad, este proyecto se encuentra inmerso en el enfoque Empírico-Analítico, cuyo interés sobresaliente es el práctico. 3.2 LÍNEA DE INVESTIGACIÓN DE USB/SUB-LÍNEA DE FACULTAD / CAMPO TEMÁTICO DEL PROGRAMA

Con base en la documentación del proyecto general concerniente a la información que sustenta la investigación que maneja la Universidad de San Buenaventura, se ha determinado que la línea de investigación en la cual el proyecto tiene cabida por las características propias de este, es la de tecnologías actuales y sociedad, la sublínea es la de sistemas de información y comunicación, en el campo temático de almacenamiento de información. 3.3 TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN

Las técnicas de recolección de información a utilizar es la encuesta, que es una herramienta para conocer las preferencias de los usuarios que tendrá el software, con ello garantizar que el usurario final obtendrá el mejor rendimiento de este producto. Se realizarán visitas a diferentes empresas que ya tienen en funcionamiento un sistema de gestión documental para determinar las conformidades y las no conformidades de estas empresas con el funcionamiento del software adquirido, al igual que a las casas desarrolladoras para determinar las características de estos sistemas y su valor comercial. La consulta de material bibliográfico en lo concerniente a la metodología del Proceso Unificado de Desarrollo de Software y documentación de las herramientas de software libre como son PostgreSQL y Java. 3.4 HIPÓTESIS

Con la implementación del software de gestión documental en el programa de Ingeniería de Sistemas de la Universidad de San Buenaventura – sede Bogota se estandarizaran los procesos, se reducirá la perdida de información y los tiempos de respuesta a usuarios disminuirán.

33

3.5 VARIABLES

3.5.1 Variables Independientes

Documentos, Tipos de documento (Información Interna, Cartas y Solicitudes, Formatos Requisiciones, Actas), medios de almacenamiento (escaneo, Digitalización). 3.5.2 Variables Dependientes.

Procesos (Producción de documentos, Recepción de documentos, Distribución de documentos, Tramite de documentos, Organización de documentos, Consulta de documentos, Conservación de documentos y Disposición final de documentos).

34

4. DESARROLLO INGENIERIL

El desarrollo ingenieril para este proyecto inicia con la evaluación del diseño propuesto en el proyecto de grado “Diseño de un Sistema de Gestión Documental para el Programa de Ingeniería de Sistemas de la Universidad de San Buenaventura - sede Bogotá”, en el cual tiene fundada la estructura este proyecto. En el proyecto anteriormente mencionado se realizó el levantamiento de información sobre como son los flujos de documentos actuales en el Programa de Ingeniería de Sistemas, es preciso enfatizar que estos procesos se están realizando de forma manual. La solución informática se desarrolla bajo la metodología de Proceso Unificado de Desarrollo de Software (RUP). Que fundamenta su representación gráfica en el modelo UML, para iniciar con esta metodología lo primero que se hizo fue el adecuar los diagramas de flujo de documentos que allí se tienen, y que representan las variables independientes del sistema de gestión documental. A continuación se presentan los diagramas de procesos (actividades) actuales. Figura 6. Solicitud de Reintegro de Estudiantes

Fuente. Los Autores

35

Figura 7. Solicitud de Contenidos Analíticos

Fuente. Los Autores

Figura 8. Solicitud de Aplazamiento o Cancelación de Semestre

Fuente. Los Autores

36

Figura 9. Solicitud de Transferencia de Programa

Fuente. Los Autores

Figura 10. Inscripción de Asignaturas

Fuente. Los Autores

CRYCRA: centro de registro y control académico

37

Figura 11. Solicitud de Adición y Cancelación de Asignaturas

Fuente. Los Autores

Figura 12. Cambio de Plan de Estudios

Fuente. Los Autores

38

Figura 13. Solicitud de Suficiencia o Validación de Asignaturas

Fuente. Los Autores

Figura 14. Actas de Nodo

Fuente. Los Autores

39

Figura 15. Solicitud de Requisición de Elementos de Oficina

Fuente. Los Autores

Figura 16. Memorandos

Fuente. Los Autores

40

Figura 17. Solicitud de Cambio de Proyecto de Grado

Fuente. Los Autores

El Proceso Unificado de Desarrollo de Software (RUP) se basa en un desarrollo en espiral e incremental, por esta razón el sistema de gestión documental se planteo en tres versiones, cada versiones cuenta con las etapas que determina la metodología, estas etapas son (Requisitos, Análisis, Diseño, Implementación y Pruebas), a continuación se detallan las tres versiones desarrolladas. 4.1 DESARROLLO VERSION 1.0

4.1.1 Etapa de Requisitos.

Requisitos candidatos es crear una lista de características que surgen en el transcurso de vida del sistema, que en la mayoría de veces son ideas (requisitos) de los clientes, usuarios y/o programadores, y así generan un equilibrio en el sistema y un flujo de trabajo inicial

41

Consideraciones de gestión del proyecto

o Estado: Validad o Costo estimado : 100000 o Prioridad: Importante o Nivel de riesgo: Significativo

Comprender el Contexto del Sistema Figura 18. Modelo de Dominio (Versión 1)

Fuente. Diseño de un Sistema de Gestión Documental para el Programa de Ingeniería de Sistemas de la Universidad

de San Buenaventura - sede Bogotá

Capturar los requisitos funcionales

El sistema debe distribuir los documentos a las diferentes dependencias (Unidad Administrativas) y generar un alerta o mensaje de notificación.

El sistema debe estar orientado y estructurado en una arquitectura WEB.

El sistema debe ser compatible a cualquier equipo de escáner.

42

Figura 19. Caso de Uso de Requerimientos (Versión 1)

Fuente. Los Autores

Descripción de Casos de Uso de Requerimientos (Versión 1)

Tabla 2. Caso de Uso Ingresar al Sistema (Versión 1)

Caso de Uso Ingresar al Sistema

Actores Administrador, Base de Datos.

Función Ingresar a SIGD por medio de un usuario y contraseña validados en la tabla Empleados de la base de datos.

Precondiciones Debe pertenecer a la Universidad de San

Buenaventura.

Asignación de privilegios para acceder al sistema Garantías de

éxito Se actualizan los datos del administrador

Flujo principal

1. El administrador ingresa al sistema SIGD , donde se encuentra con una casilla de ingreso, un usuario y una contraseña

2. Se ingresa el nombre de usuario y la respectiva contraseña del administrador.

3. Se oprime el botón Ingresar 4. Se valida el registro del administrador mediante el

43

nombre de usuario y su respectiva contraseña. 5. Se habilitan todo los módulos de SIGD.

Extensiones

En cualquier momento el sistema falla. 1. El administrador reinicia el sistema, y vuelve a iniciar

sesión.

Identificación no valida. 1. El sistema señala el error y rechaza la entrada.

Fuente. Los Autores

Tabla 3. Caso de Uso Administrar Cargo (Versión 1)

Caso de Uso Administrar Cargo

Actores Administrador, Base de Datos. Función Administrar la tabla de Cargos existente en el sistema.

Precondiciones El administrador debe haber iniciado sesión

Garantías de éxito

Se crea, se elimina, se modifica, o se consulta un registro de la entidad Cargos.

Flujo principal

1. SIGD inicia una nueva ventana mostrando el menú cargos.

2. El administrador elije la opción que desea del menú 3. El administrador guarda los cambios 4. El administrador cancela el proceso

Extensiones

En cualquier momento el sistema falla. 1. El administrador reinicia el sistema, y vuelve a iniciar

sesión.

El sistema genera las opciones por cada entidad 1. Crear 2. Modificar 3. Consultar 4. Eliminar

Fuente. Los Autores Tabla 4. Caso de Uso Administrar Unidad Administrativa (Versión 1)

Caso de Uso Administrar Unidad Administrativa


Función Administrar la tabla de Unidades Administrativas existente en el sistema.



Se crea, se elimina, se modifica, o se consulta un registro de la entidad Unidades Administrativas.

Flujo principal

1. SIGD inicia una nueva ventana mostrando el menú unidades administrativas.

44


Extensiones

En cualquier momento el sistema falla. 1. El administrador reinicia el sistema y vuelve a iniciar

sesión.


Fuente. Los Autores

Tabla 5. Caso de Uso Administrar Empleado (Versión 1)

Caso de Uso Administrar Empleado


Función Administrar la tabla Empleados existente en el sistema.



Se crea, se elimina, se modifica, o se consulta un registro de la entidad Empleados.

Flujo principal

1. SIGD inicia una nueva ventana mostrando el menú empleados.


Extensiones


sesión.


Fuente. Los Autores

Tabla 6. Caso de Uso Administrar Procedimiento (Versión 1)

Caso de Uso Administrar Procedimiento


Función Administrar la tabla de Procedimientos existente en el sistema para cada tipo de documento



Se crea, se elimina, se modifica, o se consulta un registro de la entidad Procedimientos.

45

Flujo principal

1. SIGD inicia una nueva ventana mostrando el menú procedimientos.


Extensiones


sesión.


Fuente. Los Autores

Tabla 7. Caso de Uso Administrar Tipo de Documento (Versión 1)

Caso de Uso Administrar Tipo de Documento


Función Administrar la tabla de Tipo Documentos existente en el sistema



Se crea, se elimina, se modifica, o se consulta un registro de la entidad Tipo Documentos

Flujo principal

1. SIGD inicia una nueva ventana mostrando un menú tipo documentos


Extensiones

En Cualquier momento el sistema falla. 1. El administrador reinicia el sistema y vuelve a iniciar

sesión.


Fuente. Los Autores Tabla 8. Caso de Uso Administrar Flujo de Documento (Versión 1)

Caso de Uso Administrar Flujo de Documento


Función Administrar la tabla Flujo Documentos ( los procedimientos realizados a cada documento en las diferentes Unidades Administrativas)

46



Se crea, se elimina, se modifica, o se consulta un registro de la entidad Flujo Documentos

Flujo principal

1. SIGD inicia una nueva ventana mostrando el menú flujo documentos.


Extensiones


sesión.


Fuente. Los Autores

Capturar los requisitos no funcionales

El software debe ser diseñado bajo herramientas de software libre. 4.1.2 Etapa de Análisis Una vez capturados los requerimientos para el software de gestión documental, se procederá al desarrollo de la etapa de análisis, utilizando el Lenguaje Unificado de Modelado (UML), el cual permite estructurar una representación grafica del funcionamiento del sistema.

47

Figura 20. Caso de Uso Administrar Cargos (Versión 1)

Fuente. Los Autores

Tabla 9. (Análisis) Caso de Uso Administrar Cargo (Versión 1)

Caso de Uso Administrar Cargo


Función Administrar la tabla Cargos existente en el sistema, permitiendo la creación de un nuevo cargo, la eliminación, la modificación y consulta de un cargo ya existente



Se crea, se elimina, se modifica, o se consulta un registro de esta entidad y se registran los cambios efectuados que hayan sido aprobados.

Flujo principal

1. SIGD inicia una nueva ventana mostrando el menú cargos.

2. SIGD muestra una lista con la información básica de todos los registros que contiene la entidad

3. El administrador elije la opción que desea del menú, oprimiendo sobre la opción que se desee. crear, consultar, modificar o eliminar.

4. El Administrador realiza el proceso que desee. (si es el caso)

5. El administrador guarda los cambios. 6. El administrador cancela los cambios

48

Extensiones


sesión.

Es necesario ingresar un nuevo cargo en la entidad. 1. El administrador puede ingresar un nuevo cargo en

cualquier momento, teniendo en cuenta que la identificación es automática, no se muestra en el formulario de ingreso este campo.

2. SIGD se encarga de verificar que el registro ingresado no exista.

Si existe, alerta diciendo que el dato esta repetido. 3. SIGD comprueba la transacción y la guarda.

Existen varios cargos que no son necesarios o no existen dentro de la institución.

1. El administrador puede eliminar uno o varios cargos. 2. SIGD se encarga de verificar que el cargo exista en el

sistema. 3. El administrador selecciona el cargo y lo elimina.

Los cargos sufrieron cambios con el paso del tiempo. 1. SIGD se encarga de verificar que el cargo exista en el

sistema. 2. El administrador selecciona el cargo. 3. El administrador realiza el cambio en la información

traída por SIGD mostrada en un formulario. 4. La información es aprobada y guardada por SIGD.

Los diferentes cargos pueden ser consultados en una vista general.

1. El administrador señala la opción de consulta SIGD muestra una tabla con todos los registros de esa

entidad Fuente. Los Autores

49

Figura 21. Caso de Uso Administrar Unidad Administrativa (Versión 1)

Fuente. Los Autores

Tabla 10. (Análisis) Caso de Uso Administrar Unidad Administrativa

(Versión 1)

Caso de Uso Administrar Unidad Administrativa


Función

Administrar la tabla Unidades Administrativas existente en el sistema, permitiendo la creación de una nueva unidad administrativa, la eliminación, la modificación y consulta de una unidad administrativa. ya existente



Se crea, se elimina, se modifica, o se consulta un registro de esta entidad, se registran los cambios efectuados que hayan sido aprobados.

Flujo principal

1. SIGD inicia una nueva ventana mostrando el menú unidades administrativas.


3. El administrador elije la opción que desea del menú, oprimiendo sobre la opción que se desee. crear, consultar, modificar o eliminar.

4. El administrador realiza el proceso que desee. (si es el

50

caso) 5. El administrador guarda los cambios 6. El administrador cancela los cambios

Extensiones


sesión.

Es necesario ingresar una nueva unidad administrativa. 1. El administrador puede ingresar un nuevo registro en



- Si existe, alerta diciendo que el dato esta repetido, y detendrá el proceso.

3. SIGD comprueba la transacción y la guarda.

Existen varias unidades administrativas que no son necesarios o no existen dentro de la institución.

1. El administrador puede eliminar uno o varios registros. 2. SIGD se encarga de verificar que el registro de la

unidad administrativa exista en el sistema. 3. El administrador selecciona el registro y lo elimina.

Las Unidades Administrativas pueden generar cambios a medida del tiempo.

1. SIGD se encarga de verificar que el registro de la unidad administrativa exista en el sistema.

2. El administrador selecciona el registro de la unidad administrativa.

3. El administrador realiza el cambio en la información traída por SIGD mostrada en un formulario.

4. La información es aprobada y guardada por SIGD. - Si existe un error en los caracteres ingresados SIGD

alertara de este error y detendrá el proceso.

Los diferentes Registros de Unidades Administrativas pueden ser consultados en una vista general (una tabla).

1. El administrador señala la opción de consulta 2. SIGD muestra una tabla con todos los registros de esa


51

Figura 22. Caso de Uso Administrar Empleado (Versión 1)

Fuente. Los Autores Tabla 11. (Análisis) Caso de Uso Administrar Empleado (Versión 1)



Función

Administrar la tabla de Empleados existente en el sistema, permitiendo la creación de un nuevo empleado, o la eliminación, la modificación y consulta de un empleado ya existente


Deben existir registros de Cargos en SIGD


Se crea, se elimina, se modifica, o se consulta un registro de esta entidad, Se registran los cambios efectuados que hayan sido aprobados.

Flujo principal

1. SIGD inicia una nueva ventana mostrando el menú empleados.


3. El administrador elije la opción que desea del menú, crear, consultar, modificar o eliminar, oprimiendo sobre la opción que se desee.

4. El administrador realiza el proceso que desee. (si es el caso)

52

5. El administrador guarda los cambios 6. El administrador cancela los cambios

Extensiones


sesión.

Es necesario ingresar un nuevo empleado en la entidad. 1. El administrador puede ingresar un nuevo registro en


2. El administrador debe asignarle un Cargo antes de guardar.


Si existe, alerta diciendo que el dato esta repetido, y detendrá el proceso.


Existen varios empleados que no son necesarios o no existen dentro de la institución.

1. El administrador puede eliminar uno o varios registros. 2. SIGD se encarga de verificar que el registro del

empleado exista en el sistema. 3. El administrador selecciona el registro y lo elimina.

Los empleados pueden generar cambios a medida del tiempo.

1. SIGD se encarga de verificar que el registro del empleado exista en el sistema.

2. El administrador selecciona el registro del empleado 3. El administrador realiza el cambio en la información


Si existe un error en los caracteres ingresados SIGD alertara de este error y detendrá el proceso.

Los diferentes registros de Empleados pueden ser consultados en una vista general (una tabla).



53

Figura 23. Caso de uso Administrar Tipo de Documento (Versión 1)

Fuente. Los Autores

Tabla 12. (Análisis) Caso de Uso Administrar Tipos de Documento

(Versión 1)

Caso de Uso Administrar Tipo Documento


Función

Administrar la tabla Tipos Documentos existente en el sistema, permitiendo la creación de una nuevo tipo de documento, la eliminación, la modificación y consulta de un tipo de documento ya existente




Flujo principal

1. SIGD inicia una nueva ventana mostrando el menú tipos documentos.




54


Extensiones


sesión.

Es necesario ingresar un nuevo tipo de documento. 1. El administrador puede ingresar un nuevo registro en





Los tipos de documentos pueden generar cambios a medida del tiempo.

1. SIGD se encarga de verificar que el registro del tipo de documento exista en el sistema.

2. El administrador selecciona el registro 3. El administrador realiza el cambio en la información



Los diferentes registros de tipos de documento pueden ser consultados en una vista general (una tabla).

1. El administrador señala la opción de consulta SIGD muestra una tabla con todos los registros de esa entidad

Fuente. Los Autores

55

Figura 24. Caso de Uso Administrar Usuario (Versión 1)

Fuente. Los Autores

Tabla 13. (Análisis) Caso de Uso Administrar Usuarios (Versión 1)

Caso de Uso Administrar Usuarios


Función Administrar la tabla Usuarios existente en el sistema, donde se encuentran: docentes, alumnos, administrativos


Deben tener relación con la institución



Flujo principal

1. SIGD inicia una nueva ventana mostrando el menú usuarios.





56

Extensiones


sesión.

Existen varios usuarios que no pertenecen o no tienen relación alguna con la institución. .


usuario exista en el sistema. 3. El administrador selecciona el registro y lo elimina.

Los usuarios pueden generar cambios a medida del tiempo.

1. SIGD se encarga de verificar que el registro del usuario exista en el sistema.

2. El administrador selecciona el registro del usuario 3. El administrador realiza el cambio en la información


Si existe un error en los caracteres ingresados, SIGD alertara de este error y detendrá el proceso.

Los diferentes registros de usuarios pueden ser consultados en una vista general (una tabla).



Figura 25. Caso de Uso Radicar (Versión 1)

Fuente Los Autores

57

Tabla 14. (Análisis) Caso de Uso Radicar (Versión 1)

Caso de Uso Radicar

Actores Radicador, Usuario, Base de Datos.

Función Administrar la entrada y digitalización de documentos al sistema

Precondiciones El usuario habrá de cancelar el recibo según el proceso

de su documento

El radicador debe iniciar sesión


Se crea, y se indexan las peticiones de documentos por parte de los usuarios, se inician los debidos procesos.

Flujo principal

1. SIGD inicia una nueva ventana mostrando el menú radicación.

2. SIGD muestra una lista con las opciones de ingreso según lo que el usuario ha diligenciado en el formulario de ingreso del documento, información que se almacena en la tabla Documentos.

3. El radicador guarda los cambios 4. El radicador cancela los cambios

Extensiones

En cualquier momento el sistema falla. 1. El radicador y/o empleado reinicia el sistema y vuelve a

iniciar sesión.

El documento debe seguir el orden de procedimientos y flujo asignado en la base de datos.

Pueden haber errores al momento de enviar Los documentos

1. SIGD se encarga de verificar que el documento realice los respectivos procedimientos.

2. El radicador puede editar los registros 3. La información es aprobada y guardada por SIGD.



5. El radicador señala la opción de consulta 6. SIGD muestra una tabla con todos los registros

Ingresados Fuente. Los Autores

58

Figura 26. Caso de Uso Distribuir (Versión 1)

Fuente. Los Autores

Tabla 15. (Análisis) Caso de Uso Distribuir (Versión 1)

Caso de Uso Distribuir

Actores Radicador, empleado, Base de Datos.

Función Gestiona todo el envío de documentos a sus respectivos procedimientos según el flujo de documento para ese tipo de documento

Precondiciones El radicador debe iniciar sesión


Se genera un control sobre los documentos que están pendientes en SIGD y según su prioridad y fecha de ingreso son atendidos.

Flujo principal

1. SIGD inicia una nueva ventana mostrando el menú distribución

2. SIGD muestra una lista de los documentos pendientes de envío

3. El radicador o/y empleado realizan el procedimiento que el tipo de documento exige y lo envía. (Después de enviar esta información no se puede editar )

4. El Radicador y/ o empleado cancela

Extensiones

En cualquier momento el sistema falla. 1. El radicador y /o empelado reinicia el sistema y vuelve

a iniciar sesión.

Pueden haber errores al momento de ingresar dos documentos

1. SIGD se encarga de verificar que el documento no

59

exista en el sistema y su distribución sea ordenada. 2. La información es aprobada y guardada por SIGD.


Los diferentes registros de documentos enviados y/o pendientes pueden ser consultados en una vista general (una tabla).

1. El radicador o empelado señala la opción de Consulta 2. SIGD muestra una tabla con todos los registros según

la consulta Fuente. Los Autores

4.1.3 Etapa de Diseño

Una vez finalizada la etapa de requerimientos y luego de haber evaluado el modelo propuesto en el proyecto de grado “Diseño de un Sistema de Gestión Documental para el Programa de Ingeniería de Sistemas de la Universidad de San Buenaventura - sede Bogotá’’, se encontraron algunas deficiencias en el modelo de base de datos propuesto por las autoras del proyecto para los nuevos requerimientos que tendría el sistema, es por esto que en esta etapa se planteo un nuevo modelo de base de datos que permitiera realizar un seguimiento mas profundo a los documentos que alimentan el sistema y por consiguiente tener un mayor control tanto del personal que labora, como de los tiempos de respuesta que afectan el sistema manual que tiene implementado la universidad en estos momentos. A continuación como se ilustra en la figura 27 se retoma el modelo entidad-relación propuesto en el proyecto anterior y en la figura 28 el modelo entidad relación planteado en este documento.

60

Figura 27. Modelo de Base de Datos propuesta

FLUJO_DOCUMENTOS

PK Id_flujo_documento

Flujo_documento

Tiempo_estimado

TIPO_DOCUMENTOS

PK Id_tipo_documento

Tipo_documento

ESTADOS

PK Id_estado

Estados_documento

TIPO_USUARIOS

PK Id_tipo_usuario

Tipo_usuario

UNIDADES_ADMINISTRATIVAS

PK Id_unidades_administrativas

Unidades_administrativas

USUARIOS

PK Id_usuario

Nom_usuario

Apell_usuario

Email_usuario

Id_tipo_usuario

DOCUMENTOS

PK Id_documento

Asunto

Dirigido_a

Fecha_radica

Fecha_rta

Id_tipo_documento

Id_usuario

DOC_UNID_ESTADOS

PK Id_estado

PK Id_documentos

PK Id_unidades_administrativas

Fuente. Diseño de un Sistema de Gestión Documental para el Programa de Ingeniería de Sistemas de la Universidad de San Buenaventura - sede Bogotá

Algunas de las inconformidades que se encontraron:

o No se puede tener un control exacto del tiempo que esta un documento en una dependencia.

o No se sabe quien es el empleado que esta desarrollando un procedimiento.

o No existe un campo donde almacenar correos electrónicos para avisarle al usuario que el documento ya esta listo

o Algunas tablas no reunían todos los atributos que describieran correctamente las entidades que se estaban representando.

Estas son algunas de las inconformidades que se encontraron entre muchas más que limitarían al sistema para desempeñar una labor eficiente y segura, pero que no se enumeran ya que el objetivo de este documento es construir a partir de lo que se tiene y no destruir lo que ya se ha construido. En la siguiente figura se muestra un modelo de base de datos que se plantea para solucionar las deficiencias encontradas en el modelo propuesto.

61

Figura 28. Modelo Entidad Relación SIGD Versión 1

Fuente. Los Autores

62

4.1.4 Etapa de Implementación

La construcción de la versión 1.0 del sistema SIGD se realizó en herramientas de software libre, estas herramientas fueron PostgreSQL y para desarrollar las interfaces para los usuarios se utilizó java y su entorno de desarrollo Netbeans, valiéndose de Servlet`s y JSP`s que son tecnologías que permiten construir interfaces con ambiente Web que fue uno de los requerimientos que se solicitaron para el sistema. La implementación de la versión 1.0 contemplo el módulo de administración permitiendo agregar registros a las diferentes entidades que se plantearon eran indispensables para el correcto funcionamiento del sistema, en la figura 29 se presenta el modelo de clases para esta versión.

63

Figura 29. Modelo de Clases SIGD Versión 1

Fuente. Los Autores 4.1.5 Etapa de Pruebas

Para el sistema de gestión documental se elaboraró un formato de pruebas que fue entregado a 10 personas 5 personas sin conocimientos del sistema y 5 que tenían algún conocimiento del funcionamiento del SIGD, esto con el fin de

64

realizar pruebas de caja negra y caja blanca. Se encontraron múltiples tipos de pruebas, pero no todas son pertinentes para el sistema de gestión documental, el formato desarrollado permite evaluar forma por forma el funcionamiento tanto visual como lógico del aplicativo. Esto con el fin de obtener valiosos aportes para el mejoramiento del sistema de gestión documental, en anexos se podrá ver el formato de pruebas. En esta sección solo se ilustraran resultados del consolidado que se obtuvo en general del sistema. Resultados: En general la versión 1.0 del sistema de gestión documental (SIGD) no contó con mucha aceptación entre la población de prueba ya que se encontraron con algunas inconformidades como los siguientes:

El entorno visual de la aplicación es demasiado estático y la distribución de espacios no es la adecuada ya que algunas interfaces tienen pocos atributos.

El menú de navegación es demasiado estático y sin importar el módulo en que se encuentre despliega todo el menú, denotando poca seguridad para el sistema.

Al ingresar datos erróneos el sistema se limita a mostrar un mensaje de error en la conexión y no especifica el posible error.

Se requiere de una explicación previa para la manipulación correcta del sistema ya que se presta para confusiones.

Es tediosa la función de eliminar registro ya que es necesario memorizar el código para poder ingresarlo en la forma de eliminar.

En general las formas entregan tiempos de respuesta adecuados pero a solicitudes livianas.

Efectivamente las formas trabajan en ambiente Web pero dependen del la velocidad de conexión a Internet de los usuarios.

En las recomendaciones las más vehementes fueron: implementar la paginación de resultados de una consulta y si fuere posible realizar las transacciones directamente en una sola tabla y no tener que recorrer los Tab que despliega la aplicación. En la siguiente grafica se representa la aceptación de la aplicación en la población de muestra.

65

Figura 30. Grafica de resultado de pruebas (Versión 1)

0

1

2

3

4

5

6

7

8

9

10

Visual Funcional Seguridad Rendimiento

Inconforme

Conforme

Fuente. Los Autores

4.2 DESARROLLO VERSION 2.0 4.2.1 Etapa de Requisitos.

Una vez evaluadas las deficiencias que arrojó el análisis de las pruebas de la versión 1.0, en la versión 2.0 se enfatiza en el perfeccionamiento de las deficiencias encontradas, los requerimientos de la versión 1.0 se mantienen y se le adicionan otros que permitirán mejorar el funcionamiento del sistema de gestión documental.

Comprender el Contexto del Sistema

66

Figura 31. Modelo de Dominio (Versión 2)

Fuente. Los Autores

Capturar los requisitos Funcionales

El sistema debe tener una interfaz amigable para el usuario final permitiendo mostrar los datos en forma paginada y organizada.

67

Figura 32. Caso de Uso de Requerimientos (Versión 2)

Fuente. Los Autores

Descripción de Casos de Uso de Requerimientos (Versión 2)

Tabla 16. Caso de Uso Ingresar al Sistema (Versión 2)

Caso de Uso Ingresar al Sistema.


Función Ingresar a SIGD por medio de un usuario y contraseña validados en la tabla Empleados de la base de datos.

Precondiciones Debe pertenecer a la Universidad de San Buenaventura. Asignación de privilegios para acceder al sistema


Se actualizan los datos del administrador

Flujo principal

El administrador ingresa al sistema SIGD, donde se encuentra con una casilla de ingreso con un usuario y una contraseña. Se ingresa el nombre de usuario y la respectiva contraseña del administrador. Se oprime el botón ingresar Se valida el registro del administrador mediante el nombre de usuario y su respectiva contraseña. Se habilitan todo los módulos de SIGD.

Extensiones En cualquier momento el sistema falla.

68

El administrador reinicia el sistema, y vuelve a iniciar sesión. Identificación no valida. El sistema señala el error y rechaza la entrada.

Fuente. Los Autores Tabla 17. Caso de Uso Administrar Tipo Definición (Versión 2)

Caso de Uso Administrar Tipo Definición


Función

Administrar la tabla paramétrica Tipos Definiciones, creada para disminuir tablas de la versión 1.0 y proporcionar efectividad en el tiempo de consulta. ( ver mas información en Etapa de Diseño versión 2.0)



Se crea, se elimina, se modifica, o se consulta un registro de la entidad Tipos Definiciones.

Flujo principal

1. SIGD inicia una nueva ventana mostrando una lista con todos los datos de Tipos Definiciones. De este modo no es necesario un boto para solo consultar.

2. El administrador elije la opción que desea en la misma lista ( Eliminar, Actualizar o Nuevo)

3. El administrador guarda los cambios. 4. El administrador cancela el proceso.

Extensiones En cualquier momento el sistema falla. 1. El administrador reinicia el sistema, y vuelve a iniciar

sesión.

El sistema genera la lista dinámica paginada. Fuente. Los Autores

Tabla 18. Caso de Uso Administrar Valor Definición (Versión 2)

Caso de Uso Administrar Valor Definición


Función Administrar la tabla de Valores Definiciones que junto a Tipos Definiciones son tablas que nacen en la versión 2.0 ( ver mas información en Etapa de Diseño versión 2.0)


Deben existir tipos de definición en la tabla Tipos Definiciones.


Se crea, se elimina, se modifica, o se consulta un registro de la entidad Valores Definiciones.

Flujo principal

1. SIGD inicia una nueva ventana mostrando una lista con todos los datos de Valores Definiciones. De este modo no es necesario un boto para solo una consulta

69

2. El administrador elije la opción que desea de esa lista. (Eliminar, Actualizar o Nuevo).

3. El administrador guarda los cambios 4. El administrador cancela el proceso.

Extensiones En cualquier momento el sistema falla. 1. El administrador reinicia el sistema y vuelve a iniciar

sesión. 2. El sistema genera la lista dinámica paginada.

Fuente. Los Autores Tabla 19. Caso de Uso Administrar Empleado (Versión 2)



Función Administrar la tabla Empleados existente en el sistema.

Precondiciones El Administrador debe haber iniciado sesión

Debe existir un valor definición que represente un cargo.


Se crea, se elimina, se modifica, o se consultan un registro de la entidad Empleados.

Flujo principal

1. SIGD inicia una nueva ventana mostrando una lista con todos los registros de la tabla Empleados.

2. El Administrador elije la opción que desea de esa lista (Eliminar, Actualizar o Nuevo).

3. El administrador guarda los cambios 4. El administrador cancela el proceso

Extensiones


sesión.

El Sistema genera la lista de todos los registros dinámica y paginada.

Fuente. Los Autores Tabla 20. Caso de Uso Administrar Procedimiento (Versión 2)



Función Administrar la tabla Procedimientos existentes para cada tipo de documento



Se crea, se elimina, se modifica, o se consulta un registro de la entidad Procedimiento.

Flujo principal 1. SIGD inicia una nueva ventana mostrando una lista

paginada con todos los procedimientos. 2. El administrador elije la opción que desea de esta Lista

70

(Eliminar, Modificar, Nuevo) 3. El administrador guarda los cambios 4. El administrador cancela el proceso

Extensiones


sesión.

El sistema genera la lista de todos los procedimientos existentes en la base de datos, paginados.

Fuente. Los Autores Tabla 21. Caso de Uso Administrar Tipo de Documento (Versión 2)

Caso de Uso Administrar Tipo de Documento

Actores Administrador, Base de Datos. Función Administrar la tabla Tipo Documentos existente en el

sistema. Precondiciones El Administrador debe haber iniciado sesión


Se crea, se elimina, se modifica, o se consulta un registro de la entidad Tipo Documentos

Flujo principal

1. SIGD inicia una nueva ventana mostrando una lista dinámica paginada

2. El administrador elije la opción que desea de esta lista (Eliminar, Modificar, Nuevo).

3. El Administrador guarda los cambios 4. El Administrador cancela el proceso


sesión.

El sistema genera La lista de todos los tipos de documento existentes.

Fuente. Los Autores

Tabla 22. Caso de Uso Administrar Flujo de Documento (Versión 2)

Caso de Uso Administrar Flujo de Documento


Función Administrar la tabla Flujo Documentos ( los procedimientos realizados a cada documento en las diferentes Unidades Administrativas )


Debe existir un tipo documento


Se crea, se elimina, se modifica, o se consultan un registro de la tabla Flujo Documentos

Flujo principal 1. SIGD inicia una nueva ventana mostrando una lista

71

Flujo Documentos. 2. El administrador elije la opción que desee de esta lista 3. Importante establecer la prioridad del flujo. 4. El administrador guarda los cambios 5. El administrador cancela el proceso

Extensiones


sesión.

El sistema genera La lista de todos los flujos de documentos existentes.

Fuente. Los Autores Tabla 23. Caso de Uso Administrar Usuario (Versión 2)

Caso de Uso Administrar Usuario

Actores Administrador, Base de Datos. Función Administrar la tabla Usuarios existente en el sistema.


Debe existir un valor definición que represente un Tipo Usuario.


Se crea, se elimina, se modifica, o se consulta un registro de la entidad Usuarios.

Flujo principal

1. SIGD inicia una nueva ventana mostrando una lista con todos los registros de la tabla Usuarios.

2. El administrador elije la opción que desea de esa lista. (Eliminar, Actualizar o Nuevo).

3. El administrador guarda los cambios 4. El administrador cancela el proceso

Extensiones


sesión. 2. El sistema genera la lista de todos los registros

dinámica y paginada. Fuente. Los Autores

4.2.2 Etapa de Análisis.

Debido a que se adicionaron requerimientos para el sistema de gestión documental en la versión 2.0, la fase de análisis sufrió una seria de modificaciones que permiten representar el funcionamiento del sistema según los nuevos requerimientos que surgieron en la versión 2.0.

72

Figura 33. Caso de Uso Administrar Tipo Definición (Versión 2)

Fuente. Los Autores

Tabla 24. (Análisis) Caso de Uso Administrar Tipo Definición (Versión 2)

Caso de Uso Administrar Tipo Definición


Función

Administrar la tabla de Tipos Definiciones, permitiendo la creación de un nuevo registro, la eliminación, la modificación y consulta de estos tipo definición. ( ver mas información sobre esta tabla en Etapa de Diseño versión 2.0)




Se logra la optimización de recursos a nivel de tiempos de respuesta de la base de datos.

Flujo principal

1. SIGD inicia una nueva ventana mostrando una lista dinámica paginada con los registros de esta tabla.

2. El administrador elije la opción que desea de la lista apuntando hacia el campo que desee modificar o eliminar, oprimiendo sobre la opción que se desee.

3. El administrador para crear un nuevo registro se debe dirigir hasta la última casilla existente en esa lista.


5. El administrador guarda los cambios

73

6. El administrador cancela los cambios

Extensiones


sesión.

Es necesario ingresar un nuevo tipo definición. 1. El administrador puede ingresar un nuevo registro en





Existen varios tipos definición que no son necesarios o no existen dentro de la institución.

1. El administrador puede eliminar uno o varios registros. 2. SIGD se encarga de verificar que el registro del tipo

definición exista en el sistema. 3. El administrador busca el registro y lo elimina.

Los tipos definición pueden generar cambios a medida del tiempo.

1. SIGD se encarga de verificar que el registro del tipo definición exista en el sistema.


traída por SIGD mostrada en una lista paginada. 4. La información es aprobada y guardada por SIGD.


Los diferentes Registros de tipo definición pueden ser consultados en una vista general (una tabla).



74

Figura 34. Caso de Uso Administrar Valor Definición (Versión 2)

Fuente. Los Autores

Tabla 25. (Análisis) Caso de Uso Administrar Valor Definición (Versión 2)

Caso de Uso Administrar Valor Definición


Función

Administrar la tabla Valores Definiciones permitiendo la creación de un nuevo registro, la eliminación, la modificación y consulta de estos valores definición. ( ver mas información sobre esta tabla en Etapa de Diseño versión 2.0)


Debe existir un Tipo Definición


Se crea, se elimina, se modifica, o se consulta un registro de esta entidad, se registran los cambios efectuados y que hayan sido aprobados.

Se logra la optimización de recursos a nivel de tiempos de respuesta de la base de datos.

Flujo principal

1. SIGD inicia una nueva ventana mostrando una lista dinámica paginada con los registros de esta tabla.

2. El administrador elije la opción que desea de la lista apuntando hacia el campo que desee modificar o eliminar, oprimiendo sobre la opción que se desee.

3. El administrador para crear un nuevo registro se debe dirigir hasta la última casilla existente en esta lista y seleccionar un tipo definición para este nuevo registro.


75


Extensiones


sesión.

Es necesario ingresar un nuevo valor definición. 1. El administrador puede ingresar un nuevo registro en





Existen varios, valores definición que no son necesarios o no existen dentro de la institución.

1. El administrador puede eliminar uno o varios registros. 2. SIGD se encarga de verificar que el registro del tipo

definición exista en el sistema. 3. El administrador busca el registro y lo elimina.

Los valores definición pueden generar cambios a medida del tiempo.

1. SIGD se encarga de verificar que el registro del tipo definición exista en el sistema.




Los diferentes registros de valor definición pueden ser consultados en una vista general (una tabla).

1. El Administrador señala la opción de consulta 2. SIGD muestra una tabla con todos los registros de esa


76

Figura 35. Caso de Uso Administrar Empleado (Versión 2)

Fuente. Los Autores

Tabla 26. (Análisis) Caso de Uso Administrar Empleado (Versión 2)



Función

Administrar la tabla Empleados existente en el sistema, permitiendo la creación de una nuevo empleado, la eliminación, la modificación y consulta de un empleado ya existente


Deben existir un tipo definición y valores definiciones para de tipo “tip_cargos” y asignarlo.



Flujo principal

1. SIGD inicia una nueva ventana mostrando una lista de los registros de empleados existentes.

2. El administrador elije la opción que desea de la lista, apuntando hacia el campo que desea modificar o eliminar, oprimiendo sobre la opción que se quiera

3. El Administrador realiza el proceso que desee. (si es el caso)


77

Extensiones


sesión.

Es necesario ingresar un nuevo empleado. 1. El administrador puede ingresar un nuevo registro en


2. El administrador debe asignarle un Valor Definición de tipo “tip_cargos” antes de guardar.




Existen varios empleados que no son necesarios o no existen dentro de la institución.


empleado exista en el sistema. 3. El administrador selecciona el registro y lo elimina.

Los empleados pueden generar cambios a medida del tiempo.

1. SIGD se encarga de verificar que el registro del empleado exista en el sistema.

2. El administrador selecciona el registro del empleado 3. El administrador realiza el cambio en la información



Los diferentes Registros de empleados pueden ser consultados en una vista general (una tabla).

1. El Administrador señala la opción de consulta 2. SIGD muestra una tabla con todos los registros de esa


78

Figura 36. Caso de Uso Administrar Procedimiento (Versión 2)

Fuente. Los Autores

Tabla 27. (Análisis) Caso de Uso Administrar Procedimiento (Versión 2)



Función

Administrar la tabla Procedimientos existente en el sistema, permitiendo la creación de una nuevo registro, la eliminación, la modificación y consulta de un procedimiento existente




Flujo principal

1. SIGD inicia una nueva ventana mostrando una lista con todos los procedimientos



Extensiones


sesión.

Es necesario ingresar un nuevo procedimiento.

79

1. El administrador puede ingresar un nuevo registro en cualquier momento, teniendo en cuenta que la identificación es automática, no se muestra en el formulario de ingreso este campo.




Los procedimientos pueden generar cambios a medida del tiempo.

1. SIGD se encarga de verificar que el registro del procedimiento exista en el sistema.




Los diferentes registros de la tabla Procedimientos pueden ser consultados en una vista general (una tabla).



80

Figura 37. Caso de Uso Administrar Tipo Documento (Versión 2)

Fuente. Los Autores

Tabla 28. Caso de Uso Administrar Tipo Documento (Versión 2)



Función

Administrar la tabla Tipos Documentos existente en el sistema, permitiendo la creación de una nuevo registro, la eliminación, la modificación y consulta de un procedimiento existente




Flujo principal

1. SIGD inicia una nueva ventana mostrando una lista con todos los tipos documentos



Extensiones


sesión.

Es necesario ingresar un nuevo tipo documento. 1. El administrador puede ingresar un nuevo registro en

81





Los tipos documentos pueden generar cambios a medida del tiempo.

1. SIGD se encarga de verificar que el registro del tipo documento exista en el sistema.




Los diferentes registros de la tabla Tipos Documentos pueden ser consultados en una vista general (una tabla).



82

Figura 38. Caso de Uso Administrar Flujo Documento (Versión 2)

Fuente. Los Autores

Tabla 29. (Análisis) Caso de Uso Administrar Flujo Documento (Versión 2)



Función

Administrar la tabla Flujo Documentos existente en el sistema, permitiendo la creación de una nuevo registro, la eliminación, la modificación y consulta de un procedimiento existente


Se tiene que tener registrado un tipo documento

Se tiene que tener registrados procedimientos



Flujo principal

1. SIGD inicia una nueva ventana mostrando una lista con todos los flujos documentos




83

sesión.

Es necesario ingresar un nuevo flujo documento. 1. El administrador puede ingresar un nuevo registro en





Los flujos documentos pueden generar cambios a medida del tiempo.

1. SIGD se encarga de verificar que el registro del flujo documento exista en el sistema.




Los diferentes registros de la tabla Flujo Documentos pueden ser consultados en una vista general (una tabla).



84

Figura 39. Caso de Uso Administrar Usuario (Versión 2)

Fuente. Los Autores

Tabla 30. (Análisis) Caso de Uso Administrar Usuario (Versión 2)

Caso de Uso Administrar Usuario


Función

Administrar la tabla Usuarios existente en el sistema, permitiendo la creación de una nuevo registro, la eliminación, la modificación y consulta de un procedimiento existente


Se tiene que tener valores definiciones de tipo definición “tip_usu”.



Flujo principal

1. SIGD inicia una nueva ventana mostrando una lista con todos los usuarios



Extensiones


sesión.

Es necesario ingresar un nuevo usuario. 1. El administrador puede ingresar un nuevo registro en

85





Los usuarios pueden generar cambios a medida del tiempo.

1. SIGD se encarga de verificar que el registro del flujo documento exista en el sistema.




Los diferentes registros de la tabla Usuarios pueden ser consultados en una vista general (una tabla).




Fuente. Los Autores

86


Caso de Uso Radicar


Función Administrar la entrada y digitalización de documentos al sistema


de su documento

El radicador debe iniciar sesión


Se crean, y se indexan las peticiones de documentos por parte de los usuarios y se inician los debidos procesos.

Flujo principal

1. SIGD inicia una nueva ventana mostrando un menú Radicación.


3. SIGD muestra una lista con las opciones de ingreso según lo que el usuario ha diligenciado en el formulario de ingreso del documento, información que se almacena en la tabla Documentos.

4. El radicador guarda los cambios 5. El radicador cancela los cambios 6. El administrador realiza el proceso que desee. (si es el


Extensiones

En cualquier momento el sistema falla. 1. El radicador y/o empleado reinicia el sistema y vuelve a

iniciar sesión.

El documento debe seguir el orden de procedimientos y flujo asignado en la base de datos.

Pueden haber errores al momento de enviar Los documentos

1. SIGD se encarga de verificar que el Documento realice los respectivos procedimientos.

2. El radicador puede editar los registros 3. La información es aprobada y guardada por SIGD.



1. El radicador señala la opción de consulta 2. SIGD muestra una tabla con todos los registros

Ingresados Fuente. Los Autores

87

Figura 41. Caso de Uso Distribuir (Versión 2)

Fuente. Los Autores

Tabla 32. (Análisis) Caso de Uso Distribuir (Versión 2)

Caso de Uso Distribuir

Actores Radicador, empleado, Base de Datos.

Función Gestiona todo el envío de documentos a sus respectivos Procedimientos.

Precondiciones El radicador debe iniciar sesión

El empleado debe iniciar sesión


Se genera un control sobre los documentos que están pendientes en SIGD y según su prioridad y fecha de ingreso son atendidos.

Flujo principal

1. SIGD inicia una nueva ventana mostrando el menú distribución.

2. SIGD muestra una lista de los documentos pendientes de envío

3. El radicador o/y empleado realizan el procedimiento que el tipo de documento exige y lo envía. (Después de enviar esta información no se puede editar )

4. El radicador y/ o empleado cancela.

Extensiones

En cualquier momento el sistema falla. 1. El radicador y/o empelado reinicia el sistema y vuelve a

iniciar sesión.

Pueden haber errores al momento de ingresar los documentos

1. SIGD se encarga de verificar que el documento no exista en el sistema y su distribución sea ordenada.

88

2. La información es aprobada y guardada por SIGD.


Los diferentes registros, documentos enviados y/o pendientes pueden ser consultados en una vista general (una tabla).

1. El Radicador o empelado señala la opción de consulta 2. SIGD muestra una tabla con todos los registros según

la consulta. Fuente. Los Autores

4.2.3 Etapa de Diseño

Luego de revisar los resultados de las pruebas de la versión 1.0 se llegó a la conclusión de que se debería modificar el modelo de base de datos ya que se encontraron demasiadas entidades que no tenían los atributos suficientes para desempeñarse como una entidad, entre estas se encuentran (Cargos, Estados y Unidades Administrativas). Para esta misma fecha se decidió utilizar entidades parametricas que permiten guardar la información que se almacenaba en las entidades descritas en el párrafo anterior y con esto disminuir el número de tablas en la base de datos. Estas entidades parametricas de las cuales se esta haciendo mención para la versión 2.0 de la base de datos se llamaron Tipos_Definiciones y Valores_Definiciones, en la tabla de Tipos_Definiciones se almacenan los diferentes tipos de definiciones que se pueden tener dentro del sistema. Estas tablas sustituyeron algunas entidades existentes, en un ejemplo con estas entidades se demostrara su funcionamiento, pero cabe decir que no solo fueron para sustituirlas ya que con estas dos tablas se puede crear muchas mas definiciones según la necesidad del sistema. Por ejemplo: tipo definición “tip_cargo” representa todos los cargos que se pueden tener dentro del sistema y “tip_est” representa los estados de los documentos dentro del sistema En Valores_Definiciones se crean los cargos que existen ejemplo (Administrador y Radicador) que están asociados al tipo definición “tip_cargo” y se crean los estados (Radicado, En trámite y Terminado) asociados al tipo definición “tip_est”. En la tabla valores definiciones se almacena toda la información sin discriminar de que tipo sea, pero internamente con el tipo definición se puede determinar que clase de información se esta almacenando y en que momento se puede utilizar. Con esto se reduce el numero de entidades en la base y se pueden tener tiempos de respuestas mas rápidos a

89

consultas y transacciones, ya que no se tendrán que hacer múltiples uniones a tablas que no proveen suficiente información.

90

Figura 42. Modelo Entidad Relación SIGD Versión 2

Fuente. Los Autores

91


Las pruebas de la versión 1.0 arrojaron inconformidades con la manera que se esta presentando la información al usuario ya que no se mostraban formas amigables y se empleaban demasiadas forma para hacer los procedimientos de Insertar, Eliminar y Actualizar información, ya que la tecnología de JSP dificultaba realizar paginación y trabajar los procedimientos en una sola forma se investigo una nueva tecnología, que permitiera al usuario trabajar de una manera mas rápida y se encontró un nuevo Framework de java implementado en el entorno de desarrollo Netbeans 6 llamado Java Server Face (JSF) que permite un mejor dinamismo al trabajar con componentes unidos a bases de datos por consiguiente se hizo el cambio tecnológico a esta nueva forma de desarrollo, arrojando resultados satisfactorios.

El Modelo Vista Controlador (MVC) es usado por los JSF, MVC es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos.

Como ejemplo de MVC en una aplicación Web, se puede decir que la vista es

la página HTML y el código que provee de datos dinámicos a la página, el controlador es el Sistema de Gestión de Base de Datos y el modelo es el

modelo de datos.

Modelo: Esta es la representación específica de la información con la cual el

sistema opera. La lógica de datos asegura la integridad de estos y permite derivar nuevos datos; por ejemplo, no permitiendo comprar un número de unidades negativo.

Vista: Este presenta el modelo en un formato adecuado para interactuar.

Controlador: Este responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista. En una aplicación Web el controlador recibe la petición del usuario, interactúa con el modelo para procesar los datos y hace disponible esos datos a la vista. Los controladores son la única parte del MVC que deben ser definidos. El controlador puede procesar los datos y mostrarlos, es autosuficiente.

La ventaja del sistema MVC es que, al aplicar esta separación, se hace posible crear más de una vista para el mismo modelo (una vista abreviada y una vista detallada), esto es reutilizar el modelo y el código.9

9 http://www.unadecodigo.com/2007/05/30/el-paradigma-modelo-vista-controlador-tutorial-ror-ii/,

27 de Mayo de 2008, 10:00 PM.

92

Figura 43. Modelo de Clases SIGD Versión 2

Fuente. Los Autores

93

4.2.5 Etapa de Pruebas

Como se utilizo en la versión 1.0 para esta etapa de la versión 2.0 se realizó el mismo modelo de pruebas a base del formato de pruebas existente y disponible en los anexos de este documento, para la versión 2.0 luego del cambio tecnológico respecto al desarrollo de las interfaces y los cambios en la base de datos se vio un aumento en la aceptación del sistema ya que según las observaciones plasmadas las interfaces de usuario son mucho mas amigables, se cuenta con una mejor distribución del espacio de la pantalla, entre las características visuales respecto al funcionamiento se determinó que es mucho mas ágil realizar en una misma pantalla todas las transacciones y la navegabilidad de la aplicación es mejor ya que se mejoraron aspectos en el menú que ahora es dinámico y con iconos que permiten acceder fácilmente a otros lugares de la aplicación. La inconformidad que se encontró fue: la aplicación requiere de un mayor tiempo para cargar las pantallas, esto debido a que la solución informática requiere unos recursos de hardware de alto desempeño para funcionar de manera optima, pero en general no se encontraron mayores inconformidades con el sistema actual. Figura 44. Grafica de resultado de pruebas (Versión 2)

0

1

2

3

4

5

6

7

8

9

10


Inconforme

Conforme

Fuente. Los Autores

94

4.3 DESARROLLO VERSION 3.0

4.3.1 Etapa de Requisitos

El modelamiento descrito en la versión 2.0, permitió un amplio análisis del contexto del software, también proporciono un medio intuitivo y sistemático óptimo en la captura de los requisitos funcionales, por tal motivo la etapa de requisitos de la versión 3.0 no sufrió cambios respecto a la versión 2.0

4.3.2 Etapa de Análisis

El análisis de los casos de uso estructurados en la versión 2.0 están diseñados de tal forma que facilita la comprensión, preparación, modificación y en general mantenimiento de las especificaciones de funcionalidad del sistema. De esta Forma la etapa de análisis de la versión 3.0 toma en su totalidad la estructura implementada en la versión 2.0 Sin embargo, la versión 3.0 integra la digitalización de documentos que es un complemento del módulo de radicación, este complemento fue desarrollado por el grupo de investigación NEOBYTE. De igual forma aparece un nuevo modulo de consultas denominado Monitorias.

95


Fuente. Los Autores


Caso de Uso Radicar


Función Administrar toda la entrada y digitalización de documentos al sistema

Precondiciones El radicador debe iniciar sesión El usuario debe haber cancelado el costo del trámite del documento.


Se crea, se indexan las peticiones de documentos por parte de usuarios y se inician los debidos procesos.

Flujo principal

El usuario diligencia un formulario con datos principales tanto del usuario mismo como del documento a tramitar. SIGD llama una ventana que muestra todos los dispositivos de escaneo en la red habilitados para el radicador. El radicador debe escanear el documento y determinar según el tipo documento la ubicación que tendrá el

96

documento en el sistema. SIGD inicia una nueva ventana mostrando el menú radicación. El administrador elije la opción que desea de la lista apuntando hacia el campo que desee modificar o eliminar, oprimiendo sobre la opción que se desee. SIGD muestra una lista con las opciones de ingreso según lo que el usuario ha llenado en el formulario del ingreso del documento, información que se almacena en la tabla Documentos. El radicador guarda los cambios El radicador cancela los cambios El administrador realiza el proceso que desee. (si es el caso) El administrador guarda los cambios El administrador cancela los cambios

Extensiones

En cualquier momento el sistema falla. El radicador reinicia el sistema y vuelve a iniciar sesión. El documento debe seguir el orden de procedimientos y flujo asignado en la base de datos. Pueden haber errores al momento de enviar los documentos SIGD se encarga de verificar que el documento realice los respectivos procedimientos. El radicador puede editar los registros La información es aprobada y guardada por SIGD. Si existe un error en los caracteres ingresados SIGD alertara de este error y detendrá el proceso. Los diferentes registros de Documentos pueden ser consultados en una vista general (una tabla). El radicador señala la opción de consulta SIGD muestra una tabla con todos los registros de documentos radicados.

Fuente. Los Autores

La organización de los documentos digitalizados dentro del servidor del sistema

de gestión documental se propone que se realice de la siguiente forma:10

10

Op. Cit. Proyecto de grado, p. 108 - 110

97

Figura 46. Ejemplo de clasificación de documentos electrónicos

El orden que seguirá los documentos digitalizados en el servidor del Sistema

de Gestión Documental se muestra a continuación:

Figura 47. Ejemplo de ordenación de documentos electrónicos

Ordenación Cronológica: Ubicación de los documentos electrónicos en el tiempo con relación a este, los documentos deben ser colocados en forma ascendente por año

98

Figura 48. Caso de Uso Consultar (Versión 3)

Fuente. Los Autores

Tabla 34. (Análisis) Caso de Uso Consultar (Versión 3)

Caso de Uso Consultar

Actores Usuarios Función Consultar el estado de las documentos dentro del sistema


de su documento


El sistema actualiza automáticamente el estado del documento después de reanalizar un procedimiento.

Flujo principal

1. El Usuario ingresa el código de radicación del documento.

2. SIGD verifica el estado del documento y le informa al usuario si su documento ya esta listo.

Extensiones En cualquier momento el sistema falla. 1. El usuario reinicia el sistema y vuelve a iniciar sesión.

99

4.3.3 Etapa de Diseño En esta etapa no se produjeron cambios en la base de datos de la versión 2.0 a la versión 3.0, se mantiene el modelo entidad relación de la versión 2.0. a continuación se presenta el diccionario de datos definitivo para el sistema SIGD. Tabla 35. Diccionario de datos tabla (Empleados)

Empleados

Esta tabla almacena los datos básicos de todos los empleados de la institución y también permite almacenar el login y contraseña de cada uno para el ingreso al sistema. Campo Pk Fk Tipo Dominio Req Default Descripci

ón

Empleado_id serial auto numérico

Identificador del empleado en el sistema

Codigo Character (30)

Números Código que representa al empleado en la Institución

Nombre Character (100)

letras Nombre del empleado

Apellido Character (100)

letras Apellido del empleado

Cargo_id integer Números Código que identifica el cargo del empleado en la tabla tipo definición

Unidad_Administrativa_id

integer Números Código que identifica la unidad administrativa dentro de la institución en la tabla tipo definición

Login Character (20)

Letras y caracteres

Login del Empleado

100

Password Character (20)

Letras y caracteres

Contraseña del empleado

Fuente. Los Autores

Tabla 36. Diccionario de datos tabla (Tipos_Definiciones)

Tipos_Definiciones

Esta tabla almacena los tipos_definicion (cargos, unidad administrativa, tipo_usuario, estados) la cual apoya y completa la tabla valor_definicion Campo Pk Fk Tipo Dominio Req Default Descrip

ción

Tipo_Definicion_id

serial SEQUENCE INCREMENT 1 MINVALUE 1

Identificador de el cargo en el sistema

Tipo_Definicion Character (10)

letras Nombre del cargo

Descripcion_tipo_def

Character (200)

letras Descripción del tipo definición

Fuente. Los Autores

Tabla 37. Diccionario de datos tabla (Valores_Definiciones)

Valores_Definiciones

Esta tabla almacena los valores de la definición de la base de datos, provenientes de la tabla (tipo_definicion). Campo Pk Fk Tipo Dominio Req Default Descrip

ción

Tipo_Definicion_id

serial SEQUENCE INCREMENT 1 MINVALUE 1


Tipo_Definicion Character (10)

letras Nombre del cargo

Descripcion_tipo_def

Character (200)

letras Descripción del tipo definición

Fuente. Los Autores

101

Tabla 38. Diccionario de datos tabla (Flujo_Documentos)

Flujo_documentos

Esta tabla almacena los flujos de datos que se crean a partir de los tramites de los documentos Campo Pk Fk Tipo Dominio Req Default Descripci

ón

Flujo_documento__id

serial auto numérico


Tipo_documento_id

integer Números Nombre del cargo

Procedimiento_id

integer Números

prioridad integer Números Default 3 Fuente. Los Autores

Tabla 39. Diccionario de datos tabla (Documentos)

Documentos

Esta tabla almacena los datos de los documentos que se encuentran en proceso dentro del sistema. Campo Pk Fk Tipo Dominio Req Default Descripci

ón

Documento_id serial auto numérico

Identificador del documento en el sistema

Codigo Character(50)

Letras y numeros

Código que representa el documento en la Institución

Asunto Character(500)

letras Titulo del documento

Dirigido_A Character(100)

letras Unidad a quien va dirigido

Fecha_radicacion

date Fechas now Fecha de entrada del documento

Fecha_respuesta

date Fechas Fecha de entrega del documento

102

Tipo_documento_id

integer Números Identificador de el tipo de documento en el sistema

Usuario_id integer Números Identificador del usuario en el sistema

Estado_id integer Números Identificador de el estado en el sistema

Adjunto Character(300)

letras Información adjunta al documento

Observaciones Character(6000)

letras Observaciones generales

Contador Integer Números Fuente. Los Autores

Tabla 40. Diccionario de datos tabla (Historicos)

Historicos

Esta tabla almacena los tipos de cargos de los empleados dentro de la institución Campo Pk Fk Tipo Dominio Req Default Descripci

ón

Historico_id serial auto numérico

Identificador de histórico

Documento_id integer Números Identificador de el documento en el sistema.

Fecha_inicio date Fechas Fecha de inicio del histórico.

Fecha_fin date Fechas Fecha finalización del histórico

Procedimiento_id numeric Números Identificador del procedimiento

Fuente. Los Autores

103

Tabla 41. Diccionario de datos tabla (Procedimientos)

Procedimientos

Esta tabla almacena los procesos que intervienen dentro de el tramite de un documento y su duración Campo Pk Fk Tipo Dominio Req Default Descripci

ón

Procedimiento_id serial auto numérico

Identificador del procedimiento dentro el sistema

Procedimiento Character (100)

Números Descripción procedimiento

duración integer

Números Duración del proceso

Empleado_id Integer Números Identificador del empleado

Fuente. Los Autores

Tabla 42. Diccionario de datos tabla (Tipos_Documentos)

Tipos_Documentos

Esta tabla almacena los diferentes tipos o clases de documentos que son tramitados en la institución Campo Pk Fk Tipo Dominio Req Default Descripc

ión

Tipo_documento_id

serial auto numérico

nextval('gestion_documental.tipo_documento_tipo_documento_id_seq'::regclass),

Identificador del tipo de documento dentro del sistema

Tipo _ documento

Character (100)

Letras y caracteres

Nombre del tipo de documento.

Descripcion_tipo_doc

Character (200)

Letras y caracteres

Descripción del tipo_documento.

Fuente. Los Autores

104

Tabla 43. Diccionario de datos tabla (Usuarios)

Usuarios

Esta tabla almacena los datos principales de los usuarios del sistema. El usuario es quien tramita un documento Campo Pk Fk Tipo Dominio Req Default Descripci

ón

Usuario_id serial auto numérico

Identificador del usuario en el sistema

Codigo Character (00)

Números y letras

Código que representa al usuario en la Institución

Nombre Character (100)

letras Nombre del usuario

Apellido Character (100)

letras Apellido del usuario

Solicitante Carácter (100)

Letras Solicitante

Tipo_Usuario_id integer Números Identificador del tipo_usuario definido en la tabla de valor definición.

Fuente. Los Autores


Los cambios en la interfaz gráfica de la aplicación se relacionan con la integración de la digitalización de documentos, que como se dijo anterior mente fue proporcionado al proyecto por el grupo de investigación. Por consiguiente el modelo de clases solo adiciono un Servlet con un Runtime a la aplicación descrita.

105

Figura 49. Modelo de Clases del Servlet Adicionado con la Digitalización

Fuente. Los Autores

Manejo de la Seguridad del Sistema Roles: Administrador, Radicador y administrativo En la siguiente tabla se muestra los privilegios para cada rol dentro del sistema. Tabla 44. Roles del sistema

Rol Privilegios

Administrador Puede crear, modificar y eliminar: - empleados - usuarios - tipos de documentos - flujo de documentos - tipos de definiciones - valores de definiciones - procedimientos

Puede radicar documentos (modificar y eliminar documentos) antes de ser distribuidos. Puede distribuir documentos Puede revisar su bandeja de entrada para las solicitudes de documentos. Puede visualizar los reportes del modulo de monitoreo.

Radicador Puede radicar documentos (modificar y eliminar documentos) antes de ser

106

distribuidos. Puede crear, modificar y eliminar

- usuarios Puede distribuir documentos Puede revisar su bandeja de entrada para las solicitudes de documentos.

Administrativo Puede gestionar los documentos que para su procedimiento se generen Puede revisar su bandeja de entrada para las solicitudes de su documento

* El control de acceso se realiza por login y Password

4.3.5 Etapa de Pruebas

Después de haber integrado la digitalización de documentos, el modulo de monitoreo y puesto en marcha de manera total el sistema la respuesta de la población de prueba ha sido satisfactoria respecto a los aspectos evaluados en las versiones anteriores del software. Despejando unas pocas inquietudes que se tenían sobre el sistema en la versión inmediatamente anterior. En la siguiente grafica se puede observar la aceptación que ha tenido el sistema. Figura 50. Grafica de resultado de pruebas (Versión 3)

0

1

2

3

4

5

6

7

8

9

10


Inconforme

Conforme

Fuente. Los Autores

107

5. CONCLUSIONES

Para desarrollar e implementar gestión documental en organizaciones es necesario que existan procesos y procedimientos bien definidos.

Si la universidad de san buenaventura sede bogota pretende certificarse por el ISO 9000 es necesario que implemente un sistema de gestión documental ya que es uno de los requisitos para obtener esta certificación.

La metodología de desarrollo de software RUP implementada en este proyecto cumplió satisfactoriamente las expectativas que de la metodología se tenían para el desarrollo de un software de gestión documental permitiendo obtener un producto de alta calidad.

El lenguaje de programación java que se utilizó para desarrollar la interfaz de usuario del sistema de gestión documental ofreció un potente recurso software para el desarrollo de aplicaciones portables, estables y seguras que garantiza que en cualquier recurso hardware el sistema de gestión documental se puede ejecutar.

108

6. RECOMENDACIONES

Se recomienda a las directivas del programa de Ingeniería de Sistemas darle continuidad a este proyecto de grado, ya que la solución informática que de este documento se desprende es una excelente herramienta que brinda una alternativa a la gestión de documentos.

Para un perfecto funcionamiento del sistema de gestión documental es necesario que los flujos de documentos, procesos y procedimientos académicos, estén bien documentados y correctamente establecidos.

El sistema de gestión documental que se desarrolló en este documento cumple con todos los requerimientos funcionales, sin embargo esta en desarrollo un modulo de Workflow que por motivo de tiempo no se integro al sistema pero que en el futuro es una alternativa importante para mejorar la aplicación.

Ya que en este proyecto se integraron herramientas de software libre robustas y con aceptación mundial es importante que en la Universidad de San Buenaventura Sede – Bogotá se interesaran por difundir estas herramientas que proveen una alternativa al desarrollo de software.

109

BIBLIOGRAFIA

JACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James. El proceso unificado de desarrollo de software, ED. Addison Wesley, 2000. LARMAN, Craig, UML y patrones “Una introducción al análisis y diseño orientado a objetos y al proceso unificado”, 2° edición, ED. Pearson, 2003.

ROSENBERG, Doug, KENDALL, Scottr, Use Cases “Requirements in Context”, ED. Addison Wesley, 2000 JACOBI, Jonas, FALLOWS R, John, Pro JSF and AJAX “Building rich internet components”, ED. Apress, 2006 ADAM, Myatt, LEONARD, Briand, GEERTJAN, Wielenga, Pro NetBeans IDE 6 “Rich client platform edition”, ED. Apress, 2008 http://www.alegsa.com.ar/Dic/ocr.php, 27 de noviembre de 2007, 07:10 p.m.

110

GLOSARIO

GESTIÓN DOCUMENTAL es el conjunto de normas, técnicas y prácticas usadas para administrar el flujo de documentos de todo tipo en una organización. JSF (Java Server Faces) Framework para aplicaciones Java basadas en Web, que simplifica el desarrollo de interfaces de usuario en aplicaciones Java EE. NETBEANS plataforma para el desarrollo de aplicaciones de escritorio usando Java OCR software de reconocimiento óptico de caracteres (optical character recognition), extrae de una imagen los caracteres que componen un texto para almacenarlos en un formato con el cual puedan interactuar programas de edición de texto. POSTGRESQL servidor de base de datos relacional orientada a objetos de software libre, liberado bajo la licencia BSD.

RUP (Rational Unified Process) Proceso Unificado Racional es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

http://es.wikipedia.org/wiki/Car%C3%A1cter

http://es.wikipedia.org/wiki/Servidor

http://es.wikipedia.org/wiki/Base_de_datos

http://es.wikipedia.org/wiki/Modelo_relacional

http://es.wikipedia.org/wiki/Base_de_datos_orientada_a_objetos

http://es.wikipedia.org/wiki/Software_libre

http://es.wikipedia.org/wiki/Licencia

http://es.wikipedia.org/wiki/Licencia_BSD

111

ANEXOS

112

FORMATO DE PRUEBAS PARA EL SISTEMA DE GESTIÓN DOCUMENTAL - SIGD

Sistema Gestion Documental

Documents

Transcript of Sistema Gestion Documental