PDF

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 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 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
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.
12
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.
13
Tabla 1. Cuadro comparativo (Software de Gestión Documental)
SOTWARE EMPRESA FORMATOS LICENCIA SOFTWARE ALMACENAMIENTO SEGUIMIENTO

Infoviews Perpetua, por Web Formato
LiquidOffice xml, html y pdf SI
(México) usuario registrado Sql Server 2000 Electrónico.
Docuware Licencia adicional Visual Basic Escaneado e
Docuware tiff, pdf, gif NO
(Alemania) Sql Server Sql Server 2000 Indexado.
Gitdoc tiff, pdf, jpg, bmp, Licencia adicional Visual Basic Escaneado e
Gitdoc SI
(España) xls, doc, pps Sql Server Sql Server Indexado.
Semántica Php Escaneado e
DocsDB tiff Enterprise SI
(España) Sql Server Indexado.
Wilkinsonpc no se utilizan 4D
Gestión de Documentos Freeware Digitalizado. SI
(Colombia) imágenes Postgres
Comu. Orfeo GPL (General php 5 Escaneado e
Orfeo tiff SI
(Colombia) Public License) Oracle 10g, MsSql Indexado.
Royal tiff, bmp, pcx, dcx, Escaneado e
Royal ECM Enterprise No se sabe SI
Technologies cals, pbf, pda, pdf Indexado.
Escaneado e
SAD Sysdatec tiff Enterprise Oracle 10g SI
Indexado.
C++, Oracle, Escaneado e
Siam IRS InfoDoc tiff, bmp Enterprise SI
FoxPro, MsSql Indexado.
Oracle, Sql Server, Escaneado e
AAA-Sevenet Lexco tiff No se sabe SI
Postgres, MySql Indexado
Archivos LTDA Archivos LTDA no se utilizan Delphi Borland
No se sabe Digitalizado. SI
Microópticos (Colombia) imágenes Interbase
Windows® Microsoft Servidor Web Microsoft Web
xls, doc, pps Libre SI
SharePoint™ Services. (EEUU) SQL Server 2000 Storage.
14
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.
15
 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.
16
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.
17
 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.
18
 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.
19
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.
20
 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
Documental:
21
 Organización.
 Consulta.
 Conservación.
 Disposición final de documentos.
 Archivo Histórico
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.
22
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.
23
 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.
24
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
25
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.
26
- 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
27
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.
28
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.
29
 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.
30
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
31
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.
32
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).
33
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
34
Figura 7. Solicitud de Contenidos Analíticos
Fuente. Los Autores
Figura 8. Solicitud de Aplazamiento o Cancelación de Semestre
Fuente. Los Autores
35
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
36
Figura 11. Solicitud de Adición y Cancelación de Asignaturas
Fuente. Los Autores
Figura 12. Cambio de Plan de Estudios
Fuente. Los Autores
37
Figura 13. Solicitud de Suficiencia o Validación de Asignaturas
Fuente. Los Autores
Figura 14. Actas de Nodo
Fuente. Los Autores
38
Figura 15. Solicitud de Requisición de Elementos de Oficina
Fuente. Los Autores
Figura 16. Memorandos
Fuente. Los Autores
39
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
40
 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)
 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.
41
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.
Ingresar a SIGD por medio de un usuario y contraseña
Función
validados en la tabla Empleados de la base de datos.
 Debe pertenecer a la Universidad de San
Precondiciones Buenaventura.
 Asignación de privilegios para acceder al sistema
Garantías de
 Se actualizan los datos del administrador
éxito
1. El administrador ingresa al sistema SIGD , donde se
encuentra con una casilla de ingreso, un usuario y una
contraseña
Flujo principal
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
42
nombre de usuario y su respectiva contraseña.
5. Se habilitan todo los módulos de SIGD.
 En cualquier momento el sistema falla.
1. El administrador reinicia el sistema, y vuelve a iniciar
sesión.
Extensiones
 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
