🦄💫4° SEM32 WORD PLANEACIÓN PROYECTOS DARUKEL 23-24.docx
Proyecto De Grado
1. FUNDACION UNIVERSITARIA TECNOLOGICO COMFENALCO
FACULTAD DE INGENIERIA DE SISTEMAS
PROGRAMA DE TECNOLOGIA EN SISTEMAS DE INFORMACION
CARTAGENA DE INDIAS D.T. y C
PROYECTO DE GRADO
SOFTWARE PARA LA ORGANIZACIÓN, REGISTRO,
CONTROL Y BUSQUEDA DE DOCUMENTOS EN LA
EMPRESA INFOGESTION LTDA
DAVID NAVARRO MORA JOSE LUIS MORA VILLADIEGO
LINA VICTORIA MATOSO GALAN ED LEWIS LEVER PION
2009
2. SOFTWARE PARA LA ORGANIZACIÓN, REGISTRO, CONTROL Y
BUSQUEDA DE ARCHIVOS EN LA EMPRESA INFOGESTION LTDA
DAVID NAVARRO MORA
JOSE LUIS MORA VILLADIEGO
LINA VICTORIA MATOSO GALAN
ED LEWIS LEVER PION
FUNDACION UNIVERSITARIA TECNOLOGICO COMFENALCO
FACULTAD DE INGENIERIA DE SISTEMAS
PROGRAMA DE TECNOLOGIA EN SISTEMAS DE INFORMACION
CARTAGENA DE INDIAS D.T. y C
JUNIO 2009
2
3. SOFTWARE PARA LA ORGANIZACIÓN, REGISTRO, CONTROL Y
BUSQUEDA DE ARCHIVOS EN LA EMPRESA INFOGESTION LTDA
DAVID NAVARRO MORA
JOSE LUIS MORA VILLADIEGO
LINA VICTORIA MATOSO GALAN
ED LEWIS LEVER PION
PROYECTO DE GRADO
PRESENTADO A
COLECTIVO DE DOCENTES
FUNDACION UNIVERSITARIA TECNOLOGICO COMFENALCO
FACULTAD DE INGENIERIA DE SISTEMAS
PROGRAMA DE TECNOLOGIA EN SISTEMAS DE INFORMACION
CARTAGENA DE INDIAS D. T. y C
JUNIO 2009
3
5. SOFTWARE PARA LA ORGANIZACIÓN,
REGISTRO, CONTROL Y BUSQUEDA DE
DOCUMENTOS EN LA EMPRESA
INFOGESTION LTDA
5
6. CONTENIDO
PRESENTACION ....................................................................................................................... 8
PLANTEAMIENTO DEL PROBLEMA ................................................................................... 10
DESCRIPCION DEL PROBLEMA ..................................................................................... 10
FORMULACION ................................................................................................................... 13
OBJETIVOS .......................................................................................................................... 14
General............................................................................................................................... 14
Específicos ........................................................................................................................ 14
JUSTIFICACION................................................................................................................... 16
MARCO TEORICO................................................................................................................... 18
DISEÑO METODOLÒGICO ................................................................................................... 27
METODOLOGÍA ................................................................................................................... 27
Tipo de Investigación ....................................................................................................... 27
Técnicas e Instrumentos ................................................................................................. 28
PROCEDIMIENTO ............................................................................................................... 28
ESTUDIO DE VIABILIDAD ..................................................................................................... 29
FACTIBILIDAD ...................................................................................................................... 29
ALTERNATIVAS ................................................................................................................... 30
DESCRIPCIÓN DE PROCESOS DE NEGOCIO ................................................................ 31
ALCANCE DEL PROYECTO.................................................................................................. 32
DESCRIPCION DE STAKEHOLDER.................................................................................... 33
SPONSOR ............................................................................................................................. 33
USUARIOS ............................................................................................................................ 33
DESARROLLADORES ........................................................................................................ 34
FUENTES DE REQUERIMIENTO ..................................................................................... 35
REQUERIMIENTOS ................................................................................................................ 36
REQUERIMIENTOS FUNCIONALES ............................................................................... 36
REQUERIMIENTOS NO FUNCIONALES ........................................................................ 39
PRESENTACIÓN E INTERPRETACIÓN DE DATOS ........................................................ 40
DEMOGRAFIA DE ACTORES ........................................................................................... 40
DESCRIPCION DE ENTIDADES DE NEGOCIO ............................................................ 41
INVENTARIO DE CASOS DE USO .................................................................................. 42
MODELO FUNCIONAL ....................................................................................................... 44
DIAGRAMAS DE CASOS DE USO ............................................................................... 44
6
7. DESCRIPCION DE CASOS DE USO ........................................................................... 47
MODELO ESTATICO ESTRUCTURAL ............................................................................ 58
DIAGRAMA DE CLASES ................................................................................................ 58
MODELO RELACIONAL (BASE DE DATOS) ................................................................. 59
MODELO DINAMICO .......................................................................................................... 60
DIAGRAMA DE ACTIVIDADES ..................................................................................... 60
CONCLUSIONES ..................................................................................................................... 62
BIBLIOGRAFIA ......................................................................................................................... 63
7
8. PRESENTACION
Tomando como base que el manejo documental es una situación de orden no
controlado que se presenta en la gran mayoría de las empresas cuyo archivo
físico se ve agobiado por el total de documentos generados durante vigencias
enteras, esta investigación propone una solución desde el punto de vista
tecnológico, usando como herramienta principal un sistema de computo, y un
software con una interfaz grafica agradable a la hora de su uso.
Desde el momento en que comienzan a generarse archivos físicos sin ningún
control dentro de la empresa, comienza también a crearse una dificultad que
dentro del tiempo en que lleva funcionando INFOGESTION, se ha convertido
en un problema que viene siendo manejando con diferentes políticas, criterios y
disposiciones, no concordantes, sin ninguna relación entre ella y que solo ha
contribuido a agilizar el caos documental. Cada vez que por algún motivo se
genera un cambio en la administración de la empresa, se generan también
cambios en la forma como se procesan, archiva y se da seguimiento a los
documentos. Nunca antes se ha intentado implementar una solución
sistematizada que permita los cambios de personal y disposiciones y que al
mismo tiempo exija que se respeten las normas previamente establecidas para
su óptimo funcionamiento.
En consultas realizadas dentro de La Fundación Universitaria Tecnológico
Comfenalco, no se encontraron registros de soluciones a problemas de este
tipo, por lo que se puede decir, que este proyecto es pionero dentro de la
institución con relación a problemáticas de gestión y control de documentos.
Hay que tener en cuenta que cada uno de los documentos existentes dentro de
la empresa, es una ventana abierta con información muchas veces
confidencial, y que no puede ser vista por cualquier persona. Es por esto que
es tan importante el control absoluto sobre los documentos, tener facilidad para
accesarlos y al mismo tiempo ejercer el control sobre las personas que tienen
acceso a estos.
8
9. Con esta idea se crea una herramienta capaz de brindar una solución a esta
situación de orden, dándole al usuario un esquema o procedimiento a seguir
con el fin de organizar, archivar y acceder con facilidad a la documentación
empresarial.
9
10. PLANTEAMIENTO DEL PROBLEMA
DESCRIPCION DEL PROBLEMA
INFOGESTION LTDA., es una empresa de servicios con más de 10 años
dedicada a la implantación, outsourcing y soporte de soluciones de tecnología
informática, orientadas a apoyar la estrategia de negocio de sus clientes,
ubicada en Boca grande carrera 6 calle 3. La empresa está conformada por
una Gerencia que recibe el apoyo de un Asesor financiero y un Asesor Jurídico.
También cuenta con una Asistente Administrativa y una Coordinadora para las
actividades del Sistema de Gestión de Calidad, que le permite llevar a cabo de
manera exitosa, sus funciones administrativas. El manejo de documentos,
representa para la empresa, innumerables situaciones que no son las más
adecuadas.
En términos generales, existe un problema de dificultad y costo del acceso a
los documentos que maneja la organización y el riesgo de pérdida de estos.
Desde el momento en que se genera o se recibe un documento hasta su
archivador se hace necesario ejercer un control total sobre los mismos.
Como no hay un control cuando se recibe un archivo, a la hora de buscarlo, el
trabajo se hace bastante tedioso porque no se sabe en realidad donde esta o
quien lo tiene debido a que no hay un control del documento. Solo están allí
pero no se sabe cuál es ni de donde salió. Esto genera una pérdida de tiempo
y una falta de respeto ante una persona que llegue preguntando por algún
documento.
Las posibles causas de esta situación están básicamente resumidas en que no
existe un criterio de archivo que se haya establecido. Cada usuario del
10
11. documento genera su propia forma de guardar lo que imposibilita una buena
búsqueda. La no existencia de un registro y un control sobre los diferentes
archivos de la empresa, generan una serie de consecuencias, entre las cuales
se destacar las siguientes:
Para el almacenaje de documentos físicos, se cuenta con archivadores
verticales de 4 gavetas que hoy en día no son suficientes para almacenar el
volumen de documentos generados.
Para el manejo y accesibilidad de documentos, así como problemas de
deterioro de documentos debido a las condiciones a las que han estado
expuestos.
Un mismo documento es fotocopiado varias veces dentro de la empresa, se
encuentra en diferentes escritorios. Su flujo en el proceso de negocio
implica no solo el traslado de un área a otra, sino de una oficina a otra e
inclusive de una ciudad a otra. Esto confirma que el manejo de documentos
fiscos implica una consulta lenta e ineficiente, además de altos riesgos
relacionados con el extravió y resguardo de información confidencial.
En otros casos, al consultar un documento no se encuentra y resulta que no
llegó al archivo por haberse quedado en el cajón del escritorio de algún
empleado.
Ante una posible Auditoría Interna, la búsqueda de un documento en esta
situación, conlleva a una No Conformidad mayor.
Han transcurrido más de 10 años y ya existe un problema que ha detenido
el proceso de Certificación de Calidad. Esperar más tiempo generaría una
pérdida de tiempo y dinero en cuanto a la certificación.
Para evitar que estas situaciones se sigan presentando, es necesario buscar
una alternativa que presente soluciones concretas a cada uno de los
inconvenientes generados por la falta de control. Es por esto que a través este
proyecto se presentara una solución detallada que responde a cada una de las
necesidades anteriormente planteadas. Esta solución propiamente dicha, es la
11
12. implementación de un software a medida, diseñado partiendo de los
requerimientos de una situación pero aplicado a estándares internacionales.
12
14. OBJETIVOS
General
Desarrollar y construir un software que optimice los procesos de registro,
búsqueda y control de documentos en la empresa INFOGESTION Ltda.
Específicos
De investigación
Conocer a fondo las necesidades de organización documental que una
empresa como INFOGESTION LTDA, puede estar generando en el uso
inadecuado de los documentos.
Metodológicos
Analizar procesos relacionados con el registro, control y búsqueda de archivos
a través de entrevistas y observaciones para poder identificar correctamente la
situación problemica y poder justificar el diseño del proyecto.
Establecer pautas de organización documental dentro de la empresa que
permitan la retroalimentación de la base de datos.
Técnicos
Identificar los requerimientos del sistema para interpretar el entorno problemico.
14
15. Diseñar los modelos informáticos que permitan presentar y comprender cada
uno de los procesos que conforman el sistema y sus requerimientos.
Construir un prototipo que permita representar los servicios y funciones que el
sistema ofrece a sus usuarios con el fin de validar y aprobar los requerimientos
del sistema.
15
16. JUSTIFICACION
El orden y concordancia de los documentos, sus secuencias, su disponibilidad
y la prontitud para accesarlos, editarlos o simplemente revisarlos, se ha
convertido en una de las prioridades que las empresas grandes y pequeñas
tienen como objetivo dentro del funcionamiento de las mismas. Para alcanzar
una certificación ISO en cualquiera de sus modalidades, uno de los aspectos
más relevantes es el orden y disponibilidad del archivo documental.
INFOGESTIÓN Ltda. Es una mediana empresa que busca, dentro de sus
objetivos a corto plazo, una organización documental sistematizada que le
permita acelerar el proceso de certificación ante ICONTEC. Actualmente no
cuenta con un software ni con un proceso implementado que les facilite llevar a
cabo esta organización.
La consulta constante de los “DEBE” de la Norma ISO 9000, fundamental en la
implementación de un proceso de gestión documental, abren nuevos
conocimientos sobre el manejo óptimo de un archivo empresarial;
conocimientos que son aplicables en forma directa dentro de otros ambientes
diferentes a los de INFOGESTION Ltda. Y que permitirán personalizar, de
acuerdo a las necesidades, el programa resultante de esta investigación.
Este proyecto tiene tres pilares fundamentales para las personas que lo están
desarrollando, basados en los parámetros y principios de la institución donde
se está llevando a cabo. Estos pilares son: Investigación, Desarrollo de un
proyecto de software y Desarrollo y programación de un software.
Como beneficiario en este proyecto, se encuentran en el mismo orden:
INFOGESTION LTDA, que es la empresa sobre la cual se está llevando a cabo
este proyecto, las personas desarrolladoras de este trabajo (Estudiantes: David
Navarro Mora, José Luis Mora Villadiego, Lina Victoria Matoso Galán) y por
16
17. último, la Fundación Universitaria Tecnológico Comfenalco, que es aquella que
provee los conocimientos y da las pautas a los desarrolladores para que estos
puedan llevar a cabo la investigación correspondiente.
17
18. MARCO TEORICO
Dada que toda investigación tiene un propósito llamado solución, esta, no se
daría a plenitud o parcial si el investigador buscara referencias o conceptos
anteriores frente a su problema en nuestro caso los conceptos que hemos
abstraído para desarrollar nuestra solución plena o parcial frente al problema
dado son los siguientes divididos así en disciplinares (análisis de requerimiento,
ingeniería de requisitos, estudio de viabilidad, requerimientos funcionales y no
funcionales, diagrama de casos de usos, descripción de casos de usos,
metodología del desarrollo de software, procesos del desarrollo de software,
metodología del proceso del desarrollo de software, procesos del desarrollo del
software) y temáticos (documentos, archivos, gestión documental), los
primeros son los conceptos bases para desarrollar nuestra solución, los últimos
son los conceptos del espacio o entorno en el cual vamos a investigar.
En el ámbito de la informática y los sistemas de información basada en
aplicativos y sistemas software existe un mundo de necesidades y
requerimientos por solucionar, por tal motivo existen pasos para el desarrollo
de un sistema software.
En esto procesos existen conceptos que denotan los intereses a resolver como
los siguientes a tratar.
El requerimiento se define como “condición o capacidad que un usuario
necesita para poder resolver un problema o lograr un objetivo (Instituto of
Eléctrica and Electrónicos Engieres o IEEE), condición o capacidad que debe
exhibir o poseer un sistema para satisfacer un contrato, estándar,
especificación, u otra documentación formalmente impuesta (IEEE). Una
condición o capacidad que debe ser conformada por el sistema (RUP). Algo
18
19. que el sistema debe hacer o una cualidad que el sistema debe poseer
(Robertson - Robertson)”1.
Entonces entendemos por análisis de requerimiento todo el proceso y análisis
que se le hace a las condiciones que da un usuario, con relación a esto existe
la ingeniería de requisitos la cual hace parte del análisis de requerimiento, el
IEEE define requisito como condición o aptitud necesaria para resolver un
problema o alcanzar un objetivo. Este concepto se ve reflejado en la ingeniería
de requisitos lo cual se define por el IEEE como proceso de estudio y
refinamiento de un sistema, aquí entrar todas las formas de recolección de
información para adaptarla a los requerimientos y requisitos del sistema y
usuario. Luego de esto se definen los requisitos del sistema o mejor los
requisitos funcionales los cuales se definen y relacionan con los no funcionales
como “comportamiento interno del software: cálculos, detalles técnicos,
manipulación de datos y otras funcionalidades específicas que muestran cómo
los casos de uso serán llevados a la práctica. Son complementados por los
requerimientos no funcionales, que se enfocan en cambio en el diseño o la
implementación.”2
Después de haber investigado y referenciado y examinado fuentes y tener fijos
los requisitos y requerimientos del problema, se llega al punto del estudio de la
viabilidad la cual es la “condición que hace posible el funcionamiento del
sistema, proyecto o idea al que califica, atendiendo a sus características
tecnológicas y a las leyes de la naturaleza involucradas.”3
1
Wikimedia Foundation, Inc. (2 de Octubre de 2008). www.wikipedia.org. Recuperado el 5 de
Octubre de 2008, de http://es.wikipedia.org/wiki/Empresa
2
Wikimedia Foundation, Inc. (2 de Octubre de 2008). www.wikipedia.org. Recuperado el 5 de
Octubre de 2008, de http://es.wikipedia.org/wiki/Empresa
3
Wikimedia Foundation, Inc. (2 de Octubre de 2008). www.wikipedia.org. Recuperado el 5 de
Octubre de 2008, de http://es.wikipedia.org/wiki/Empresa
19
20. Este estudio debe ser en el ámbito legal, económico y de la empresa para su
validación, este paso dice en pocas palabras si se hace o no el proyecto en
este caso el software. Como se dijo antes en este punto el proyecto es decisivo
en su terminación, luego de una viabilidad aceptada en todos los aspectos
antes mencionados viene el paso de un lenguaje técnico a uno casto
entendible por el usuario de lo que va a hacer el software, en pocas palabras
un manual de usuario que comprenden los casos de usos sus descripciones
previas, un caso de uso es “una técnica para la captura de requisitos
potenciales de un nuevo sistema o una actualización de software. Cada caso
de uso proporciona uno o más escenarios que indican cómo debería interactuar
el sistema con el usuario o con otro sistema para conseguir un objetivo
específico. Normalmente, en los casos de usos se evita el empleo de jergas
técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final.
En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el
desarrollo de casos de uso”.4 Estos se representan por medio de diagramas
que facilitan la lectura de usuario y la traducción del lenguaje técnico para esto
los casos de usos se complementa con la descripción de los casos de usos ,
que o es más que el simple proceso o procedimiento que hace el caso de uso
entre el sistema y el usuario.
Los anteriores conceptos dados por pasos pueden ser rígidos sin una
metodología del desarrollo de software, Cuando los proyectos que se van a
desarrollar son de mayor envergadura, ahí si toma sentido el basarnos en una
metodología de desarrollo, y empezamos a buscar cual sería la más apropiada
4
Wikimedia Foundation, Inc. (2 de Octubre de 2008). www.wikipedia.org. Recuperado el 5 de
Octubre de 2008, de http://es.wikipedia.org/wiki/Empresa
20
21. para nuestro caso. Lo cierto es que muchas veces no encontramos la más
adecuada y terminamos por hacer o diseñar nuestra propia metodología, algo
que por supuesto no está mal, siempre y cuando cumpla con el objetivo.
Muchas veces realizamos el diseño de nuestro software de manera rígida, con
los requerimientos que el cliente nos solicitó, de tal manera que cuando el
cliente en la etapa final (etapa de prueba), solicita un cambio se nos hace muy
difícil realizarlo, pues si lo hacemos, altera muchas cosas que no habíamos
previsto, y es justo éste, uno de los factores que ocasiona un atraso en el
proyecto y por tanto la incomodidad del desarrollador por no cumplir con el
cambio solicitado y el malestar por parte del cliente por no tomar en cuenta su
pedido. Obviamente para evitar estos incidentes debemos haber llegado a un
acuerdo formal con el cliente, al inicio del proyecto, de tal manera que cada
cambio o modificación no perjudique al desarrollo del mismo.
Por experiencia, muchas veces los usuarios finales, se dan cuenta de las cosas
que dejaron de mencionar, recién en la etapa final del proyecto, pese a que se
les mostró un prototipo del software en la etapa inicial del proyecto.
Los proyectos en problemas son los que salen del presupuesto, tienen
importantes retrasos, o simplemente no cumplen con las expectativas del
cliente.
Una de las metodologías más importantes son: RUP, XP y MSF.
El RUP “La metodología RUP, llamada así por sus siglas en inglés Racional
Iniciad Procesos, divide en 4 fases el desarrollo del software:
Inicio, El Objetivo en esta etapa es determinar la visión del proyecto.
Elaboración, En esta etapa el objetivo es determinar la arquitectura óptima.
21
22. Construcción, En esta etapa el objetivo es llevar a obtener la capacidad
operacional inicial.
Transmisión, El objetivo es llegar a obtener el reléase del proyecto.
Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la
cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los
Objetivos de una iteración se establecen en función de la evaluación de las
iteraciones precedentes”.5
El XP, Extreme Programing: “Es una de las metodologías de desarrollo de
software más exitosas en la actualidad utilizadas para proyectos de corto plazo,
corto equipo y cuyo plazo de entrega era ayer. La metodología consiste en una
programación rápida o extrema, cuya particularidad es tener como parte del
equipo, al usuario final, pues es uno de los requisitos para llegar al éxito del
proyecto”6.
En conclusión para estas dos metodologías, la metodología RUP es más
adaptable para proyectos de largo plazo y la metodología XP en cambio, se
recomienda para proyectos de corto plazo.
Luego de definir conceptos disciplinarios pasamos a los temáticos que abarcan
el espacio en el cual se va a investigar, comenzaremos desde un ámbito
general a o particular, los conceptos del problema que nos interesan.
5
Wikimedia Foundation, Inc. (2 de Octubre de 2008). www.wikipedia.org. Recuperado el 5 de
Octubre de 2008, de http://es.wikipedia.org/wiki/Empresa
6
Wikimedia Foundation, Inc. (2 de Octubre de 2008). www.wikipedia.org. Recuperado el 5 de
Octubre de 2008, de http://es.wikipedia.org/wiki/Empresa
22
23. Por empresa al “organismo social integrado por elementos humanos, técnicos
y materiales cuyo objetivo natural y principal es la obtención de utilidades, o
bien, la prestación de servicios a la comunidad, coordinados por un
administrador que toma decisiones en forma oportuna para la consecución de
los objetivos para los que fueron creadas. Para cumplir con este objetivo la
empresa combina naturaleza y capital”7.
Entendido lo que es una empresa tomaremos el camino a nuestro problema a
tratar que es la gestión de información documentada o la gestión documental,
definamos documento como “es el testimonio material de un hecho o acto
realizado en el ejercicio de sus funciones por instituciones o personas físicas,
jurídicas, públicas o privadas, registrado en una unidad de información en
cualquier tipo de soporte (papel, cintas, discos magnéticos, películas,
fotografías, etcétera) en lenguaje natural o convencional. Es el testimonio de
una actividad del hombre fijado en un soporte”8. Este es nuestro concepto más
importante a tratar en nuestra investigación ya que nos genera una gestión
documental que debe ser administrada por el sistema, definimos entonces
gestión documental como “el conjunto de normas, técnicas y prácticas usadas
para administrar el flujo de documentos de todo tipo en una organización,
permitir la recuperación de información desde ellos, 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”9.
Plantados y entendidos los conceptos disciplinares y temáticos que refleja la
investigación de la gestión de documentos y la creación de un software que
7
Wikimedia Foundation, Inc. (2 de Octubre de 2008). www.wikipedia.org. Recuperado el 5 de
Octubre de 2008, de http://es.wikipedia.org/wiki/Empresa
8
Wikimedia Foundation, Inc. (2 de Octubre de 2008). www.wikipedia.org. Recuperado el 5 de
Octubre de 2008, de http://es.wikipedia.org/wiki/Documento
9
Wikimedia Foundation, Inc. (2 de Octubre de 2008). www.wikipedia.org. Recuperado el 5 de
Octubre de 2008, de http://es.wikipedia.org/wiki/Gesti%C3%B3n_documental
23
24. aplique estas características, concluimos que solo se dará solución a una parte
de nuestro entorno o espacio de investigación que es la empresa.
Actualmente en la ingeniería de sistemas y en el desarrollo de de software se
están utilizando patrones de abstracción de problemas como son la
programación orientada a objetos el análisis y desarrollo orientados a objetos
es un dato en común en la actualidad es un “enfoque de la ingeniería de
software que modela un sistema como un grupo de objetos que interactúan
entre sí. Este enfoque representa un dominio en términos de conceptos
compuestos por verbos y sustantivos, clasificados de acuerdo a su
dependencia funcional.
En éste método de análisis y diseño se crea un conjunto de modelos utilizando
una notación acordada como, por ejemplo, el lenguaje unificado de modelado
(UML). ADOO aplica técnicas de modelado de objetos para analizar los
requerimientos para un contexto por ejemplo, un sistema de negocio, un
conjunto de módulos de software y para diseñar una solución para mejorar los
procesos involucrados. No está restringido al diseño de programas de
computadora, sino que cubre sistemas enteros de distinto tipo. Las
metodologías de análisis y diseño más modernas son casos de uso guiados a
través de requerimientos, diseño, implementación, pruebas, y despliegue. El
lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estándar
usado en análisis y diseño orientado a objetos.”10
“La arquitectura de software, tiene que ver con el diseño y la implementación
de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto
número de elementos arquitectónicos de forma adecuada para satisfacer la
mayor funcionalidad y requerimientos de desempeño de un sistema, así como
requerimientos no funcionales, como la confiabilidad, escalabilidad,
11
portabilidad, y disponibilidad” . De tal modo se tiene que implementar una
10
Wikimedia Foundation, Inc. (2 de Octubre de 2008). www.wikipedia.org. Recuperado el 20
de Octubre de 2008, de
http://es.wikipedia.org/wiki/An%C3%A1lisis_y_dise%C3%B1o_orientado_a_objetos
11
Kruchten, Philippe
24
25. arquitectura novedosa y robusta para nuestra aplicación dicha arquitectura es
la MVC (Modelo vista controlador), “es un patrón de arquitectura de software
que separa los datos de una aplicación, la interfaz de usuario, y la lógica de
control en tres componentes distintos. El patrón MVC se ve frecuentemente en
aplicaciones web, donde la vista es la página HTML y el código que provee de
datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de
Datos y la Lógica de negocio, y el controlador es el responsable de recibir los
eventos de entrada desde la vista”12.
Siendo que los datos se expresan en un modelo, y que su pertinencia
necesitamos una base de datos que se define como “banco de datos (en
inglés: database) es un conjunto de datos pertenecientes a un mismo contexto
y almacenados sistemáticamente para su posterior uso. En este sentido, una
biblioteca puede considerarse una base de datos compuesta en su mayoría por
documentos y textos impresos en papel e indexados para su consulta. En la
actualidad, y debido al desarrollo tecnológico de campos como la informática y
la electrónica, la mayoría de las bases de datos están en formato digital
(electrónico), que ofrece un amplio rango de soluciones al problema de
almacenar datos”13. La pertinencia de esos datos se debe modelar para llegar
a una relación entre datos los datos para que se puedan ver como una
información coherente, entonces hablamos de un modelo relacional definido
como “En este modelo todos los datos son almacenados en relaciones, y como
cada relación es un conjunto de datos, el orden en el que estos se almacenen
no tiene mayor relevancia (a diferencia de otros modelos como el jerárquico y
el de red). Esto tiene la considerable ventaja de que es más fácil de entender y
de utilizar por un usuario no experto. La información puede ser recuperada o
almacenada por medio de «consultas» que ofrecen una amplia flexibilidad y
poder para administrar la información.
12
Wikimedia Foundation, Inc. (13 mayo 2009.). www.wikipedia.org. Recuperado 24 de Mayo de
2009, de http://es.wikipedia.org/wiki/Modelo_Vista_Controlador
13
Wikimedia Foundation, Inc. (13 mayo 2009.). www.wikipedia.org. Recuperado 24 de Mayo de
2009, de http://es.wikipedia.org/wiki/Base_de_datos
25
26. Este modelo considera la base de datos como una colección de relaciones. De
manera simple, una relación representa una tabla que no es más que un
conjunto de filas, cada fila es un conjunto de campos y cada campo representa
un valor que interpretado describe el mundo real. Cada fila también se puede
denominar tupla o registro y a cada columna también se le puede llamar campo
o atributo.
Para manipular la información utilizamos un lenguaje relacional, actualmente se
cuenta con dos lenguajes formales el Álgebra relacional y el Cálculo relacional.
El Álgebra relacional permite describir la forma de realizar una consulta, en
cambio, el Cálculo relacional sólo indica lo que se desea devolver.
El lenguaje más común para construir las consultas a bases de datos
relacionales es SQL, Structured Query Language o Lenguaje Estructurado de
Consultas, un estándar implementado por los principales motores o sistemas
de gestión de bases de datos relacionales”14.
14
Wikimedia Foundation, Inc. (13 mayo 2009.). www.wikipedia.org. Recuperado 24 de Mayo de
2009, de http://es.wikipedia.org/wiki/Modelo_relacional
26
27. DISEÑO METODOLÒGICO
METODOLOGÍA
Para la gestión documental, el nivel de estudio en este documento serán
exploratorios; ya que el tema de gestión documental por sistemas informáticos
en la última década no ha sido muy documentado y practicado ya que es un
tema muy extenso, aunque ya se hayan hechos estudios con anterioridad la
gestión documental viene desde los principios de la escritura, y el problema de
organizar y hacer consultas rápidas de un escrito es lo primordial a tratar.
Con este proyecto se una gran parte de la gestión documental en forma
informática rápida y sin daño al medio ambiente, de lo anterior concluimos que
este proyecto servirá como base para otros proyectos venideros del mismo
tema.
Para el nivel de estudio descriptivo, buscaremos las formas de encontrar el
entorno de la problemática, haciendo caracterizaciones de hechos o
situaciones como por ejemplo el préstamo de un documento en la empresa, o
el registro manual y físico que no es eficiente de un documento, como hemos
visto y explicado nuestra investigación está basada en dos niveles de estudio
que son la de exploratoria y descriptiva, aunque no entraremos al tercer nivel
que es el de explicativo ya que en este abundan las teorías y las formas de
gestión documental .
Tipo de Investigación
La tipología de investigación utilizada para desarrollar este proyecto va
encaminada a la observación, ya que en la gestión documental existen
procesos como los préstamos y registros que deben ser de observación y
compresión del comportamiento de la entidad, toda vez que no existe un
27
28. procedimiento documentado sobre la forma cómo se viene realizando esta
actividad. La mayoría de las veces se hace a criterio de la persona que autoriza
el préstamo.
Adicionalmente se utilizarán formas de investigación inductiva y deductiva que
guiarán a los principales procesos que se pueden establecer para el manejo de
los documentos generalizando así la gestión documental en la empresa
INFOGESTION LTDA.
Finalmente y aplicando la investigación de análisis se logrará establecer con
claridad cuáles y cuántos deben ser los pasos a seguir en el esquema de
gestión documental a aplicar en esta empresa.
Técnicas e Instrumentos
Se basa en una entrevista hecha a un funcionario del la empresa, que esté
completamente relacionado con el proceso polémico y la gestión documental, y
observando los procesos de préstamos y registros de documentos, de forma
simple o participante para entender la forma y las molestias al momento de
ejecutar estos procesos manuales.
PROCEDIMIENTO
Para la elaboración del software que plantea este proyecto, se utilizara la
técnica de programación orientada a objetos (POO). Este estilo de
programación, es el más adecuado para este caso ya que a través de el, se
puede abstraer de la realidad, las diferentes entidades de negocio, y
convertirlas en objetos que posteriormente serán la base fundamental del
programa.
28
29. ESTUDIO DE VIABILIDAD
FACTIBILIDAD
La realización de esta investigación, no lleva un recurso económico que
represente mayor problema. Esta parte se ve más marcada a la hora de
implementar el software producto de este proyecto, y cumplir con las
exigencias que este demanda. De igual manera el proyecto tiene el apoyo de la
empresa que está siendo objeto de investigación para la realización de la
misma.
Además, en la parte legal, el proyecto se desenvuelve bajo el parámetro de
software libre lo que quiere decir que se enmarca en normas internacionales ya
establecidas y que son aplicables en Colombia donde no existe una
normatividad acerca de estos.
Como todo procedimiento nuevo, la parte operativa se verá algo complicada al
principio debido a la falta de costumbre y a que es primera vez que el software
se pondrá en marcha. No obstante la misma facilidad de navegación a través
del programa permitirá la fácil adaptación de sus usuarios.
Para el desarrollo del programa, la parte tecnológica es una de las cosas a
favor. Existen disponibles 3 equipos de computo, con muy buenas
características como son gran velocidad en procesador, espacio en memoria
superior o igual a 1GB y suficiente espacio en disco duro como para guardar
toda la información necesaria. Además, estos equipos se encuentran
disponibles las 24 horas del día y los 7 días de la semana.
29
30. ALTERNATIVAS
Existen en el mercado diferentes programas que dan solución a los problemas
de tipo documental, pero la mayoría de ellos no responden a las necesidades
de INFOGESTION. Basado en los requerimientos funcionales obtenidos, se
puede lograr una aplicación que reúna en forma amigable todas las inquietudes
del usuario final.
30
31. DESCRIPCIÓN DE PROCESOS DE NEGOCIO
Llegada de un nuevo documento en la empresa:
Un funcionario interno o ajeno a la empresa hace llegar un documento nuevo,
éste se entrega a la archivadora la cual verifica su estado y pone sus datos en
una planilla y realiza todos los procesos de gestión documental necesarios
antes de archivarlo, luego de esto la archivista le genera un código llamado
consecutivo el cual lo identifica y lo diferencia de los demás documentos,
finalmente se guarda en el gabinete deseado. Ejemplo: el ultimo consecutivo
fue A1AZ3F5P4 este nuevo llevara A1AZ3F5P5 y se pondrá encima de este.
Préstamo de un documento físico en la empresa:
Un funcionario de cualquier dependencia solicita un archivo ya existente en los
gabinetes administrados por la archivista, este funcionario lo busca y se lo
entrega. Luego de que el funcionario solicitante haya terminado de usar este
archivo lo devuelve a la archivista la cual lo pone en la ubicación
correspondiente, si el documento o archivo solicitado por el funcionario al
momento de entregarlo a la archivista viene con otro documento esta engrapa y
agrupa los documentos anexos y pone un solo consecutivo a este grupo y lo
guarda en su lugar.
31
32. ALCANCE DEL PROYECTO
La Gestión Documental no se detiene en la organización de los archivos
físicos, va mucho más allá al pretender que el contenido de éste sea
accequible a todos los usuarios desde cualquier computador conectado al
servidor de la empresa. Con niveles de seguridad previamente establecidos, el
software pretende regular y controlar de manera ordenada la adición,
sustracción, modificación y/o eliminación de registros en la base de datos.
Debe concordar en todo momento con el contenido físico de los archivadores y
el movimiento de los mismos debe ser previamente validado por el software.
Una vez obtenido este control, la base de datos documental crecerá en forma
paralela con la empresa, permitiendo en todo momento un absoluto manejo
organizado y responsable de los documentos.
Mirando hacia el futuro y contando con una plataforma tecnológica dentro de la
empresa que permite la conectividad al servidor vía Internet, se tendrá una
aplicación que permitirá la consulta documental desde cualquier lugar.
32
33. DESCRIPCION DE STAKEHOLDER
SPONSOR
Nombre: INFOGESTION LIMITADA
Dirección: Boca grande, Carrera 3ª. No. 6-24 Local 2
Intereses en el proyecto: Lograr la organización y control de los
documentos empresariales, adicionando una solución que interactúe con los
usuarios.
USUARIOS
Nombre: Federico Mora
Cargo: Gerente General
Empresa: INFOGESTION LTDA
Teléfono: 6434176
Dirección: Boca grande, Carrera 3ª. No. 6-24 Local 2
e-mail: fmora@infogestion.com.co
Funciones para el proyecto: Administrador.
Nombre: Pastora Mora
Cargo: Técnico
Empresa: INFOGESTION LTDA
Teléfono: 6434176
Dirección: Boca grande, Carrera 3ª. No. 6-24 Local 2
e-mail: pmora@infogestion.com.co
Funciones para el proyecto: Administrador, archivista.
Nombre: Rosana Delgado
Cargo: Administradora
Empresa: INFOGESTION LTDA
Teléfono: 6434176
Dirección: Boca grande, Carrera 3ª. No. 6-24 Local 2
33
34. e-mail: rdelgado@infogestion.com.co
Funciones para el proyecto: Usuario, archivista.
Nombre: Evelyn Pérez
Cargo: Asistente de ventas
Empresa: INFOGESTION LTDA
Teléfono: 6434176
Dirección: Boca grande, Carrera 3ª. No. 6-24 Local 2
e-mail: eperez@infogestion.com.co
Funciones para el proyecto: Usuario, archivista.
DESARROLLADORES
Nombre: José Luis Mora Villadiego
Teléfono: 6666983 – 3118020161
Dirección: Lo Amador Cra 19 # 32-13
e-mail: esao0718@hotmail.com
Nombre: Lina Victoria Matoso Galán
Teléfono: 6741804 – 3135774732
Dirección: Camino del Medio calle Visbal 31A-195
e-mail: livimaga@hotmail.com
Nombre: David Navarro Mora
Teléfono: 6437218
Dirección: Pie de la popa calle 29D # 21B59
e-mail: dnavarro@infogestion.com.co
Nombre: Ed. Lewis Lever Pion
Teléfono: 3167646385 - 6447121
Dirección: República de chile Mz 37 Lote 8
e-mail: ellp-05@hotmail.com - ellp-06@hotmail.com
34
35. FUENTES DE REQUERIMIENTO
Nombre: Pastora Mora
Cargo: TÉCNICO
Empresa: INFOGESTION LIMITADA
Teléfono: 6434176
Dirección: Boca grande, Carrera 3ª. No. 6-24 Local 2
e-mail: pmora@infogestion.com.co
Requerimiento: El sistema debe gestionar el nivel de acceso de los
usuarios por medio de perfiles ya sea funcionario o administrador, así como
los procesos y la información relacionada con los documentos tales como
salidas, préstamos y/o entrada de los documentos.
35
36. REQUERIMIENTOS
REQUERIMIENTOS FUNCIONALES
El sistema debe gestionar el nivel de acceso de los usuarios por medio de
perfiles ya sea funcionario o administrador:
Iniciar sesión: Todo usuario debe iniciar sesión para entrar al sistema.
Registrar usuario: solo un administrador tendrá permiso para registrar un
usuario nuevo al sistema.
Consultar usuario: todos los usuarios podrán consultar el perfil de otros
usuarios, pero la información será mostrada dependiendo del nivel de acceso
que tenga, es decir, si es un administrador, serán mostrados todos los datos,
desde el nombre hasta la contraseña de acceso. Pero si es un usuario normal,
solo será mostrado un perfil correspondiente al nombre, apellidos, cargo en la
empresa, e-mail y teléfonos.
Eliminar usuario: solo un administrador tendrá el acceso para eliminar del
sistema a un usuario.
Suspender usuario: solo un administrador, tendrá acceso para suspender por
un tiempo determinado, a un usuario para que este no tenga acceso desde
ningún punto, al sistema.
36
37. El sistema debe gestionar los procesos y la información relacionada con los
documentos:
Registrar documento: Cualquier usuario podrá registrar un documento en el
software, convirtiéndose así en un archivista por un lapso de tiempo.
Consultar documento por características: Cualquier usuario que cumpla el
papel de archivista, podrá consultar los documentos que su nivel de acceso le
permita, además de que este podrá ser consultado por título o nombre,
ubicación, fecha de ingreso, fecha del documento o consecutivo.
Cantidad de documentos prestados: Una persona que accede al sistema en
forma de administrador, tendrá el permiso de ver la cantidad de documentos
prestados en un lapso de tiempo determinado, con el fin de llevar una cuenta o
control sobre la cantidad de documentos activos prestados dentro de la
empresa. Esta consulta mostrara como resultado, no solo la cantidad numérica
de cuantos documentos se prestaron, sino que como añadido, se mostraran los
tipos de documentos y el número de veces que fueron prestados y las
personas que prestaron ese tipo de documento.
El sistema debe gestionar las salida o préstamo y entrada de los documentos
dentro de la empresa.
Registrar préstamo: Cualquier usuario que tenga de acceso a los documentos y
que cumpla el papel de archivista, podrá prestarlos siempre y cuando su nivel
de acceso se lo permita. Este préstamo se debe registrar para llevar un control
de quien tiene el documento, en qué estado se lo llevo y saber cuántos
documentos hay fuera de la empresa, en caso de que este salga.
37
38. Registrar devolución: Cualquier usuario que tenga acceso a los documentos y
que cumpla el papel de archivista, podrá registrar una devolución, siempre y
cuando el documento haya sido prestado en ese departamento. Este registro
se hace con el fin de llevar un control sobre los documentos y saber que
aquellos que han sito prestados, ya regresaron. En la devolución se tendrá en
cuenta la fecha en que llega, el estado y la cantidad de hojas de más o de
menos en el documento.
Consultar préstamos: Cualquier usuario que tenga de acceso a los documentos
y que cumpla el papel de archivista, podrá hacer una consulta de los préstamos
hechos, con el fin de llevar un control sobre estas prestaciones y saber cuáles
son los documentos que más se prestan. Esta consulta no solo arrojara el dato
numérico de los prestamos, sino que también dejara saber de qué tipo son los
documentos, por quienes fueron prestados, en qué fecha se prestaron y en qué
estado se encuentran si devueltos o aun prestados.
Consultar devolución: Cualquier usuario que tenga de acceso a los documentos
y que cumpla el papel de archivista, podrá hacer una consulta de las
devoluciones hechas, con el fin de llevar un control sobre estos retornos. Esta
consulta no solo arrojara el dato numérico de las devoluciones, sino que
también dejara saber de qué tipo son los documentos, por quienes fueron
devueltos y en qué fecha.
Ultimo documento prestado: Cualquier usuario que tenga de acceso a los
documentos ya sea administrador o archivista, podrá consultar el último
documento prestado, con el fin de tener un acceso rápido a este.
38
39. REQUERIMIENTOS NO FUNCIONALES
Gestor de base de datos.
Escáner.
300 Gigabyte mínimo de disco duro.
Conexión a Internet.
Maquina virtual JAVA
39
40. PRESENTACIÓN E INTERPRETACIÓN DE DATOS
DEMOGRAFIA DE ACTORES
Archivista (dor): Persona encargada de manejar el software y archivar los
documentos físicos en su gabinetes, gestionando la información digital de los
documento en el software. Esta puede ser algún administrador, o un usuario
con estos derechos.
Administrador: Usuario que tiene mayor nivel de acceso al sistema, es el
encargado de administrar la gestión de usuarios y ver estadísticas para la toma
de decisiones.
Usuario: Generalización de funcionario, administrador y archivista que puede
tener acceso al software obteniendo un nivel de acceso a la información que
provee el sistema al momento de su registro.
Solicitante: Usuario cualquiera que este registrado en el sistema, que solicita
préstamos de documentos físicos para su óptimo desempeño en la empresa.
40
41. DESCRIPCION DE ENTIDADES DE NEGOCIO
NOMBRE TIPO ATRIBUTO
Departamento Objeto Nombre
Nombre
Archivador Objeto Capacidad
Departamento
Nombre
Gabinete Objeto Capacidad
Archivador
Nombre
Carpeta Objeto Numero de documentos
Gabinete
Nombre
Tipo
Fecha ingreso
Fecha documento
Documento Objeto Descripción
Estado
Folio
Versión
Carpeta
Nombre
Apellido
Nombre de usuario
Contraseña
Usuario Objeto Correo electrónico
Teléfono
Cargo en la empresa
Cargo en el sistema
Estado de actividad
41
42. Fecha préstamo
Objeto, Fecha devolución
Devolución
evento Documento
Solicitante de tipo usuario
INVENTARIO DE CASOS DE USO
El sistema debe gestionar el nivel de acceso de los usuarios por medio
de perfiles ya sea funcionario o administrador
N° Caso de uso Actores Caso de uso relacionado
Usuario
1 Iniciar sesión
2 Registrar Usuario Administrador Consultar usuario
Modificar Usuario
3 Administrador Eliminar usuario
Consultar Usuario Eliminar usuario, modificar
4 Administrador
usuario, suspender usuario.
5 Eliminar Usuario Administrador Consultar usuario.
6 Suspender Usuario Administrador Consultar usuario.
Eliminar usuario, modificar
7 Reporte de Usuario Administrador
usuario, suspender usuario.
Reporte gráficos de
8 Administrador
Usuarios
42
43. El sistema debe gestionar los procesos y la información relacionada con
los documentos
N° Caso de uso Actores Caso de uso relacionado
1 Registrar documento Archivador
2 Modificar Documento Archivador Consultar Documento
3 Eliminar Documento Archivador Consultar Documento
Eliminar Documento,
4 Consultar Documento Archivador
Modificar Documento
Eliminar Documento,
5 Reporte de Documentos Archivador
Modificar Documento
Reporte gráficos de
6 Archivador
Documentos
El sistema debe gestionar las salida o préstamo y entrada de los
documentos dentro de la empresa.
N° Caso de uso Actores Caso de uso
relacionado
1 Registrar préstamo Archivador Consultar documento,
Consultar Usuario
2 Registrar devolución Archivador Consultar Documento,
Consultar Usuario.
3 Consultar Prestamos Archivador Registrar
devolución
4 Historial de Prestamos Archivador
43
47. DESCRIPCION DE CASOS DE USO
El sistema debe gestionar los permisos y la información relacionada con
el usuario.
N° 1
Nombre Iniciar sesión
Objetivo Identificar el nivel de acceso de los usuarios al sistema
Actores Usuario
Precondición Conexión a la base de datos satisfactoria
Que el usuario este registrado en el sistema
Que se haya iniciado el programa
Usuario Sistema
1. Inicia cuando el 2. El sistema despliega una
usuario pide interfaz de usuario para
funcionalidad para iniciar sesión, con dos
iniciar sesión. campos de contraseña y
usuario
3. El usuario, ingresa el 4. El sistema valida si los datos
usuario y la son correctos.
contraseña.
Flujo Ideal
5. El sistema consulta la
existencia del usuario en la
base de datos
6. El sistema aplica los
permisos correspondientes
para dicho usuario.
7. El sistema despliega la
interfaz grafica para dicho
usuario.
8. El sistema despliega la
interfaz grafica para dicho
48. usuario.
1. En el flujo ideal #4 la
validación es errada
1.1. El sistema notifica el
error
1.2. El sistema retorna al
flujo normal #2
Flujo
2. El flujo ideal #5, el sistema
Alternativo
determina que el usuario no
está registrado
2.1. El sistema notifica el
error.
2.2. El sistema retorna al
flujo ideal #2
Pos El sistema guarda un registro de la fecha y hora de la entrada al
condición sistema.
N° 3
Nombre Consultar usuario
Objetivo Ver una información breve del funcionario.
Actores Administrador
Precondición Conexión a la base de datos satisfactoria
Haber iniciado sesión un usuario
Usuario Sistema
1. El usuario pide 2. El sistema despliega una
funcionalidad de interfaz grafica para
consultar usuario consultar usuario.
3. El sistema consulta en
base de datos la
existencia de dicho
usuario
4. El sistema despliega una
48
49. interfaz grafica donde
Flujo Ideal aparecen los siguientes
datos: apellidos, nombres,
nivel de acceso de
funcionario, cargo de
funcionario.
Pos
condición
N° 4
Nombre Modificar usuario
Objetivo Registrar modificaciones en un usuario deseado
Actores Administrador
Precondición Conexión a la base de datos satisfactoria
Haber iniciado sesión un Administrador
Flujo ideal Usuario Sistema
1. El usuario estando 2. El sistema valida si el
en el caso de uso usuario en sesión tiene
#2 pide nivel de accesibilidad de
funcionalidad en administrador
modificar usuario.
3. El sistema despliega una
interfaz grafica para
Flujo ideal modificar
4. El usuario 5. El sistema valida los datos
selecciona los entrantes.
atributos del
usuario que desee
modificar.
6. El sistema actualiza en la
base de datos la nueva
modificación
49
50. 1. En el flujo ideal #5 los
datos no son validos
1.1. El sistema notifica
el error
1.2. El sistema regresa
al flujo de datos ideal #
1
Flujo 2. En el flujo ideal #2 el
Alternativo usuario no tiene un
nivel de acceso de
administrador
2.1. El sistema notifica
los permisos que tiene
tal usuario
2.2. El sistema regresa
al flujo ideal #1
Pos
condición
N° 5
Nombre Eliminar usuario
Objetivo Eliminar del sistema un usuario ya sea por causas no
relacionadas con el sistema sino con la empresa
Actores administrador
Precondición Conexión a la base de datos satisfactoria
Haber iniciado sesión un Administrador
Flujo ideal Usuario Sistema
1. El usuario estando 2. El sistema valida si el
en el caso de uso usuario en sesión tiene
#2 pide nivel de accesibilidad de
funcionalidad en administrador
Flujo Ideal eliminar usuario
50
51. 3. El sistema despliega una
interfaz grafica para
eliminar usuario con los
datos generales del
usuario previamente
consultado para eliminar.
1. En el flujo ideal# 2 el
usuario no tiene nivel de
accesibilidad de
administrador.
1.1. El sistema notifica
Flujo los permisos de
Alternativo accesibilidad del usuario
actualmente en sesión.
1.2. El sistema retorna
al usuario al caso de uso
#2
Pos
condición
51
52. N° 6
Nombre Suspender usuario
Objetivo Dejar inhabilitado a un usuario por un rango de tiempo por
cualquier circunstancia dada previamente
Actores Administrador (p)
Precondición Conexión a la base de datos satisfactoria
Haber iniciado sesión un Administrador
Usuario Sistema
1.El usuario estando en el 2.El sistema verifica si el usuario
caso de uso consultar tenga los permisos de
usuario puede pedir administrador para utilizar este
ejecución a suspender caso de uso
usuario
Flujo Ideal
4.El usuario selecciona el 3.El sistema despliega la interfaz
rango de fecha en que el grafica para suspender usuario
usuario va a hacer
suspendido
5.El sistema deja inhabilitado al
usuario seleccionado como
suspendido por el periodo de fecha
introducido
1.El el flujo ideal #2 el usuario no
tiene el nivel de acceso de
administrador para hacer esta tarea
Flujo
1.1 El sistema notifica los permiso
Alternativo
del usuario actual
1.2 El sistema regresa al flujo ideal
#1
Pos El sistema actualiza los datos y los eventos y estadísticas de la
condición gestión de usuarios.
52
53. El sistema debe gestionar los procesos y la información relacionada con
los documentos.
N° 1
Nombre Registrar documento
Objetivo Registrar un documento.
Actores Archivador (P), Administrador (S)
Precondición Conexión a la base de datos satisfactoria
Haber iniciado sesión como Archivador o Administrador
Usuario Sistema
1 El usuario pide 2 El sistema despliega la interfaz
funcionalidad a registrar grafica para registrar un nuevo
nuevo documento documento
Flujo Ideal 3 El usuario llena los 4 El sistema valida los datos
atributos del nuevo introducidos por el usuario
documento solicitados por la
interfaz grafica dada por el
sistema
5 El sistema guarda en la base de
datos el nuevo documento
1 en el flujo ideal 4 los deditos no
son validos
Flujo
1.1 El sistema muestra el error
Alternativo
1.2 El sistema regresa al flujo ideal
2
Pos El sistema actualiza la base de datos
condición
53
54. N° 2
Nombre Consultar documento
Objetivo Encontrar un documento cualquiera por parámetros de búsqueda
definidos por el usuario
Actores Usuario
Precondición Haber iniciado sesión, tener conexión a la base de datos
Usuario Sistema
1. El usuario pide 2. El sistema despliega una interfaz
funcionalidad a consultar grafica para consultar documentos
documento
3. El usuario llena los 4. El sistema valida los parámetros
parámetros por los cuales introducidos por el usuario
Flujo Ideal
quiere buscar el documento
5. El sistema busca en la base de
datos las posibles documentos
relacionados con los parámetros
que introdujo el usuario
6. El sistema despliega los
documentos en una lista
encontrados en la base de datos
1. En el flujo ideal # 4 los dato no
son validos
1.1 El sistema notifica el error
1.2 el sistema regresa al flujo ideal
#2
Flujo 2. El sistema no encuentra
Alternativo relaciones con los parámetros
introducidos por el usuario
2.1 el sistema notifica no haber
encontrado documentos
relacionados con esos parámetros
2.2 Regresa al flujo ideal #2
54
55. Pos El sistema no hace nada
condición
El sistema debe gestionar las salida o préstamo y entrada de los
documentos dentro de la empresa.
N° 1
Nombre Registrar préstamo
Objetivo Registrar la salida de un documento
Actores Archivador (P), Administrador (S)
Precondición Conexión a la base de datos satisfactoria
Usuario Sistema
1 el usuario pide 2 El sistema despliega la interfaz
funcionalidad para hacer un grafica para registrar los atributos
préstamo del préstamo
3 El usuario mientras hace 4 El sistema hace el mismo
el préstamo pide buscar un proceso de búsqueda que en el
Flujo Ideal
documento caso de uso consultar documento
descrito antes
6 El usuario selecciona el 8 El sistema valida los atributos de
documento que desea préstamo introducidos por el
prestar usuario
7 El usuario termina de 9 El sistema guarda en la base de
llenar los atributos del datos el préstamo y referencia el
préstamo préstamo al usuario
1 Los atributos introducidos no son
validos
Flujo
1.1 El sistema notifica el error
Alternativo
1.2 El sistema regresa al flujo ideal
7
Pos El sistema actualiza la base de datos y la base de préstamos.
condición
55
56. N° 2
Nombre Consultar préstamo
Objetivo Listar los documentos que están prestados
Actores Archivador (P), Administrador
Precondición Conexión a la base de datos satisfactoria
Usuario Sistema
1. El usuario pide consultar 2 .El sistema despliega una interfaz
préstamo grafica donde aparecen atributos
para rellenar y poder relacionar,
mas una opción que lista todo los
prestamos de documentos
3. El usuario registra los 4. El sistema valida los parámetros
Flujo Ideal parámetros introducidos por el usuario
5. El sistema busca en la base de
datos las relaciones de préstamos
con los atributos introducidos por el
usuario
6. El sistema muestra una interfaz
grafica en donde se puede apreciar
los prestamos relacionados con los
parámetros pasados por el usuario
1. En el flujo ideal # 4 los datos no
son correctos
1.1 El sistema notifica el error
1.2 El sistema retorna al flujo ideal
#2
Flujo 2 El sistema no encuentra
Alternativo relaciones de préstamos con los
parámetros introducidos por el
usuario
2.1 El sistema notifica la excepción
2.2 El sistema regresa al flujo ideal
#2
56
57. Pos El sistema no hace nada
condición
N° 3
Nombre Registrar devolución
Objetivo Registrar la devolución de un documento prestado
Actores Archivador (P), Administrador (S)
Precondición Conexión a la base de datos satisfactoria
Usuario Sistema
1 El usuario puede pedir 2 El sistema despliega una interfaz
funcionalidad de registrar grafica donde actualiza el estado
devolución estando en el de préstamo del documento
caso de uso consultar
Flujo Ideal
préstamo
3 El usuario digita los 4 El sistema valida los datos de
parámetros en interfaz entrada
grafica
5 El sistema actualiza el estado de
préstamo del documento
1 En el flujo ideal # 4 los datos son
errados
Flujo
1.1 El sistema notifica el error
Alternativo
1.2 El sistema regresa al flujo ideal
#2
Pos El sistema actualiza los datos en la base de datos
condición
57
62. CONCLUSIONES
De la mano con la tecnología, la administración de una empresa lleva consigo
el manejo óptimo de toda la documentación.
Se hace necesaria la participación de todo el personal de la empresa que de
una u otra forma tenga acceso a los documentos.
La gestión documental requiere en forma inminente un software capaz de
identificar usuarios, niveles de acceso, manejo de la información reportes y
casos de uso, así como ser capaz de retroalimentarse con los nuevos
documentos generados.
El acceso a la información no puede ni debe encontrarse restringido por
distancias ni espacios.
Tan importante como el manejo de la base de datos, lo es el archivo físico
como tal.
62
63. BIBLIOGRAFIA
Wikimedia Foundation, Inc. (2 de Octubre de 2008). www.wikipedia.org.
JOYANES AGUILAR, Louis. Fundamentos de programación, y
estructura de datos, 2 ed., España, Mc Gran Hill Interamericana, c
1998.
De la Hoz, Rita – Manyoma, Enyel. Formatos para proyectos de
investigación
ICONTEC. 4 Septiembre de 2008. www.icontec.org
Tipos de programación. 18 Septiembre de 2008.
http://www.desarrolloweb.com/articulos/2477.php
63