SISTEMA DE INFORMACIÓN ESTÁNDAR DE GESTIÓN …

109
SISTEMA DE INFORMACIÓN ESTÁNDAR DE GESTIÓN DOCUMENTAL EN AMBIENTE WEB. CARLOS LEÓN ARENAS RIVERA GEOVANNY GÓMEZ OROZCO UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BASICAS E INGENIERÍA PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES PEREIRA Noviembre 2014

Transcript of SISTEMA DE INFORMACIÓN ESTÁNDAR DE GESTIÓN …

SISTEMA DE INFORMACIÓN ESTÁNDAR DE GESTIÓN DOCUMENTAL EN AMBIENTE WEB.

CARLOS LEÓN ARENAS RIVERA

GEOVANNY GÓMEZ OROZCO

UNIVERSIDAD CATÓLICA DE PEREIRA

FACULTAD DE CIENCIAS BASICAS E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES

PEREIRA

Noviembre 2014

INFORME DE PROYECTO DE GRADO PARA OPTAR POR EL TÍTULO DE INGENIEROS EN SISTEMAS Y TELECOMUNICACIONES

CARLOS LEÓN ARENAS RIVERA

GEOVANNY GÓMEZ OROZCO

DIRECTOR

JUAN CARLOS BLANDÓN ANDRADE

MAGISTER EN INGENIERÍA ÉNFASIS EN SISTEMAS Y COMPUTACIÓN

UNIVERSIDAD CATÓLICA DE PEREIRA

FACULTAD DE CIENCIAS BASICAS E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES

PEREIRA

Noviembre 2014

DECLARACIÓN DE DERECHOS DE AUTOR

Como estudiantes de la Universidad Católica de Pereira del programa de Ingeniería de Sistemas y Telecomunicaciones, declaramos que este proyecto fue iniciativa propia, resultado de un estudio realizado, en el cual se vio la necesidad de desarrollar un aplicativo que administre los procesos de gestión documental enmarcados en la ley 594 del 2000 que aplica para todas las entidades públicas y privadas que generen documentos de interés público. Autorizamos la utilización de este proyecto a la Universidad o a diferentes estudiantes para ser utilizado como material de estudio y/o base para otros proyectos.

DEDICATORIA

GEOVANNY GÓMEZ OROZCO: Dedico este trabajo de grado a mi esposa (Catalina Buriticá Osorio) y a mis hijos (José Daniel, Laura Sofía, Samuel David y Juan Alejandro) quienes han esperado pacientemente la culminación de este proceso, quienes muchas veces encontraba dormidos al llegar a casa, pero que fueron la fuente de inspiración y el motivo para ser en Ingeniero. LEÓN ARENAS: Dedico este trabajo de grado a mi papá Jesús Arenas, papá sos un grande, este más que un logro mío es un triunfo tuyo, también le dedico este proyecto a mi mamá Rosa Helena y a mis hijos: Wendy y Sebastián.

AGRADECIMIENTOS

GEOVANNY GÓMEZ OROZCO: Gracias a Dios, por la historia que me ha regalado, por haber puesto en el camino personas que han sido guía a lo largo de toda la vida, hasta llegar a este momento.

Agradezco a mi familia por apoyarme incondicionalmente, por el sacrificio del tiempo que no he pasado con ellos durante tantas noches y brindarme en cada instante su fortaleza para seguir adelante.

De igual manera mis más sinceros agradecimientos a nuestro director de proyecto de grado Ing. Juan Carlos Blandón por aportar sus conocimientos para hacer de este un buen proyecto, a la Ingeniera Lina María Suarez porque fue mi primera profesora de bases de datos y quien ha hecho crecer en mí el gran interés hacia este tema.

Gracias al Dr. Juan Carlos Medina (Director Regional Occidente), Ing. Luz Piedad Vallejo Duque, al Comité de Capacitación, a la Dra. Claudia Isabel Niño Izquierdo (Secretaria General), Ing. Diego Yesid Ortiz, Ing. Pablo Contreras, Sr. Jorge Eduardo Cardona y en general al Instituto nacional de Medicina Legal y Ciencias Forenses porque hicieron posible con el ánimo, el conocimiento, la gestión y el apoyo, que hoy esté en este punto de mi carrera.

Muchas gracias a todas y cada una de las personas que han hecho parte del desarrollo de este proyecto. LEÓN ARENAS: Agradezco a mi papá Jesús, mis hijos, mis amigos, nuestro director de proyecto de grado Ing. Juan Carlos Blandón por aportar su increíble paciencia, don de gente, conocimiento y a la Ingeniera Lina María Suarez por brindarme su apoyo y amistad desde el primer día que la conocí.

TABLA DE CONTENIDO Pág. INTRODUCCIÓN. 14 1. FORMULACIÓN DEL PROYECTO 15

1.1. DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA 15

1.1.1. Situación problemática 15

1.1.2. Planteamiento del Problema 16

1.2. OBJETIVOS 16

1.2.1. Objetivo General 16

1.2.2. Objetivos Específicos. 16

1.3. JUSTIFICACIÓN 17

1.4. CRONOGRAMA. 18

1.5. PRESUPUESTO. 19

1.6. APORTE TEÓRICO Y PRÁCTICO. 21

2. MARCOS DE REFERENCIA 21

2.1. MARCO TEÓRICO 21

2.1.1. Antecedentes 21

2.1.2. Antecedentes teóricos 24

2.1.2.1. Ciclo de vida de software modelo clásico 24

2.1.2.2. Ciclo de vida en espiral 25

2.1.2.3. Ciclo de vida en V 25

2.1.2.4. Metodologías ágiles 26

2.1.2.5. Arquitectura ANSI/SPARC 33

2.1.2.6. Arquitectura MVC 34

2.2. MARCO CONTEXTUAL 34

2.3. MARCO CONCEPTUAL 36

3. MODELO TEÓRICO 39

3.1. METODOLOGÍA PARA EL DESARROLLO DE SOFTWARE (AUP) 40 3.1.1. Fases 40 3.1.1.1 Inicio 40 3.1.1.1.1. Modelo de requisitos basado en IEEE STD 830-1998 40

3.1.1.2. Elaboración 58 3.1.1.3. Construcción 60 3.1.1.4. Transición 67 3.1.2. Actividades 68 3.1.2.1. Modelo 68 3.1.2.2. Implementación 68 3.1.2.3. Prueba 68 3.1.2.4. Despliegue 68 3.1.2.5. Administración de la configuración 68 3.1.2.6. Ambiente 68 3.2. Tendencias 69

4. CONCRECIÓN DEL MODELO 70 CONCLUSIONES 80 RECOMENDACIONES 81 REFERENCIAS BIBLIOGRAFICAS 82 GLOSARIO 85 ANEXOS (REFERENCIA TECNICA) 88-109

LISTA DE TABLAS Y FIGURAS

Lista de Tablas Pág.

TABLA 1. Presupuesto del proyecto 19 TABLA 2. Metodología general del proyecto 39 Lista de Figuras Pág. FIGURA 1. Modelo de la cascada 24 FIGURA 2. Modelo en espiral 25 FIGURA 3. Modelo en V 26 FIGURA 4. El ciclo de vida del AUP 31 FIGURA 5. Modelo de diseño de la base de datos 54 FIGURA 6. Diagrama de flujo de Procesos 55 FIGURA 7. Despliegue de Alto Nivel 58

FIGURA 8. Símil con aplicación de Arquitectura ASI/SPARC 59 FIGURA 9. Arquitectura MVC 59 FIGURA 10. Diagrama de ciclo de vida del documento 60 FIGURA 11. Recepción y entrega de documentos 61

FIGURA 12. Distribución de documentos 62 FIGURA 13. Trámite de documentos 63 FIGURA 14. Producción de documentos 64 FIGURA 15. Organización de documentos 65 FIGURA 16. Conservación de documentos 66 FIGURA 17. Disposición final de documentos 66 FIGURA 18. Consulta de documentos 67 FIGURA 19. Pantalla Usuario y Contraseña 72 FIGURA 20. Pantalla Principal 73 FIGURA 21. Pantalla Crear Documento 73 FIGURA 22. Pantalla de Consulta 74 FIGURA 23. Visualización de Documento 74 FIGURA 24. Prueba Digitalización 75 FIGURA 25. Prueba Autenticación 76 FIGURA 26. Prueba Perfil de Usuario 76

FIGURA 27. Prueba Guardar Información en la base de datos y validar campos 77 FIGURA 28. Prueba Almacenar Documento Digital 78 FIGURA 29. Prueba Consulta 78 FIGURA 30. Prueba Cambio de Tema (Personalizar entorno) 79

LISTA DE ANEXOS

REFERENCIA TECNICA

ANEXO A. CRONOGRAMA POR ITERACIONES ANEXO B. PRODUCTO MINIMO A ENTREGAR

ANEXO C. MANUAL DE USUARIO

RESUMEN

Las empresas por naturaleza deben manejar grandes cantidades de información en documentos físicos. Debido a la globalización de la información, a la gran cantidad de documentos y leyes vigentes, se hace necesario digitalizarlos, de esta forma podrán ser gestionados eficientemente a través de aplicaciones de Software. Este trabajo propone el desarrollo de una aplicación de Software en ambiente Web, para la gestión eficiente de estos documentos, teniendo en cuenta las leyes vigentes en Colombia y la metodología de desarrollo AUP. Esta aplicación permitirá consultar los documentos a cualquier momento que se requiera y en cualquier lugar. PALABRAS CLAVES: Gestión documental, desarrollo de software, arquitectura

MVC, metodología AUP, aplicación Web, ley 594 de 2000, directiva presidencial 04 de 2012, disponibilidad, control y digitalización de documentos.

ABSTRACT

Companies normally have to manage large amounts of information in paper documents. By the globalization of information, the great amount of documents and current laws, is necessary the digitizing, in this way they may be managed efficiently through software applications. This project proposes the development of a software application in web environment, for the efficient management of these documents, taking into account existing laws in Colombia and the development methodology AUP. This application will allow consult documents to any time as required and anywhere.

KEYWORDS: Document management, software development, MVC architecture,

AUP methodology, Web application, Law 594 of 2000, Presidential Directive 04, 2012, availability, control and document scanning.

14

INTRODUCCIÓN

Las empresas por naturaleza deben manejar gran cantidad de información en documentos físicos, razón por la cual, gestionarlos, controlarlos y tenerlos disponibles, resulta muy complejo. La 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, esto significa: tener disponibilidad, gestión y control de los documentos, determinando el tiempo que deben guardarse, eliminarse o asegurar la conservación indefinida de los más valiosos, aplicando principios de racionalización y economía.

En Colombia La ley 594 de 2000 (ley general de archivo) define la gestión documental, como: “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.” [1].

Por lo anterior la ley contempla que las empresas del estado o privadas que cumplen labores públicas deben implementar un sistema de gestión documental que permita manejar los procesos del ciclo de vida de un documento de manera digital y disponibilidad en lapsos mínimos.

Este proyecto se enmarca en el desarrollo de un software, que permita a las entidades que así lo requieran, mejorar los procesos de gestión documental, utilizando tablas de retención documental y digitalización de los documentos, permitiendo disponibilidad de información en tiempo real desde cualquier punto de acceso.

El software es compatible con las normas y estándares de la gestión documental. Esto aunado a su fase de desarrollo y estudio de requisitos, lo convierte un software eficaz, eficiente y confiable. En el capítulo 1 se trata la formulación del proyecto. En el capítulo 2 están los marcos de referencia. En el capítulo 3 se encuentra el modelo teórico, es decir, la solución planteada. En el capítulo 4 se aborda la concreción del modelo, lo que incluye las conclusiones, recomendaciones y por último los anexos.

15

1. FORMULACION DEL PROYECTO

1.1. DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA

1.1.1. Situación Problemática

Para entender la situación se hará una descripción del proceso general del flujo de los documentos en una empresa. Es necesario aclarar que los documentos se pueden generar de forma interna o externa, en el segundo caso llegan a la empresa por algún medio (fax, email, personalmente, correo).

Una vez recibido o generado el documento, éste pasa por manos de muchas personas, lo que es un potencial riesgo de: Perdida, daño, desgaste o una mala disposición final del mismo (archivo), mala aplicación de tablas de retención documental, duplicidad de información, etc. Una vez se recibe por el funcionario que debe dar respuesta o tramite al mismo, se generan nuevos documentos que hacen parte de un “expediente”, que empieza un nuevo ciclo en el proceso y está completamente ligado al documento que dio paso a su creación y así se repite el ciclo hasta que se puede archivar el expediente completo de acuerdo a las tablas de retención documental. Posteriormente llegan solicitudes de consulta o requisitos sobre alguno de los documentos que reposan en el archivo de la organización y se requiere obtener información de manera ágil tanto de forma digital como física. En la actualidad muchas entidades realizan los procesos de gestión documental de forma manual, llevando libros de actas, y entregas, formatos en papel, etc. Otras empresas no han implementado algo al respecto, otras gestionan los documentos de manera empírica o por fuera de lo establecido por la ley. Esto hace difícil la planificación, manejo y organización de la documentación producida y recibida por las entidades, más aún cuando se cuenta con sucursales o muchas dependencias y ocasionando un alto consumo de papel y poca eficiencia administrativa [2].