Función Administrar la tabla de Cargos existente en el sistema.
Precondiciones  El administrador debe haber iniciado sesión
Garantías de  Se crea, se elimina, se modifica, o se consulta un
éxito registro de la entidad Cargos.
1. SIGD inicia una nueva ventana mostrando el menú
cargos.
Flujo principal 2. El administrador elije la opción que desea del menú
3. El administrador guarda los cambios
4. El administrador cancela el proceso

sesión.
 El sistema genera las opciones por cada entidad
Extensiones
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
Administrar la tabla de Unidades Administrativas existente
Función
en el sistema.
éxito registro de la entidad Unidades Administrativas.
Flujo principal 1. SIGD inicia una nueva ventana mostrando el menú
unidades administrativas.
43
2. El administrador elije la opción que desea del menú
1. El administrador reinicia el sistema y vuelve a iniciar
sesión.
Extensiones
1. Crear
2. Modificar
3. Consultar
4. Eliminar
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.
éxito registro de la entidad Empleados.
empleados.
Flujo principal
sesión.
Extensiones
1. Crear
2. Modificar
3. Consultar
4. Eliminar
Fuente. Los Autores
Tabla 6. Caso de Uso Administrar Procedimiento (Versión 1)

Caso de Uso Administrar Procedimiento
Administrar la tabla de Procedimientos existente en el
Función
sistema para cada tipo de documento
éxito registro de la entidad Procedimientos.
44
procedimientos.
Flujo principal
sesión.
Extensiones
1. Crear
2. Modificar
3. Consultar
4. Eliminar
Fuente. Los Autores
Tabla 7. Caso de Uso Administrar Tipo de Documento (Versión 1)

Caso de Uso Administrar Tipo de Documento
Administrar la tabla de Tipo Documentos existente en el
Función
sistema
éxito registro de la entidad Tipo Documentos
1. SIGD inicia una nueva ventana mostrando un menú tipo
documentos
Flujo principal
 En Cualquier momento el sistema falla.
sesión.
Extensiones
1. Crear
2. Modificar
3. Consultar
4. Eliminar
Fuente. Los Autores
Tabla 8. Caso de Uso Administrar Flujo de Documento (Versión 1)

Caso de Uso Administrar Flujo de Documento
Administrar la tabla Flujo Documentos ( los procedimientos
Función realizados a cada documento en las diferentes Unidades
Administrativas)
45
éxito registro de la entidad Flujo Documentos
1. SIGD inicia una nueva ventana mostrando el menú flujo
documentos.
Flujo principal
sesión.
Extensiones
1. Crear
2. Modificar
3. Consultar
4. Eliminar
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.
46
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
Administrar la tabla Cargos existente en el sistema,
Función 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
Garantías de
registro de esta entidad y se registran los cambios
éxito
efectuados que hayan sido aprobados.
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ú,
Flujo principal
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
47
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.
Extensiones 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
48
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
Administrar la tabla Unidades Administrativas existente en
el sistema, permitiendo la creación de una nueva unidad
Función
administrativa, la eliminación, la modificación y consulta de
una unidad administrativa. ya existente
Garantías de
registro de esta entidad, se registran los cambios
éxito
unidades administrativas.
Flujo principal todos los registros que contiene la entidad
oprimiendo sobre la opción que se desee. crear,
consultar, modificar o eliminar.
4. El administrador realiza el proceso que desee. (si es el
49
caso)
sesión.
 Es necesario ingresar una nueva unidad administrativa.
1. El administrador puede ingresar un nuevo registro en
no exista.
- Si existe, alerta diciendo que el dato esta repetido, y
detendrá el proceso.
 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.
Extensiones
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.
- 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).
2. SIGD muestra una tabla con todos los registros de esa
entidad
Fuente. Los Autores
50
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)

Administrar la tabla de Empleados existente en el sistema,
permitiendo la creación de un nuevo empleado, o la
Función
eliminación, la modificación y consulta de un empleado ya
existente
 El administrador debe haber iniciado sesión
