REPUBLICA BOLIVARIANA DE VENEZUELA ......21 Historias de usuario Nº 21 38 22 Tarea Nº 1 39 23 Tarea Nº 2 39 24 Tarea Nº 3 39 v 25 Tarea Nº 4 40 26 Tarea Nº 5 40 27 Tarea Nº

REPUBLICA BOLIVARIANA DE VENEZUELA

UNIVERSIDAD JOSE ANTONIO PAEZ

FACULTAD DE INGENIERIA

ESCUELA DE COMPUTACION

INGENIERIA EN COMPUTACION

Desarrollo de un sistema de información

para la gestión de los archivos inactivos

en la empresa Distribuidora Universal Kia, C.A.

EMPRESA:

Distribuidora Universal Kia, C.A.

AUTOR: Sergio Daniel Da Silva Almeida

CI: 17316045

San Diego, enero de 2013

REPUBLICA BOLIVARIANA DE VENEZUELA

UNIVERSIDAD JOSE ANTONIO PAEZ

FACULTAD DE INGENIERIA

ESCUELA DE COMPUTACION

INGENIERIA EN COMPUTACION

Desarrollo de un sistema de información para la gestión de los archivos inactivos

en la empresa Distribuidora Universal Kia, C.A.

______________________________________________

Nombre, firma y cedula de identidad del tutor académico

______________________________________________

Nombre, firma y cedula de identidad del tutor empresarial

AUTOR: Sergio Daniel Da Silva Almeida

CI: 17316045

San Diego, enero de 2013

i

INDICE GENERAL

LISTA DE TABLAS........................................................................................... iv

LISTA DE GRAFICOS....................................................................................... ix

INTRODUCCION……………………………………………………………... 1

CAPITULOS

I. LA EMPRESA

1.1. Nombre y ubicación……………………………………………………. 3

1.2. Razón social…………………………………………………….……… 3

1.3. Visión………………………………………………………….……...... 3

1.4. Misión………………………………………………………………….. 4

1.5. Descripción del departamento o área donde se desarrolla la pasantía.… 4

II. EL PROBLEMA

2.1. Planteamiento del problema…………………………………………… 6

2.1.1. Formulación del problema……………………………………....... 10

2.2. Objetivos de la investigación………………………….……………...... 10

2.2.1. Objetivo general…………………………….…………………...... 10

2.2.2. Objetivos específicos…………………………………………....... 10

2.3. Justificación y alcance…………………………………………………. 10

III. MARCO TEORICO

3.1. Antecedentes……………………………………….…………………... 12

3.2. Bases teóricas……………………………………….………………...... 14

3.2.1. Ciclo de vida del documento…………………………………....... 14

ii

3.2.1.1. Archivo de gestión………………………………………....... 15

3.2.1.2. Archivo central……………………………………………… 15

3.2.1.3. Archivo histórico……………………………………………. 16

3.2.2. Valor documental………………………………………….……… 16

3.2.2.1. Valor primario………………………………………………. 16

3.2.2.2. Valor secundario………………………………………….…. 17

3.2.3. Tabla de retención documental (TRD)…………………………… 17

3.2.4. Tabla de valoración documental (TVD)………………………….. 17

3.2.5. Páginas web……………………………………………………..... 18

3.2.6. Software libre……………………………………………………... 19

3.2.7. Hypertext preprocessor (PHP)……………………………………. 19

3.2.8. MySQL……..…………………………………………………….. 20

3.3. Definición de términos básicos………………………………………… 21

IV. MARCO METODOLOGICO

4.1. Tipo de investigación…………………………………………………... 23

4.2. Base metodológica……………………………………………………... 24

4.2.1. Planificación……………………………………………………… 27

4.2.2. Diseño…………………………………………………………….. 27

4.2.3. Desarrollo………………………………………………………… 28

4.2.4. Pruebas…………………………………………………………..... 28

V. RESULTADOS

5.1. Fase I. Planificación……………………………………………............. 30

5.1.1. Historias de usuario………………………………………………. 30

5.1.2. Planificación de entregas…………………………………………. 38

5.1.3. Iteraciones………………………………………………………… 47

5.2. Fase II. Diseño…………………………...………….............................. 51

iii

5.2.1. Diagramas de entidad-relacion........................................................ 51

5.2.2. Diccionario de datos........................................................................ 53

5.2.3. Diagramas de caso de uso................................................................ 66

5.2.4. Especificaciones de caso de uso...................................................... 70

5.2.5. Mapa de navegación........................................................................ 109

5.3. Fase III. Desarrollo.................................................................................. 104

5.3.1. Desarrollo de la base de datos……………………………………. 111

5.3.2. Interfaz de usuario………………………………………………... 113

5.4. Fase IV. Pruebas...................................................................................... 127

CONCLUSIONES............................................................................................... 145

RECOMENDACIONES...................................................................................... 147

REFERENCIAS.................................................................................................. 148

Bibliográficas............................................................................................. 148

Electrónicas................................................................................................ 149

ANEXOS

A. Tabla de retención documental (TRD)................................................. 153

B. Tabla de valoración documental (TVD)............................................... 154

C. Archivo Central de la empresa Distribuidora Universal Kia, C.A........ 155

D. Archivo Central de la empresa Distribuidora Universal Kia, C.A....... 156

E. Encuesta Nº 1........................................................................................ 157

iv

LISTA DE TABLAS

TABLA CONTENIDO PAG.

1 Historias de usuario Nº 1 30





















22 Tarea Nº 1 39

23 Tarea Nº 2 39

24 Tarea Nº 3 39

v

25 Tarea Nº 4 40

26 Tarea Nº 5 40

27 Tarea Nº 6 40

28 Tarea Nº 7 41

29 Tarea Nº 8 41

30 Tarea Nº 9 42

31 Tarea Nº 10 42

32 Tarea Nº 11 43

33 Tarea Nº 12 43

34 Tarea Nº 13 44

35 Tarea Nº 14 44

36 Tarea Nº 15 44

37 Tarea Nº 16 45

38 Tarea Nº 17 45

39 Tarea Nº 18 45

40 Tarea Nº 19 46

41 Tarea Nº 20 46

42 Tarea Nº 21 46

43 Tarea Nº 22 47

44 Iteración Nº 1 47








52 Diccionario de datos. Tabla “Usuarios” 54

vi

53 Diccionario de datos. Tabla “Parámetro” 54

54 Diccionario de datos. Tabla “Departamento” 55

55 Diccionario de datos. Tabla “Dpto_Dep” 55

56 Diccionario de datos. Tabla “Dependencia” 56

57 Diccionario de datos. Tabla “Usuario_Dpto” 56

58 Diccionario de datos. Tabla “Rol_Usuario” 57

59 Diccionario de datos. Tabla “Rol” 57

60 Diccionario de datos. Tabla “Menu_Rol” 58

61 Diccionario de datos. Tabla “Menú” 58

62 Diccionario de datos. Tabla “Destrucción” 59

63 Diccionario de datos. Tabla “Traslado” 59

64 Diccionario de datos. Tabla “Carpeta” 60

65 Diccionario de datos. Tabla “Caja” 61

66 Diccionario de datos. Tabla “Localizacion” 62

67 Diccionario de datos. Tabla “Ubicacion” 62

68 Diccionario de datos. Tabla “Prestamo” 63

69 Diccionario de datos. Tabla “Valordoc” 64

70 Diccionario de datos. Tabla “Tipocarpeta” 64

71 Diccionario de datos. Tabla “Digitalizacion” 65

72 Especificación de caso de uso “Crear parámetros” 70

73 Especificación de caso de uso “Modificar parámetros” 71

74 Especificación de caso de uso “Crear departamento” 72

75 Especificación de caso de uso “Editar departamento” 73

76 Especificación de caso de uso “Eliminar departamento” 74

77 Especificación de caso de uso “Crear dependencia” 75

78 Especificación de caso de uso “Editar dependencia” 76

79 Especificación de caso de uso “Eliminar dependencia” 77

80 Especificación de caso de uso “Crear localización” 78

vii

81 Especificación de caso de uso “Editar localización” 79

82 Especificación de caso de uso “Eliminar localización” 80

83 Especificación de caso de uso “Crear ubicación” 81

84 Especificación de caso de uso “Editar ubicación” 82

85 Especificación de caso de uso “Crear valor” 83

86 Especificación de caso de uso “Modificar valor” 84

87 Especificación de caso de uso “Eliminar valor” 85

88 Especificación de caso de uso “Crear tipo de carpeta” 86

89 Especificación de caso de uso “Modificar tipo de carpeta” 87

90 Especificación de caso de uso “Eliminar tipo de carpeta” 88

91 Especificación de caso de uso “Ingresar tabla de retención

documental”

89

92 Especificación de caso de uso “Modificar tabla de retención

documental”

91

93 Especificación de caso de uso “Conservar carpetas” 93

94 Especificación de caso de uso “Destruir carpeta” 94

95 Especificación de caso de uso “Registrar préstamo” 95

96 Especificación de caso de uso “Registrar devolución de

préstamo”

96

97 Especificación de caso de uso “Consultar localizaciones” 97

98 Especificación de caso de uso “Consultar carpetas” 98

99 Especificación de caso de uso “Consultar préstamo” 99

100 Especificación de caso de uso “Crear usuarios” 100

101 Especificación de caso de uso “Editar usuarios” 101

102 Especificación de caso de uso “Cambiar clave” 102

103 Especificación de caso de uso “Crear submenú” 103

104 Especificación de caso de uso “Modificar submenú” 104

105 Especificación de caso de uso “Crear rol” 105

viii

106 Especificación de caso de uso “Editar rol” 106

107 Especificación de caso de uso “Eliminar rol” 107

108 Especificación de caso de uso “Asignar rol” 108

109 Prueba Nº 1 127


















ix

INDICE DE GRAFICOS

GRAFICO CONTENIDO PAG.

1 Organigrama del departamento de sistemas 5

2 Diagrama de flujo para el proceso de traslado de archivos 7

3 Diagrama de flujo para el proceso de préstamo de archivos 8

4 Diagrama de flujo para el proceso de desincorporación de

archivos

9

5 Ciclo de vida del documento 15

6 Diagrama Entidad-Relación 51



9 Diagrama de caso de uso del usuario 66



12 Diagrama de caso de uso del administrador 69

13 Mapa de navegación 109

14 Esquema de la base de datos 111

15 Esquema de la base de datos 112

16 Pantalla de ingreso al sistema 113

17 Pantalla del menú principal 114

18 Pantalla del menú “parámetros” 114

19 Pantalla del menú “departamentos” 115

20 Pantalla del menú “Localizaciones” 115

21 Pantalla del menú “Valor Documental” 116

22 Pantalla del menú “Tipo de carpetas” 116

23 Pantalla del menú “Ingresar TRD” 117

x

24 Pantalla del menú “Ingresar TRD”. Generación de la tabla de

retención documental en PDF.

117

25 Pantalla del menú “modificar TRD”. 118

26 Pantalla del menú “Desincorporar”. 118

27 Pantalla del menú “Desincorporar”. Opción “Conservar” 119

28 Pantalla del menú “Desincorporar”. Opción “Destruir” 119

29 Pantalla del menú “Registro de Préstamo”. 120

30 Pantalla del menú “Registro de Préstamo”. 120

31 Pantalla del menú “Registro de Préstamo”. Generación de

reporte de préstamo en PDF.

121

32 Pantalla del menú “Devolución de Préstamo”. 121

33 Pantalla del menú “Consulta de préstamo”. 122

34 Pantalla del menú “Consulta de carpetas”. 122

35 Pantalla del menú “Consulta de localizaciones”. 123

36 Pantalla del menú “Administración de usuarios”. 123

37 Pantalla del menú “Administración de usuarios”. Opción “crear

nuevo usuario”

124

38 Pantalla del menú “Menús”. 124

39 Pantalla del menú “Menús”. Opción “Ver menús” 125

40 Pantalla del menú “Roles”. 125

41 Pantalla del menú “Asignación de roles”. 126

42 Pantalla del menú “Asignación de roles”. Asignación de roles

al usuario “sfernandez”.

126

1

INTRODUCCION

Hoy en día, observamos como las tecnologías de información forman parte de

nuestro trabajo. Ventajas tales como un mayor control, rapidez, simplicidad del

trabajo, almacenamiento de la información en bases de datos, estandarizar procesos;

son razones suficientes para que existan la necesidad de implementar estos sistemas

en el campo laboral.

Numerosas empresas manejan una gran cantidad de documentación física que al

incrementarse se dificulta bastante el poder gestionar la misma. Los documentos se

acumulan generando almacenamiento de papel caduco, ocupación de espacio,

desorden, perdida o dificultad para conseguir un documento.

El propósito de este proyecto consiste en desarrollar un sistema de información

web que permita gestionar estos documentos de manera organizada, simple y rápida,

facilitar el trabajo de la empresa y reducir el trabajo y tiempo perdido en la actividad

documental que puede ser aprovechado para actividades más relevantes. El desarrollo

de este trabajo consta de cinco capítulos:

Capítulo I: Corresponde a la empresa, su ubicación, razón social, visión y misión.

Capitulo II: Contiene el planteamiento del problema, los objetivos generales y

específicos de la investigación y la justificación y alcance.

Capitulo III: Se mencionan los antecedentes y se explica todo acerca de la

documentación y los archivos, el ciclo de vida del documento, el valor documental, la

tabla de retención y valoración documental. También se explica lo que es una página

web, el lenguaje a utilizar para realizar el sistema de información (PHP) y la base de

datos a utilizar (MySQL). Finalmente se incluye la definición de términos básicos.

Capitulo IV: Describe acerca de la metodología utilizada para el desarrollo del

trabajo de grado y la metodología de desarrollo del sistema de información para este

2

proyecto. La metodología de desarrollo es conocida como la metodología agil XP

(eXtreme Programming) que consta de 4 fases: planificación, diseño, desarrollo y

pruebas.

Capítulo V: Se muestran los resultados en cada fase de la metodología aplicada en

este proyecto.

Finalmente se reseñan las referencias bibliográficas que sirvieron de apoyo para la

realización del proyecto.

3

CAPITULO I

LA EMPRESA

1.1. NOMBRE Y UBICACION

Distribuidora Universal Kia C.A. se encuentra ubicada en la calle Diego Tovar

Nº11, Sector Grupo Covenal, Mariara, Edo Carabobo.

1.2. RAZON SOCIAL

Distribuidora Universal Kia, es una empresa dedicada a la importación,

distribución y venta de vehículos y partes automotrices de alta calidad, lo cual

permite satisfacer al exigente y competitivo mercado nacional.

1.3. VISION

Distribuidora Universal Kia C.A., se perfila a convertirse en la primera empresa

importadora de vehículos y partes automotrices, a fin de posesionarse del mercado

nacional con vehículos de inmejorable calidad; brindando a sus clientes un servicio

técnico de primera línea, con lo cual lograremos tener clientes cada día identificados

con la marca, aumentando nuestro prestigio.

4

1.4. MISION

Distribuidora Universal Kia, es una empresa dedicada a la importación,