En las empresas donde no se cuenta con la aplicación de técnicas de gestión documental o sistemas de gestión documental, obtener el acceso a la información se convierte en un proceso complicado para quien sea responsable, en la mayoría de los casos, se tiene que realizar de nuevo el trabajo que se solicita o recurrir a la memoria para dar respuesta. También se pierde por completo la trazabilidad y

16

confianza de la procedencia de los documentos. El cumulo y la duplicidad de los mismos, aumenta el consumo del papel y en general se perjudica la empresa, a los clientes o usuarios, internamente el clima organizacional y la comunicación en general se ven truncadas.

1.1.2. Planteamiento del Problema

¿Se puede realizar el desarrollo de un sistema informático en ambiente web, que permita a las organizaciones tener un control sobre sus documentos, trazabilidad y disponibilidad de los mismos cuando lo requieran?

1.2 OBJETIVOS

1.2.1. Objetivo general

Desarrollar un sistema de información estándar de gestión documental en ambiente web, acorde a la ley 594 de 2000, que incluya manejo de tablas de retención documental, digitalización y contribuya a la aplicación de la directiva presidencial 04 del 2012. 1.2.2. Objetivos específicos

- Analizar el flujo de los procesos de la gestión de los documentos.

- Diseñar los diagramas de flujo de los procesos. - Implementar una metodología de desarrollo de Software enmarcada dentro de

las metodologías AGILE.

- Documentar mediante el manual de usuario los aspectos relevantes de la aplicación.

17

1.3. JUSTIFICACIÓN

Cada día las empresas generan gran cantidad de documentos para satisfacer las necesidades propias de la administración y de su quehacer diario, al mismo tiempo surge la necesidad impetuosa de contar con la disponibilidad de la información en tiempo real. Dentro del marco establecido por la ley 594 de 2000 y la directiva presidencial 04 de 2012, se hace necesario la utilización de las nuevas tecnologías, ello con el fin de garantizar un buen manejo de los procesos de gestión documental y el uso eficiente de los recursos, asegurando la reducción significativa del uso del papel, la buena conservación de los documentos existentes y la eficiencia de la administración de los mismos. Se puede evidenciar en las empresas públicas y privadas la falta de un software de estas características, por ello se ve una oportunidad de negocio en las mismas, también como una oportunidad de aprendizaje en el desarrollo de versiones futuras del Software. Por lo anterior, se plantea desarrollar un sistema de gestión documental en ambiente Web, que cumpla con lo que dispone la ley y que esté acorde a las necesidades de las entidades que lo requieran para asegurar la optimización de recursos.

18

1.4. CRONOGRAMA

De acuerdo a la Metodología que se utilizará para realizar el proyecto (AUP - Agile Unified Process o Proceso Unificado Ágil), se trabaja por Iteraciones. Los resultados de una iteración se utilizan como punto de partida para la siguiente. El proyecto se realizará en 4 iteraciones de 2 semanas para el prototipo no funcional V1.0 y 3 iteraciones de 4 semanas para la V1.1 Software Funcional (ver cronograma detallado por iteraciones en ANEXO B):

Cronograma General

Fuente: Elaboración propia

Tiempo Iteración

Mes 1 Mes 2 Mes 3

Mes 4 Mes 5

Iteración 1 (Levantamiento de información, identificar el alcance inicial del proyecto)

Iteración 2 (Análisis de requisitos, identificar una arquitectura potencial para el sistema, realizar presupuesto)

Iteración 3 (Seleccionar la arquitectura del sistema, generar modelo BD)

Iteración 4 (Generar Código inicial)

Iteración 5 (Construir software funcional en una base regular e incremental)

Iteración 6 (Continuar Implementación)

Iteración 7 (Validar y desplegar el sistema)

19

1.5. PRESUPUESTO

TABLA 1. Presupuesto del proyecto basado en Juicio de Expertos y Estimación de Costos

Descripción / Tarea Requerimiento

Cantidad

Presupuesto

Equipos

Equipo de cómputo (especificaciones mínimas) Procesador AMD Athlon X2, DD 200 GB, Memoria RAM de 2GB, Monitor, Teclado y mouse, sistema operativo Windows 8.

2 $3.000.000

Impresora láser multifuncional 1 $300.000

Muebles Escritorio PC 2 $300.000

Software Glasfish, Netbeans, JDK Java, SQL Postgres o MySql.

0

Conectividad Internet 5 Mb. 5 $50.000

Costos Fijos $4.000.000 Planificación

Revisar cumplimiento de las metas de una iteración

anterior y plantear o replantear las nuevas metas.

Persona con rol de gerente de proyecto 1

$5.000.000

Tomar acciones preventivas o correctivas si hay lugar a atrasos o problemas.

Programar reuniones de seguimiento.

Generar nuevas tareas.

Distribuir tareas.

Asignar roles. Análisis de Requisitos

Realizar entrevistas en las áreas para levantar la información del flujo de los documentos generales.

Persona rol Analista. 1

$2.000.000

Leer la documentación sobre gestión documental en la entidad (manual de calidad, tablas de retención documental, etc.).

Analizar la documentación anterior.

Verificar si lo analizado está de acuerdo a la ley y documentación de la empresa.

Plasmar el proceso general y generar el documento sobre el proceso general de gestión documental si no se cuenta con uno.

20

Diseño

Elaborar los diagramas de flujo del proceso para garantizar el entendimiento de los que intervienen en el proyecto, así como la elaboración certera del modelo de base de datos, de acuerdo a la información recolectada en el anterior objetivo.

Persona Rol Analista y Administrador Base de datos

1

$3.000.000

Partiendo del diagrama de flujo de datos se da inicio a la elaboración del modelo de la base de datos.

Análisis del modelo. Codificación

Persona Rol Diseñador

1

$1.000.000

Generar la base de datos.

Creación de pantallazos.

Creación de la interface a partir del modelo de la base de datos.

Creación de la interface a partir de la base de datos.

Persona rol programador JAVA - JSF (XHTML)- Netbeans 1

$5.000.000

Adecuación de la interface a la entidad.

o Desarrollo y adecuación de la interface a partir de código.

Revisión y Pruebas

Pruebas del modelo.

Persona Rol Analista

1

$2.000.000

Realizar pruebas de base de datos.

Llevar a cabo pruebas de Interface.

Validar el proceso VS lo construido y la ley. Documentación

Recopilar información de lo que se generó en la iteración.

Persona Rol Analista

1

$2.000.000

Plasmar en documento digital y de manera gráfica los cambios o nuevos procesos.

Documentar el código.

Alimentar manual del usuario y manual del programador.

TOTAL $31.150.000

Fuente: Elaboración propia

21

1.6. APORTE TEÓRICO Y PRÁCTICO

El desarrollo del proyecto permitirá realizar el análisis, diseño e implementación de un sistema estándar de gestión documental en entorno web, permitiendo la comprensión de los procesos de gestión documental y ciclo de vida de los documentos teniendo en cuenta la política de CERO PAPEL [2], al igual que la utilización de una metodología de desarrollo de software AGILE (AUP), que son métodos de ingeniería del software basados en el desarrollo iterativo e incremental, cuyo ciclo de vida incluye: planificación, análisis de requisitos, diseño, codificación, revisión y documentación.

2. MARCOS DE REFERENCIA

2.1. MARCO TEÓRICO

2.1.1 Antecedentes

El proyecto de desarrollo de un sistema de gestión documental nace de la necesidad de mejorar los procesos de gestión documental en las entidades que lo requieren, según lo establece la ley 594 de 2000 - Ley General de Archivos, que reguló en su Título V: “Gestión de documentos, la obligación que tienen las entidades públicas y privadas que cumplen funciones públicas, de elaborar programas de gestión de documentos, independientemente del soporte en que produzcan la información para el cumplimiento de su cometido estatal, o del objeto social para el que fueron creadas” [1]; de la misma manera optimizar y racionalizar los recursos y el uso del papel según lo estableces la directiva presidencial 04 de 2012 [2]. En su regulación la Ley 594 previó que el desarrollo tecnológico en las entidades es desigual y por lo tanto deja claro que los principios y procesos archivísticos deben aplicarse cualquiera sea la tecnología y el soporte en que se produce la información. Con este instrumento el Archivo General de la Nación pretende entonces orientar a las entidades y facilitarles la adopción y adaptación de los procesos de gestión documental, preferiblemente mediante el uso de las nuevas tecnologías.

22

El Artículo 19 de la ley Menciona: “Las entidades del Estado podrán incorporar tecnologías de avanzada en la administración y conservación de sus archivos, empleando cualquier medio técnico, electrónico, informático, óptico o telemático, siempre y cuando cumplan con los siguientes requisitos: a) Organización archivística de los documentos.

b) Realización de estudios técnicos para la adecuada decisión, teniendo en cuenta aspectos como la conservación física, las condiciones ambientales y operacionales, la seguridad, perdurabilidad y reproducción de la información contenida en estos soportes así como el funcionamiento razonable del sistema” [1].

A continuación se presentan algunos casos de Implementación de Sistemas que manejan procesos de Gestión Documental:

Zady Gestores logra digitalizar el proceso de gestión de expedientes de trámites

de tráfico para ofrecer a sus casi 300 clientes un servicio telemático ágil [3].

BVA - Caso de Éxito en Gestión Documental: La unidad inmobiliaria de BBVA (ANIDA) consigue centralizar más de 125.600 expedientes inmobiliarios en un único repositorio y recuperarlos con rapidez desde las aplicaciones de Tasación, Promociones y Gestión. El resultado fue una solución de gestión documental que permitió agilizar los trámites y asegurar un retorno de la inversión (ROI) inmediato [4].

DGT- Detalles del Proyecto de Gestión Documental: Dirección General de

Tráfico elige Athento para su Gestión documental, en un proyecto que conseguirá un ahorro para la DGT de más de un millón de euros al año y la implantación de las Normas Técnicas de Interoperabilidad [3].

Notaría 25 de Medellín: La Notaría 25 de Medellín en su plan estratégico de modernización requería una solución de digitalización del archivo escriturario, centrados en los textos de los instrumentos públicos sin incluir los anexos propios del acto al que accede a la escritura pública, permitiendo con uso restringido por el Notario la impresión del protocolo sin manipular el libro físico, como también la consulta en línea de forma segura integrando la solución de gestión documental con la página web corporativa www.notaria25medellin.com y presentando

23

restricciones como marcas de seguridad, sombreado de firmas y acceso con clave personal [5].

La empresa SUMMAN planteó una solución que permitiera a los usuarios conectarse a la Notaría 25 de Medellín en www.notaria25medellin.com y consultar las escrituras para verificación de texto y/o lectura, de forma segura, evitando así el desplazamiento físico de los usuarios a las instalaciones de la Notaría [5].

Programas de Gestión Documental ATHENTO Automatiza la clasificación de documentos, mejorar el OCR (Optical Character Recognition, reconocimiento Óptico de Caracteres) mediante ICR (Intelligent Character Recognition), contabilización Automática de Facturas (extracción automática de información relevante de cualquier documento), extracción de Metadatos clave en Contratos y cualquier otro tipo de documento, División de lotes de documentos escaneados [3].

SIMAD 4.0 Sistema Integrado de Administración Documental.

Herramienta que automatiza los procesos de la gestión documental proporcionando un completo dominio y uso del poder de su información, atendiendo cada aspecto del ciclo de vida de la administración de sus documentos, es una aplicación en Ambiente web de fácil operación y acceso rápido en cualquier momento y desde cualquier lugar [6].

Software D.I Software y documentación integrados.

EL software da acceso a los instrumentos de descripción, desde inventarios generales hasta catálogos e índices, por lo que permite control de los proyectos archivísticos de cualquier empresa o institución. Permite el diseño, instalación, configuración y puesta en marcha de herramientas automatizadas para informatización bibliográfica, soportadas en Marc21 (Machine Readable Cataloging o Catalogación legible por máquina) y AACR2 (Reglas de Catalogación Angloamericanas, Anglo-American Cataloguing Rules, Second Edition,). [7]

24

2.1.2. Antecedentes Teóricos 2.1.2.1. Ciclo de vida de software Modelo clásico El modelo de la cascada o clásico, indica un enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado [17].

FIGURA 1. Modelo de la cascada

Fuente: Ingeniería del Software un Enfoque Practico [17]

2.1.2.2. Ciclo de vida en Espiral Es un modelo evolutivo del proceso del software y se acopla con la naturaleza iterativa de hacer prototipos con los aspectos controlados y sistémicos del modelo de cascada. Tiene el potencial para hacer un desarrollo rápido de versiones cada vez más completas. Tiene dos características distintivas principales:

El enfoque cíclico para el crecimiento incremental del grado de definición de un sistema y su implementación, mientras que disminuye su grado de riesgo.

La otra es un conjunto de puntos de referencia de anclaje puntual para asegurar el compromiso del participante con soluciones factibles y mutuamente satisfactorias [17].

25

FIGURA 2. Modelo en espiral

Fuente: Ingeniería del Software un Enfoque Practico [17]