Precondiciones
 Deben existir registros de Cargos en SIGD
Garantías de
registro de esta entidad, Se registran los cambios
éxito
empleados.
Flujo principal
crear, consultar, modificar o eliminar, oprimiendo sobre
la opción que se desee.
caso)
51
sesión.
 Es necesario ingresar un nuevo empleado en la entidad.
2. El administrador debe asignarle un Cargo antes de
guardar.
no exista.
 Si existe, alerta diciendo que el dato esta repetido, y
 Existen varios empleados que no son necesarios o no
Extensiones
2. SIGD se encarga de verificar que el registro del
empleado exista en el sistema.
 Los empleados pueden generar cambios a medida del
tiempo.
2. El administrador selecciona el registro del empleado
 Si existe un error en los caracteres ingresados SIGD
 Los diferentes registros de Empleados pueden ser
consultados en una vista general (una tabla).
entidad
Fuente. Los Autores
52
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
Administrar la tabla Tipos Documentos existente en el
sistema, permitiendo la creación de una nuevo tipo de
Función
documento, la eliminación, la modificación y consulta de
un tipo de documento ya existente
Garantías de
éxito
1. SIGD inicia una nueva ventana mostrando el menú tipos
documentos.
Flujo principal
crear, consultar, modificar o eliminar, oprimiendo sobre
la opción que se desee.
53
caso)
sesión.
 Es necesario ingresar un nuevo tipo de documento.
no exista.
 Si existe, alerta diciendo que el dato esta repetido, y
Extensiones  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
 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
54
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
Administrar la tabla Usuarios existente en el sistema,
Función
donde se encuentran: docentes, alumnos, administrativos
Precondiciones
 Deben tener relación con la institución
Garantías de
éxito
usuarios.
Flujo principal
crear, consultar, modificar o eliminar, oprimiendo
sobre la opción que se desee.
caso)
55
sesión.
 Existen varios usuarios que no pertenecen o no tienen
relación alguna con la institución. .
usuario exista en el sistema.
 Los usuarios pueden generar cambios a medida del
tiempo.
Extensiones
usuario exista en el sistema.
2. El administrador selecciona el registro del usuario
 Si existe un error en los caracteres ingresados, SIGD
 Los diferentes registros de usuarios pueden ser
entidad
Fuente. Los Autores
Figura 25. Caso de Uso Radicar (Versión 1)
Fuente Los Autores
56
Tabla 14. (Análisis) Caso de Uso Radicar (Versión 1)
Caso de Uso Radicar
Actores Radicador, Usuario, Base de Datos.
Administrar la entrada y digitalización de documentos al
Función
sistema
 El usuario habrá de cancelar el recibo según el proceso
Precondiciones de su documento
 El radicador debe iniciar sesión
Garantías de  Se crea, y se indexan las peticiones de documentos por
éxito parte de los usuarios, se inician los debidos procesos.
radicación.
2. SIGD muestra una lista con las opciones de ingreso
según lo que el usuario ha diligenciado en el formulario
Flujo principal
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
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.
Extensiones
2. El radicador puede editar los registros
5. El radicador señala la opción de consulta
6. SIGD muestra una tabla con todos los registros
Ingresados
Fuente. Los Autores
57
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.
Gestiona todo el envío de documentos a sus respectivos
Función 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
Garantías de
pendientes en SIGD y según su prioridad y fecha de
éxito
ingreso son atendidos.
distribución
2. SIGD muestra una lista de los documentos pendientes
de envío
Flujo principal
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
1. El radicador y /o empelado reinicia el sistema y vuelve
a iniciar sesión.
Extensiones
 Pueden haber errores al momento de ingresar dos
documentos
1. SIGD se encarga de verificar que el documento no
58
exista en el sistema y su distribución sea ordenada.
 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.