distribución y venta de vehículos y partes automotrices de alta calidad, lo cual

permite satisfacer al exigente y competitivo mercado nacional.

1.5. DESCRIPCION DEL DEPARTAMENTO O AREA DONDE SE

DESARROLLO LA PASANTIA

El departamento de Sistemas Informáticos ofrece a la empresa soporte técnico

para los problemas o dificultades que puedan presentarse en cada puesto de trabajo

Los cargos y las responsabilidades se definen de acuerdo a la estructura

organizativa.

Propósito general

Planificar, coordinar y supervisar todas las actividades referidas al área de

tecnología de la información con el propósito de garantizar la operatividad de la

empresa en la plataforma y la tecnología seleccionada por el grupo, cubrir los

requerimientos tecnológicos, optimizar los procesos en las diferentes áreas de la

planta y brindar soluciones efectivas a los usuarios.

5

Gráfico Nº1. Organigrama del departamento de sistemas

Fuente: Distribuidora universal Kia, C.A. (2012)

6

CAPITULO II

EL PROBLEMA

2.1. PLANTEAMIENTO DEL PROBLEMA

En las distintas organizaciones y empresas que existen a nivel mundial, surge la

necesidad de mantener un orden al momento de almacenar documentos, pues estos

tienen un valor importante. Con frecuencia, requieren ser consultados, para la toma de

decisiones o para solucionar algún problema. Sin embargo, muchas de estas

organizaciones, acumulan una gran cantidad de documentos, lo cual dificulta el

proceso de consulta o determinar cuáles ya caducaron.

En el caso de la empresa Distribuidora Universal Kia, existen varios

departamentos que generan documentos: administración, tráfico y aduanas, garantía,

sistemas, repuestos, PDI, distribución y recursos humanos. El almacenamiento de

estos es realizado en su totalidad de forma manual y sin un control. Se colocan los

documentos en carpetas, se introduce la carpeta dentro de una caja, se identifica la

caja y se almacena en un estante. Dichas cajas están ubicadas dentro de un

departamento, el cual está casi a su máxima capacidad.

A raíz de esto, los distintos departamentos presentan problemas para ubicar donde

se encuentran los documentos, incluso en situaciones donde se realizan

fiscalizaciones dentro de la empresa, sucede que no se encuentra algún documento en

el momento. Además de esto, la documentación se acumula sin establecer un tiempo

de retención, ocasionando el almacenamiento de documentos en los archivos

inactivos que con el paso del tiempo caducan, no son desincorporados y ocupan

espacio. También ocurre que no existe un control de quien realiza consultas, que

documentos hay dentro de las cajas, cuales ingresan o salen del departamento, su

clasificación, mala ubicación de las cajas y desconocimiento de que documentos hay

almacenado actualmente dentro de ellas en los archivos inactivos.

7

Para comprender de manera más explícita la problemática expuesta en el párrafo

anterior, se ilustrara gráficamente los tres procesos llevados a cabo por los empleados

de la empresa para la gestión de los archivos inactivos.

Gráfico Nº 2. Diagrama de flujo para el proceso de traslado de archivos

Fuente: Da Silva, Sergio (2012).

En la figura anterior, observamos el proceso llevado a cabo por el empleado para

trasladar los archivos inactivos. Este proceso se lleva a cabo de forma manual en su

8

totalidad y cada empleado realiza el traslado de los documentos que corresponden a

su departamento. El empleado no realiza un registro de los documentos que traslada,

lo que ocasiona dificultad para conseguir estos documentos posteriormente en una

consulta. Tampoco se les asigna un periodo de retención que permita en el futuro

decidir si se debe desincorporar o si se desea conservar por un nuevo periodo de

tiempo, ocasionando acumulación de documentación a que a largo plazo ya no tenga

valor.

Gráfico Nº 3. Diagrama de flujo para el proceso de préstamo de archivos


El proceso de préstamo lo puede realizar casi cualquier empleado. Los archivos

inactivos se encuentran almacenados en un lugar cerrado, al cual se accede con una

llave. El empleado que no tiene la llave, la obtiene solicitándole a otro empleado el

préstamo de la misma. Una vez adentro, la ubicación del documento resulta un

problema porque no existe un registro de los documentos y su ubicación, por lo que el

9

empleado debe revisar las cajas. Algunas cajas presentan una descripción insuficiente

o desactualizada de lo que se encuentra almacenado dentro de ellas. Una vez ubicado

el documento, el empleado toma la carpeta o la caja y la lleva a su departamento. El

tiempo de devolución y la persona que tomo prestada la carpeta no es registrado.

Gráfico Nº 4. Diagrama de flujo para el proceso de desincorporación de archivos


Cuando el empleado decide desincorporar un documento que se encuentre en los

archivos inactivos o en su departamento, realiza este proceso. En el caso de los

documentos ubicados en los archivos inactivos, resulta bastante complicado

desincorporar porque no existe un registro de los documentos que se encuentran

almacenados y esto dificulta ubicarlos. Este proceso representa el fin del documento.

De acuerdo con lo expresado, la meta del presente trabajo es desarrollar un sistema

de información que le permita a la empresa facilitar la gestión de estos documentos a

través de un ordenador, que sirva para consultas y operaciones, para que este proceso

sea más sencillo, rápido y organizado.

10

2.1.1. Formulación del problema

¿Cómo puede contribuir las TIC para garantizar la eficiencia en la gestión de

archivos inactivos de la empresa Distribuidora Universal Kia?

2.2. OBJETIVOS DE LA INVESTIGACION

2.2.1. Objetivo general

Desarrollar un sistema de información para la gestión de los archivos inactivos de

la empresa Distribuidora Universal Kia, C.A.

2.2.2. Objetivos específicos

Identificar los procesos actuales de la empresa para la gestión de archivos

inactivos, a través de reuniones con el cliente y observación directa.

Determinar los nuevos procesos necesarios para realizar la gestión de archivos

inactivos, que cumplan los principios de gestión archivística.

Diseñar el nuevo sistema de información de gestión de archivos inactivos para la

empresa Distribuidora Universal Kia, C.A.

Aplicar la metodología XP para el desarrollo del sistema de información de

gestión de archivos inactivos para la empresa Distribuidora Universal Kia, C.A.

2.3. JUSTIFICACION Y ALCANCE

La gestión de los archivos inactivos de la empresa se realizan actualmente de

forma manual. Existe dificultad cuando se necesita ubicar un documento ya que no se

cuenta con un registro de lo que se encuentra almacenado en el depósito y tampoco

hay un control de lo que entra y sale. Sucede también que se acumula documentación

que ha perdido valor para la empresa y esta ocupa espacio innecesario, además de que

11

el espacio para almacenar dichos documentos es limitado, por lo que se requiere

mantener en los archivos lo que realmente tenga valor.

El propósito de este proyecto es sustituir este proceso manual por un sistema de

información web que facilite la gestión de estos archivos inactivos de forma digital y

controlada por los usuarios. Esto permitirá encontrar documentos en segundos (una

consulta en el sistema tardaría desde el ingreso al mismo hasta generar la consulta

unos 30 segundos), registrar a los distintos usuarios de cada departamento, llevar un

control de quien realiza consultas, control de entrada/salida de los documentos

archivados donde se registre tanto la fecha de préstamo como la fecha de devolución,

desincorporación de la documentación que ha perdido su valor, registrar los traslados

de documentación donde se le asignara a cada carpeta un lugar, el periodo de tiempo

que permanecerá archivado y realizar consultas desde cada una de las dependencias

sin tener que hacerlo directamente en las cajas.

El nuevo sistema será utilizado internamente en la empresa por cada departamento

y cada usuario tendrá un acceso definido a la documentación.

12

CAPITULO III

MARCO TEORICO

3.1. ANTECEDENTES

Para efectos de esta investigación, se tomó en cuenta varios trabajos relacionados

como referencia para desarrollar este proyecto, los cuales se muestran a

continuación:

En el año 2010, Eduardo López en su trabajo de grado titulado “Desarrollo de un

sistema integral para el control del inventario del fondo editorial del ipasme y

solicitud de pedidos para sus afiliados, basado en tecnologías web” para optar por el

título de Ingeniero en computación de la Universidad José Antonio Páez, escribió

acerca de la problemática que existía con la gestión de recursos literarios cuando eran

almacenados, recibidos o enviados. Esta actividad se realizaba manualmente sin

ningún lineamiento establecido, lo cual dificultaba mucho el control de estos

recursos. Asimismo expreso acerca de la pérdida de tiempo que acarreaba la

búsqueda de información. Su propuesta fue automatizar esta gestión utilizando

tecnología web, permitiendo al usuario controlar todo este proceso de manera

organizada, rápida y eficaz, por lo cual es una buena referencia de que un sistema

web es una posible solución para el control de inventarios, en el caso de este

proyecto, para gestionar los archivos inactivos.

En el año 2010, José E. Escalona Surth realizó un trabajo de grado para optar por

el título de Licenciado en Relaciones Industriales de la Universidad de Carabobo,

donde propuso un modelo de gestión de información para la dirección de asuntos

profesorales en su sección de archivo central de la Facultad de Odontología de la

Universidad de Carabobo, donde no contaban con un sistema automatizado,

ocasionando pérdida de tiempo de búsqueda y descontrol de la documentación,

generando más trabajo para el personal. Para darle solución a este problema, el autor

planteo un modelo de sistema de información, donde primero se realizó un

13

diagnóstico de los procedimientos internos que existían para el manejo de la

información y documentación, determino las necesidades del personal de archivo

central de la facultad de odontología y por ultimo estableció el modelo de gestión de

información. Este trabajo tiene similitud con la problemática presente en este

proyecto.

En el año 2009, Ericka C. López P. en su trabajo de grado “Implementación de

una base de datos bibliográfica del archivo de la gerencia del control interno y

calidad procesos corporativo en la corporación petróleos de Venezuela S.A”,

requisito para optar por el título de Técnico Superior Universitario en Organización

Empresarial de la Universidad Simón Bolívar, realizo una investigación acerca de la

gestión documental en la gerencia de control interno y calidad de procesos

corporativos, donde observo la movilización de documentos. El proceso se realizaba

de forma manual lo cual generaba dificultad para obtener los documentos con un

tiempo de respuesta ineficiente. Como solución se implementó una base de datos

asociada a un manual de normas y procedimientos que ayude a los usuarios a

mantener un control sobre la documentación. Para el proyecto que se está

desarrollando, es necesario realizar una base de datos para el sistema donde se

registre todos los archivos inactivos y quienes acceden a ellos.

En el año 2008, Jesús Alvarenga y Gerard Roa, realizaron un trabajo de grado

titulado “Plataforma para la gestión de documentos del vicerrectorado académico de

la universidad José Antonio Páez” para optar por el título de ingeniero en

computación de la Universidad José Antonio Páez, donde describe la situación que

existía en el vicerrectorado académico. Los archivos gestionados por esta entidad se

manejaban manualmente, generando dificultad y pérdida de tiempo para el acceso y

consulta de los mismos. Para agilizar este proceso, el desarrollo una plataforma

basada en el estudio de flujo de trabajo (workflow) que es manejada vía intranet

dentro del vicerrectorado. Esto permitió automatizar y mecanizar esta gestión,

facilitando el trabajo de consulta y acceso a estos documentos, ahorro de tiempo y

14

dinero. Este trabajo presenta una situación similar al problema que se presenta en

este proyecto.

En el año 2006, Luis Alfredo Prieto en su trabajo de grado “Sistema de gestión de

archivos para el departamento de salud y seguridad de la empresa Ford Motor de

Venezuela S.A. basado en tecnología web”, requisito para optar por el título de

ingeniero en computación de la Universidad José Antonio Páez, tomo como

investigación los requerimientos de la auditoria MCRP (Modular control review

program) que se realiza en el departamento de salud y seguridad de la empresa. La

propuesta para resolver este problema fue la realización de un sistema web

administrador de archivos, donde el usuario actualiza los archivos pertenecientes al

departamento.

3.2. BASES TEORICAS

3.2.1. Ciclo de vida del documento

Según el manual de archivo y correspondencia del instituto nacional de salud,

Bogotá D.C, define ciclo de vida del documento como: “Etapas sucesivas por las que

atraviesan los documentos desde su producción o recepción en la oficina o

dependencia (archivo de gestión) y su conservación temporal (archivo central), hasta

su eliminación o integración a un archivo permanente (archivo histórico). El ciclo

vital del documento se entiende bajo el concepto de archivo total.”

Los documentos poseen un ciclo de vida desde su generación hasta que pierde su

valor administrativo y es descartado. Al crearse un documento en una dependencia

este adquiere un valor que perdurara hasta un cierto tiempo que luego podría ser

destruido o conservado con un nuevo valor.

15

Gráfico Nº5. Ciclo de vida del documento.

Fuente: Manual de archivo y correspondencia. Instituto nacional de salud de Bogotá (2005)

En el caso de la empresa Distribuidora Universal Kia, C.A., el archivo central y el

archivo histórico están físicamente ubicados en el mismo lugar.

3.2.1.1. Archivo de gestión

También conocido como archivo de oficina. Es aquel archivo que está presente en

cada una de las dependencias que originaron el mismo. Son de uso imprescindible

para el desarrollo de actividades o funciones y se consultan constantemente.

3.2.1.2. Archivo central

Es el archivo donde se traslada aquellos documentos de gestión de cada

dependencia que ha finalizado el asunto por el cual fue creado, que no

16

necesariamente implica eliminarlos porque pueden ser objeto de consulta o

referencia, y poseen un valor. Estos documentos se acumulan con un plazo de tiempo

determinado.

3.2.1.3. Archivo histórico

Es aquel archivo donde una vez finalizado el plazo de tiempo por el cual fue

almacenado en los archivos centrales, se selecciona y se determina que documentos

aún son de valor para la organización. Estos se almacenan permanentemente.

3.2.2. Valor documental

Es la valoración que las distintas dependencias le asignan a la documentación para

determinar el tiempo de permanencia en los distintos archivos. Estos poseen un valor

primario y un valor secundario.

3.2.2.1. Valor primario

Son aquellos documentos útiles para la organización. Entre los valores primarios

se tiene:

Valor administrativo: Relacionado con el trámite o asunto que motivo su

creación. Responde a una necesidad administrativa mientras dure su trámite y

son importantes para la planificación y toma de decisiones.

Valor jurídico: Derechos u obligaciones.

Valor legal: Sirven de testimonio ante la ley.

Valor fiscal: Registran movimientos de dinero.

Valor contable: Registran ingresos, egresos y movimientos económicos de la

organización.

Valor técnico: Información específica de alguna función.

17

3.2.2.2. Valor secundario

Es aquel que posee el documento una vez que cumplió con el plazo de retención

en el archivo central o archivo de gestión. Son archivados permanentemente debido a

que poseen un valor histórico, cultural o sirven de investigación científica para la

organización. Pueden ser objeto de consulta para la toma de decisiones.

3.2.3. Tabla de retención documental (TRD)

Según la compañía de servicios archivísticos y tecnológicos Ltda., la TRD es un