2.1.2.3. Ciclo de vida en V Es una variante del modelo en cascada donde se aprecia la relación entre las acciones para el aseguramiento de la calidad y aquellas asociadas con la comunicación, modelado y construcción temprana. A medida que el equipo de software avanza hacia abajo desde el lado izquierdo de la V, los requerimientos básicos del problema mejoran hacia representaciones técnicas cada vez más detalladas del problema y de su solución. Una vez que se ha generado el código, el equipo sube por el lado derecho de la V, y en esencia ejecuta una serie de pruebas (acciones para asegurar la calidad) que validan cada uno de los modelos creados cuando el equipo fue hacia abajo por el lado izquierdo [17].

26

FIGURA 3. Modelo en V

Fuente: Ingeniería del Software un Enfoque Practico [17]

2.1.2.4. Metodologías Agiles

Breve Historia de la aceptación de las Metodologías Agiles

Para entender esta metodología es necesario conocer un poco de historia [8]: Los días 11-13 de febrero de 2001, en el Lodge en la estación de esquí de Snowbird en las montañas de Wasatch de Utah, surgió el Manifiesto de Desarrollo Ágil de Software.

Ejemplo explícito en el manifiesto:

“Por ejemplo, creo que al final, la programación extrema se ha multiplicado en uso, no por la programación o refactorización, sino porque, en conjunto, las prácticas

27

de una comunidad de desarrolladores libera trabajo de las corporaciones. Kent Beck cuenta la historia de un trabajo en la que se estima un esfuerzo de programación de seis semanas para dos personas. Después reasignó otro programador en el inicio del proyecto y lo completó en doce semanas, lo que lo hizo sentir muy mal por sí mismo. Kent, desanimado porque era un "fracaso", como un programador, se dio cuenta de que su estimación original de 6 semanas fue extremadamente real, de hecho, el fracaso de la norma "fija", la mentalidad del proceso que afecta con tanta frecuencia nuestra industria”.

“El movimiento Ágil no es anti-metodología, de hecho, queremos restaurar la credibilidad de la metodología de la palabra, restaurar un equilibrio, pero no con el fin de presentar algún diagrama en un repositorio corporativo polvoriento. Pero no cientos de raramente-tomos. Tenemos la intención, pero reconocemos los límites de la planificación en un entorno turbulento”.

“Esperamos que nuestro trabajo juntos como la Agile Alliance ayude a los demás en nuestra profesión a pensar en el desarrollo de software, metodologías y organizaciones, de nuevas formas más ágiles. Si es así, hemos logrado nuestras metas” [8].

En las metodologías agiles se siguen los siguientes principios [9]:

Se prioriza satisfacer al cliente mediante la entrega temprana y continua de software con valor.

Se Acepta que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

Se entrega software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

Trabajo conjunto de gerente y desarrolladores de forma cotidiana durante todo el proyecto.

Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

El software funcionando es la medida principal de progreso.

28

Los procesos Ágiles promueven el desarrollo sostenible. El equipo global debe ser capaz de mantener un ritmo constante de forma indefinida.

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para, a continuación, ajustar y perfeccionar su comportamiento en consecuencia.

Algunos autores del Manifiesto Ágil [8]:

Arie van Bennekum ha participado activamente en DSDM y el Consorcio DSDM desde 1997. Ward Cunningham es uno de los fundadores de Cunningham y Cunningham, Inc. Jim Highsmith es el desarrollador principal de la "Adaptive Software Development" Agile Métod y autor de un libro del mismo nombre. Ron Jeffries es el propietario de XProgramming.com, consultor de Object Mentor, y el autor (con Ann Anderson y Chet Hendrickson) de Extreme Programming. Ken Schwaber es presidente de Métodos Avanzados de Desarrollo (ADM).

¿Qué es el desarrollo Ágil de Software?

El desarrollo ágil de software consiste en utilizar métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan mediante la colaboración de grupos auto organizado y

29

multidisciplinario. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en lapsos cortos [10]. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requisitos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, sino que la meta es tener una «demo» (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto [10]. Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés). La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica [10].

Metodologías Agiles

Lean software development La metodología de desarrollo de software Lean, es una traducción de los principios

y las prácticas de la forma de producir LEAN, hacia el área del desarrollo de software. Inicialmente, originado en el Sistema de Producción de Toyota y ahora, apoyado por una corriente que está surgiendo desde la comunidad Ágil. Este método ofrece todo un marco teórico sólido y basado en la experiencia, para las prácticas ágiles de gestión [11]. Programación extrema La programación extrema o eXtreme Programming (de ahora en adelante, XP) es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia

30

de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad [11]. Método de desarrollo de sistemas dinámicos El método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development Method o DSDM) es un método que provee un framework para el desarrollo ágil de software, apoyado por su continua implicación del usuario en un desarrollo iterativo y creciente que sea sensible a los requisitos cambiantes, para desarrollar un sistema que reuna las necesidades de la empresa en tiempo y presupuesto. Es uno de un número de métodos de desarrollo ágil de software y forma parte de la alianza ágil [11]. Metodología AUP (Proceso Unificado Ágil) [12] [13]: Es una versión simplificada de Rational Unified Process (RUP). Describe un enfoque simple y fácil de entender el desarrollo de software usando técnicas y conceptos que aún se mantienen vigentes en RUP. Las disciplinas han cambiado respecto a Rational Uniefied Process (RUP):

La disciplina de Modelado abarca las disciplinas de Modelado del Negocio, de Requisitos y de Análisis y Diseño de RUP. El modelado es una parte importante en AUP, como se puede ver, pero no domina el proceso. Puede seguir ágil creando modelos y documentos los cuales son lo suficientemente buenos.

Las disciplinas de la Administración de la Configuración y Cambios ahora es la disciplina de la Administración de la Configuración. En el desarrollo ágil sus actividades de administración de cambios son típicamente parte del esfuerzo de la administración de requisitos, la cual es parte de la disciplina de Modelado.

31

FIGURA 4. El ciclo de vida de AUP.

Fuente: Scott W. Ambler 2005 La naturaleza serial en AUP es capturada en cuatro fases que se realizan de manera serial o lineal en el tiempo:

Iniciación. El objetivo es identificar el alcance inicial del proyecto, una arquitectura potencial de su sistema, y obtener la financiación inicial del proyecto y la aceptación del involucrado.

Elaboración. El objetivo es mejorar la arquitectura del sistema.

Construcción. El objetivo es construir software funcional en una base regular e incremental, la cual cumpla con las necesidades de prioridad más alta de los involucrados de su proyecto.

Transición. El objetivo es validar y desplegar su sistema en su ambiente de producción.

Las disciplinas son ejecutadas en una manera iterativa, definiendo las actividades las cuales los miembros del equipo ejecutan para construir, validar y liberar software funcional que cumpla con las necesidades de sus involucrados. Las disciplinas son:

32

Modelado. El objetivo de esta disciplina es entender el negocio de la organización, el problema de dominio que se aborda en el proyecto, e identificar las soluciones viables para manejar el dominio del problema.

Implementación. El objetivo de esta disciplina es transformar su modelo (s) en código ejecutable y llevar a cabo un nivel básico de las pruebas, en particular, la unidad de prueba.

Pruebas. El objetivo de esta disciplina es ejecutar una objetiva evaluación para asegurar la calidad. Esto incluye la detección de defectos, validaciones de que el sistema funciona como fue diseñado, y verificar que se cumplan los requisitos.

Despliegue. El objetivo de ésta disciplina es planificar la entrega del proyecto de desarrollo y ejecutar el plan, para dejar disponible el sistema al usuario final.

Administración de la Configuración. La meta de esta disciplina es manejar el acceso a sus productos de trabajo de proyecto. Esta no sólo incluye el rastreo de versiones del trabajo del producto en el tiempo, sino que también el control y administración de los cambio estos productos.

Administración del Proyecto. El objetivo de esta disciplina es dirigir las actividades a lo largo del proyecto. Esto incluye la administración del riesgo, dirección del personal (asignación de tareas, rastreo del progreso, etc.), y coordinación con personas y sistemas fuera del alcance del proyecto para asegurar su liberación a tiempo y dentro del presupuesto.

Entorno. El objetivo de esta disciplina es soportar el resto del esfuerzo asegurando que el proceso apropiado, las guías (normas y directrices), y herramientas (hardware y software) estén disponibles para cuando el equipo las necesite.

El AUP se basa en los siguientes principios [13]:

Su personal sabe lo que él está haciendo: La gente no va a leer la documentación de proceso detallada, sino que ella querrá una cierta dirección de alto nivel y/o el entrenamiento de vez en cuando.

Simplicidad: se describe usando poca cantidad de páginas, no millares de páginas.

Agilidad: Se ajusta a los valores y a los principios de la Agile Alliance.

Poner importancia en actividades de alto valor: actividades que importan

33

realmente, no cada cosa posible que podría sucederle en un proyecto.

Independencia de la herramienta: se puede utilizar cualquier juego de herramientas, se recomienda herramientas simples.

Roles del equipo:

Las roles pueden llevarse a cabo por varias personas, una persona puede adquirir roles múltiples, un rol no es una posición.

Entregables:

AUP clasifica los entregables en tres tipos (Ver detalle en ANEXO B):

Productos a entregar mínimos: es la documentación mínima requerida para realizar el proyecto.

Otros productos del trabajo de proyecto: es la documentación no esencial según AUP.

Productos del trabajo de la empresa: son los entregables que la empresa debe realizar para el proyecto.

Para llevar a cabo este proyecto se utilizará la metodología de desarrollo de software AGILE denominada AGILE UNIFIED PROCCESS (AUP). Está estandarizada y es la evolución del RUP.

2.1.2.5. Arquitectura ANSI/SPARC [28]: Es la arquitectura estándar descrita por el comité ANSI/X3/SPARC, basada en 3 niveles o esquemas: nivel físico o de máquina, nivel externo o de usuario y nivel conceptual.

El modelo externo: es la vista que tienen los usuarios finales del ambiente de datos.

Modelo Conceptual: representa una vista general de la base de datos, como la ve la organización.

34

Modelo Fisico: Describe la forma en que se almacenan los datos. 2.1.2.6. Arquitectura MVC (Modelo-Vista-controlador): Es un patrón que define la organización independiente del modelo (objetos de negocio), la vista (Interfaz con el usuario u otro sistema) y el controlador

(controlador del Workflow de la aplicación) [31]. De esta forma se divide el sistema en 3 capas: una donde se encapsulan los datos, otra la interfaz o vista y por último la lógica interna o controlador. Esto hace que MVC se utilice para proyectos donde se requieren muchas vistas y se requiere de un alto procesamiento, es decir para proyectos robustos, aunque

también aplica para proyectos de poca envergadura [31][32]. 2.2. MARCO CONTEXTUAL.

Actualmente la república de Colombia, tiene reglamentado en sus leyes el manejo general de los archivos, mediante de la ley 594 de 2000, donde se derivan los procesos archivísticos y de gestión documental [1]. Un sistema de gestión documental permite entre otras operaciones, hacer llegar la información a quién la necesita, ya sea dirigiendo documentos a través de un flujo de trabajo, enviando o extrayendo información de sistemas externos, elimina pérdidas de tiempo en búsquedas, puede realizar búsqueda de documentos a través de búsquedas semánticas. A continuación se presentan algunas características de un Sistema de Gestión Documental

Automatización de tiempos de valoración.

Generación de reportes y estadísticas.

Consultas según criterios de información.

Ingreso ágil y eficiente para la actualización de datos.

Ambiente de usuario sencillo y flexible.

35

Regido por los lineamientos del Archivo General de la Nación.

Permite aumentar drásticamente la productividad.

El tiempo de consulta de un documento en papel (se estima que en organizaciones basadas en papel, se pueden llegar a perder más de 500 horas por empleado y año en busca de documentos).

Disminución del tiempo de consulta de documentos electrónicos.

Bajos costes de archivado: en el caso de documentos electrónicos sólo hace falta categorizarlos para que éstos se archiven de forma transparente para el usuario.

En el caso de documentos que tienen su versión original en papel, y que deben archivarse en un archivo físico por cuestiones legales, en el momento en que son digitalizados se produce una reducción costes en varios sentidos:

o No se precisa su manipulación física (ya que están escaneados), con

lo que el archivado y acceso al documento es mucho más rápido.

o No se deterioran ni pierden documentos, al no manipularse manualmente.

o El espacio de archivo físico puede reducirse hasta un 35% al poderse

utilizar criterios de ordenación secuencial.

Fácil recuperación de un documento: el documento está catalogado y organizado, con lo que su recuperación (tiempo que transcurre desde la búsqueda hasta que lo tenemos en pantalla) es óptima. Igualmente, se reducen drásticamente los riesgos de pérdida del documento físico original.

Acceso concurrente a un documento: disponer de los documentos dentro de un sistema de Gestión Documental nos permite que varios empleados puedan acceder simultáneamente a un mismo documento, lo cual es imposible con el documento físico (en este caso hay que esperar a que el usuario A termine de utilizar un documento para que B pueda hacerlo también).

Mejora de atención a los clientes, tanto internos (otros empleados o departamentos) como externos (clientes finales), ya al disponer de la información de forma centralizada y rápidamente accesible es posible solucionar online cuestiones relacionadas con una consulta de un cliente.

36