59
Figura 27. Modelo de Base de Datos propuesta
DOC_UNID_ESTADOS
ESTADOS PK Id_estado UNIDADES_ADMINISTRATIVAS
PK Id_estado PK Id_documentos
PK Id_unidades_administrativas PK Id_unidades_administrativas
Estados_documento Unidades_administrativas
DOCUMENTOS USUARIOS
TIPO_DOCUMENTOS
PK Id_documento PK Id_usuario
PK Id_tipo_documento
Asunto Nom_usuario
Tipo_documento Apell_usuario
Dirigido_a
Fecha_radica Email_usuario
Fecha_rta Id_tipo_usuario
Id_tipo_documento
Id_usuario
FLUJO_DOCUMENTOS
PK Id_flujo_documento
Flujo_documento
Tiempo_estimado
TIPO_USUARIOS
PK Id_tipo_usuario
Tipo_usuario
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.
60
Figura 28. Modelo Entidad Relación SIGD Versión 1
Fuente. Los Autores
61
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.
62
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
63
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.
64
Figura 30. Grafica de resultado de pruebas (Versión 1)
10
9
8
7
6
Inconforme
5
Conforme
4
3
2
1
0
Visual Funcional Seguridad Rendimiento
Fuente. Los Autores
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
65
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.
66
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.
Ingresar a SIGD por medio de un usuario y contraseña
Función
validados en la tabla Empleados de la base de datos.
Debe pertenecer a la Universidad de San Buenaventura.
Precondiciones
Asignación de privilegios para acceder al sistema
Garantías de
Se actualizan los datos del administrador
éxito
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
Flujo principal 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.
67
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
Administrar la tabla paramétrica Tipos Definiciones, creada
para disminuir tablas de la versión 1.0 y proporcionar
Función
efectividad en el tiempo de consulta. ( ver mas información
en Etapa de Diseño versión 2.0)
éxito registro de la entidad Tipos Definiciones.
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.
Flujo principal 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.
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.
éxito 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
68
2. El administrador elije la opción que desea de esa lista.
(Eliminar, Actualizar o Nuevo).
4. El administrador cancela el proceso.
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.
 El Administrador debe haber iniciado sesión
Precondiciones  Debe existir un valor definición que represente un
cargo.
Garantías de  Se crea, se elimina, se modifica, o se consultan un
éxito registro de la entidad Empleados.
todos los registros de la tabla Empleados.
2. El Administrador elije la opción que desea de esa lista
Flujo principal
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)

Administrar la tabla Procedimientos existentes para cada
Función
tipo de documento
Precondiciones  El Administrador debe haber iniciado sesión
éxito registro de la entidad Procedimiento.
1. SIGD inicia una nueva ventana mostrando una lista
Flujo principal paginada con todos los procedimientos.
2. El administrador elije la opción que desea de esta Lista
69
(Eliminar, Modificar, Nuevo)
 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
Función Administrar la tabla Tipo Documentos existente en el
sistema.
éxito 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
Administrar la tabla Flujo Documentos ( los procedimientos
Función realizados a cada documento en las diferentes Unidades
Administrativas )
Precondiciones
 Debe existir un tipo documento
Garantías de  Se crea, se elimina, se modifica, o se consultan un
éxito registro de la tabla Flujo Documentos
Flujo principal 1. SIGD inicia una nueva ventana mostrando una lista
70
Flujo Documentos.
2. El administrador elije la opción que desee de esta lista
3. Importante establecer la prioridad del flujo.
 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
Función Administrar la tabla Usuarios existente en el sistema.
Precondiciones  Debe existir un valor definición que represente un Tipo
Usuario.
éxito registro de la entidad Usuarios.
todos los registros de la tabla Usuarios.
2. El administrador elije la opción que desea de esa lista.
Flujo principal
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.
71
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
Administrar la tabla de Tipos Definiciones, permitiendo la
creación de un nuevo registro, la eliminación, la
Función 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)
Garantías de
éxito
 Se logra la optimización de recursos a nivel de tiempos