“Listado de series con sus correspondientes tipos documentales, producidos o

recibidos por las unidades administrativas de una entidad, a las cuales se les asigna el

tiempo de permanencia en cada fase de archivo, ellas se constituyen en el instrumento

archivístico esencial que permite la normalización de la gestión documental, la

racionalización de la producción documental y la institucionalización del ciclo vital

de los documentos en los archivos de las organizaciones.”

Esta tabla forma parte de la gestión documental. Su finalidad es de administrar los

documentos durante su ciclo de vida, especialmente cuando su periodo de gestión ha

terminado y se ha de trasladar al archivo central para su conservación, donde se le

asignará un valor documental según su dependencia.

3.2.4. Tabla de valoración documental (TVD)

Según la compañía de servicios archivísticos y tecnológicos Ltda, la TVD es un

“listado de series y subseries con sus correspondientes tipos documentales

producidos o recibidos por una entidad, una vez identificados los valores primarios

(administrativos, contables, fiscales, legales y técnicos) y los valores secundarios

(históricos, científicos y culturales), que posea la documentación de un archivo, se

determina su tiempo de retención y se establece su destino final.”

18

Esta tabla se aplica una vez que se determinó el valor de la documentación y se le

asigna un tiempo de retención y donde se ubicara durante ese tiempo. Su destino final

depende de:

Si la documentación será seleccionada, se realiza un muestreo de la

documentación y se agrupa aquella que se conservara, el resto se

descartara.

Si la documentación será eliminada o,

Si la documentación será conservada en su totalidad

3.2.5. Páginas Web

Según Sergio Lujan Mora en su libro titulado “programación de aplicaciones web:

Historia, principios básicos y clientes web”, define sitio web y pagina web: “Un sitio

web es un conjunto de páginas web relacionadas entre sí. Se entiende por página web

tanto el fichero que contiene el código HTML como todos los recursos que se

emplean en la página (imágenes, sonidos, código JavaScript, etc.)”.

Las páginas web se acceden mediante un navegador desde una computadora o un

dispositivo móvil y está escrito generalmente en formato HTML o XHTML. Este

formato consiste en etiquetas que definen el cuerpo, estilo y puede incluso incluir un

script.

Además estas páginas incluyen otros recursos tales como hojas de estilo en

cascada (CSS). Este es un lenguaje utilizado para dar formato a una presentación

HTML. También puede incluir imágenes, videos y scripts generalmente escritos en

lenguajes del lado del cliente como Javascript y lenguajes del lado del servidor como

PHP.

Estas pueden estar alojadas en una maquina local o en un servidor web remoto. El

protocolo utilizado para acceder a estas páginas es el protocolo de transferencia de

hipertexto (HTTP).

19

El contenido de una página web puede ser estático (el contenido es fijo) o puede

ser dinámico (se comunica con un servidor y realiza el intercambio de información).

3.2.6. Software Libre

Según la Free Software Fundation, “«Software libre» significa que el software

respeta la libertad de los usuarios y la comunidad. En términos generales, los usuarios

tienen la libertad de copiar, distribuir, estudiar, modificar y mejorar el software. Con

estas libertades, los usuarios (tanto individualmente como en forma colectiva)

controlan el programa y lo que hace.”

El software libre es aquel software que el usuario adquiere generalmente de

manera gratuita, aunque no siempre es así. Este puede ser estudiado, modificado,

copiado, usado o redistribuido por el usuario. Según la licencia que el software tenga,

el grado de libertad de hacer lo que se desee con el varia.

Entre las licencias más comúnmente utilizadas se encuentran la GPL, AGPL y

BSD. La Licencia Pública General (GPL) es la más común de todas, permite la

redistribución y modificación bajo términos diseñados para asegurarse de que todas

las versiones modificadas del software permanecen bajo los términos de la GPL, es

decir, si se crea un producto con partes GPL, el producto final será GPL.

La licencia AGPL es igual que la GPL pero añade la obligación de distribuir el

software si éste se ejecuta para ofrecer servicios a través de una red de ordenadores.

Por último, la licencia BSD permite libertad total del software pero el autor

mantiene la protección de los derechos de autor únicamente para la renuncia de

garantía y para requerir la adecuada atribución de la autoría en trabajos derivados.

3.2.7. Hypertext Preprocessor (PHP)

Según el sitio oficial web de PHP, “PHP es un lenguaje de código abierto muy

popular especialmente adecuado para desarrollo web y que puede ser incrustado en

HTML.”

20

PHP es un lenguaje de programación interpretado, diseñado para crear páginas

web dinámicas del lado del servidor. Su principal utilidad es permitir la comunicación

de las páginas con el motor de base de datos tales como MySQL, PostgreSQL,

Oracle, Microsoft SQL Server, entre otros, para realizar consultas, actualizaciones y

eliminar registros. Actualmente va en su versión 5.4.4 y 5.3.14. Está publicado bajo la

PHP License, la Free Software Foundation considera esta licencia como software

libre. Su sintaxis es similar al lenguaje C y Perl.

Si el cliente realiza una petición al servidor para que envíe una página web, el

servidor ejecutara el intérprete de PHP, procesando el script solicitado el cual

generara el contenido de manera dinámica. El resultado es enviado por el intérprete al

servidor y este a su vez se lo envía al cliente.

3.2.8. MySQL

Según Luke Welling y Laura Thomson en su libro titulado “Desarrollo web con

PHP y MySQL”: “MySQL es un sistema para la administración de bases de datos

relacionales (RDBMS) rápido y sólido. Las bases de datos permiten almacenar,

buscar, ordenar y recuperar datos de forma eficiente. El servidor MySQL controla el

acceso a los datos para garantizar el uso simultáneo de varios usuarios, para

proporcionar acceso a dichos datos y para asegurarse de que solo obtienen acceso a

ellos los usuarios con autorización. Por lo tanto, MySQL es un servidor multiusuario

y de subprocesamiento múltiple.”

Es un sistema de gestión de bases de datos relacional, multihilo y multiusuario, el

cual pertenece desde enero de 2008 a Sun Microsystems y ésta a su vez de Oracle

Corporation desde abril de 2009 quien desarrolla MySQL como software libre con

licenciamiento dual.

Se ofrece bajo la GNU GPL para cualquier uso compatible con esta licencia, y si

alguna empresa quiere incorporarlo en productos privativos deben comprar a la

empresa una licencia específica que les permita este uso. Está desarrollado

mayormente en lenguaje C. Actualmente se encuentra en su versión 5.1.43 y 5.5.3.

21

MySQL es muy utilizado para aplicaciones web. Hay aplicaciones tales como Wamp

que incluyen PHP y MySQL para desarrollar páginas web dinámicas.

3.3. DEFINICION DE TERMINOS BASICOS

AJAX: acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y

XML), es una técnica de desarrollo web para crear aplicaciones interactivas. Estas se

ejecutan en el navegador de los usuarios mientras se mantiene la comunicación

asíncrona con el servidor en segundo plano. Esto permite realizar cambios sobre las

páginas sin necesidad de recargarlas, lo que significa aumentar la interactividad,

velocidad y usabilidad en las aplicaciones.

Apache: es un servidor web HTTP de código abierto y multiplataforma. Es utilizado

para enviar páginas web estáticas y dinámicas en la world wide web.

Archivo: Según el manual de archivo y correspondencia del instituto nacional de

salud de Bogotá: “Conjunto de documentos, sea cual sea su fecha, su forma y el

soporte material, acumulados en un proceso natural por una persona o entidad en el

transcurso de su gestión. Los archivos cumplen una función probatora, garantizadora

y perpetuadora”.

JQUERY: es una biblioteca de JavaScript que permite simplificar la manera de

interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos,

desarrollar animaciones y agregar interacción con la técnica AJAX a páginas web.

Esta biblioteca es software libre y de código abierto, posee un doble licenciamiento

bajo la Licencia MIT y la Licencia Pública General de GNU v2, permitiendo su uso

en proyectos libres y privativos.

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

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

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

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

http://es.wikipedia.org/wiki/As%C3%ADncrono

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

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

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

http://es.wikipedia.org/wiki/Software_de_c%C3%B3digo_abierto

http://es.wikipedia.org/wiki/Biblioteca_%28inform%C3%A1tica%29


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

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

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

http://es.wikipedia.org/wiki/Software_libre_y_de_c%C3%B3digo_abierto

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

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

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

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

22

JSON: acrónimo de JavaScript Object Notation. Es un formato ligero para el

intercambio de datos. JSON es un subconjunto de la notación literal de objetos de

JavaScript que no requiere el uso de XML.

WAMP: es el acrónimo utilizado para un sistema de infraestructura de internet el

cual utiliza las siguientes herramientas: Windows, Apache, MySQLy PHP.

XML (eXtensible Markup Language, lenguaje de marcas generalizado): Es un

lenguaje usado para estructurar información en un documento o en general en

cualquier fichero que contenga texto, como por ejemplo ficheros de configuración de

un programa o una tabla de datos.


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

23

CAPITULO IV

MARCO METODOLOGICO

4.1. TIPO DE INVESTIGACION

El nivel de investigación según la problemática planteada en este trabajo de grado

es descriptivo, ya que se describe la situación actual de la empresa respecto a los

archivos inactivos basada en la recolección de datos proveniente de los usuarios y el

estudio de los procesos actuales. Según Dankhe (1986), citado por Roberto Sampieri,

Carlos Fernández y Pilar Baptista en el libro “Metodología de la Investigación”, “Los

estudios descriptivos buscan especificar las propiedades importantes de personas,

grupos, comunidades o cualquier otro fenómeno que sea sometido a análisis”. Un

estudio descriptivo toma en cuenta una serie de aspectos para luego medirlos y así

describir lo que se investiga.

El diseño de la investigación empleado que responde a la problemática planteada

es la investigación de campo, ya que para el estudio se recolectara información

directamente de los usuarios y del estudio de la situación actual de la empresa con

respecto a los archivos inactivos.

Según Manual de Trabajos de Grado, de Especialización y Maestría y Tesis

Doctorales de la universidad pedagógica experimental libertador, “Se entiende por

investigación de campo, el análisis sistemático de problemas en la realidad, con el

propósito bien sea de describirlos, interpretarlos, entender su naturaleza y factores

constituyentes, explicar sus causas y efectos, o predecir su ocurrencia, haciendo uso

de métodos característicos de cualquiera de los paradigmas o enfoques de

investigación conocidos o en desarrollo. Los datos de interés son recogidos en forma

directa de la realidad; en este sentido se trata de investigaciones a partir de datos

originales o primarios”.

24

4.2. BASE METODOLOGICA

Para cumplir con los objetivos de este proyecto, se necesita de una metodología

que permita desarrollar el nuevo sistema acorde a la necesidad del cliente, la

complejidad del proyecto y el tiempo disponible.

Como metodología de desarrollo de software se utilizara la metodología de

desarrollo ágil conocida como XP (eXtreme Programing) creada por Kent Beck.

Según Manuel Calero Solís, “la programación extrema se basa en la simplicidad,

la comunicación y el reciclado continuo de código, para algunos no es más que

aplicar una pura lógica”

Esta metodología permitirá prestar mayor atención en darle al cliente el software

que necesita en el menor tiempo posible, involucrar al cliente y al programador

juntos como grupo en el desarrollo del software y modificar o integrar requisitos.

Las ventajas de esta metodología son las siguientes:

Evitar al máximo retrasos en la planificación

Mayor enfoque en la comprensión de cada uno de los requisitos del cliente,

logrando que el software realmente cumpla las expectativas del usuario.

Evitar un tiempo desarrollo extenso lo que repercute en mayor costo de

desarrollo y mantenimiento

Reducir la tasa de defecto en el desarrollo del software

Durante el desarrollo del software, es muy común que existan cambios en los

requisitos, tecnología, personal o reglas del negocio, pero el problema en si no son los

cambios sino la capacidad que tenemos de enfrentarnos a ellos.

25

Según Luis Miguel Echeverry Tobón y Luz Elena Delgado Carmona, “XP resalta una

serie de valores y principios que deben tenerse en cuenta y practicarlos durante el

tiempo de desarrollo que dure el proyecto”

XP plantea cuatro valores que se deben cumplir para el desarrollo del software:

Comunicación: Es muy importante la comunicación con el cliente donde tanto

el usuario como el desarrollador expone sus ideas, opiniones, cambios en el

diseño. Una mala comunicación conduciría a fallos en el diseño.

Sencillez: el objetivo es desarrollar de la forma más sencilla aquello que el

cliente demande, evitando desarrollar algo que en un futuro no se utilice o que

no esté en los requisitos.

Retroalimentación: Esta actúa en conjunto con la comunicación y la sencillez.

A mayor retroalimentación, mayor comunicación y sencillez. Por medio de

pruebas funcionales al software nos mantendrá informado el grado de

fiabilidad del mismo

Valentía: consiste en asumir retos, ser valientes ante los problemas y

afrontarlos. El equipo de desarrollo debe estar preparado para cualquier

cambio que se presente durante el desarrollo, exponer los problemas o dudas,

y tener el valor de eliminar alguna codificación realizada si esta no cumple

con los requisitos o no funciona.

Las cuatro actividades básicas que la metodología XP plantea para satisfacer estos

valores, construir una disciplina y cumplir con el buen desarrollo del software son las

siguientes:

Escuchar: Como los programadores no conocen todo, es importante escuchar

al cliente porque nadie mejor que este sabe lo que necesita. Hay que escuchar

26

los problemas del cliente y explicarle de qué manera se pueden resolver. Al

realizar pruebas es importante saber si lo obtenido es lo deseado y exista una

retroalimentación. Se deben realizar distintas reuniones para organizar tareas

e ideas que surgen por parte del cliente y del equipo. El cliente debe estar en

el lugar de desarrollo para responder ante cualquier duda o problema que se

presente.

Diseñar: Un buen diseño permite que el sistema crezca correctamente. El

diseño debe ser sencillo, y de no ser posible se debe dividir en partes. Si hay

fallos en el diseño estos deben ser corregidos lo antes posible. Se debe utilizar

metáforas para entender mejor los elementos del sistema.

Codificar: El código fuente debe ser simple, aplicando estándares para que

sea entendible y debe ser revisado para depurarlo y simplificarlo. La

integración de módulos debe realizarse en cortos lapsos de tiempo. Se deben

realizar entregas pequeñas al cliente que estén funcionales para que interactúe

con el mismo y realice pruebas. No es recomendable trabajar más de cuarenta

(40) horas semanales en el desarrollo para que el programador utilice al

máximo su rendimiento y energía. Por último la metodología recomienda el

trabajo en parejas de programadores, para aumentar la calidad del código.

Hacer pruebas: Las pruebas son necesarias para probar que cada módulo y su

integración funciona correctamente. El usuario realiza pruebas para

determinar si lo que se desarrolló cumple con las tareas programadas y con

los requisitos, y el programador realiza pruebas de cada módulo para corregir

errores.

La metodología XP consta de cuatro fases: planificación, diseño, desarrollo y

pruebas.

27

4.1.1. Planificación