Disminución de costes legales: la pérdida o deterioro de documentación sensible o de alto valor contractual puede derivar en elevados costes legales por incurrir en demandas y otros procesos legales.

Reducción de costes de acceso a la documentación (ej.: sistemas de identificación por tarjeta), al contar con un sistema fácil y claro de permisos.

Posibilidad de integrarse con subsistemas de gestión documental específicos: software de captura de facturas, formularios, entre otros.

Incremento en la satisfacción de los usuarios internos (miembros de la organización) por agilizar sus procesos de trabajo.

2.3. MARCO CONCEPTUAL

Para entender lo que se pretende realizar en este proyecto es necesario conocer los siguientes términos, pues ayudaran a comprender lo que es la gestión documental y todo lo que conlleva y los cuales encontramos en la ley 594 de 2000 [1]: Archivo: Conjunto de documentos, sea cual fuere su fecha, forma y soporte material, acumulados en un proceso natural por una persona o entidad pública o privada, en el transcurso de su gestión, conservados respetando aquel orden para servir como testimonio e información a la persona o institución que los produce y a los ciudadanos, o como fuentes de la historia.

Archivo público: Conjunto de documentos pertenecientes a entidades oficiales y aquellos que se derivan de la prestación de un servicio público por entidades privadas. Archivo privado de interés público: Aquel que por su valor para la historia, la investigación, la ciencia o la cultura es de interés público y declarado como tal por el legislador.

Acceso a los archivos: Derecho de los ciudadanos a consultar la información que conservan los archivos públicos, en los términos consagrados por la Ley. Automatización: Aplicación de los medios tecnológicos a los procesos de almacenamiento y recuperación de la información documental y de los documentos electrónicos de archivo.

37

Accesibilidad: La característica de ser de fácil acceso o utilizar con un mínimo de barreras. Capacidad para localizar la información relevante a través del uso de catálogos, índices, instrumentos de búsqueda, u otras herramientas. Ciclo vital del documento: Etapas sucesivas por las que atraviesan los documentos desde su producción o recepción en los archivos de gestión y archivos administrativos y su conservación temporal, hasta su eliminación o integración a un archivo permanente. Documento: Toda aquella Información creada o recibida, conservada como prueba, por una organización o un individuo en el desarrollo de sus actividades o en virtud de sus obligaciones legales. Cualquiera sea su forma o el medio utilizado. Según la Unesco, el patrimonio documental consta de dos componentes: el contenido informativo y el soporte en el que se consigna. A partir de lo anterior, plantea que dicho patrimonio está conformado por:

Piezas textuales: manuscritos, libros, periódicos, carteles, etc. El contenido textual puede haber sido inscrito con tinta, lápiz, pintura u otro medio. El soporte puede ser de papel, plástico, papiro, pergamino, hojas de palmera, corteza, tela, piedra, etc.

Piezas no textuales: dibujos, grabados, mapas o partituras.

Piezas audiovisuales: películas, discos, cintas y fotografías, grabadas en forma analógica o numérica, con medios mecánicos, electrónicos, u otros, de las que forma parte un soporte material con un dispositivo para almacenar información donde se consigna el contenido.

Documentos virtuales: los sitios de Internet almacenados en servidores. El soporte puede ser un disco duro o una cinta y los datos electrónicos forman el contenido. Una pieza del patrimonio documental puede ser un solo documento de cualquier tipo, o bien un grupo de documentos, como una colección, un fondo o conjunto de archivos. Documento de archivo: Registro de información producida o recibida por una persona o entidad en razón a sus actividades o funciones, que tiene valor administrativo, fiscal o legal, o valor científico, económico, histórico o cultural y debe ser objeto de conservación.

38

Documento electrónico de archivo: Registro de información producida o recibida por una entidad pública o privada que preste servicios públicos en razón de sus actividades o funciones haciendo uso de medios electrónicos Documento original: Es la fuente primaria de información con todos los rasgos y características que permiten garantizar su autenticidad integridad. Función archivística: Actividades relacionadas con la totalidad del que hacer archivístico, que comprende desde la elaboración del documento hasta su eliminación o conservación permanente. Gestión Documental: es 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 (Creación o recepción) hasta su destino final (Archivo, destrucción, etc.) con el objeto de facilitar su utilización y conservación. Sistemas electrónicos de gestión documental: son el conjunto de programas, utilizados para recuperar y almacenar documentos electrónicos y/o imágenes digitales de documentos originalmente soportados en papel. Sistema de gestión documental: Es un Sistema de información que incorpora, gestiona y facilita el acceso a los documentos a lo largo del tiempo. Entre ellos encontramos diferentes tipos:

Programas de gestión de bases de datos que disponen de una tecnología idónea para el tratamiento de documentos científicos, culturales y técnicos.

Programas que permiten la recuperación de información sin ir a los físicos, permiten determinar el tiempo que los documentos deben guardarse, eliminar los que ya no sirven y asegurar la conservación indefinida de los documentos más valiosos, aplicando principios de racionalización y economía.

Tabla De Retención Documental: Listado de series con sus correspondientes tipos documentales, a las cuales se asigna el tiempo de permanencia en cada etapa del ciclo vital de los documentos.

39

Desarrollo de software: Desarrollar software significa construirlo simplemente mediante su descripción, es decir, desde cero, siguiendo unos parámetros resultantes del análisis de los requisitos y con miras en resolver una situación problemática. Bases de datos: Una base de datos o banco de datos es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso, en este proyecto se requiere generar una base de datos que almacene toda la información del SGD.

Aplicaciones web: Son aquellas herramientas que los usuarios pueden utilizar accediendo a un servidor a través de Internet.

3. MODELO TEÓRICO Este capítulo contiene la teoría del modelo técnico a seguir, con el fin de establecer el funcionamiento del sistema de información: En primera instancia se describe la metodología para el desarrollo integral del proceso y luego el paso a paso de la metodología de desarrollo de software que se utiliza.

Tabla 2. Metodología General del proyecto.

Fase 1 Definición de la situación problemática.

Búsqueda de posible solución.

Presentación de documento propuesta para aprobación.

Fase2 Establecimiento de Objetivos, alcance e inicio de proceso de investigación. Se presentan avances.

Fase 3 Documentación de los marcos de referencia y solicitud de aprobación de anteproyecto.

Fase 4 Inicio aplicación de metodología AUP, Generación del documento de requisitos y diseño de modelo de la base de datos.

Fase 5 Desarrollo del sistema de información y concreción del modelo dentro de lo establecido por la metodología AUP y la arquitectura MVC y ANSI/SPARC.

Fase 6 Pruebas, generación de manual de usuario, finalización y entrega de documento informe final.

Fuente: Elaboración propia

40

3.1. Metodología para el desarrollo del software (AUP):

La metodología AUP contiene las 4 fases del RUP (Inicio, Elaboración, Construcción y Transición), las cuales se desarrollan de manera lineal, mientras que las actividades se realizan de manera cíclica o en iteraciones. A continuación se explica la arquitectura de AUP:

3.1.1. Fases

3.1.1.1. Inicio

Objetivo: Identificar el alcance inicial del proyecto, proveer una arquitectura potencial para el sistema y definir costos, cronograma factibilidad, entre otros.

Tareas: Definir alcance del proyecto Estimar costos y plazos Definir riesgos Determinar factibilidad del proyecto Preparar el ambiente

Resultado: Modelo de Requisitos y Modelo de Diseño basado en el estándar IEEE STD 830-1998.

Modelo de Requisitos y Modelo de Diseño basado en el estándar IEEE STD 830-1998

a. Propósito

Este documento tiene como propósito orientar al lector sobre los requisitos necesarios para realizar el proyecto, teniendo en cuenta la metodología a

41

utilizar y el tipo de software que se desarrollará, pues aunque es particular en su funcionamiento, puede ser punto de partida para otros desarrollos.

o Alcance

El sistema de Información Se denominará SIMAGED (Sistema para el Manejo de la Gestión Documental). El alcance de este documento es para un software de gestión documental basado en la ley 594 del 2000, desarrollado en un entorno Web, con manejo de tablas de retención documental y digitalización.

o Personal involucrado

Nombre Juan Carlos Blandón Andrade

Rol Director de Proyecto

Categoría profesional

Ingeniero de sistemas

Responsabilidades Dirigir el proyecto, tomar decisiones

Información de contacto

Aprobación

Nombre Geovanny Gómez Orozco

Rol Analista y Programador

Categoría profesional

Estudiante Ing. Sistemas y Telecomunicaciones

Responsabilidades Análisis y Desarrollo

Información de contacto

3173473333

Aprobación

42

Nombre Carlos León Arenas Rivera

Rol Desarrollador

Categoría profesional

Estudiante Ing. Sistemas y Telecomunicaciones

Responsabilidades Estudio y Realización

Información de contacto

3166921130

Aprobación

o Definiciones, acrónimos y abreviaturas

Aplicación web: Son aquellas herramientas que los usuarios pueden utilizar

accediendo a un servidor a través de Internet o de una LAN, mediante

un navegador. En otras palabras, es una aplicación que se codifica en un

lenguaje soportado por los navegadores web en la que se confía la ejecución

al navegador, o sea en el cliente.

AUP: Agile Unified Process - Proceso Unificado Ágil, El Proceso Unificado Agil de Scott Ambler o Agile Unified Process (AUP) en inglés es una versión simplificada del Proceso Unificado de Rational (RUP). Este describe de una manera simple y fácil de entender la forma de desarrollar aplicaciones de software de negocio usando técnicas ágiles y conceptos que aún se mantienen válidos en RUP.

Base de datos: Una base de datos o banco de datos es un conjunto de datos

pertenecientes a un mismo contexto y almacenados sistemáticamente para

su posterior uso, en este proyecto se requiere generar una base de datos

que almacene toda la información del SGD.

MySql: es un sistema de gestión de bases de datos relacional, multi

hilo y multiusuario.

SIMAGED: Sistemas para el Manejo de la Gestión Documental. RUP: Rational Unified Process, es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la

43

metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos. UML: Unified Modeling Language - Lenguaje Unificado de Modelado, es el

lenguaje de modelado de sistemas de software más conocido y utilizado en

la actualidad.

o Referencias

Referencia Titulo Fecha Autor

[5] REQUIREMENTS ENGINEERING FOR WEB APPLICATIONS – A COMPARATIVE STUDY

University of Munich (LMU)

andand F.A.S.T. GmbH, Germany

January 9, 2004

M. JOSÉ ESCALONA, NORA KOCH

o Resumen

El software de gestión documental SIMAGED (Sistema para el Manejo de la Gestión Documental), es una herramienta, que recopila todas las necesidades que requiera cualquier empresa para gestionar los documentos.

b. Descripción general

o Perspectiva del producto

Este trabajo presenta el estado y un estudio de los requisitos del Software SIMAGED (Sistema para el Manejo de la Gestión Documental), programa diseñado en ambiente web, y compatible con cualquier sistema operativo, por lo cual se hace portable, un programa que contiene el proceso estándar

44

para realizar la gestión documental de cualquier empresa, bien sea del sector público o privado, se presenta una visión general de la metodología AUP utilizada para desarrollar software en tiempo cortos.

c. Funcionalidad del producto

Permite llevar a cabo de manera fácil, confiable y segura las etapas de la gestión de los documentos en una organización, con el fin de garantizar la disponibilidad, el control y la gestión de los documentos. Etapas de la gestión de los documentos en el sistema: Creación: Los documentos se deben crear mediante procedimientos planificados y documentados en los cuales de determine su identificación. Mantenimiento: Se refiere al establecimiento de los requisitos que permiten mantener la integridad técnica, estructural y relacional de los documentos en el sistema de gestión documental así como sus metadatos. Difusión: Abarca el establecimiento de los requisitos para el acceso, consulta recuperación, clasificación de acceso y visualización de los documentos. Administración: Hace referencia a los procedimientos que permitan administrar todas las operaciones relativas a los documentos, tanto funcionalmente como dentro del sistema de información.

d. Características de los usuarios

Tipo de usuario Administrador.

Formación Desarrollador o analista de sistemas.

Habilidades Manejo de lenguaje JAVA y MYSQL.

Actividades Desarrollo y administración del software y a base de datos.

45

Tipo de usuario Supervisor.

Formación Tecnológica o profesional.

Habilidades Capacidad de análisis y toma de decisiones de Software.

Actividades Revisor y solucionador de problemas técnicos y de funcionamiento del aplicativo que no impliquen programación o modificación de códigos.

Tipo de usuario Usuario externo.

Formación Básica en ofimática e internet.

Habilidades Digitadores y conocimientos básicos de Hardware y Software.

Actividades Almacenamiento y consulta de datos.

e. Restricciones

El software se desarrolló en base a la metodología AUP, que maneja la documentación mínima necesaria para el entendimiento del proyecto, por lo cual no se realiza muchísima documentación como en otros proyectos. El lenguaje de programación utilizado es JAVA, Motor MYSQL, el Software trabaja en ambiente web lo que lo hace multiplataforma, o sea que es compatible con todos los sistemas operativos actuales MS Windows, Mac OS X, GNU/Linux. No se han realizado pruebas en sistemas operativos FreeBSD y OpenBSD, sin embargo hay incopatibilidad con algunas versiones de internet explorer, las cuales no soportan XHTML. En cuanto a las restricciones de máquina los requisitos mínimos serían: Para los clientes: CPU Minimum: Pentium IV o superior y sus equivalentes, Procesador: 1.4 GHz, Memoria RAM: DDR1 1 GB, Disco Duro: 10 GB disponible. Para el servidor: Procesador: 4 nucleos, CPU Speed Minimum: 1.5 GHz, Memoria RAM: DDR3 8 GB, Disco Duro: 10 GB disponible.