de respuesta de la base de datos.
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.
Flujo principal
3. El administrador para crear un nuevo registro se debe
dirigir hasta la última casilla existente en esa lista.
caso)
72
sesión.
 Es necesario ingresar un nuevo tipo definición.
no exista.
 Existen varios tipos definición que no son necesarios o
no existen dentro de la institución.
2. SIGD se encarga de verificar que el registro del tipo
Extensiones
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.
traída por SIGD mostrada en una lista paginada.
 Los diferentes Registros de tipo definición pueden ser
entidad
Fuente. Los Autores
73
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
Administrar la tabla Valores Definiciones permitiendo la
creación de un nuevo registro, la eliminación, la
Función 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)
 El Administrador debe haber iniciado sesión
Precondiciones
 Debe existir un Tipo Definición
Garantías de
efectuados y que hayan sido aprobados.
éxito
 Se logra la optimización de recursos a nivel de tiempos
de respuesta de la base de datos.
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
Flujo principal 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.
74
caso)
sesión.
 Es necesario ingresar un nuevo valor definición.
no exista.
 Existen varios, valores definición que no son necesarios
o no existen dentro de la institución.
Extensiones
3. El administrador busca el registro y lo elimina.
 Los valores definición pueden generar cambios a
medida del tiempo.
 Los diferentes registros de valor definición pueden ser
1. El Administrador señala la opción de consulta
entidad
Fuente. Los Autores
75
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)

Administrar la tabla Empleados existente en el sistema,
permitiendo la creación de una nuevo empleado, la
Función
eliminación, la modificación y consulta de un empleado ya
existente
Precondiciones  Deben existir un tipo definición y valores definiciones
para de tipo “tip_cargos” y asignarlo.
Garantías de
éxito
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
Flujo principal eliminar, oprimiendo sobre la opción que se quiera
3. El Administrador realiza el proceso que desee. (si es el
caso)
76
sesión.
 Es necesario ingresar un nuevo empleado.
2. El administrador debe asignarle un Valor Definición de
tipo “tip_cargos” antes de guardar.
no exista.
 Si existe, alerta diciendo que el dato esta repetido, y
 Existen varios empleados que no son necesarios o no
Extensiones
 Los empleados pueden generar cambios a medida del
tiempo.
2. El administrador selecciona el registro del empleado
 Los diferentes Registros de empleados pueden ser
1. El Administrador señala la opción de consulta
entidad
Fuente. Los Autores
77
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)

Administrar la tabla Procedimientos existente en el
sistema, permitiendo la creación de una nuevo registro, la
Función
eliminación, la modificación y consulta de un procedimiento
existente
Garantías de
éxito
todos los procedimientos
Flujo principal apuntando hacia el campo que desea modificar o
eliminar, oprimiendo sobre la opción que se quiera
Extensiones
sesión.
 Es necesario ingresar un nuevo procedimiento.
78
no exista.
 Los procedimientos pueden generar cambios a medida
del tiempo.
procedimiento exista en el sistema.
 Los diferentes registros de la tabla Procedimientos
tabla).
entidad
Fuente. Los Autores
79
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)

Administrar la tabla Tipos Documentos existente en el
Función
existente
Garantías de
éxito
todos los tipos documentos
 Es necesario ingresar un nuevo tipo documento.
80
no exista.
 Los tipos documentos pueden generar cambios a
medida del tiempo.
 Los diferentes registros de la tabla Tipos Documentos
tabla).
entidad
Fuente. Los Autores
81
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)

Administrar la tabla Flujo Documentos existente en el
Función
existente
Precondiciones  Se tiene que tener registrado un tipo documento
 Se tiene que tener registrados procedimientos
Garantías de
éxito
todos los flujos documentos
Extensiones
82
sesión.
 Es necesario ingresar un nuevo flujo documento.
no exista.
 Los flujos documentos pueden generar cambios a