La planificación es la etapa inicial de todo proyecto. Aquí es donde se determina

los requerimientos del sistema entre el cliente y el grupo de desarrollo.

Una parte de la planificación consiste en realizar historias de usuario, donde el

mismo decide que tareas realizara la aplicación, sin profundizar y sirve para planificar

las entregas de las mismas. Luego se determina la velocidad del proyecto basado en

las tareas a realizar, asignándole a estas un tiempo de desarrollo, se agrupan en

iteraciones, las cuales deben de durar mínimo una (1) semana y máximo tres (3)

semanas. Al finalizar cada iteración se debe realizar la entrega del módulo, y aquellas

tareas que no se realizaron se realizan en la siguiente iteración. Deben existir

reuniones para que exista una revisión continua del trabajo.

4.1.2. Diseño

En esta etapa se realiza el diseño del sistema de forma sencilla para reducir el

tiempo de implementación. Se pueden utilizar diagramas siempre y cuando sean de

utilidad y no tomen mucho tiempo en realizarse. Para el caso de este proyecto, se

utilizara el lenguaje unificado de modelado (UML), donde se determinara los actores

y que tareas van a realizar. Para el diseño de la base de datos, se realizara el diagrama

de entidad-relación (ER) y el diccionario de datos del mismo, esto con el fin de

facilitar el desarrollo. Por último, se realizara el mapa navegacional del sistema web

para diseñar una adecuada navegación entre las páginas.

Se puede utilizar metáforas para tener una visión del proyecto y lograr una

adaptación más rápida por parte del usuario.

28

4.1.3. Desarrollo

La metodología XP propone como tiempo de trabajo 40 horas semanales, y como

regla no más de dos semanas seguidas realizando horas extras, ya que es síntoma de

que hay problemas con el proyecto. Para el caso de este proyecto, se invierten 34

horas semanales en su desarrollo.

La reutilización de código funcional es recomendada y su implementación reduce

tiempo de codificación. Asimismo es recomendable la utilización de estándares al

programar para simplificar el trabajo. Luego de haber codificado se puede

refactorizar el código, que consiste en reescribir el código sin afectar su funcionalidad

con el objetivo de optimizarlo.

Debido a la existencia de un software desarrollado en la empresa que funciona

bajo WampServer, se utilizara los lenguajes PHP como lenguaje del lado del servidor,

JavaScript como lenguaje del lado del cliente, HTML y CSS para el diseño de las

paginas, MySQL como motor de base de datos y APACHE como servidor web. Para

el desarrollo de las páginas se utilizara el mismo diseño del sistema existente pero el

nuevo sistema funcionara de forma independiente. Para facilitar el trabajo, se utilizara

el paquete JSON y JQuery. Cabe destacar que todas las herramientas funcionan bajo

licencia de software libre.

4.1.4. Pruebas

La metodología XP es estricta con las pruebas. Si un módulo no pasa la prueba al

cien por ciento, este no se puede colocar en producción y se debe solucionar los

errores. El programar y probar ahorrara tiempo de programación, ya que se evitara

volver atrás en el código para corregir errores o escuchar innecesariamente al cliente

decir que el modulo no funciona.

El programador debe realizar pruebas unitarias o de caja blanca de cada módulo

sin liberarlos hasta que estos funcionen completamente asegurándose de que el

29

código funcione correctamente. También se deberá realizar pruebas de aceptación las

cuales son realizadas por el cliente basándose en las historias de usuario sin

intervención del programador. Las pruebas de aceptación son pruebas de caja negra,

es decir, se toma en cuenta las entradas y las salidas del módulo ignorando como lo

hace. Si se encuentra un error debe escribirse una prueba antes de corregirlo.

30

CAPITULO V

RESULTADOS

5.1. FASE I. PLANIFICACION

5.1.1 Historias de usuario

Las historias de usuario fueron construidas con la participación de la Coordinadora

de Sistemas (Katy Hernández) y de los usuarios de cada departamento de la empresa,

a partir de reuniones. A continuación, se expondrán las historias de usuario:

Tabla Nº 1. Historias de usuario Nº 1

Identificador 1

Nombre Análisis del sistema actual

Cliente Katy Hernández

Prioridad alta

Descripción Se requiere determinar y conocer los procesos actuales, evaluar sus

fortalezas y debilidades, entradas y salidas de flujo de información.


31


Identificador 2

Nombre Análisis del sistema propuesto


Prioridad Alta

Descripción Se requiere determinar los procesos, realizar el diseño lógico, los

flujos de entrada y salida de información, y el mapa de navegación

del nuevo sistema.



Identificador 3

Nombre Diseño y desarrollo de la base de datos


Prioridad Alta

Descripción Se requiere diseñar la estructura de la base de datos en base a los

requerimientos, definiendo los campos, tablas y relaciones.



Identificador 4

Nombre Llenado de la base de datos


Prioridad Media

Descripción Se requiere realizar la migración de la data que se encuentra en un

documento en Excel hacia la base de datos.


32


Identificador 5

Nombre Parámetros


Prioridad Alta

Descripción Se requiere crear o editar los parámetros que serán condiciones para

el control y correcto funcionamiento del sistema.



Identificador 6

Nombre Departamentos


Prioridad Alta

Descripción Se requiere que el usuario pueda crear, editar o eliminar los

departamentos y dependencias de la empresa que funcionaran en el

sistema.



Identificador 7

Nombre Localizaciones


Prioridad Alta

Descripción Se requiere que el usuario pueda crear, editar o eliminar las

localizaciones y ubicaciones existentes en el archivo central, con las

que funcionara el sistema.


33


Identificador 8

Nombre Valor Documental


Prioridad Alta

Descripción Se requiere que el usuario pueda crear, editar o eliminar los valores

documentales y su tiempo de retención en años, con los cuales

funcionara el sistema. La finalidad de esto, es que el sistema calcule

automáticamente la fecha máxima de retención de la carpeta cuando

se le asigne a esta un valor documental.



Identificador 9

Nombre Tipo de carpetas


Prioridad Alta

Descripción Se requiere que el usuario pueda crear, editar o eliminar los tipos de

carpeta con las que funcionara el sistema.


34


Identificador 10

Nombre Registro de la tabla de retención documental

Cliente Todos los usuarios

Prioridad Alta

Descripción El usuario requiere ingresar todo los datos de la tabla de retención

documental (TRD). Dichos datos son: serie documental, subserie

documental, fecha inicial, fecha final, serie inferior, serie superior,

valor documental, tiempo de retención, numero de cada y

localización. Una vez ingresada toda la información, se debe

generar un reporte con la TRD, el cual se adjuntara a la caja donde

se introducen las carpetas.



Identificador 11

Nombre Modificar la tabla de retención documental


Prioridad Media

Descripción El usuario debe tener la posibilidad de modificar la información

ingresada en la tabla de retención documental (TRD), la

localización de la caja en el caso que lo requiera. Al realizar

cualquier modificación se debe generar un nuevo reporte con la

TRD.


35


Identificador 12

Nombre Desincorporar documentación


Prioridad Alta

Descripción Se requiere desincorporar aquellas carpetas que han cumplido con

el tiempo de retención establecido por el usuario, o en dado caso de

que se requiera, extenderle el tiempo de retención a la carpeta.

Aquellas carpetas que sean desincorporadas, el usuario requiere la

opción de almacenar un archivo digitalizado de la misma. Esto

permitirá mayor orden, evitando acumular carpetas que han perdido

valor.



Identificador 13

Nombre Registrar préstamo


Prioridad Alta

Descripción Se requiere un control de acceso de las carpetas, registrar quien las

consulta, ubicar rápidamente donde esta se encuentra localizada, la

fecha de préstamo y devolución. Al finalizar el registro se generara

un reporte para que el usuario lleve un control de sus préstamos.


36


Identificador 14

Nombre Devolver préstamo


Prioridad Alta

Descripción Se requiere un módulo donde el usuario registre la devolución de

las carpetas con solo ingresar el número de caja.



Identificador 15

Nombre Consultar carpetas


Prioridad Media

Descripción Se requiere realizar consultas a todas las carpetas registradas y que

exista la opción de generar un reporte con el resultado de la

consulta.



Identificador 16

Nombre Consultar prestamos


Prioridad Media

Descripción Se requiere realizar consultas a los préstamos realizados por los

usuarios, a fin de conocer quienes han accedido a las carpetas, y que

exista la opción de generar un reporte con el resultado de la

consulta.


37


Identificador 17

Nombre Consultar localizaciones


Prioridad Media

Descripción Se requiere realizar consultas de aquellas localizaciones del archivo

central que se encuentren vacantes u ocupados.



Identificador 18

Nombre Administrar usuarios


Prioridad Alta

Descripción El administrador requiere crear y editar las cuentas de usuario que

podrán crear, editar, desincorporar, consultar o registrar préstamo

de las carpetas.



Identificador 19

Nombre Mantenimiento de menús


Prioridad Alta

Descripción Se requiere un módulo para crear o editar la descripción de los

menús que forman parte del sistema, los cuales irán integrados en

cada rol de usuario.


38


Identificador 20

Nombre Definir roles


Prioridad Alta

Descripción Se requiere crear, editar y eliminar los distintos roles que los

usuarios tendrán con el fin de mantener un mayor control sobre los

menús a los cuales podrán acceder.



Identificador 21

Nombre Asignar roles


Prioridad Alta

Descripción Se requiere asignar o quitar los roles previamente creados a los

usuarios, por lo cual un usuario podrá tener uno o más roles

dependiendo del caso


5.1.2. Planificación de entregas

Para cumplir con los requerimientos del usuario, se realizó la planificación donde

se establece la duración y fechas de entrega de las tareas basadas en las historias de

usuario, en la cual se tomara en cuenta la prioridad que cada una tenga. Las tareas a

realizar son las siguientes:

39

Tabla Nº 22. Tarea Nº 1

Nombre de la tarea: Análisis del sistema actual

Numero de historias: 1

Fecha de inicio: 14 / 05 / 2012

Fecha de finalización: 01 / 06 / 2012

Descripción: Identificar los procesos, conocer el funcionamiento general, identificar

entradas y salidas, evaluar fortalezas y debilidades.



Nombre de la tarea: Análisis del sistema propuesto




Descripción: Identificar los procesos, conocer el funcionamiento general, identificar

entradas y salidas, realizar mapa de navegación.



Nombre de la tarea: Diseño y desarrollo de la base de datos




Descripción: Diseñar la estructura de la base de datos en base a los requerimientos,

definir los campos, tablas y relaciones, normalización y desarrollar la base de datos

en MySQL.


40


Nombre de la tarea: Diseño y desarrollo del módulo “parámetros”




Descripción: Diseñar y desarrollar el modulo para la creación, o modificación de los

parámetros los cuales permitirá un funcionamiento correcto y controlado del sistema.



Nombre de la tarea: Diseño y desarrollo del módulo “departamentos”




Descripción: Diseñar y desarrollar el modulo donde el usuario podrá crear,

modificar o eliminar los departamentos y dependencias de la empresa que utilizaran

el sistema, los cuales estarán relacionados con las carpetas y los usuarios.



Nombre de la tarea: Diseño y desarrollo del módulo “localizaciones”





modificar o eliminar las localizaciones del archivo central donde se almacenan las

cajas que contienen las carpetas.


41


Nombre de la tarea: Diseño y desarrollo del módulo “valor documental”





modificar o eliminar los valores documentales y su tiempo de retención en años, los

cuales estarán asignados a cada carpeta registrada y permitirá calcular la fecha

máxima de retención cada vez que se registre una carpeta.



Nombre de la tarea: Diseño y desarrollo del módulo “Tipo de carpetas”





modificar o eliminar los tipos de carpeta, los cuales estarán asignados a cada carpeta

registrada.


42


Nombre de la tarea: Diseño y desarrollo del módulo “Ingresar TRD”




Descripción: Diseñar y desarrollar el modulo donde el usuario podrá ingresar los

datos de la tabla de retención documental (TRD), la fecha de transferencia de la

carpeta, crear cajas, asignarlas a una localización y generar un reporte en formato

PDF donde se muestre la TRD.



Nombre de la tarea: Diseño y desarrollo del módulo “Modificar TRD”




Descripción: Diseñar y desarrollar el modulo donde el usuario podrá modificar los

datos de la tabla de retención documental en caso de algún error o actualización,

cambio de localización de alguna caja o datos de la misma y generar un reporte en

formato PDF donde se muestre la TRD actualizada.


43


Nombre de la tarea: Diseño y desarrollo del módulo “Desincorporar”




Descripción: Diseñar y desarrollar el modulo donde el usuario podrá realizar una

búsqueda de las carpetas que hay en el sistema, clasificadas por fecha (aquellas que

ya excedieron la fecha de retención, y aquellas que aún no).

Diseñar y desarrollar el submodulo donde el usuario podrá decidir si desea conservar

una carpeta, crear caja o reasignar esta carpeta a una nueva caja en caso de que

adquiera un nuevo valor documental y generar un reporte en formato PDF donde se

muestre la TRD actualizada.

Diseñar y desarrollar el submodulo donde el usuario podrá desincorporar carpetas y

guardar una digitalización de la misma en la base de datos si lo desea.



Nombre de la tarea: Diseño y desarrollo del módulo “Registrar Préstamo”





búsqueda de las carpetas que hay en el sistema, registrar el préstamo de una o más de

ellas y generar un reporte en formato PDF que servirá de control para el usuario.


44


Nombre de la tarea: Diseño y desarrollo del módulo “Devolución Préstamo”




Descripción: Diseñar y desarrollar el modulo donde el usuario podrá registrar la

devolución de las carpetas en préstamo.



Nombre de la tarea: Diseño y desarrollo del módulo “Admón. Usuarios”




Descripción: Diseñar y desarrollar el modulo donde el administrador podrá crear o

editar los usuarios que tendrán acceso al sistema y realizar un cambio de contraseña

si el caso lo amerita.



Nombre de la tarea: Diseño y desarrollo del módulo “Mant. Menús”




Descripción: Diseñar y desarrollar el modulo donde el administrador podrá crear o

editar la descripción de los menús que forman parte del sistema.


45


Nombre de la tarea: Diseño y desarrollo del módulo “Definir Roles”




Descripción: Diseñar y desarrollar el modulo donde el administrador podrá crear,

editar y eliminar los roles de usuario.



Nombre de la tarea: Diseño y desarrollo del módulo “Asignar Roles”




Descripción: Diseñar y desarrollar el modulo donde el administrador podrá asignar o

eliminar roles a los usuarios.



Nombre de la tarea: Diseño y desarrollo del módulo “Consultar Carpetas”





búsqueda detallada de las carpetas registradas en el sistema y generar un archivo en

Excel con el resultado de la búsqueda.


46


Nombre de la tarea: Diseño y desarrollo del módulo “Consultar Préstamo”





búsqueda detallada de los prestamos registrados por los distintos usuarios del sistema

y generar un archivo en Excel con el resultado de la búsqueda.



Nombre de la tarea: Diseño y desarrollo del módulo “Consultar localizaciones”