46

f. Evolución previsible del sistema

Personalización.

Integración de dispositivos de digitalización para automatización.

Posibilidad de consultas simples en Smartphone (App)

g. Requisitos específicos

o Captura de requisitos

“La captura de requisitos es la actividad mediante la que el equipo de desarrollo de un sistema de software extrae, de cualquier fuente de información disponible, las necesidades que debe cubrir dicho sistema”

El levantamiento de requisitos se realizó a través de investigación y cursos de formación sobre gestión documental, así como entrevistas a funcionarios que manejan gestión documental dentro del Instituto Nacional de Medicina Legal y Ciencias Forenses. [5]

o Definición de requisitos

Requisitos de datos: Los datos almacenados por el sistema, son todos

aquellos documentos que se reciben o genera la empresa en manera física

una vez sean digitalizados, para su posterior almacenamiento.

Requisitos de interfaz: El software trabajará en ambiente web, por medio de

formularios y ventanas, en las cuales los usuarios, deberán autenticarse

para poder acceder al sistema, podrán consultar información, así como

modificar rutas o destino de los documentos, los usuarios podrán modificar

información solo de almacenamiento de documentos.

Requisitos de navegación: Se determinará la cantidad de usuarios y sus

roles, dependiendo de sus privilegios, también se restringirá el acceso a

todos los usuarios a los aplicativos y/o formularios de los cuales no tengan

pertinencia alguna, para garantizar seguridad y efectividad de la aplicación.

47

Requisitos transaccionales o funcionales internos: El aplicativo archivará

documentos digitalizados, los distribuirá a las áreas que les sean asignadas,

los rastreará y tendrá disponibilidad de ellos, podrá almacenarlos por un

período de tiempo o indefinidamente, así como podrá destruirlos o

eliminarlos.

Requisitos no funcionales: El aplicativo podrá ser ejecutado en cualquier

equipo de cómputo con características mínimas, también en equipos

portátiles, se desarrollará en ambiente web, después de su instalación

estará disponible las 24 horas del día los 365 días del año, y podrá ser

utilizado por cualquier usuario que tenga los permisos dispuestos para un fin

determinado en el aplicativo.

También Mejorará el proceso la para gestión documental, tanto en

consultas, como en la alimentación de los archivos, y todos los procesos

que esto conlleve, además de permitir una trazabilidad real sobre los

documentos, para poder ubicarlos en cualquier escenario de tiempo

determinado, así como preservar la memoria histórica de las entidades con

sus procesos tradicionales, pero implementando herramientas que permiten

la modernización.

El uso de nuevas tecnologías y software de punta. Garantizará lo siguiente:

Acumulación innecesaria de información, reduciendo costos en la producción y conservación documental.

Funcionalidad, disposición y seguridad del patrimonio documental.

Tener a disposición servicios de apoyo.

El flujo físico innecesario de documentos.

Simplificar trámites que conducen al manejo integral de la información para la toma de decisiones.

Reducir el tiempo de búsqueda, distribución, impresión, archivo y destrucción de documentos en papel.

48

Modelar la interfaz de usuario. Para ello, propone el uso de sketches

(especie de bocetos esbozos o borradores) y prototipos que permitan

presentar los datos al usuario.

Entregar un repositorio de conocimiento centralizado.

Suministrar un respaldo automatizado de los documentos a la empresa.

Contribuir con la seguridad.[5]

o Requisitos comunes de las interfaces

El software trabajará en ambiente web, por medio de formularios y ventanas,

en las cuales, los usuarios deberán autenticarse para poder acceder al

sistema, solo tendrán un rol de almacenadores de información, también

podrán consultar, así como modificar rutas o destino de los documentos,

ningún usuario tendrá acceso a la base de datos del aplicativo.

Interfaces de usuario

Entrada: Teclado, Mouse, Scanner. Salida: Monitor. Software: Navegador Web.

Interfaces de hardware

Entrada: Teclado, Mouse, Scanner. Salida: Monitor.

49

Interfaces de software

Tipo de BD: Relacional con enfoque a Objetos.

Arquitectura: MVC

Motor Base de datos: MYSQL.

Mecanismo de almacenamiento de datos: InnoDB.

Entorno de Desarrollo: Netbeans 7.2

Componentes adicionales: PRIME FACES (componente para Java Server Faces (JSF) de código abierto que cuenta con un conjunto de componentes enriquecidos que facilitan la creación de las aplicaciones web).

Lenguaje programación: JAVA.

Tecnología y framework JAVA para WEB: JAVA SERVER FACES (JSF) es una tecnología y framework para aplicaciones Java basadas en web que simplifica el desarrollo de interfaces de usuario en aplicaciones Java EE.

Patrón de Diseño:MVC (Modelo Vista Controlador) Compatibilidad: Multiplataforma.

Interfaces de comunicación

Conexión directa.

Controlador JDBC que accede directamente al controlador del

fabricante, ya que éstas no necesitan un puente para comunicarse,

el trabajo y la conexión son mucho más rápidos que la conexión

indirecta.

50

o Requisitos funcionales

Permitir llevar a cabo de manera fácil, confiable y segura las etapas de la

gestión de los documentos en una organización, con el fin de garantizar la

disponibilidad, control y gestión de los mismos.

Los datos almacenados por el sistema, son todos aquellos documentos que recepciona la empresa en manera física una vez sean digitalizados, para su posterior almacenamiento.

Requisito funcional 1

Requisitos de interfaz: El software trabajará en ambiente web, herramienta

que los usuarios pueden utilizar accediendo a un servidor web a través de

Internet o de una intranet mediante un navegador, podrán almacenar

información.

Requisito funcional 2

Requisitos de navegación: Se determinará la cantidad de usuarios y sus roles,

por ejemplo, un rol de usuario puede contener autorizaciones para crear

nuevos elementos de datos, actualizar una unidad organizativa o ver un

reporte. Estos grupos de autorizaciones constituyen un rol de usuario.

Requisito funcional 3

Requisitos transaccionales o funcionales internos: El aplicativo archivará

documentos digitalizados, los distribuirá a las áreas que les sean

asignadas, facilitará la recepción y envío de documentos o solicitudes y sus

respectivas respuestas por medio de su respectiva configuración.

51

o Requisitos no funcionales

Requisitos de rendimiento

Completo soporte para operadores y funciones en cláusulas select y

where.

Completo soporte para cláusulas group by y order by, soporte de

funciones de agrupación.

Seguridad: ofrece un sistema de contraseñas y privilegios seguro

mediante verificación basada en el host y el tráfico de contraseñas está

cifrado al conectarse a un servidor.

Soporta gran cantidad de datos. MySQL Server tiene bases de datos de

hasta 50 millones de registros.

Se permiten hasta 64 índices por tabla (32 antes de MySQL 4.1.2).

Cada índice puede consistir desde 1 hasta 16 columnas o partes de

columnas. El máximo ancho de límite son 1000 bytes (500 antes de

MySQL 4.1.2).

Los clientes se conectan al servidor MySQL usando sockets TCP/IP en

cualquier plataforma. En sistemas Windows se pueden conectar usando

named pipes y en sistemas Unix usando ficheros socket Unix.

En MySQL 5.0, los clientes y servidores se pueden conectar usando

memoria compartida.

MySQL contiene su propio paquete de pruebas de rendimiento

proporcionado con el código fuente de la distribución de MySQL.

52

Seguridad

Por ser un software hecho en JAVA combina la compilación y la interpretación y esto facilita la seguridad y la estabilidad, además de reducir los problemas de versiones.

El código Java pasa muchos tests antes de ejecutarse en una máquina SIMAGED por ser diseñado con un esquema o arquitectura de 3 niveles para su base de datos tiene tres características importantes inherentes a los sistemas de bases de datos: la separación entre los programas de aplicación y los datos, el manejo de múltiples vistas por parte de los usuarios y el uso de un catálogo para almacenar el esquema de la base de datos. Cumple con la arquitectura ANSI-SPARC, y lo hace altamente seguro.

Disponibilidad

De acuerdo a la monitorización correcta del sistema la disponibilidad real del servicio, tiene un compromiso estrecho y real con el proceso de calidad dentro de la organización. No se dispone de las herramientas de software y personal adecuado, si la organización o empresa que adquiere el software no se hace cargo de éste. Los objetivos de disponibilidad están alineados con las necesidades del cliente, y está ligada a la coordinación con los otros procesos. Los proveedores internos y externos deben reconocer la autoridad del Gestor del aplicativo de la disponibilidad por falta de apoyo de la dirección. Teniendo en cuenta los factores anteriormente mencionados este proyecto garantizaría una disponibilidad del 90% ante eventuales fallas y bugs del sistema. Mantenibilidad

Cuanto mejor se mantenga la base de datos, mejor rendimiento se obtendrá de las consultas que se realicen sobre la misma (los resultados se obtendrán más rápidamente, y en consecuencia, se podrán mostrar antes), con solo realizar unas tareas sencillas como lo son:

53

Backups: de los ficheros de datos, ficheros de logs de transacciones, ficheros de configuración y logs binarios.

Limpieza de logs binarios.

Optimización de tablas: después de inserts y updates las tablas se llenan de espacio inútil, por lo que es necesario optimizar las tablas.

Vaciar la caché

Rotar los logs binarios.

También es conveniente de forma regular realizar un mantenimiento del navegador de la siguiente manera:

Borrar archivos temporales e historial de búsqueda

Borrar las cookies

Bloquear ventanas emergentes o pop-ups

Reparación de las asociaciones

Portabilidad

Gracias a que SIMAGED no se compila a código máquina, sino a un lenguaje intermedio que luego es interpretado por la "máquina virtual Java", que sí es específica de cada plataforma, lo hace completamente portable, esto le da una velocidad ligeramente inferior a la de los programas realizados en otros lenguajes compilados, como C++, a cambio de una mayor portabilidad (aparte de las mejoras que el lenguaje en sí incorpora sobre otros como C++). Es importante recordar que los tiempos de espera para visualizar los contenidos en versión Web serán un poco mayores. No conviene olvidar que en las aplicaciones web la comunicación entre el servidor y el cliente dependen de la velocidad de conexión y las características de la maquina cliente y servidor.

54

FIGURA 5. Modelo de Diseño de la Base de Datos

Fuente: Elaboración Propia

55

FIGURA 6. Diagrama de flujo de Procesos

Fuente: Elaboración Propia

NO SI

56

En la figura 6 se presenta el diagrama que contiene los siguientes procesos:

Recepción de Documentos: hace referencia a la acción de recibir los documentos en un área, provenientes de otra o de una entidad externa, incluye subprocesos como:

Tamizaje.

Radicación.

Digitalización

Distribución de Documentos: este proceso incluye la entrega y transferencia de documentos entre áreas o a entidad externa, incluye subprocesos:

Entrega o Envío de Documento.

Establecer ruta.

Realizar transferencia

Generar solicitud de trámite.

Trámite de Documentos: en este proceso se lleva a cabo la acción requerida por el documento recibido, del cual puede desprenderse otros procesos como la creación de un nuevo documento que se anexará al expediente. Incluye subprocesos:

Aceptar y Recibir.

Respuesta o Solución.

Genera Solicitud de Préstamo.

Solicitud de Consulta.

Producción de Documentos: este proceso me permite crear un nuevo documento que se vinculará a un expediente o que hará parte de un expediente nuevo, este documento se vinculara a las tablas de retención documental y hará parte del archivo de gestión, Central e Histórico si así lo determinan las mismas. Para este proceso se realizaran los subprocesos:

Seleccionar Tipo de Documento.

Ingresar Información.

57

Generar Documento (PDF en nuestro caso).

Vincular a expediente.

Entrega.

Organización de Documentos: este proceso hace referencia a la vinculación del documento a las tablas de retención documental clasificando su serie y subserie a la que pertenece, ubicación y organización física en el archivo según lo establezca la tabla de retención documental teniendo en cuenta el principio de procedencia, fechas, si es público, privado etc.

Consulta de Documentos: En caso de res requerido para dar trámite a un requerimiento, se pueden hacer consultas de nuestros documentos al archivo de gestión, central o histórico según sea el caso, tiempo, disponibilidad e importancia del documento, según lo establezcan las tablas de retención documental. Este proceso abarca los subprocesos:

Recibir solicitud de consulta.

Generación de Catálogos.

Realizar acción de consulta solicitada.

Control y préstamo de documento.

Conservación de Documentos: se refiere a las acciones que permiten que el documento físico se conserve en buen estado, incluye técnicas para arreglar daños que se presenten, en este caso se deberá guardar la información de cambios que se realicen y que se deriven de dichas técnicas.

Disposición Final de Documento: una vez cumplido el tiempo máximo establecido en las tablas de retención documental y dependiendo de la clasificación e importancia del documento se realizan los siguientes subprocesos:

Inventario de documentos.

Digitalización de lo que no estuviera digitalizado o microfilmación.

Proceso de eliminación o almacenamiento como Histórico.

58

3.1.1.2. Elaboración

Objetivo: obtener la arquitectura del sistema.

Tareas:

Identificar arquitectura

Validar la arquitectura

Establecer el ambiente de desarrollo del proyecto Informar al personal del proyecto

Resultado: Arquitectura del Ciclo de Vida (LCA)

Figura 7. Despliegue de Alto Nivel

Fuente: Elaboración propia

59

FIGURA 8. Símil con aplicación de Arquitectura ANSI/SPARC

Fuente: http://escritura.proyectolatin.org/

FIGURA 9. Arquitectura MVC

Fuente: Elaboración propia

60

Figura 10. Diagrama de procesos del clico de vida del documento

Fuente: Elaboración propia

3.1.1.3. Construcción

Objetivo: implementar un software sobre una base incremental la que debe estar relacionada con los objetivos de los involucrados.

Tarea:

Modelado, construcción y testeo del sistema

Creación de documentación de apoyo

Resultado: Casos de uso y capacidad operacional inicial (IOC) (Ver Concreción del Modelo).

61

Casos de uso

Figura 11. Recepción y entrega de documentos

Fuente: Elaboración propia

Recepción y entrega de

documentos

62

FIGURA 12. Distribución de documentos

Fuente: Elaboración propia

63

Figura 13. Trámite de documentos

Fuente: Elaboración propia

Entidad Interna

64

Figura 14. Producción de documentos

Fuente: Elaboración propia

65

Figura 15. Organización de documentos

Fuente: Elaboración propia

66

Figura 16. Conservación de documentos

Fuente: Elaboración propia

Figura 17. Disposición final de documentos

Fuente: Elaboración propia

Entidad Interna

67

Figura 18. Consulta de documentos

Fuente: Elaboración propia

3.1.1.4. Transición

Objetivo: validar y entregar el sistema en un ambiente de puestas en producción.

Tarea: Test del sistema Test de usuarios Correcciones

Instalación del sistema

Resultado: Lanzamiento del producto (PR) (Ver Concreción del Modelo).

68

3.1.2. ACTIVIDADES

Definen actividades que el equipo debe realizar para construir, validar y entregar un software que satisfaga las necesidades.

3.1.2.1. Modelo:

Entender los procesos de negocios de la organización, el dominio de problema que puede ser abordado por el software, e identificar una solución viable.

3.1.2.2. Implementación:

Transformar los modelos en código ejecutable y aplicar pruebas básicas en unidades particulares de prueba.

3.1.2.3. Prueba:

Realizar una evaluación objetiva para asegurar la calidad. Esto incluye encontrar defectos, validar que el sistema funcione como fue diseñado, y verificar que los requisitos estén abordados por las funcionalidades

3.1.2.4. Despliegue:

Planificar la entrega del sistema y ejecutar el plan para que el sistema esté disponible para los usuarios.

3.1.2.5. Administración de la Configuración:

Administrar el acceso a los artefactos del proyecto. Esto no solo incluye el seguimiento de las versiones de los artefactos, sino también controlar y administrar los cambios sobre ellos. Administración del Proyecto: Dirigir las actividades que forman parte del proyecto. Esto incluye administración de riesgos, dirigir personas y coordinar personas con sistemas que están fuera del alcance del proyecto.

3.1.2.6. Ambiente:

Facilitar todo el entorno que permita el normal desarrollo del proyecto.

69

3.2. Tendencias [29][30]:

La gestión documental se encuadra actualmente dentro del contexto más amplio de la “Gestión de Contenidos Empresariales” o ECM en inglés (“Enterprise content Management”) [29]. Las principales tendencias actuales se resumen en [29]:

Estrategia global. El ECM es un tema global en las compañías y no sólo departamental como hace unos años, abarcando todo tipo de contenidos.

Infraestructuras consolidadas. Diferentes proyectos confluyen bajo una

misma infraestructura tecnológica.

La integración de sistemas y la capacidad de reutilización del software.

Aseguramiento de la información. No sólo se refiere a la política de acceso a la información, sino también a su protección integral y duradera, trazabilidad, el cumplimiento de normas, la protección de datos, el secreto empresarial, etc.

Búsqueda “federada”. El sistema debe ser capaz de buscar en cualquier

origen de datos, sin que el usuario tenga que saber dónde. El contenido debe aflorar cuando se lo necesita.

Experiencia del usuario. Hay una clara tendencia a la socialización del

entorno tecnológico. Se requieren sistemas capaces de medir la experiencia del usuario.

Principales tecnologías en gestión documental que se perfilan para el futuro [30]: “Las empresas se enfrentan a un entorno más duro y volátil, en el que la inteligencia y la eficiencia de procesos serán claves para ganar posiciones a la competencia. Continuará la tendencia hacia la externalización de servicios y procesos como herramienta de reducir costes y aparecerá un creciente uso de formas más eficientes en la “entrega” intensiva en tecnología, como virtualización, cloud computing, smart computing, digitalización o e-commerce” [30].

70

DocPath, compañía española especializada en el desarrollo de soluciones de software documental, reunió a sus expertos para realizar un profundo análisis y determinar qué tendencias marcarán el devenir de esta tecnología en los próximos años. Estas son sus cinco propuestas [30]:

“Soluciones más intuitivas: Los documentos se han convertido en el principal vehículo de comunicación entre las empresas y sus clientes.

Incremento del outsourcing: Aunque las compañías cuenten con sus propios

departamentos de Sistemas, el outsourcing se ha convertido en una práctica muy habitual cuando hablamos de software de gestión documental.

Nuevas tendencias en movilidad: Los smartphones, tablet PC´s y los

netbooks han desbordado todas las expectativas de consumo.

Almacenamiento inteligente: En el mundo se genera un volumen de información por segundo cercano a los 400 GB y todas las previsiones apuntan a que este volumen continuará creciendo a un ritmo del 50%.

Crecimiento del ECM: Según datos de la consultora PwC en 2020 el 80% de los ingresos del mercado de software documental se generará a través de servicios de Enterprise Content Management. Una tendencia que ya ha empezado a destacar y que muy pronto tendrá más fuerza que la de la digitalización de documentos”.

4. CONCRECIÓN DEL MODELO

Las aplicaciones web son herramientas que se utilizan accediendo a un servidor web a través de Internet o de una intranet mediante un navegador. De una forma más clara, son aplicaciones de software que se codifican en un lenguaje soportado por los navegadores web en la que se confía la ejecución al navegador.

Las aplicaciones web en el último tiempo han ganado terreno debido a lo práctico del navegador web como cliente ligero, así como a la facilidad para actualizar y mantener aplicaciones web sin distribuir e instalar software a miles de usuarios potenciales. Existen aplicaciones como los webmails, wikis, weblogs, tiendas en línea y la propia Wikipedia que son ejemplos conocidos de aplicaciones web.

Es importante mencionar que una página Web puede contener elementos que permiten una comunicación activa entre el usuario y la información. Esto permite que el usuario acceda a los datos de modo interactivo, gracias a que la página responderá a cada una de sus acciones, como por ejemplo rellenar y enviar

71

formularios, participar en juegos diversos y acceder a gestores de base de datos de todo tipo. A tener en cuenta:

Interfaz

Es la conexión que se da de manera física y a nivel de utilidad entre dispositivos o sistemas. En el desarrollo web generalmente se utilizan lenguajes interpretados (scripts) en el lado del cliente para añadir funcionalidades, especialmente para ofrecer una experiencia interactiva. Recientemente se han desarrollado tecnologías para coordinar estos lenguajes con las tecnologías en el lado del servidor. Como ejemplo, AJAX es una técnica de desarrollo web que usa una combinación de varias tecnologías.

Estructura de las aplicaciones Web

Las aplicaciones web pueden estructurarse comúnmente en tres capas, de la siguiente manera:

El navegador web ofrece la primera capa, que son las vistas que permiten la interacción de los usuarios.

Un lenguaje (ejemplo: PHP, Java Servlets o ASP, ASP.NET, CGI, ColdFusion, embPerl, Python (programming language) o Ruby on Rails) que constituye la capa intermedia y permite la comunicación entre la primera capa y la base de datos.

Por último, la base de datos forma la tercera y última capa.

72

Resultados obtenidos

Como cualquier base de datos, el sistema tiene una serie de tablas creadas a partir de un código y lenguaje específico que ya se ha definido y explicado con anterioridad.

Después del tiempo definido, se muestran las primeras imágenes del sistema en funcionamiento. La imagen inicial corresponde al pantallazo con el que el usuario tendrá contacto una vez trate de ingresar al sistema, el cual pide autenticación para poder acceder.

FIGURA 19. Pantalla Usuario y Contraseña

Fuente: Elaboración propia

Después de la autenticación, se accede al pantallazo principal del sistema, el cual presenta los menús de usuario y administrador, a los cuales se accede dependiendo el rol que tenga el usuario.

73

FIGURA 20. Pantalla Principal

Fuente: Elaboración propia

En el menú de usuario se observan varias opciones del ciclo de vida del documento, recepción de documento, generar el documento digital, consultar, etc., en la siguiente captura se observará detalladamente.

FIGURA 21. Pantalla Crear Documento

Fuente: Elaboración propia

74

La siguiente captura de pantalla muestra el pantallazo de consulta, donde podemos realizar búsqueda por filtro, sea por número de documento o por contenido (palabras clave), sin embargo aún no se ve en pantalla el documento, solo la información del mismo.

FIGURA 22. Pantalla de Consulta

Fuente: Elaboración propia

Por último se muestra el pantallazo en el cual los usuarios pueden ver el documento dando clic en el botón de despliegue al inicio de la fila seleccionada.

FIGURA 23. Visualización de Documento

Fuente: Elaboración propia

75

Pruebas

En este proyecto a partir de la tercera iteración se realizaron pruebas unitarias y generales de tipo: funcionales y de aceptación. Dichas pruebas son las que se realizan de acuerdo a la metodología usada y consisten en identificar si la solución dada durante la iteración funciona según los requisitos, y determina, que lo realizado es lo que el cliente quiere, lo que da como resultado, nuevos requisitos para la siguiente iteración, o la posibilidad de avanzar si las pruebas fueron satisfactorias.

Dentro de las pruebas funcionales, se establecen también las posibilidades que tienen los usuarios de interactuar con el sistema. Por ej. Establecer el tamaño del documento digitalizado: Se realiza una prueba donde se ve un documento de 146 páginas en formato PDF escaneado a 150 dpi y a blanco y negro y su peso es de 1.11MB.

FIGURA 24. Prueba Digitalización

Fuente: Elaboración propia

76

A continuación algunas imágenes de las pruebas realizadas:

Prueba Autenticación:

En la figura 21 se muestra la prueba del módulo de autenticación, cuando un usuario ingresa algún dato erróneo en el proceso de identificación, automáticamente sale un mensaje de error y vuelve a solicitar los datos.

FIGURA 25. Prueba Autenticación

Fuente: Elaboración propia

Prueba Perfil de Usuario: Dependiendo el Rol de usuario se habilitan algunas características, en el caso de la FIGURA 22 se evidencia que el menú del lado derecho desaparece si el rol de usuario no es administrador.

FIGURA 26. Prueba Perfil de Usuario

Fuente: Elaboración propia

77

Prueba Guardar Información en la base de datos y validar campos: En la próxima figura se realiza prueba de almacenamiento de la información en la base de datos, así mismo, la validación de los campos, que son particulares para cada caso.

FIGURA 27. Prueba Guardar Información en la base de datos y validar

campos

Fuente: Elaboración propia

Prueba Almacenar Documento Digital:

Una parte importante del sistema es la de guardar los documentos digitalizados en la base de datos, por ello se realizan pruebas para identificar la validación del tipo de documentos que permite subir, el tamaño y que permita realizar la acción.

78

FIGURA 28. Prueba Almacenar Documento Digital

Fuente: Elaboración propia

Prueba Consulta:

La siguiente figura muestra la prueba de consulta y visualización del documento, en la cual se puede ver satisfactoriamente el documento digitalizado que se encuentra en la base de datos.

FIGURA 29. Prueba Consulta

Fuente: Elaboración propia

79

Prueba Cambio de Tema (Personalizar entorno):

En la figura 25 se ve la prueba de cambio de entorno o tema, es decir, cada usuario tiene la posibilidad de cambiar su entorno o personalizarlo (colores, tamaño letra) a través de la opción: Tema de Usuario que está en las opciones de Persona, donde se puede seleccionar una lista de temas.

FIGURA 30. Prueba Cambio de Tema (Personalizar entorno)

Fuente: Elaboración propia

80

CONCLUSIONES

Se realizó el análisis, diseño e implementación de un sistema informático en ambiente web, que permite a cualquier empresa tener un control sobre sus documentos, garantizando trazabilidad y disponibilidad de los mismos cuando se requiera. El sistema desarrollado es estándar porque permite manejar 3 conceptos básicos de la gestión documental (Control, disponibilidad y gestión), esto hace que cualquier empresa pueda usarlo. La fase de análisis de requisitos, permitió a los desarrolladores del proyecto materializar el diseño mediante la elaboración de los diagramas necesarios para llegar a la implementación del sistema en su complejidad. La aplicación de la metodología AGILE AUP permitió desarrollar el proyecto cumpliendo con los tiempos estipulados para el desarrollo del proyecto.