medida del tiempo.
1. SIGD se encarga de verificar que el registro del flujo
 Los diferentes registros de la tabla Flujo Documentos
tabla).
entidad
Fuente. Los Autores
83
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
Administrar la tabla Usuarios existente en el sistema,
permitiendo la creación de una nuevo registro, la
Función
existente
Precondiciones  Se tiene que tener valores definiciones de tipo definición
“tip_usu”.
Garantías de
éxito
todos los usuarios
 Es necesario ingresar un nuevo usuario.
84
no exista.
 Los usuarios pueden generar cambios a medida del
tiempo.
1. SIGD se encarga de verificar que el registro del flujo
 Los diferentes registros de la tabla Usuarios pueden ser
entidad
Fuente. Los Autores
Fuente. Los Autores
85
Caso de Uso Radicar
Administrar la entrada y digitalización de documentos al
Función
sistema
Precondiciones de su documento
 Se crean, y se indexan las peticiones de documentos
Garantías de
por parte de los usuarios y se inician los debidos
éxito
procesos.
1. SIGD inicia una nueva ventana mostrando un menú
Radicación.
apuntando hacia el campo que desea modificar o
3. SIGD muestra una lista con las opciones de ingreso
según lo que el usuario ha diligenciado en el formulario
Flujo principal 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
caso)
1. El radicador y/o empleado reinicia el sistema y vuelve a
iniciar sesión.
 El documento debe seguir el orden de procedimientos y
 Pueden haber errores al momento de enviar Los
documentos
1. SIGD se encarga de verificar que el Documento realice
los respectivos procedimientos.
Extensiones
2. El radicador puede editar los registros
1. El radicador señala la opción de consulta
2. SIGD muestra una tabla con todos los registros
Ingresados
Fuente. Los Autores
86
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.
Gestiona todo el envío de documentos a sus respectivos
Función
Procedimientos.
Precondiciones
 El empleado debe iniciar sesión
 Se genera un control sobre los documentos que están
Garantías de
pendientes en SIGD y según su prioridad y fecha de
éxito
ingreso son atendidos.
distribución.
2. SIGD muestra una lista de los documentos pendientes
de envío
Flujo principal
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.
1. El radicador y/o empelado reinicia el sistema y vuelve a
iniciar sesión.
Extensiones  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.
87
 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
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
88
consultas y transacciones, ya que no se tendrán que hacer múltiples uniones a
tablas que no proveen suficiente información.
89
Figura 42. Modelo Entidad Relación SIGD Versión 2
Fuente. Los Autores
90
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.
91
Figura 43. Modelo de Clases SIGD Versión 2
Fuente. Los Autores
92
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.
10
9
8
7
6
Inconforme
5
Conforme
4
3
2
1
0
Fuente. Los Autores
93
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.
94
Fuente. Los Autores