búsqueda detallada de los prestamos registrados por los distintos usuarios.



Nombre de la tarea: Diseño y desarrollo de la página de acceso y el menú principal.

Ensamblaje de los módulos.

Numero de historias: Todas



Descripción: Diseño y desarrollo de la página principal de acceso, el menú principal

y el acceso a cada uno de los módulos del sistema.


47


Nombre de la tarea: Migrar la data almacenada en una hoja en formato MS-Excel a

la base de datos MySQL.




Descripción: Ingresar los datos de las carpetas que se encuentran en una hoja de

Excel en el sistema y almacenarlos en la base de datos.


5.1.3. Iteraciones

Para cumplir con las tareas mencionadas en el punto anterior, se realiza una

planificación en ocho (8) iteraciones, cada una con un periodo de tres (3) semanas de

duración, comenzando por aquellas de alta prioridad, a fin de realizar entregas

prontas al cliente y que exista una retroalimentación de las tareas realizadas. Las

iteraciones para este proyecto se muestran a continuación de manera detallada:

Tabla Nº 44. Iteración Nº 1

Iteración Nº1

Tareas Análisis del sistema actual

Historias de usuario 1

Fecha de inicio 14 / 05 / 2012

Fecha de finalización 01 / 06 / 2012


48


Iteración Nº2

Tareas Análisis del sistema propuesto






Iteración Nº3

Tareas Diseño y desarrollo de la base de datos






Iteración Nº4

Tareas Diseño y desarrollo del módulo “parámetros”

Diseño y desarrollo del módulo “departamentos”

Diseño y desarrollo del módulo “localizaciones”

Diseño y desarrollo del módulo “valor documental”

Diseño y desarrollo del módulo “Tipo de carpetas”

Historias de usuario 5, 6, 7, 8, 9




49


Iteración Nº5

Tareas Diseño y desarrollo del módulo “Ingresar TRD”

Diseño y desarrollo del módulo “Modificar TRD”

Historias de usuario 10, 11





Iteración Nº6

Tareas Diseño y desarrollo del módulo “Desincorporar”

Diseño y desarrollo del módulo “Registrar

Préstamo”

Diseño y desarrollo del módulo “Devolución

Préstamo”

Historias de usuario 12, 13, 14




50


Iteración Nº7

Tareas Diseño y desarrollo del módulo “Admón. Usuarios”

Diseño y desarrollo del módulo “Mant. Menús”

Diseño y desarrollo del módulo “Definir Roles”

Diseño y desarrollo del módulo “Asignar Roles”

Historias de usuario 18, 19, 20, 21





Iteración Nº8

Tareas Diseño y desarrollo del módulo “Consultar

Carpetas”

Diseño y desarrollo del módulo “Consultar

Préstamo”

Diseño y desarrollo del módulo “Consultar

localizaciones”

Diseño y desarrollo de la página de acceso y el

menú principal. Ensamblaje de los módulos.

Migrar la data almacenada en una hoja en formato

MS-Excel a la base de datos MySQL

Historias de usuario Todas




51

5.2. FASE II. DISEÑO

5.2.1. Diagramas de Entidad-Relación

Se realizó el diagrama Entidad-Relación como apoyo para el diseño de la base de

datos donde se representa las entidades relevantes del sistema así como sus interrelaciones

y propiedades:

Gráfico Nº 6. Diagrama Entidad-Relación.

Fuente: Da Silva, Sergio (2012). diaw.exe 0.97.1

52



53



5.2.2. Diccionario de datos

Además del diagrama de entidad-relación, se realizó un diccionario de datos,

donde se especificó la metadata y la relación entre tablas, para obtener un desarrollo

correcto y más simple de la base de datos, cumpliendo con los requerimientos del

cliente y del sistema:

54

Tabla Nº 52. Diccionario de datos. Tabla “Usuarios”

Nombre de Tabla: Usuario Fecha de Creación: 09/07/2012

Descripción: Contiene información personal de cada uno de los empleados

Campo Tipo Longitud Descripción

idUsuario Caractér 12 ID de cada usuario. Por políticas de la

empresa, el ID de usuario consta de las

iniciales del nombre y el primer

apellido completo.

Clave Caractér 12 Contraseña de ingreso del usuario

Nombre Caractér 25 Nombre del usuario

Apellido Caractér 25 Apellido del usuario

Cedula Caractér 10 Cedula de identidad del usuario

Usuario_Creador Caractér 12 Usuario que creó el registro

Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro de

usuario

Clave Foránea: Campos Clave:

idUsuario Fuente: Da Silva, Sergio (2012).

Tabla Nº 53. Diccionario de datos. Tabla “Parámetro”

Nombre de Tabla: Parámetro Fecha de Creación: 09/07/2012

Descripción: Contiene los parámetros necesarios para validar el ingreso de

información al sistema


idParametro Entero 3 ID del parámetro. Este valor se

autoincrementa.

Descripción Caractér 40 Descripción del parámetro

Valor Entero 5 Valor del parámetro

idDpto_Dep Entero 3 ID de dependencia por departamento

Usuario Caractér 12 ID del usuario que creó el parámetro

Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del parámetro


idParametro Fuente: Da Silva, Sergio (2012).

55

Tabla Nº 54. Diccionario de datos. Tabla “Departamento”

Nombre de Tabla: Departamento Fecha de Creación: 09/07/2012

Descripción: Contiene la descripción de cada uno de los departamentos existentes

en la empresa


idDpto Entero 3 ID del departamento. Se

autoincrementa.

Descripción Caractér 20 Nombre del departamento

Usuario Caractér 12 ID del usuario que creó el registro del

departamento

Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro de

departamento


idDpto Fuente: Da Silva, Sergio (2012).

Tabla Nº 55. Diccionario de datos. Tabla “Dpto_Dep”

Nombre de Tabla: Dpto_Dep Fecha de Creación: 09/07/2012

Descripción: Contiene a que departamento corresponde cada una de las

dependencias de la empresa


idDpto_Dep Entero 3 ID de dependencia por departamento.

Se autoincrementa.

idDpto Entero 3 ID de departamento

idDep Entero 3 ID de dependencia

Usuario Caractér 12 ID del usuario que creó el registro

Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro


idDpto con el campo idDpto de la tabla Departamento

idDep con el campo idDep de la tabla Dependencia

idDpto_Dep


56

Tabla Nº 56. Diccionario de datos. Tabla “Dependencia”

Nombre de Tabla: Dependencia Fecha de Creación: 09/07/2012

Descripción: Contiene la descripción de cada una de las dependencias

pertenecientes a la empresa


idDep Entero 3 ID de la dependencia. Se

autoincrementa.

Descripción Caractér 30 Nombre de la dependencia

Usuario Caractér 12 ID del usuario que creó el registro



idDep Fuente: Da Silva, Sergio (2012).

Tabla Nº 57. Diccionario de datos. Tabla “Usuario_Dpto”

Nombre de Tabla: Usuario_Dpto Fecha de Creación: 10/07/2012

Descripción: Contiene a cada uno de los usuarios y los departamentos y

dependencias a los cuales se encuentra asociado.


idUsuario_Dpto Entero 5 ID de Usuario por departamento. Se

autoincrementa.

idDpto_Dep Entero 3 ID de dependencia por departamento

idUsuario Caractér 12 ID del usuario que tendrá el acceso

Usuario_Creador Caractér 12 ID del usuario que creó el registro

Fecha_Creacion Fecha aaaa/mm/dd Fecha de registro de acceso


idUsuario con el campo idUsuario de la tabla Usuario

idDpto_Dep con el campo idDpto_Dep de la tabla

Dpto_Dep

idUsuario

idDpto_Dep


57

Tabla Nº 58. Diccionario de datos. Tabla “Rol_Usuario”

Nombre de Tabla: Rol_Usuario Fecha de Creación: 10/07/2012

Descripción: Contiene cada uno de los roles que posee el usuario


idRol_Usuario Entero 5 ID de acceso por usuario. Se

autoincrementa.

idUsuario Caractér 12 ID del usuario

idRol Entero 5 ID del rol




idRol con el campo idRol de la tabla Rol


idRol_Usuario


Tabla Nº 59. Diccionario de datos. Tabla “Rol”

Nombre de Tabla: Rol Fecha de Creación: 10/07/2012

Descripción: Contiene la descripción de cada uno de los roles


idRol Entero 5 ID de acceso por usuario. Se

autoincrementa.

Nombre_Rol Caractér 20 ID del usuario




idRol Fuente: Da Silva, Sergio (2012).

58

Tabla Nº 60. Diccionario de datos. Tabla “Menu_Rol”

Nombre de Tabla: Menu_Rol Fecha de

Creación:

10/07/2012

Descripción: Contiene los menús asociados a cada rol


idMenu_Rol Entero 5 ID de menú por rol. Se autoincrementa.

idMenus Entero 5 ID del menú

idRol Entero 5 ID del rol




idMenus con el campo idMenus de la tabla Menú


idMenu_Rol


Tabla Nº 61. Diccionario de datos. Tabla “Menú”

Nombre de Tabla: Menu Fecha de Creación: 10/07/2012

Descripción: Contiene los menús asociados a cada rol


idMenus Entero 5 ID de menú por rol. Se autoincrementa.

Menú Caractér 15 ID del menú

Submenu Caractér 20 ID del rol




idMenus con el campo idMenus de la tabla Menú


idMenu_Rol


59

Tabla Nº 62. Diccionario de datos. Tabla “Destrucción”

Nombre de Tabla: Destrucción Fecha de Creación: 11/07/2012

Descripción: Contiene los registros de cada carpeta que ha sido desincorporada de

los archivos inactivos.


idDestruccion Entero 8 ID de la destrucción. Se

autoincrementa.

idUsuario Caractér 12 ID del usuario quien destruye la carpeta

idCarpeta Entero 8 ID de la carpeta destruida

Dpto Caractér 20 Nombre del departamento al que

pertenece la carpeta

Fecha_Destr Fecha y

Hora

aaaa/mm/dd

HH:MM:SS

Fecha y hora en la que se realizo la

destrucción de la carpeta




idCarpeta con el campo idCarpeta de la tabla Carpeta

idDestruccion


Tabla Nº 63. Diccionario de datos. Tabla “Traslado”

Nombre de Tabla: Traslado Fecha de Creación: 11/07/2012

Descripción: Contiene la información de cada traslado registrado en el sistema


idTraslado Entero 8 ID del traslado de la caja. Se

autoincrementa.

idCarpeta Entero 8 ID de la carpeta a trasladar

Usuario Caractér 12 ID del usuario que registro el traslado

Fecha_Traslado Fecha y

Hora

aaaa/mm/dd

HH:MM:SS

Fecha y hora de traslado de cada carpeta



idCarpeta con el campo idCarpeta de la tabla Carpeta idTraslado Fuente: Da Silva, Sergio (2012).

60

Tabla Nº 64. Diccionario de datos. Tabla “Carpeta”

Nombre de Tabla: Carpeta Fecha de Creación: 12/07/2012

Descripción: Contiene toda la información de las carpetas.


idCarpeta Entero 8 ID de la carpeta. Se autoincrementa.

idCaja Entero 8 ID de caja a la cual pertenece la carpeta.

SI el valor es nulo, significa que la

carpeta ha sido destruida.

idTipoCarpeta Entero 3 ID del tipo de carpeta

idUsuario Caractér 12 ID de usuario que realizo el registro

Fecha_Ini Fecha aaaa/mm/dd Fecha más antigua de los documentos

que se encuentran en la carpeta.

Fecha_Fin Fecha aaaa/mm/dd Fecha más reciente de los documentos

que se encuentran en la carpeta.

Serie Caractér 30 Serie documental. Corresponde al grupo

de documentos.

Subserie Caractér 100 Subserie documental. Aquella serie

perteneciente a un grupo de

documentos.

nSerieInf Entero 8 Numero de serie inferior de la carpeta

nSerieSup Entero 8 Numero de serie superior de la carpeta

FechaMaxRet Fecha aaaa/mm/dd Fecha máxima de retención de la

carpeta en archivos muertos.

Fecha_Creacion Fecha aaaa/mm/dd Fecha de registro de la carpeta


idCaja con el campo idCaja de la tabla Caja

idTipoCarpeta con el campo idTipoCarpeta de la tabla

TipoCarpeta

idCarpeta


61

Tabla Nº 65. Diccionario de datos. Tabla “Caja”

Nombre de Tabla: Caja Fecha de Creación: 12/07/2012

Descripción: Contiene la información de cada una de las cajas. Cada caja tiene un

único valor documental y pertenece a un único departamento.


idCaja Entero 8 ID de la caja. Se autoincrementa.

idDpto_Dep Entero 3 ID de dependencia por departamento al

que pertenece la caja

idUbicacion Entero 8 ID de la ubicación donde se encuentra

la caja.

idValorDoc Entero 3 ID de valor documental.

Disponibilidad Caractér 15 Disponibilidad de la caja: disponible,

en uso, destruida

Capacidad Booleano 1

1 si la caja está llena, 0 si la caja tiene

espacio disponible para insertar

carpetas

Usuario Caractér 12 Usuario que creó el registro



idDpto_Dep con el campo idDpto_Dep de la tabla

Dpto_Dep

idUbicacion con el campo idUbicacion de la tabla

ubicación

idValorDoc con el campo idValorDoc de la tabla valordoc

idCaja

idDpto_Dep


62

Tabla Nº 66. Diccionario de datos. Tabla “Localizacion”

Nombre de Tabla: Localizacion Fecha de Creación: 12/07/2012

Descripción: Contiene en que estante se encuentra localizada cada caja.


idLocalizacion Entero 8 ID de localización. Se

autoincrementa.

idDpto Entero 3 ID del departamento al que pertenece

la localización

Fila Entero 5 Numero de fila

Estante Caractér 5 Numero de estante


Fecha_Creacion aaaa/mm/dd Fecha Fecha de creación del registro


idDpto con el campo idDpto de la tabla departamento idLocalizacion Fuente: Da Silva, Sergio (2012).

Tabla Nº 67. Diccionario de datos. Tabla “Ubicacion”

Nombre de Tabla: Ubicación Fecha de Creación: 12/07/2012

Descripción: Contiene en ubicación del estante se encuentra cada caja.


idUbicacion Entero 8 ID de ubicación. Se autoincrementa.

idLocalizacion Entero 8 ID de localización.

Disponibilidad Caractér 15 Indica si la ubicación está vacante u

ocupada por una caja


Fecha_Creacion aaaa/mm/dd Fecha Fecha de creación del registro


idLocalizacion con el campo idLocalizacion de la tabla

Localizacion

idUbicacion


63

Tabla Nº 68. Diccionario de datos. Tabla “Prestamo”

Nombre de Tabla: Prestamo Fecha de Creación: 13/07/2012

Descripción: Contiene los registros de los préstamos de cajas.


idPrestamo Entero 8 ID del préstamo. Se autoincrementa.

idUsuario Caractér 25 ID del usuario que solicito el

préstamo.

idCaja Entero 8 ID de la caja a prestar.

Fecha_Prestamo Fecha y