Si se requiere conectar el software desarrollado con otras aplicaciones de la organización, es necesario la creación de una pasarela que lo permita. El sistema permitió ver en pantalla los documentos digitalizados, los cuales pueden ser consultados aplicando filtros y buscando palabras clave, esto reduce la impresión de copia de dichos documentos, ayudando al cumplimiento de la directiva presidencial 02 de 2012. Las pruebas realizadas determinaron que la digitalización directa de documentos al software no fue posible, sin embargo, se puede ingresar un documento digitalizado siguiendo las recomendaciones de digitalización. Se espera mejorar este aspecto para una próxima versión, así como la inclusión de reportes y pasarelas con otros sistemas de información, con el fin de hacerlo más robusto.

81

RECOMENDACIONES

Teniendo en cuenta el tiempo para desarrollar y la complejidad del tema, es

necesario en la implantación a una empresa, llevar a cabo la fase de

personalización, es decir, la creación de las interfaces o pasarelas para conexión

con aplicaciones existentes.

En el momento de la digitalización se recomienda escanear en los siguientes

formatos: pdf, png y/o jpg, el documento se debe digitalizar en blanco y negro a

150dpi lo que nos permite tener un documento de 100 páginas con peso de 1 MB.

Se debe definir el tamaño máximo del documento digitalizado, de acuerdo a las

necesidades de cada empresa, tener en cuenta un máximo de 4MB. Si es

necesario guardar documentos de mayor tamaño, se debe cambiar la

configuración de la aplicación para que guarde en un medio de almacenamiento y

no en la base de datos.

Se deberá consultar en el Manual de Usuario las características que se necesitan

para usar el programa y/o su instalación en un servidor, pues depende del caso

particular de cada empresa.

82

REFERENCIAS BIBLIOGRÁFICAS

[1] R. d. C. Gobierno Nacional, Ley 594 LEY GENERAL DE ARCHIVOS, Bogotá, 2000.

[2] P. d. l. R. d. C. Colombia, Directiva Presidencial 04, Bogotá, 2012.

[3] Athento, «http://www.athento.com,» [En línea]. Available:

http://www.athento.com/gestion-documental-inteligente/. [Último acceso: 01 05 2014].

[4] Y. S. Inc, «Athento,» Yerbabuena Software Inc, 2014. [En línea]. Available:

http://go.athento.com/zady-gestores-la-primera-gestoria-inteligente-de-

espana?origen=seccionRecursos. [Último acceso: 02 05 2014].

[5] SUMMAN, «http://www.summan.com/,» [En línea]. Available:

http://www.summan.com/casos-de-exito/implementacion-del-sistema-de-gestion-

documental-en-la-notaria-25-de-medellin. [Último acceso: 01 05 2014].

[6] A. LTDA, «www.aurealtda.com,» [En línea]. Available: http://www.aurealtda.com/simad-

gestion-documental.html. [Último acceso: 01 05 2014].

[7] CASTILLALANUEVA, «CASTILLALANUEVA,» [En línea]. Available: http://castillalanueva-

meta.gov.co/apc-aa-

files/30336535636539646534383061383735/EM19..PROGRAMADEGESTI_NDOCUMENTAL.

pdf.

[8] p. l. A. Á. Jim Highsmith, «http://agilemanifesto.org/,» 2001. [En línea]. Available: Jim

Highsmith, para la Alianza Ágil.

[9] K. K. Patcha, «Agile EDI Framework for B2B Applications,» IEEE Computer Society, 2009.

[10] K. Beck, Una explicación de la programación extrema. Aceptar el cambio, Addison Wesley,

2000.

[11] P. L. y. M. C. P. José H. Canós, «Métodologías Ágiles en el Desarrollo de Software,» DSIC -

Universidad Politécnica de Valencia.

[12] C. Edeki, «AGILE UNIFIED PROCESS,» IJCSMA International Journal of Computer Science and

nobile aplications, vol. I, nº 3, pp. 13-17, 2013.

[13] S. Ambler, Enterprise Unified Process: Extending the Rational Unified Process, 2005.

[14] A. Scott, «The Agile Unified Process (AUP),» 2006. [En línea]. Available:

83

www.ambysoft.com/unifiedprocess/agileUP.html. [Último acceso: 2014].

[15] C. Edeki, «AGILE UNIFIED PROCESS,» IJCSMA International Journal Computer Science and

Mobile Aplitations, vol. I, nº 3, pp. 13-17, 2013.

[16] G. B. a. J. E. R. I. Jacobson, The Unifed Software Development Process, Massachusetts:

Addison - Welsly, 1999.

[17] R. Presman, Ingeniería del Software. Un Enfoque Practico 7th ed., Mexico: Mc Graw-Hill,

2010.

[18] A, «Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the

Enterprise,» IBM press ISBN 978-0132810135, 2012.

[19] IEEE, «IEEE Standard for Software User Documentation 1063-2001,» IEEE, New York, 2001.

[20] IEEE, «IEEE Especificaciones de Requisitos del Software STD 830-1998,» IEEE, New York,

1998.

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

J. E. a. N. Koch, «REQUIREMENTS ENGINNERING FOR WEB APLICATIONS - A COMPARATIVE

STUDY,» Journal of Web Engineering, vol. 2, nº 3, pp. 193-212, 2004.

R. S. Pressman, Software Engineering. A practitioner’s Aproach, 5th ed. New York:

McGraw­Hill series in computer science, 2001.

P. Bourque and R. Dupuis, “SWEBOK: Guide to the software engineering Body of

knowledge,” IEEE Computer Society, vol. 200, no. 4, pp. 22–190, 2004.

I. Sommerville, Ingeniería del Software, 7th ed. Madrid, España: Pearson Educación S.A,

2005.

G. Booch, J. E. Rumbaugh, and I. Jacobson, El lenguaje unificado de modelado, 2nd ed.

España: Pearson Educación S.A, 2006.

J. Rumbaugh, I. Jacobson, G. Booch, El Lenguaje Unificado de Modelado. Manual de referencia. Addison-Wesley,2000.

ANSI/X3/SPARC, Study Group on Data Base Management Systems: Interim Report. FDT, ACM SIGMOD bulletin. Volume 7, No. 2, (1975).

T. Dennis, K. Anthony,The ANSI/X3/SPARC DBMS framework report of the study group on

database management systems, Information systems vol. 3, iss 3 pp. 173-191,1978.

84

[29]

[30]

[31]

[32]

http://www.gestiondocumental.biz/noticias/ultimas-tendencias-en-la-gestion-documental-

de-empresas/post-9-1-1-500-1/.

Dataprix, «http://www.dataprix.com,» [En línea] http://www.dataprix.com/empresa/recursos/tendencias-software-gesti-n-documental-2011. Leff, Avraham; James T. Rayfield (September 2001). «Web-Application Development Using the Model/View/Controller Design Pattern». IEEE Enterprise Distributed Object Computing Conference. pp. 118–127, 2001. L. López Román, Metodología de la programación orientada a objetos, 2nd ed. México: AlfaOmega, 2013.

85

GLOSARIO

Ambiente web, 22, 1 aplicaciones de Software, 13 Arquitectura ANSI/SPARC, 1 AUP, 13, 17, 20, 26, 27, 28, 29, 35, 55, 58, 1,

6, 8, 10, 11, 1 control, 13, 15, 22, 28, 55, 10, 16, 2 digitalizar, 21, 56 disponibilidad, 13, 15, 16, 40, 55, 6, 10, 13,

16, 18 Dpi, 1 DSDM, 24, 26, 1 entidades, 5, 13, 14, 16, 20, 21, 32, 34, 6, 13 Flujo de documentos, 1 gestión documental, 5, 13, 14, 15, 16, 18, 20,

21, 22, 30, 31, 32, 34, 55, 6, 7, 9, 10, 12, 13

interactivo, 49 Iteraciones, 17, 1

Ley 594 de 2000, 2 Manifiesto de Desarrollo Ágil de Software, 23,

2 metodología de desarrollo, 13, 15, 20, 25, 26,

29 Metodologías AGILE, 2 MVC, 13, 53, 2, 15, 2 OOPSLA, 2 prototipo no funcional, 17 Servidor web, 3 Software Funcional, 17 Tamizaje, 39, 3 trazabilidad, 14, 15, 55, 13 weblogs, 49 webmails, 49 wikis, 49 Zady Gestores, 21, 3

Ambiente web: el ambiente web hace referencia a un entorno de desarrollo y/o ejecución programas o servicios en el marco de la web en general. El entorno web es una forma de interfaz de usuario gráfico. Aplicaciones de software: conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específica. Arquitectura ANSI/SPARC: arquitectura de tres niveles para los sistemas de bases de datos, que resulta muy útil a la hora de conseguir estas tres características. AUP: es una versión simplificada del Proceso Unificado de Rational (RUP). Este describe de una manera simple y fácil de entender la forma de desarrollar aplicaciones de software. Control: Dirección o dominio de una organización o sistema. Digitalizar: consiste en la transcripción de señales analógicas en señales digitales, en este caso documentos físicos a documentos digitales. Disponibilidad: cualidad de estar libre para ser usado en cualquier momento.

86

Dpi: unidad de medida para resoluciones de impresión. DSDM: es un método que provee un framework para el desarrollo ágil de software, apoyado por su continua implicación del usuario en un desarrollo iterativo y creciente. Entidad pública o privada: organización con personalidad jurídica, perteneciente al estado a al sector privado. Flujo de documentos: asignación de documentos en secuencia del sistema que pertenecen. Gestión Documental: conjunto de normas técnicas y prácticas usadas para administrar el flujo de documentos. Interactivo: La interactividad hace referencia al nivel de respuesta, y se estudia como un proceso de comunicación en el que cada mensaje se relaciona con el previo, y con la relación entre éste y los precedentes. Interfaz: conexión física y funcional entre dos sistemas o dispositivos de cualquier tipo. Iteraciones: acto de repetir un proceso con el objetivo de alcanzar una meta deseada, objetivo o resultad. Ley 594 de 2000: ley de la cual se dicta la Ley General de Archivos y se dictan otras disposiciones en el Congreso de Colombia Manifiesto de Desarrollo Ágil de Software: principios sobre los que se basan los métodos alternativos de los modelos de mejora del desarrollo de software en cuatro postulados. Metodologías de desarrollo: marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información. Metodologías AGILE: métodos de ingeniería del software basados en el desarrollo iterativo e incremental.

87

MVC (Modelo-Vista-Controlador): patrón de arquitectura de software que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario. OOPSLA: conferencia estadounidense que se ha convertido en el foro en que se han presentado y presentan las mejores ideas para mejorar el desarrollo software. Prototipo no funcional: modelo del comportamiento del sistema que puede ser usado para entender la realidad de un proceso, pero no funciona en su totalidad. Software funcional: sistema de información en funcionamiento. Servidor web: programa informático que procesa una aplicación del lado del servidor, realizando conexiones bidireccionales y/o unidireccionales y síncronas o asíncronas con el cliente. Tamizaje: exámenes aplicados con el fin de identificar una población. Trazabilidad: La propiedad del resultado de una medida o del valor de un estándar donde éste pueda estar relacionado con referencias especificadas. Weblog: sitio web en el que se publican anotaciones (historias, artículos, posts) mediante un sistema de publicación sencillo. WebMails: interfaz web por la que accede al correo electrónico. Wikis: es el nombre que recibe un sitio web cuyas páginas pueden ser editadas directamente desde el navegador, donde los usuarios crean, modifican o eliminan contenidos que, generalmente, comparten. Zady Gestores: sociedad que nace para la prestación de servicios de gestoría.

1

ANEXO A. Cronograma por Iteraciones

El título de cada cronograma: Iteración #Iteración (Nombre de la Iteración). El nombre contiene letra inicial de la fase y

#de iteración.

ITERACIÓN 1 (I1)

Fase Tarea

Inicio

Semana1 Semana2

Entorno o ambiente: Disposición, instalación de herramientas para iniciar proyecto, levantamiento información.

Administración Configuración: Iniciar a documentar el proceso, establecer como se hace la revisión y los cambios.

Administración del proyecto: Establecer políticas del proyecto, roles, duración de las iteraciones, cronograma.

Modelado: Tomar la información recolectada, verificar requisitos, identificar y entender el problema y la solución.

ITERACIÓN 2 (I2)

Fase Tarea

Inicio

Semana1 Semana2

Entorno o ambiente: Revisión resultados iteración anterior, disponer herramientas que se necesiten según análisis de información levantada.

Administración Configuración: Realizar tareas pendientes, gestionar cambios que se requieren, Identificar arquitectura.

Administración del proyecto: Revisión de resultados y tareas anteriores y distribución de nuevas tareas, Presupuesto.

Modelado: análisis de requisitos e inicio de modelo de Base de datos

2

ITERACIÓN 3 (E3)

Fase Tarea

Elaboración

Semana1 Semana2

Modelado: Generar diagramas.

Implementación: Generación de scripts de base de datos para su creación.

Administración del proyecto: Revisión de tareas y asignación de nuevas tareas.