Caso de Uso Radicar
Administrar toda la entrada y digitalización de documentos
Función
al sistema
El radicador debe iniciar sesión
Precondiciones El usuario debe haber cancelado el costo del trámite del
documento.
Garantías de Se crea, se indexan las peticiones de documentos por
éxito parte de usuarios y se inician los debidos procesos.
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
Flujo principal
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
95
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
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
Pueden haber errores al momento de enviar los
documentos
SIGD se encarga de verificar que el documento realice los
respectivos procedimientos.
Extensiones El radicador puede editar los registros
La información es aprobada y guardada por SIGD.
Si existe un error en los caracteres ingresados SIGD
Los diferentes registros de Documentos pueden ser
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
96
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
97
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
Precondiciones
de su documento
Garantías de  El sistema actualiza automáticamente el estado del
éxito documento después de reanalizar un procedimiento.
1. El Usuario ingresa el código de radicación del
Flujo principal documento.
2. SIGD verifica el estado del documento y le informa al
usuario si su documento ya esta listo.
Extensiones
1. El usuario reinicia el sistema y vuelve a iniciar sesión.
98
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  Identificad
numérico or del
empleado
en el
sistema
Codigo Character Números  Código
(30) que
representa
al
empleado
en la
Institución
Nombre Character letras  Nombre
(100) del
empleado
Apellido Character letras  Apellido
(100) del
empleado
Cargo_id  integer Números  Código
que
identifica
el cargo
del
empleado
en la tabla
tipo
definición
Unidad_Administ  integer Números  Código
rativa_id que
identifica
la unidad
administra
tiva dentro
de la
institución
en la tabla
tipo
definición
Login Character Letras y  Login del
(20) caracteres Empleado
99
Password Character Letras y  Contraseñ
(20) caracteres 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_  serial SEQUENCE  Identific
id INCREMENT 1 ador de
MINVALUE 1 el cargo
en el
sistema
Tipo_Definicion Character letras  Nombre
(10) del
cargo
Descripcion_tipo Character letras  Descripc
_def (200) ió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_  serial SEQUENCE  Identific
id INCREMENT 1 ador de
MINVALUE 1 el cargo
en el
sistema
Tipo_Definicion Character letras  Nombre
(10) del
cargo
Descripcion_tipo Character letras  Descripc
_def (200) ión del
tipo
definició
n
Fuente. Los Autores
100
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
ón
Flujo_document  serial auto  Identificad
o__id numérico or de el
cargo en
el sistema
Tipo_documento  integer Números Nombre
_id del cargo
Procedimiento_i  integer Números 
d
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.
ón
Documento_id  serial auto  Identificad
numérico or del
document
o en el
sistema
Codigo Character( Letras y  Código
50) numeros que
representa
el
document
o en la
Institución
Asunto Character( letras  Titulo del
500) document
o
Dirigido_A Character( letras  Unidad a
100) quien va
dirigido
Fecha_radicacio date Fechas  now Fecha de
n entrada
del
document
o
Fecha_respuest date Fechas  Fecha de
a entrega
del
document
o
101
Tipo_documento  integer Números  Identificad
_id or de el
tipo de
document
o en el
sistema
Usuario_id  integer Números  Identificad
or del
usuario en
el sistema
Estado_id  integer Números  Identificad
or de el
estado en
el sistema
Adjunto Character( letras Informació
300) n adjunta
al
document
o
Observaciones Character( letras Observaci
6000) ones
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
ón
Historico_id  serial auto  Identificad
numérico or de
histórico
Documento_id  integer Números  Identificad
or de el
document
o 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  Identificad
or del
procedimi
ento
Fuente. Los Autores
102
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
ón
Procedimiento_id  serial auto  Identificad
numérico or del
procedimi
ento
dentro el
sistema
Procedimiento Character Números  Descripció
(100) n
procedimi
ento
duración integer Números  Duración
del
proceso
Empleado_id  Integer Números  Identificad
or 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  serial auto  nextval('gesti Identifica
_id numérico on_document dor del
al.tipo_docu tipo de
mento_tipo_d documen
ocumento_id to dentro
_seq'::regcla del
ss), sistema
Tipo _ Character Letras y  Nombre
documento (100) caracteres del tipo
de
documen
to.
Descripcion_tipo Character Letras y  Descripci
_doc (200) caracteres ón del
tipo_doc
umento.
Fuente. Los Autores
103
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
ón
Usuario_id  serial auto  Identificad
numérico or del
usuario en
el sistema
Codigo Character Números y  Código
(00) letras que
representa
al usuario
en la
Institución
Nombre Character letras  Nombre
(100) del
usuario
Apellido Character letras  Apellido
(100) del
usuario
Solicitante Carácter Letras  Solicitante
(100)
Tipo_Usuario_id  integer Números  Identificad
or del
tipo_usuar
io 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.
104
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
105
distribuidos.
Puede crear, modificar y eliminar

- usuarios
Puede distribuir documentos

para las solicitudes de documentos.
Administrativo Puede gestionar los documentos que
para su procedimiento se generen