hora

aaaa/mm/dd

HH:MM:SS

Fecha y hora de registro del

préstamo.

Entrega_Estimada Fecha y

hora

aaaa/mm/dd

HH:MM:SS

Fecha y hora estimada en la cual se

hará la entrega.

Entrega_Prestamo Fecha y

hora

aaaa/mm/dd

HH:MM:SS

Fecha y hora de entrega del

préstamo. Si el campo es nulo, es

porque la caja no ha sido entregada.

Observación Caractér 70 Observaciones acerca del préstamo.

El campo puede ser nulo.

idUsuario_Receptor Caractér 12 Usuario que recibe la caja. SI el

campo es nulo, quien recibe la caja es

el usuario que realizo el registro.

Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro.


idUsuario con idUsuario de la tabla Usuario

idCaja con idCaja de la tabla Caja

idPrestamo


64

Tabla Nº 69. Diccionario de datos. Tabla “Valordoc”

Nombre de Tabla: valordoc Fecha de Creación: 13/07/2012

Descripción: Contiene los valores documentales y el tiempo de retención de cada

valor.


idValorDoc Entero 3 ID del valor documental. Se

autoincrementa.

Descripcion Caractér 15 Descripción o nombre del valor

documental.

Anos_Ret Entero 3 Tiempo de retención de los

documentos en años.

Usuario Caractér 12 Usuario que realizo el registro.



idValorDoc Fuente: Da Silva, Sergio (2012).

Tabla Nº 70. Diccionario de datos. Tabla “Tipocarpeta”

Nombre de Tabla: tipocarpeta Fecha de Creación: 13/07/2012

Descripción: Contiene los tipos de carpetas donde se archivan los documentos.


idTipoCarpeta Entero 3 ID del tipo de carpeta. Se

autoincrementa.

Descripcion Caractér 20 Descripcion del tipo de carpeta.

Usuario Caractér 12 Usuario que realizo el registro.



idTipoCarpeta Fuente: Da Silva, Sergio (2012).

65

Tabla Nº 71. Diccionario de datos. Tabla “Digitalizacion”

Nombre de Tabla: Digitalizacion Fecha de Creación: 11/07/2012

Descripción: Almacena la digitalización de las carpetas que han sido destruidas.


idDigitalizacion Entero 10 ID de digitalización. Se

autoincrementa.

idCarpeta Entero 8 ID de carpeta a digitalizar

Nombre_Archivo Caractér 25 Nombre del archivo

Tipo_Archivo Caractér 25 Tipo de archivo

Tamano_Archivo Entero 10 Tamaño del archivo

Ruta Caractér 260 Ruta del archivo que se digitalizo

Dpto Caractér 20 Departamento al cual pertenece la

carpeta digitalizada

Usuario Caractér 12 Usuario que realizo el registro

Fecha_Creacion Fecha aaaa/mm/dd Fecha de registro de la digitalización


idCarpeta con el campo idCarpeta de la tabla Carpeta idDigitalizacion Fuente: Da Silva, Sergio (2012).

66

5.2.3. Diagramas de caso de uso

Se realizó el diagrama de casos de uso correspondiente a este proyecto para

describir la funcionalidad del sistema desde el punto de vista del cliente, detallando

todos los requisitos y acciones que el usuario estará involucrado.

Gráfico Nº 9. Diagrama de caso de uso del usuario.


67



68



69

Gráfico Nº8. Diagrama de caso de uso del administrador.


70

5.2.4. Especificación de caso de uso

Se realizó cada uno de los casos de uso presentes en los diagramas:

Tabla Nº 72. Especificación de caso de uso “Crear parámetros”


Caso de uso Crear parámetros

Entradas ID de usuario

Contraseña de usuario

Descripción del parámetro

Valor del parámetro

Precondiciones El usuario debe estar registrado

El usuario debe tener un rol que le permita acceder a

este menú.

Salidas Una tabla con todos los parámetros.

Post-condición éxito El parámetro aparecerá en la tabla

Post-condición fallo Ninguno

Rol responsable Usuarios

Flujo principal

1. El usuario accede al sistema con su ID y contraseña

2. El sistema valida que la información del usuario sea correcta

3. El usuario ingresa la descripción del parámetro y el valor

4. El sistema guarda la información en la base de datos.

Flujo alternativo

3.1. El usuario decide cancelar la operación

Observaciones

Los campos no pueden ser nulos.

71

Tabla Nº 73. Especificación de caso de uso “Modificar parámetros”


Caso de uso Modificar parámetro



Valor del parámetro



este menú.

Salidas Una tabla con todos los parámetros

Post-condición éxito El valor del parámetro aparecerá modificado en la

tabla



Flujo principal



3. El usuario modifica el valor del parámetro

4. El sistema guarda la información modificada en la base de datos.

Flujo alternativo


Observaciones


72

Tabla Nº 74. Especificación de caso de uso “Crear departamento”


Caso de uso Crear departamento



Descripción del departamento

Descripción de la dependencia



este menú.

Salidas Una tabla con todos los departamentos.

Post-condición éxito El departamento aparecerá en la tabla.



Flujo principal



3. El usuario ingresa la descripción del departamento y la dependencia


Flujo alternativo


Observaciones


73

Tabla Nº 75. Especificación de caso de uso “Editar departamento”


Caso de uso Editar departamento



Descripción del departamento



este menú.

El departamento debe existir

Salidas Una tabla con todos los departamentos

Post-condición éxito La descripción del departamento aparecerá

modificado en la tabla



Flujo principal



3. El usuario modifica la descripción del departamento


Flujo alternativo


Observaciones


74

Tabla Nº 76. Especificación de caso de uso “Eliminar departamento”


Caso de uso Eliminar departamento





este menú.

El departamento debe existir

Salidas Una tabla con todos los departamentos

Post-condición éxito El departamento desaparece de la tabla.

Post-condición fallo Mensaje de error, debido a que el departamento está

asociado con un usuario o carpeta.


Flujo principal



3. El usuario decide eliminar el departamento y las dependencias asociadas a

este.

4. El sistema elimina la información en la base de datos.

Flujo alternativo


Observaciones

Para poder eliminar un departamento, este no puede estar asociado a ninguna

carpeta o usuario registrado.

75

Tabla Nº 77. Especificación de caso de uso “Crear dependencia”


Caso de uso Crear dependencia






este menú.

Salidas Una tabla con los departamentos

Una tabla con las dependencias de ese departamento

Post-condición éxito La dependencia aparece en la tabla



Flujo principal



3. El usuario ingresa la descripción de la dependencia


Flujo alternativo


Observaciones


76

Tabla Nº 78. Especificación de caso de uso “Editar dependencia”


Caso de uso Editar dependencia






este menú.

La dependencia debe existir



Post-condición éxito La descripción de la dependencia aparecerá

modificado en la tabla



Flujo principal



3. El usuario modifica la descripción de la dependencia


Flujo alternativo


Observaciones


77

Tabla Nº 79. Especificación de caso de uso “Eliminar dependencia”


Caso de uso Eliminar dependencia





este menú.



Post-condición éxito La dependencia desaparece de la tabla.

Post-condición fallo Mensaje de error, debido a que la dependencia está

asociado con un usuario o carpeta.


Flujo principal



3. El usuario decide eliminar la dependencia


Flujo alternativo


Observaciones

Para poder eliminar una dependencia, esta no puede estar asociada a ninguna

carpeta o usuario registrado.

78

Tabla Nº 80. Especificación de caso de uso “Crear localización”


Caso de uso Crear localización



Descripción del estante

Numero de fila



este menú.

Salidas Una tabla con las localizaciones

Post-condición éxito La localización aparecerá en una tabla

Post-condición fallo No se crea la localización, ya que el estante y la fila

ya están registrados.


Flujo principal



3. El usuario introduce un identificador del estante y el número de fila


Flujo alternativo


Observaciones

Los campos no pueden ser nulos. La localización no puede repetirse.

79

Tabla Nº 81. Especificación de caso de uso “Editar localización”


Caso de Uso Editar localización



Numero de fila



este menú.


Post-condición éxito La localización aparecerá modificada en la tabla

Post-condición fallo No se crea la localización, ya que el estante y la fila

ya están registrados.


Flujo principal



3. El usuario modifica el número de fila


Flujo alternativo


Observaciones

Los campos no pueden ser nulos. La localización no puede repetirse.

80

Tabla Nº 82. Especificación de caso de uso “Eliminar localización”


Caso de uso Eliminar localización





este menú.


Post-condición éxito La localización desaparece de la tabla

Post-condición fallo Mensaje de error, ya que existen cajas en esa

localización


Flujo principal



3. El usuario decide eliminar la localización


Flujo alternativo


Observaciones

Para poder eliminar una localización, esta no puede estar asociada a ninguna caja.

81

Tabla Nº 83. Especificación de caso de uso “Crear ubicación”


Caso de uso Crear ubicación





este menú.


Una tabla con las ubicaciones asociadas a esa

localización

Post-condición éxito La ubicación aparecerá en la tabla



Flujo principal



3. El usuario decide agregar una ubicación


Flujo alternativo


Observaciones

82

Tabla Nº 84. Especificación de caso de uso “Editar ubicación”


Caso de uso Editar ubicación



Estatus de la ubicación



este menú.


Una tabla con las ubicaciones asociadas a esa

localización

Post-condición éxito La ubicación cambia de ocupado a vacante o

viceversa



Flujo principal



3. El usuario modifica estatus de la ubicación


Flujo alternativo


Observaciones

83

Tabla Nº 85. Especificación de caso de uso “Crear valor”


Caso de uso Crear valor



Descripción del valor documental

Tiempo de retención en años



este menú.

Salidas Una tabla con los valores documentales y el tiempo

de retención en años

Post-condición éxito La descripción del valor documental y el tiempo de

retención aparecerá en una tabla



Flujo principal



3. El usuario ingresa la descripción del valor documental y el tiempo de

retención en años


Flujo alternativo


Observaciones

Los campos no pueden ser nulos

84

Tabla Nº 86. Especificación de caso de uso “Modificar valor”


Caso de uso Modificar valor




Tiempo de retención en años



este menú.




retención aparecerá modificado en la tabla



Flujo principal



3. El usuario ingresa la descripción del valor documental y el tiempo de

retención en años


Flujo alternativo


Observaciones


85

Tabla Nº 87. Especificación de caso de uso “Eliminar valor”


Caso de uso Eliminar valor





este menú.




retención desaparecerá de la tabla

Post-condición fallo Mensaje de error, ya que el valor documental está

asociado a una caja o carpeta.


Flujo principal



3. El usuario decide eliminar el valor documental


Flujo alternativo


Observaciones

El valor documental no puede estar asociado a una carpeta o caja, de lo contrario

no se podrá eliminar.

86

Tabla Nº 88. Especificación de caso de uso “Crear tipo de carpeta”


Caso de uso Crear tipo de carpeta



Descripción del tipo de carpeta



este menú.

Salidas Una tabla con los tipos de carpeta

Post-condición éxito El tipo de carpeta aparecerá en la tabla



Flujo principal



3. El usuario ingresa la descripción del tipo de carpeta

4. El sistema guarda la información en la base de datos

Flujo alternativo


Observaciones


87

Tabla Nº 89. Especificación de caso de uso “Modificar tipo de carpeta”


Caso de uso Modificar tipo de carpeta



Descripción del tipo de carpeta



este menú.


Post-condición éxito El tipo de carpeta aparecerá modificado en la tabla



Flujo principal



3. El usuario modifica la descripción del tipo de carpeta


Flujo alternativo


Observaciones


88

Tabla Nº 90. Especificación de caso de uso “Eliminar tipo de carpeta”


Caso de uso Eliminar tipo de carpeta





este menú.


Post-condición éxito El tipo de carpeta desaparecerá de la tabla

Post-condición fallo Mensaje de error, ya que el tipo de carpeta está

asociado a una carpeta


Flujo principal



3. El usuario decide eliminar el tipo de carpeta


Flujo alternativo


Observaciones

Si el tipo de carpeta está asociado a una carpeta, el registro no se eliminara.

89

Tabla Nº 91. Especificación de caso de uso “Ingresar tabla de retención documental”

Caso de uso Ingresar tabla de retención documental



Número de serie inferior

Número de serie superior

Serie

Subserie

Fecha inicial

Fecha final

Valor documental

Tipo de carpeta

Fecha de transferencia

Ubicación



este menú.

Debe estar previamente registrado los valores

documentales y los tipos de carpeta en el sistema

Debe existir ubicaciones disponibles para crear las

cajas que almacenaran las carpetas

Salidas Tabla de retención documental

Post-condición éxito Se generara un reporte donde se muestra la tabla de

retención documental

Post-condición fallo No se puede registrar la información porque no hay

ubicaciones disponibles para almacenar la carpeta


Flujo principal



3. El usuario ingresa todos los datos de la carpeta en un formulario

4. El usuario crea una caja donde le indica el estante, fila y ubicación de la

misma

5. El usuario introduce la carpeta en la caja

90


6. Se genera un reporte con la tabla de retención documental

Flujo alternativo

4.1.El usuario inserta la carpeta en una caja existente que tenga espacio

disponible. Se omite el paso 5.

Observaciones

Los campos no pueden ser nulos. Las fechas deben ser coherentes. Para poder

ingresar la información de la carpeta, debe existir una ubicación disponible donde

estará almacenada la carpeta, de lo contrario no se podrá realizar el registro.

91

Tabla Nº 92. Especificación de caso de uso “Modificar tabla de retención documental”

Caso de uso Modificar tabla de retención documental



Número de serie inferior

Número de serie superior

Serie

Subserie

Fecha inicial

Fecha final

Valor documental

Tipo de carpeta


Ubicación

Capacidad de la caja

Departamento y dependencia al que pertenece la

caja



este menú.

Salidas La tabla de retención documental



Post-condición fallo No se puede cambiar la caja de ubicación, ya que no

existen ubicaciones disponibles


Flujo principal



3. El usuario realiza la búsqueda de la carpeta

4. El usuario decide si modifica los datos de la carpeta, de la caja o de su

ubicación

5. El sistema guarda los cambios en la base de datos


92


Flujo alternativo

Observaciones

Si el usuario decide cambiar la caja de ubicación, debe existir otra ubicación

disponible. El usuario solo podrá consultar carpetas que pertenecen a su

departamento

93

Tabla Nº 93. Especificación de caso de uso “Conservar carpetas”


Caso de uso Conservar carpetas







este menú.

Salidas La tabla de retención documental





Flujo principal




4. El usuario le asigna un nuevo valor documental a la carpeta a conservar y la

fecha de transferencia

5. El usuario crea una nueva caja

6. El usuario inserta la carpeta en la caja


Flujo alternativo

5.1. El usuario inserta la carpeta en una caja que esté disponible. Se omite el

paso 6.

Observaciones

No se podrá realizar la operación si no existen cajas disponibles o ubicaciones

disponibles para una nueva caja.

94

Tabla Nº 94. Especificación de caso de uso “Destruir carpeta”


Caso de uso Destruir carpeta



Fecha de destrucción