Administración Configuración: seleccionar arquitectura, documentar arquitectura.

Pruebas: Validar arquitectura, verificar modelo de base de datos y probar scripts creados.

ITERACIÓN 4 (E4)

Fase Tarea

Elaboración

Semana1 Semana2

Implementación: Generar código a partir del modelo de la base de datos, generar prototipo funcional.

Modelado : Terminar diagramas.

Pruebas: Realizar pruebas funcionales sobre prototipo

Administración del proyecto: Revisión de tareas y establecer fechas de entrega de primera fase.

Administración Configuración: Documentar y generar documento para entrega.

3

ITERACIÓN 5 (C5)

FASE Tarea

Construcción

Semana 1 Semana 2 Semana 3 Semana 4

Modelado: Revisión del modelo.

Implementación: Avanzar en el código, implementar librería PRIMEFACES.

Administración del proyecto: Revisión de tareas y asignación de nuevas tareas.

Pruebas : Realizar pruebas Unitarias.

Administración Configuración: Inicio de documentación guía usuario.

ITERACIÓN 6 (C6)

FASE Tarea

Construcción

Semana 1 Semana 2 Semana 3 Semana 4

Modelado: Revisión aplicación de arquitectura MVC.

Pruebas: Realizar pruebas funcionales.

Administración Configuración: Documentar guía de usuario.

Implementación: Implementar servlets para control de imágenes desde el entorno a la BD.

Administración del proyecto: Revisión de tareas y asignación de nuevas tareas y planificar la finalización.

4

ITERACIÓN 7 (T7)

FASE Tarea

Transición

Semana 1 Semana 2 Semana 3 Semana 4

Implementación: Realizar código para funcionamiento de perfiles en la aplicación.

Pruebas : Realizar pruebas de aceptación.

Despliegue: Software funcionando, instalación fuera del entorno IDE de Netbeans en servidor Glassfish.

Administración Configuración: Generar documento de entrega, generar presentación y preparar sustentación.

Administración del proyecto: Revisión del estado del proyecto y las tareas, generar cambios necesarios, establecer entrega.

1

ANEXO B. Productos mínimos a entregar

Fuente: S. Ambler, Agile Unified Process: AUP. 2005.

Entregable Descripción

Sistema El software, el soporte físico, y la documentación de trabajo que se desplegará en la producción.

Código fuente El código del programa para su sistema.

Casos de testeo Una colección de casos de prueba, y el código para hacerlos funcionar en el orden apropiado.

Scripts de Instalación Código para instalar el sistema en su ambiente de producción.

Documentación de sistema La documentación entregada como parte de su sistema para ayudar a los stakeholders a trabajar con él y los developers para mantenerlo y desarrollarlo.

Release Notes Resumen las “buenas cosas para saber” sobre la versión actual del sistema que está construyendo.

Modelo de Requisitos Test de Aceptación, Procesos de Negocio, Dominio, Casos de Uso, Interfaz de Usuario

Modelo del diseño Describe el diseño del sistema.

El mejor lugar para documentar el diseño es en los test unitarios y en el código fuente

Basado en Estándar IEEE Std 1063-2001

1

ANEXO C. Manual de usuario

SISTEMA DE INFORMACIÓN ESTÁNDAR DE GESTIÓN DOCUMENTAL EN AMBIENTE WEB.

Manual de Usuario 2014

Basado en Estándar IEEE Std 1063-2001

2

Tabla de Contenido

Pág.

1. Introducción 5 2. Información para el uso de la documentación 5 3. Conceptos de las operaciones 5 4. Información sobre los comandos de software 16 5. Mensajes de error y resolución de problemas 16 6. Características de navegación 17

Basado en Estándar IEEE Std 1063-2001

3

Lista de ilustraciones

Pág. FIGURA 1. Ingresar 6

FIGURA 2. Guardar 7

FIGURA 3. Editar 7

FIGURA 4. Consultar 7

FIGURA 5. Mostrar 8

FIGURA 6. Desplegar Vista 8

FIGURA 7. Consultar PDF 8

FIGURA 8. Filtro 9

FIGURA 9. Salir 9

FIGURA 10. Procesos del Ciclo de Vida del Documento 10

FIGURA 11. Radicación 10

FIGURA 12. Creación de Expediente 11

FIGURA 13. Creación del Documento en el sistema 11

FIGURA 14. Distribuir documento 12

FIGURA 15. Crear Documento 13

Basado en Estándar IEEE Std 1063-2001

4

FIGURA 16. Organizar Documento 13

FIGURA 17. Consulta y Visualización de Documentos 14

FIGURA 18. Conservación de Documentos 15

FIGURA 19. Disposición Final 15

FIGURA 20. Diagrama de flujo del ciclo de vida del documento 16

FIGURA 21. Mensajes de error y resolución de problemas 17

FIGURA 22. Navegación 17

Basado en Estándar IEEE Std 1063-2001

5

1. INTRODUCCIÓN

El propósito de este manual es orientar al lector sobre qué es y cómo se maneja de SIMAGED (Sistema para el manejo de la Gestión Documental). SIMAGED es un sistema de información estándar para el manejo de la gestión documental, su ambiente de trabajo es WEB lo que lo hace accesible desde cualquier equipo que haga parte de la red donde se encuentra instalado. Es estándar porque permite manejar los tres aspectos básicos de la gestión documental: Disponibilidad, control y administración de los documentos. 2. INFORMACIÓN PARA EL USO DE LA DOCUMENTACIÓN En este manual podrá encontrar las características propias del sistema, los módulos y las acciones que debe seguir para llevar a cabo una tarea. En caso de requerir información específica, remitirse a la tabla de contenido y verificar el lugar donde se encuentra el tema que necesita. La información técnica inherente al sistema se encuentra en como anexo de manera digital en archivo html. 3. CONCEPTOS DE LAS OPERACIONES Dentro del Sistema de Manejo de la Gestión Documental SIMAGED se encuentran operaciones que están basadas en los procesos del ciclo de vida del documento, así mismo operaciones propias del sistema. En este apartado se explicarán las más importantes. Operaciones del sistema:

Ingresar: por medio de esta operación el sistema valida los datos de usuario y contraseña (Ver Figura 1).

Guardar: almacena la información del formulario en la base de datos (Ver Figura 2).

Editar: muestra en pantalla la información de un registro seleccionado, con la finalidad de que sea modificado (Ver Figura 3).

Basado en Estándar IEEE Std 1063-2001

6

Consultar: da la opción de buscar Información en las tablas a las se quiere tener acceso (Ver Figura 4).

Mostrar: muestra la información de un registro almacenado y que se selecciona para verlo completo (Ver Figura 5).

Desplegar vista: se usa para ver los documentos de manera digital en la aplicación (Ver Figura 6).

Mostrar PDF: muestra en la pantalla el documento en formato PDF (Ver Figura 7).

Filtro: esta operación permite a los usuarios realizar filtros en el momento de hacer consultas (Ver Figura 8).

Salir: perite salir de la aplicación cuando el usuario así lo quiera (Ver Figura 9).

Prototipos Funcionales

FIGURA 1. Ingresar

Fuente: Elaboración propia

Basado en Estándar IEEE Std 1063-2001

7

FIGURA 2. Guardar

Fuente: Elaboración propia

FIGURA 3. Editar

Fuente: Elaboración propia

FIGURA 4. Consultar

Fuente: Elaboración propia

Basado en Estándar IEEE Std 1063-2001

8

FIGURA 5. Mostrar

Fuente: Elaboración propia

FIGURA 6. Desplegar Vista

Fuente: Elaboración propia

FIGURA 7. Consultar PDF

Fuente: Elaboración propia

Basado en Estándar IEEE Std 1063-2001

9

FIGURA 8. Filtro

Fuente: Elaboración propia

FIGURA 9. Salir

Fuente: Elaboración propia Operaciones relacionadas con el ciclo de vida del documento:

Basado en Estándar IEEE Std 1063-2001

10

FIGURA 10. Procesos del Ciclo de Vida del Documento

Fuente: Elaboración propia

Recepción de Documentos: hace referencia a la acción de recibir los documentos en un área, provenientes de otra o de una entidad externa, incluye subprocesos como:

o Tamizaje.

o Radicación.

o Digitalización

FIGURA 11. Radicación

Fuente: Elaboración propia

Basado en Estándar IEEE Std 1063-2001

11

FIGURA 12. Creación de Expediente

Fuente: Elaboración propia

FIGURA 13. Creación del Documento en el sistema

Fuente: Elaboración propia

Distribución de Documentos: este proceso incluye la entrega y transferencia de documentos entre áreas o a entidad externa, incluye subprocesos:

o Entrega o Envío de Documento.

o Establecer ruta.

o Realizar transferencia

Botón para

adjuntar archivo

digitalizado

Basado en Estándar IEEE Std 1063-2001

12

o Generar solicitud de trámite.

FIGURA 14. Distribuir documento

Fuente: Elaboración propia

Trámite de Documentos: en este proceso se lleva a cabo la acción requerida por el documento recibido, del cual puede desprenderse otros procesos como la creación de un nuevo documento que se anexará al expediente. Incluye subprocesos:

o Aceptar y Recibir.

o Respuesta o Solución.

o Genera Solicitud de Préstamo.

o Solicitud de Consulta.

Producción de Documentos: este proceso me permite crear un nuevo documento que se vinculará a un expediente o que hará parte de un expediente nuevo, este documento se vinculara a las tablas de retención documental y hará parte del archivo de gestión, Central e Histórico si así lo determinan las mismas. Para este proceso se realizaran los subprocesos:

o Seleccionar Tipo de Documento.

Basado en Estándar IEEE Std 1063-2001

13

o Ingresar Información.

o Generar Documento (Subir documento digitalizado en nuestro caso).

o Vincular a expediente.

o Entrega.

FIGURA 15. Crear Documento

Fuente: Elaboración propia

Organización de Documentos: este proceso hace referencia a la vinculación del documento a las tablas de retención documental clasificando su serie y subserie a la que pertenece, ubicación y organización física en el archivo según lo establezca la tabla de retención documental teniendo en cuenta el principio de procedencia, fechas, si es público, privado etc.

FIGURA 16. Organizar Documento

Fuente: Elaboración propia

Basado en Estándar IEEE Std 1063-2001

14

Consulta de Documentos: En caso de res requerido para dar trámite a un requerimiento, se pueden hacer consultas de nuestros documentos al archivo de gestión, central o histórico según sea el caso, tiempo, disponibilidad e importancia del documento, según lo establezcan las tablas de retención documental. Este proceso abarca los subprocesos:

o Recibir solicitud de consulta.

o Generación de Catálogos.

o Realizar acción de consulta solicitada.

o Control y préstamo de documento.

FIGURA 17. Consulta y Visualización de Documentos

Fuente: Elaboración propia

Conservación de Documentos: se refiere a las acciones que permiten que el documento físico se conserve en buen estado, incluye técnicas para arreglar daños que se presenten, en este caso se deberá guardar la información de cambios que se realicen y que se deriven de dichas técnicas.

Basado en Estándar IEEE Std 1063-2001

15

FIGURA 18. Conservación de Documentos

Fuente: Elaboración propia

Disposición Final de Documento: una vez cumplido el tiempo máximo establecido en las tablas de retención documental y dependiendo de la clasificación e importancia del documento se realizan los siguientes subprocesos:

o Inventario de documentos.

o Digitalización de lo que no estuviera digitalizado o microfilmación.

o Proceso de eliminación o almacenamiento como Histórico.

FIGURA 19. Disposición Final

Fuente: Elaboración propia

Basado en Estándar IEEE Std 1063-2001

16

A continuación se muestra el diagrama de flujo de los procesos del ciclo de vida del documento, para dar al lector una mejor ilustración del proceso de gestión documental, lo que ayuda a que se pueda dar un manejo optimo al sistema de información:

FIGURA 20. Diagrama de flujo del ciclo de vida del documento

Fuente: Elaboración propia

4. INFORMACIÓN SOBRE LOS COMANDOS DE SOFTWARE

SIMAGED permite utilizar los comandos generales para el manejo de portapapeles, como Copiar CRTL + C, Pegar CRTL + V, también los que permite manejar el navegador como Actualizar F5, Cambiar zoom CRTL + SCROLL MOUSE UP o CRTL + SCROLL MOUSE DOWN.

5. MENSAJES DE ERROR Y RESOLUCIÓN DE PROBLEMAS

El sistema cuenta con mensajes que indican al usuario sobre problemas que se pueden ocasionar en un proceso, indicando si hace falta llenar un campo o si el formato ingresado está mal, si las características de los datos corresponden, etc.

Basado en Estándar IEEE Std 1063-2001

17

La resolución de problemas en indicada dentro del error, por ej. (Ver la siguiente Figura)

FIGURA 21. Mensajes de error y resolución de problemas

Fuente: Elaboración propia

6. CARACTERÍSTICAS DE NAVEGACIÓN

Por ser un sistema de información en entorno web, la navegación dentro del sistema se da a través de links, cada menú contiene links que envían al usuario al módulo correspondiente, adicional también se pueden usar las opciones de navegación propias del navegador web.

FIGURA 22. Navegación

Fuente: Elaboración propia

Menús