para las solicitudes de su documento
* El control de acceso se realiza por login y Password
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.
10
9
8
7
6
Inconforme
5
Conforme
4
3
2
1
0
Fuente. Los Autores
106
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.
107
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.
108
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.
109
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.
110
ANEXOS
111
FORMATO DE PRUEBAS PARA EL SISTEMA DE GESTIÓN DOCUMENTAL - SIGD
112

PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

PDF

Încărcat de

Drepturi de autor:

Formate disponibile

DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN

DOCUMENTAL UTILIZANDO HERRAMIENTAS DE SOFTWARE LIBRE

ANDRES FELIPE CASTILLEJO ALDANA

UNIVERSIDAD DE SAN BUENAVENTURA

ANDRES FELIPE CASTILLEJO ALDANA

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

UNIVERSIDAD DE SAN BUENAVENTURA

Bogota, 04 de Junio de 2008

A portas de culminar nuestro proyecto de grado, que ha requerido de sacrificio

En primera medida agradecerle a nuestro creador por la oportunidad de estar

Queremos decirle a nuestros padres, hermanos y a todos nuestros seres

En segundo lugar agradecerle a la Ingeniera Claudia Rodríguez, que ha hecho

A la Caja de Retiro de las Fuerzas Militares (CRAMIL) que nos permitió el

Por ultimo agradecerle a los docentes de la facultad de ingeniería que

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

Figura 1. Ciclo vital del documento. 22

Durante la historia reciente de la humanidad la información se ha convertido en

La sociedad actual, genera grandes volúmenes de información que algunos

En el ámbito interno de la ingeniería del software se ha trabajado arduamente

El programa de Ingeniería de Sistemas de la Universidad de San Buenaventura

El objetivo esencial de implementar un software de gestión documental en el

La solución informática que se plantea en este documento, se desarrolla bajo la

El programa de Ingeniería de Sistemas de la Universidad de San Buenaventura

Es por esto, que el programa de Ingeniera de Sistemas dentro de su campo

En Colombia y en el mundo ya se han desarrollado e implementado con éxito

SOTWARE EMPRESA FORMATOS LICENCIA SOFTWARE ALMACENAMIENTO SEGUIMIENTO

En la actualidad el programa de Ingeniería de Sistemas de la Universidad de

¿Cómo diseñar e implementar el sistema de gestión documental para el

Con la implementación de un sistema de gestión documental desarrollado con

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

1.4.2 Objetivos Específicos

 Validar el modelo de base de datos propuesto en el proyecto de grado

1.5 ALCANCES Y LIMITACIONES DEL PROYECTO

El proyecto culmina con la implementación del sistema de gestión documental

2.1 MARCO TEÓRICO – CONCEPTUAL

2.1.1 Gestión Documental

Se define Gestión documental como el Conjunto de actividades administrativas

Un Sistema de gestión documental se puede concebir como el conjunto de

El sistema de gestión documental debe asegurar la asignación de recursos

 Resaltar la importancia del papel de los documentos y archivos, como

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

 Normalizar la utilización de materiales, soportes y equipos de calidad y que a

 Lograr una acertada normalización en los procedimientos para el recibo,

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

 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,

 El manejo integral de los documentos y de la información como base para la

 La integración de los estamentos institucionales en torno a objetivos

 La evaluación y valoración de la documentación para evitar la acumulación

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

 La normalización de las tareas archivísticas a la luz de la nueva concepción

Dentro del proceso archivístico tradicionalmente las entidades han centrado su

Un sistema de gestión documental permite tener una visión exacta y completa

Para elaborar un Software de gestión documental, se deben considerar los

 Administrativos: se refiere a contemplar las situaciones administrativas de la

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

A partir del estudio y análisis de la documentación el sistema de gestión

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

o Diagnóstico. El diseño y desarrollo de un Software de gestión documental,

 Centralización de la recepción y envío de los documentos.