Nombre del archivo digitalizado

Ruta del archivo



este menú.

Salidas Ninguna

Post-condición éxito Mensaje donde se indica que el archivo fue

guardado exitosamente

Post-condición fallo Mensaje de error al intentar subir un archivo que no

cumple las condiciones


Flujo principal



3. El usuario ingresa la fecha de destrucción de la carpeta

4. El sistema guarda el registro en la base de datos

5. El usuario introduce el nombre del archivo y la ruta del mismo. Repite el

paso 3 tantos archivos sean necesarios

6. El usuario finaliza la carga de archivos y el sistema los almacena en la base

de datos

Flujo alternativo

3.1. El usuario cancela la destrucción

5.1. El usuario cancela la digitalización y finaliza la destrucción.

Observaciones

El usuario no podrá subir archivos que sobrepasen un tamaño determinado y solo

podrá almacenar archivos tipo PDF o imágenes.

95

Tabla Nº 95. Especificación de caso de uso “Registrar préstamo”


Caso de uso Registrar préstamo



Fecha de entrega estimada

Persona que recibe (opcional)

Observación (opcional)



este menú.

Salidas Reporte de préstamo

Post-condición éxito Se emite un reporte del préstamo realizado



Flujo principal




4. El usuario introduce la fecha de entrega estimada y de manera opcional la

persona que recibe la caja y una observación

5. El sistema registra el préstamo en la base de datos y emite un reporte

Flujo alternativo

Observaciones

96

Tabla Nº 96. Especificación de caso de uso “Registrar devolución de préstamo”


Caso de uso Registrar devolución de préstamo



Número de caja

Fecha de entrega real



este menú.

Salidas Ninguna

Post-condición éxito Mensaje donde se indica que el registro se realizó

correctamente

Post-condición fallo El número de caja no existe


Flujo principal



3. El usuario ingresa el número de caja que desea regresar

4. El usuario ingresa la fecha de entrega real

5. El sistema registra la devolución de la caja

Flujo alternativo

Observaciones

97

Tabla Nº 97. Especificación de caso de uso “Consultar localizaciones”


Caso de uso Consultar localizaciones





este menú.

Salidas Ninguna

Post-condición éxito Se muestra un croquis con los estantes y una tabla

con las localizaciones



Flujo principal



3. El usuario escoge entre consultar las localizaciones disponibles u ocupadas

4. El sistema muestra la búsqueda y un croquis de los estantes.

Flujo alternativo

Observaciones

98

Tabla Nº 98. Especificación de caso de uso “Consultar carpetas”


Caso de uso Consultar carpetas





este menú.

Salidas El resultado de la consulta en pantalla

El resultado de la consulta en Excel (opcional)

Post-condición éxito El resultado de la consulta aparecerá en pantalla



Flujo principal



3. El usuario realiza la consulta de las carpetas según: disponibles en préstamo,

destruidas, digitalizadas o por usuario

4. El sistema muestra la consulta con la información disponible en la base de

datos y según el filtro de búsqueda

5. Si el usuario lo desea, se puede generar un reporte en Excel con el resultado

de la consulta

Flujo alternativo

Observaciones

99

Tabla Nº 99. Especificación de caso de uso “Consultar préstamo”


Caso de uso Consultar préstamo





este menú.

Salidas El resultado de la consulta en pantalla

El resultado de la consulta en Excel (opcional)

Post-condición éxito El resultado de la consulta aparecerá en pantalla



Flujo principal



3. El usuario realiza la consulta de los préstamos por usuario, fecha de

préstamo, fecha de entrega, departamento, caja o estante

4. El sistema muestra la consulta con la información disponible en la base de

datos y según el filtro de búsqueda

5. Si el usuario lo desea, se puede generar un reporte en Excel con el resultado

de la consulta

Flujo alternativo

Observaciones

100

Tabla Nº 100. Especificación de caso de uso “Crear usuarios”


Caso de uso Crear usuarios

Entradas ID de administrador

Contraseña de administrador

Nombre

Apellido

Cedula

ID del usuario

Contraseña del usuario

Dependencias a las que pertenece

Precondiciones El administrador debe estar registrado

Salidas Ninguna

Post-condición éxito El usuario aparecerá en la tabla de usuarios

Post-condición fallo Mensaje de error, debido a que el ID de usuario ya

existe

Rol responsable Administrador

Flujo principal

1. El administrador accede al sistema con su ID y contraseña

2. El sistema valida que la información del administrador sea correcta

3. El administrador rellena el formulario con los datos del usuario y las

dependencias a las que pertenece

4. El sistema almacena la información en la base de datos

Flujo alternativo

3.1. El usuario cancela la operación

Observaciones

Los campos no pueden ser nulos. El ID del usuario no se puede repetir.

101

Tabla Nº 101. Especificación de caso de uso “Editar usuarios”


Caso de uso Editar usuarios



Nombre

Apellido

Cedula

Dependencias a las que pertenece


El usuario debe estar registrado

Salidas Ninguna

Post-condición éxito El usuario aparecerá en la tabla de usuarios con la

información modificada



Flujo principal



3. El administrador modifica los datos del usuario en el formulario

4. El sistema modifica la información en la base de datos

Flujo alternativo


Observaciones

Los campos no pueden ser nulos. El ID del usuario no se puede repetir.

102

Tabla Nº 102. Especificación de caso de uso “Cambiar clave”


Caso de uso Cambiar clave



Contraseña del usuario


El usuario debe estar registrado

Salidas Ninguna

Post-condición éxito Aparecerá la contraseña en un mensaje



Flujo principal



3. El administrador modifica la contraseña del usuario

4. La clave se muestra en pantalla

5. La información se almacena en la base de datos

Flujo alternativo


Observaciones

103

Tabla Nº 103. Especificación de caso de uso “Crear submenú”


Caso de uso Crear submenú



Descripción del submenú


Salidas Ninguna

Post-condición éxito El submenú aparecerá en una tabla perteneciente al

menú seleccionado



Flujo principal



3. El administrador selecciona un menú

4. El administrador crea un nuevo submenú ingresando su descripción


Flujo alternativo

4.1.El administrador cancela la operación

Observaciones

104

Tabla Nº 104. Especificación de caso de uso “Modificar submenú”


Caso de uso Modificar submenú



Descripción del submenú


Salidas Ninguna

Post-condición éxito El submenú aparecerá modificado en una tabla

perteneciente al menú seleccionado



Flujo principal



3. El administrador selecciona un menú

4. El administrador crea un nuevo submenú ingresando su descripción


Flujo alternativo

4.1.El administrador cancela la operación

Observaciones

105

Tabla Nº 105. Especificación de caso de uso “Crear rol”


Caso de uso Crear rol



Descripción de rol

submenús


Salidas Ninguna

Post-condición éxito El nuevo rol aparecerá en una tabla



Flujo principal



3. El administrador ingresa la descripción del rol y selecciona los submenús

4. El sistema almacena la información en la base de datos

Flujo alternativo

3.1. El administrador cancela la operación

Observaciones

Los campos no pueden ser nulos. Se debe seleccionar al menos un submenú.

106

Tabla Nº 106. Especificación de caso de uso “Editar rol”


Caso de uso Editar rol



Descripción de rol

submenús


Salidas Ninguna

Post-condición éxito El rol aparecerá modificado en la tabla



Flujo principal



3. El administrador selecciona el rol y modifica la información

4. El sistema almacena los datos modificados en la base de datos

Flujo alternativo


Observaciones

Los campos no pueden ser nulos. Se debe seleccionar al menos un submenú.

107

Tabla Nº 107. Especificación de caso de uso “Eliminar rol”


Caso de uso Eliminar rol




Salidas Ninguna

Post-condición éxito El valor del parámetro aparecerá modificado en la

tabla

Post-condición fallo Mensaje de error, debido a que existe usuarios con

este rol asignado


Flujo principal



3. El administrador selecciona el rol y lo elimina

4. El sistema elimina el rol de la base de datos

Flujo alternativo


Observaciones

El rol no se eliminara si existe un usuario con este rol

108

Tabla Nº 108. Especificación de caso de uso “Asignar rol”


Caso de uso Asignar rol



Precondiciones El administrador debe estar registrado.

Salidas Todos los roles existentes

Los roles del usuario

Post-condición éxito Si se desea asignar un rol al usuario, este aparecerá

asignado a el

Si no se desea que el usuario tenga el rol, este no

aparecerá asignado a el



Flujo principal



3. El administrador selecciona al usuario

4. El administrador asigna o quita roles al usuario

5. El sistema registra los cambios en la base de datos

Flujo alternativo

Observaciones

Deben existir roles registrados en el sistema. El usuario al que se le asignara el rol

debe estar registrado.

109

5.2.5. Mapa de navegación

Se realizó el mapa de navegación web del sistema, con el fin de facilitar la

ubicación de las páginas y el ensamblaje de cada uno de los módulos para crear un

menú principal, y entender cuál es la estructura en la que el usuario puede acceder a

los distintos datos del sistema web:

Gráfico Nº 13. Mapa de navegación


110

5.3. FASE III. DESARROLLO

El desarrollo de la aplicación web se llevó a cabo en el departamento de sistemas

de la empresa, contando con la supervisión de la coordinadora de sistemas y con los

usuarios, tal como lo recomienda la metodología XP. El tiempo de desarrollo fue de

entre siete (7) y ocho (8) horas diarias, cinco (5) días a la semana, en una estación de

trabajo bajo el sistema operativo Windows XP Service Pack 3, requisito necesario

para poder correr las aplicaciones o herramientas de trabajo.

El desarrollo de la base de datos se realizó con la herramienta visual de diseño

MySQL Workbench 5.2. Esta herramienta posee una interfaz gráfica donde se crean

las tablas, relaciones entre ellas, atributos clave y foráneos, tipo y tamaño de datos.

Una vez creada la base de datos, el software genera un script en lenguaje SQL.

Para el desarrollo de las páginas web en se utilizó el editor de texto Notepad++, el

cual soporta los lenguajes HTML, CSS, JavaScript y PHP.

Se utilizó el sistema de infraestructura web Wamp 2.2 para gestionar las páginas.

Este sistema incluye PHPMyAdmin como gestor de base de datos MySQL, Apache

como servidor web y PHP como lenguaje de programación del lado del servidor.

Tanto las páginas web como el script SQL desarrollado anteriormente se alojaron en

este sistema durante el desarrollo permitiendo probar la aplicación web y una vez

finalizado el desarrollo se implanto en el servidor de aplicaciones de la empresa, que

ya poseía una instalación previa de Wamp.

La metáfora utilizada para el diseño de las páginas se basó en utilizar los colores

característicos de la empresa, el logotipo y otra aplicación web desarrollada en PHP

que se encuentra actualmente en funcionamiento en la empresa. Esto permitió

disminuir el tiempo empleado en el diseño, lograr una mayor aceptación del cliente y

adaptación más rápida, sin dejar de cumplir con los requisitos.

La aplicación funciona en todos los navegadores excepto Internet Explorer. Se

realizó pruebas durante el desarrollo con el navegador Mozilla Firefox, google

chrome y opera obteniendo resultados favorables.

111

5.3.1. Desarrollo de la base de datos

Gráfico Nº 14. Esquema de la base de datos


112

Gráfico Nº 15. Esquema de la base de datos


113

5.3.2. Interfaz de usuario

Gráfico Nº 16. Pantalla de ingreso al sistema


114

Gráfico Nº 17. Pantalla del menú principal


Gráfico Nº 18. Pantalla del menú “parámetros”


115

Gráfico Nº 19. Pantalla del menú “departamentos”


Gráfico Nº 20. Pantalla del menú “Localizaciones”


116

Gráfico Nº 21. Pantalla del menú “Valor Documental”


Gráfico Nº 22. Pantalla del menú “Tipo de carpetas”


117

Gráfico Nº 23. Pantalla del menú “Ingresar TRD”


Gráfico Nº 24. Pantalla del menú “Ingresar TRD”. Generación de la tabla de retención documental en PDF.


118

Gráfico Nº 25. Pantalla del menú “modificar TRD”.


Gráfico Nº 26. Pantalla del menú “Desincorporar”.


119

Gráfico Nº 27. Pantalla del menú “Desincorporar”. Opción “Conservar”


Gráfico Nº 28. Pantalla del menú “Desincorporar”. Opción “Destruir”


120

Gráfico Nº 29. Pantalla del menú “Registro de Préstamo”.


Gráfico Nº 30. Pantalla del menú “Registro de Préstamo”.


121

Gráfico Nº 31. Pantalla del menú “Registro de Préstamo”. Generación de reporte de préstamo en PDF.


Gráfico Nº 32. Pantalla del menú “Devolución de Préstamo”.


122

Gráfico Nº 33. Pantalla del menú “Consulta de préstamo”.


Gráfico Nº 34. Pantalla del menú “Consulta de carpetas”.


123

Gráfico Nº 35. Pantalla del menú “Consulta de localizaciones”.


Gráfico Nº 36. Pantalla del menú “Administración de usuarios”.


124

Gráfico Nº 37. Pantalla del menú “Administración de usuarios”. Opción “crear nuevo usuario”


Gráfico Nº 38. Pantalla del menú “Menús”.


125

Gráfico Nº 39. Pantalla del menú “Menús”. Opción “Ver menús”.


Gráfico Nº 40. Pantalla del menú “Roles”.


126

Gráfico Nº 41. Pantalla del menú “Asignación de roles”.


Gráfico Nº 42. Pantalla del menú “Asignación de roles”. Asignación de roles al usuario “sfernandez”.


127

5.4. FASE IV. PRUEBAS

Se realizaron pruebas de caja negra cada uno de los módulos y pruebas de caja

blanca con el usuario. Los resultados obtenidos fueron los siguientes:

Tabla Nº 109. Prueba Nº1.

Prueba de verificación del sistema de control de archivos inactivos en


Fecha 23 / 10 / 2012

Objetivos Comprobar el correcto funcionamiento del acceso al sistema

Usuario Katy Hernández

Elemento a probar Funcionamiento de los botones

Inicio de sesión

Validación de usuario

Selección de departamento

Cambio de departamento

Cierre de sesión

Pasos Elemento Resultado

Botones Correcto

Inicio de sesión Correcto, si el usuario no existe,

el sistema emite mensaje de error.

Selección de

departamento

Aplica para usuarios con más de

un departamento. Funciona

correctamente Cambio de departamento

Cierre de sesión Correcto

Observaciones Corregir repetición de departamentos

Supervisor Katy Hernández


128




Fecha 23 / 10 / 2012

Objetivos Comprobar el correcto funcionamiento del módulo

“Parámetros”



Crear y editar un parámetro

Comprobar el rol de usuario


Botones Correcto

Crear parámetro Correcto

Editar parámetro Correcto

Acceso al menú Accede correctamente si el rol

del usuario se lo permite, mensaje

de error si el rol no se lo permite

Observaciones



129




Fecha 23 / 10 / 2012


“Departamentos”



Crear, editar y eliminar un departamento

Crear, editar y eliminar una dependencia



Botones Correcto

Crear departamento Correcto

Editar departamento Correcto

Eliminar departamento Correcto

Crear dependencia Correcto

Editar dependencia Correcto

Eliminar dependencia Correcto




Observaciones



130




Fecha 23 / 10 / 2012


“Localizaciones”



Crear, editar y eliminar una localización

Crear y editar una ubicación



Botones Correcto

Crear localización Correcto

Editar localización Correcto

Eliminar localización Correcto

Crear ubicación Correcto

Editar ubicación Correcto




Observaciones Ordenar las tablas por estante.

Colocar una barra de desplazamiento para la tabla



131




Fecha 23 / 10 / 2012

Objetivos Comprobar el correcto funcionamiento del módulo “Valor

Documental”



Crear, editar y eliminar un valor documental



Botones Correcto

Crear valor documental Correcto

Editar valor documental Correcto

Eliminar valor

documental

Correcto




Observaciones



132




Fecha 23 / 10 / 2012

Objetivos Comprobar el correcto funcionamiento del módulo “Tipo de

carpetas”



Crear, editar y eliminar un tipo de carpeta



Botones Correcto

Crear un tipo de carpeta Correcto

Editar un tipo de carpeta Correcto

Eliminar un tipo de

carpeta

Correcto




Observaciones



133




Fecha 23 / 10 / 2012

Objetivos Comprobar el correcto funcionamiento del módulo “Ingresar

TRD”


Elemento a probar Funcionamiento de los botones y listas de selección

Validación de los campos

Crear una caja

Registro de la carpeta

Generación de tabla de retención documental



Botones y listas de

selección

Correcto

Validación de campos Correcto

Crear cajas Correcto

Registrar carpeta Correcto, se genera la tabla de

retención documental.




Observaciones



134




Fecha 23 / 10 / 2012


“Modificar TRD”


Elemento a probar Funcionamiento de los botones y listas de selección

Búsqueda de carpetas

Editar ubicación, cajas o TRD




Botones y listas de

selección

Correcto

Búsqueda de carpetas Correcto

Editar caja Correcto, se genera la TRD

Editar TRD Correcto, se genera la TRD

Editar ubicación Correcto, se genera la TRD




Observaciones Ordenar filtro de búsqueda en una lista



135




Fecha 23 / 10 / 2012


“Desincorporar”




Editar ubicación, cajas o TRD




Botones Correcto


Conservar carpeta Correcto, se genera la tabla de


Eliminar carpeta Correcto

Digitalizar carpeta Funciona correctamente en la

carga de archivos menores a

25MB.




Observaciones



136




Fecha 23 / 10 / 2012

Objetivos Comprobar el correcto funcionamiento del módulo “Registrar

préstamo”




Registrar un préstamo

Generación de reporte de préstamo



Botones Correcto


Registrar préstamo Correcto, se genera el reporte de

préstamo




Observaciones



137




Fecha 23 / 10 / 2012


“Devolución préstamo”



Búsqueda de caja en préstamo

Registrar una devolución de préstamo



Botones Correcto

Búsqueda de caja en

préstamo

Correcto

Registrar devolución de

préstamo

Correcto




Observaciones



138




Fecha 23 / 10 / 2012


“Consultar préstamo”


Elemento a probar Funcionamiento de las listas de selección y botones

Realizar una búsqueda



Botones y lista de

selección

Correcto

Búsqueda de prestamos Correcto




Observaciones Adicionar una opción para exportar búsqueda en hoja de

Excel



139




Fecha 23 / 10 / 2012


“Consultar carpetas”


Elemento a probar Funcionamiento de las listas de selección y botones




Botones y lista de

selección

Correcto





Observaciones Adicionar una opción para exportar búsqueda en hoja

de Excel

Adicionar la opción de realizar búsqueda de carpetas

por usuario



140




Fecha 23 / 10 / 2012


“Consultar localizaciones”


Elemento a probar Funcionamiento de botones




Botones Correcto

Búsqueda de

localizaciones

Correcto




Observaciones



141




Fecha 23 / 10 / 2012

Objetivos Comprobar el correcto funcionamiento del módulo “Admón.

usuarios”



Validación de campos

Crear y editar cuentas de usuario

Cambio de contraseñas



Botones Correcto

Validación de campos Correcto, emite mensaje de error

si un ID de usuario ya existe.

Crear usuario Correcto

Editar usuario Correcto

Cambio de contraseña Correcto, emite mensaje

indicando la nueva contraseña.




Observaciones Mejorar formulario de creación de usuarios.



142




Fecha 23 / 10 / 2012

Objetivos Comprobar el correcto funcionamiento del módulo “Mant. De

menús”



Crear y editar submenús



Botones Correcto

Crear submenú Correcto

Editar submenú Correcto




Observaciones Colocar en cada tabla de submenú el menú al que

corresponden



143




Fecha 23 / 10 / 2012

Objetivos Comprobar el correcto funcionamiento del módulo “definir

roles”



Crear, editar y eliminar roles



Botones Correcto

Crear rol Correcto

Editar rol Correcto

Eliminar rol Correcto




Observaciones



144




Fecha 23 / 10 / 2012

Objetivos Comprobar el correcto funcionamiento del módulo “asignar

roles”



Asignar y quitar roles a los usuarios



Botones Correcto

Asignar rol a usuario Correcto

Quitar rol a usuario Correcto




Observaciones



145

CONCLUSIONES

Mediante el proceso de pasantía se ha logrado cumplir de manera satisfactoria el

objetivo principal que fue el desarrollar un sistema de información para la gestión de

los archivos inactivos de la empresa Distribuidora Universal Kia, C.A.

Se logró cumplir con cada uno de los requisitos de los usuarios de la manera más

simple y en el tiempo establecido gracias a la metodología XP, que fue aplicada para

el desarrollo del sistema. Esta consiste en cuatro fases: Planificación, diseño,

desarrollo y pruebas.

Durante la fase de planificación, se obtuvo una gran participación de los usuarios,

donde aportaron ideas, requisitos, opiniones y sugerencias concernientes al sistema en

cada una de las reuniones realizadas.

En la fase de diseño, la metáfora utilizada fue tomar el diseño de una aplicación ya

existente que funciona en la empresa. Esto redujo el tiempo empleado en el diseño y

emplearlo en el desarrollo, además de que el usuario se adaptara rápidamente ya que

conoce como navegar en las páginas web.

Para el desarrollo, se utilizó WampServer (Apache, MySQL y PHP), que ya se

encontraba instalado y funcionando en el servidor con otra aplicación. Esto permitirá

una fácil implantación del sistema.

Por último, se realizaron pruebas individuales de cada módulo al finalizar el

desarrollo de cada uno y pruebas del sistema en partes con el usuario. En algunas

ocasiones hubo que eliminar, modificar o agregar ciertas funcionalidades en el

sistema, para así lograr con la satisfacción total del cliente. Los errores encontrados se

corrigieron una vez realizadas las pruebas.

146

Una vez que la aplicación se encuentre implantada en el servidor, se reducirá

notablemente el tiempo que los usuarios realizan las actividades de consulta y

permitirá controlar y ordenar todos los archivos inactivos existentes.

147

RECOMENDACIONES

Para el buen funcionamiento del sistema, se sugiere ubicar una persona encargada

de los archivos inactivos, para así lograr un mayor control de los documentos que

entran y salen. Esta persona podrá recibir la planilla para retirar cajas en préstamo,

recibir las cajas una vez concluido el tiempo de préstamo y chequear las cajas nuevas

que ingresen al departamento.

La ubicación de un computador con el sistema SCAI en el departamento de

archivos inactivos facilitaría al usuario realizar consultas y búsquedas rápidas de

aquellas carpetas que realmente necesite, sin necesidad de transportar la caja de un

lado a otro.

La identificación de los estantes y las cajas en el departamento de archivos

inactivos, deben coincidir con los del sistema, por lo que estos deben estar

debidamente identificados y ordenados.

Se debe evitar las cajas fuera de los estantes, ya que así no podrán ser registradas

correctamente en el sistema.

148

REFERENCIAS

Bibliográficas.

1. Roger S. Pressman (2005). Ingeniería del Software. Un enfoque Práctico.

Editorial McGraw Hill. Sexta Edición

2. Ian Sommerville (2005). Ingeniería del software. Editorial Pearson. Séptima

Edición

3. Eduardo López (2010). “Desarrollo de un sistema integral para el control del

inventario del fondo editorial del ipasme y solicitud de pedidos para sus

afiliados, basado en tecnologías web”

4. Luis Alfredo Prieto (2006). “Sistema de gestión de archivos para el

departamento de salud y seguridad de la empresa Ford Motor de Venezuela

S.A. basado en tecnología web”

5. Jesús Alvarenga y Gerard Roa (2008). “Plataforma para la gestión de

documentos del vicerrectorado académico de la universidad José Antonio

Páez”.

6. Luke Welling y Laura Thomson (2005). “Desarrollo web con PHP y

MySQL”. Editorial Ayana Multimedia

7. Fondo editorial de la Universidad Pedagógica Experimental Libertador

(2006). Manual de trabajos de grado de especialización y maestría y tesis

doctorales. Cuarta edición.

149

8. Roberto Hernandez Sampieri, Carlos Fernández Collado y Pilar Baptista

Lucio (2003). “Metodología de la Investigación”. Editorial McGraw Hill

Interamericana. Tercera Edición.

Electrónicas.

1. Luis Miguel Echeverry Tobón y Luz Elena Delgado Carmona (2007). Caso

práctico de la metodología ágil XP al desarrollo de software. Universidad

Tecnológica de Pereira. Disponible:

http://repositorio.utp.edu.co/dspace/bitstream/11059/794/1/0053E18cp.pdf

[Consulta: 2012, Diciembre 09].

2. Manuel Calero Solís (2003). Una explicación de la programación extrema

(XP). Disponible:

http://www.willydev.net/descargas/prev/ExplicaXP.pdf. [Consulta: 2012,

Diciembre 09].

3. Ericka López (2009). Implementación de una base de datos bibliográfica del

archivo de la gerencia del control interno y calidad procesos corporativo en la

corporación petróleos de Venezuela S.A. Disponible:

http://159.90.80.55/tesis/000148932.pdf [Consulta: 2012, Junio 08]

4. José E. Escalona Surth (2010). Propuesta de un modelo de gestión de

información para la dirección de asuntos profesorales en su sección de

archivo central de la facultad de odontología de la universidad de Carabobo.

Disponible:

http://produccion-uc.bc.uc.edu.ve/documentos/trabajos/63002DF7.pdf

[Consulta: 2012, Junio 08]

150

5. Servicio de Aplicación de tablas de valoración y retención (TDV – TRD).

CSA: Compañía de servicios archivísticos y tecnológicos Ltda.

Disponible: http://www.csaltda.com/tablas.aspx [Consulta: 2012, Junio 08]

6. Manual de archivo y correspondencia del instituto nacional de salud, Bogotá

D.C. (2005). Disponible:

http://www.ins.gov.co/recursos_user/documentos/Normatividad/Normas%20I

NS/manuales/Manual_archivo_correspondencia.pdf [Consulta: 2012, Junio

08]

7. Manual de normas y procedimientos sobre el control y organización de

archivos administrativos. Universidad Pontificia Bolivariana. Departamento

administración de documentos. (2006). Disponible:

http://www.upb.edu.co/pls/portal/docs/PAGE/GPV2_UPB_MEMPLEADOS/

GPV2_MDOC_030_DOCUMENTOS/MANUAL_ORGANIZACION_DE_

ARCHIVOS%5B1%5D.PDF [Consulta: 2012, Junio 08]

8. Manual para la operación de archivos administrativos de la administración

portuaria integral de progreso S.A. de C.V. (2005). Disponible:

http://www.puertosyucatan.com/marcolegal/manual_de_archivos.pdf

[Consulta: 2012, Junio 08].

9. Julia Godoy, Imelda López, Clara Casimilla y Otros. Mini/manual Nº4. tablas

de retención y transferencias documentales. Archivo general de la nación.

Colombia. Disponible:

http://gestiondocumental.univalle.edu.co/ARCHIVOSPDF/minimanual.pdf

[Consulta: 2012, Junio 08].

151

10. Página oficial de PHP.

http://www.php.net/ [Consulta: 2012, Julio 19].

11. Sergio Lujan Mora (2002). “programación de aplicaciones web: Historia,

principios básicos y clientes web”. Editorial club universitario.

http://rua.ua.es/dspace/bitstream/10045/16995/1/sergio_lujan-

programacion_de_aplicaciones_web.pdf [Consulta: 2013, Enero 27].

12. Página oficial de la free software fundación:

http://www.gnu.org/licenses/licenses.html [Consulta: 2013, Enero 27].

13. http://www.ri5.com.ar/ayuda07.php [Consulta: 2013, Enero 27].

152

ANEXOS

153

ANEXO A

Tabla de Retención Documental (TRD)

Departamento: Fecha de

transferencia

DD MM AAAA

Oficina productora:

Nombre responsable:

CC serie o

subserie

Doc.

Doc. Identificación de la serie, subserie,

expediente o asunto

Fechas extremas Valor Retención Ubicación

OR CO Inicial Final A L F C T H I Años Fecha a

destruir

Estante Fila Caja

Abreviaturas:

CC.: Código Carpeta OR: Original

CO: Copia

A: Administrativo L: Legal

F: Fiscal

C: Contable T: técnico

H: Histórico I: Informativo

154

ANEXO B

Tabla de Valoración Documental (TVD)

Departamento: Fecha de

transferencia: DD MM AAAA

Oficina productora:

Cód.

Carpeta Caja Nº Identificación de la serie, subserie, expediente o asunto

Disposición

Final Procedimientos

CT S E

Abreviaturas:

CT – Conservación Total

E – Eliminación

S – Selección

Firma responsable:

Fecha:

155

ANEXO C

Archivo central de la empresa Distribuidora Universal Kia, C.A.

156

ANEXO D

Archivo central de la empresa Distribuidora Universal Kia, C.A.

157

ANEXO E

Encuesta Nº1

Nombre: Fecha: 19 / 06 / 2012

Departamento: Dependencia:

Sistema para el control de los archivos inactivos

Tiempo de permanencia en meses de los documentos en su dependencia: Tiempo de permanencia en años de los documentos en los archivos inactivos según su valor:

(rellene aquella opción que aplique en su caso)

Valor Administrativo

Valor Legal

Valor Fiscal

Valor Jurídico

Valor Técnico

Valor Contable

Valor Histórico Cuando se destruye la documentación, se elimina (marque una opción con una X):

La caja en su totalidad

Por carpeta Número máximo de carpetas por caja: Al momento de destruir la documentación, se digitalizara (marque una opción con una X):

Toda la carpeta

Se seleccionaran las carpetas

Documents

REPUBLICA BOLIVARIANA DE VENEZUELA ......21 Historias de usuario Nº 21 38 22 Tarea Nº 1 39 23 Tarea Nº 2 39 24 Tarea Nº 3 39 v 25 Tarea Nº 4 40 26 Tarea Nº 5 40 27 Tarea Nº