republica bolivariana de venezuela ......21 historias de usuario nº 21 38 22 tarea nº 1 39 23...
TRANSCRIPT
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
2 Historias de usuario Nº 2 31
3 Historias de usuario Nº 3 31
4 Historias de usuario Nº 4 31
5 Historias de usuario Nº 5 32
6 Historias de usuario Nº 6 32
7 Historias de usuario Nº 7 32
8 Historias de usuario Nº 8 33
9 Historias de usuario Nº 9 33
10 Historias de usuario Nº 10 34
11 Historias de usuario Nº 11 34
12 Historias de usuario Nº 12 35
13 Historias de usuario Nº 13 35
14 Historias de usuario Nº 14 36
15 Historias de usuario Nº 15 36
16 Historias de usuario Nº 16 36
17 Historias de usuario Nº 17 37
18 Historias de usuario Nº 18 37
19 Historias de usuario Nº 19 37
20 Historias de usuario Nº 20 38
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º 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
45 Iteración Nº 2 48
46 Iteración Nº 3 48
47 Iteración Nº 4 48
48 Iteración Nº 5 49
49 Iteración Nº 6 49
50 Iteración Nº 7 50
51 Iteración Nº 8 50
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
110 Prueba Nº 2 128
111 Prueba Nº 3 129
112 Prueba Nº 4 130
113 Prueba Nº 5 131
114 Prueba Nº 6 132
115 Prueba Nº 7 133
116 Prueba Nº 8 134
117 Prueba Nº 9 135
118 Prueba Nº 10 136
119 Prueba Nº 11 137
120 Prueba Nº 12 138
121 Prueba Nº 13 139
122 Prueba Nº 14 140
123 Prueba Nº 15 141
124 Prueba Nº 16 142
125 Prueba Nº 17 143
126 Prueba Nº 18 144
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
7 Diagrama Entidad-Relación 52
8 Diagrama Entidad-Relación 53
9 Diagrama de caso de uso del usuario 66
10 Diagrama de caso de uso del usuario 67
11 Diagrama de caso de uso del usuario 68
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
Fuente: Da Silva, Sergio (2012).
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
Fuente: Da Silva, Sergio (2012).
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.
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.
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.
Fuente: Da Silva, Sergio (2012).
31
Tabla Nº 2. Historias de usuario Nº 2
Identificador 2
Nombre Análisis del sistema propuesto
Cliente Katy Hernández
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 3. Historias de usuario Nº 3
Identificador 3
Nombre Diseño y desarrollo de la base de datos
Cliente Katy Hernández
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 4. Historias de usuario Nº 4
Identificador 4
Nombre Llenado de la base de datos
Cliente Katy Hernández
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.
Fuente: Da Silva, Sergio (2012).
32
Tabla Nº 5. Historias de usuario Nº 5
Identificador 5
Nombre Parámetros
Cliente Katy Hernández
Prioridad Alta
Descripción Se requiere crear o editar los parámetros que serán condiciones para
el control y correcto funcionamiento del sistema.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 6. Historias de usuario Nº 6
Identificador 6
Nombre Departamentos
Cliente Katy Hernández
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 7. Historias de usuario Nº 7
Identificador 7
Nombre Localizaciones
Cliente Katy Hernández
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.
Fuente: Da Silva, Sergio (2012).
33
Tabla Nº 8. Historias de usuario Nº 8
Identificador 8
Nombre Valor Documental
Cliente Katy Hernández
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 9. Historias de usuario Nº 9
Identificador 9
Nombre Tipo de carpetas
Cliente Katy Hernández
Prioridad Alta
Descripción Se requiere que el usuario pueda crear, editar o eliminar los tipos de
carpeta con las que funcionara el sistema.
Fuente: Da Silva, Sergio (2012).
34
Tabla Nº 10. Historias de usuario Nº 10
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 11. Historias de usuario Nº 11
Identificador 11
Nombre Modificar la tabla de retención documental
Cliente Todos los usuarios
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.
Fuente: Da Silva, Sergio (2012).
35
Tabla Nº 12. Historias de usuario Nº 12
Identificador 12
Nombre Desincorporar documentación
Cliente Todos los usuarios
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 13. Historias de usuario Nº 13
Identificador 13
Nombre Registrar préstamo
Cliente Todos los usuarios
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.
Fuente: Da Silva, Sergio (2012).
36
Tabla Nº 14. Historias de usuario Nº 14
Identificador 14
Nombre Devolver préstamo
Cliente Todos los usuarios
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 15. Historias de usuario Nº 15
Identificador 15
Nombre Consultar carpetas
Cliente Todos los usuarios
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 16. Historias de usuario Nº 16
Identificador 16
Nombre Consultar prestamos
Cliente Todos los usuarios
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.
Fuente: Da Silva, Sergio (2012).
37
Tabla Nº 17. Historias de usuario Nº 17
Identificador 17
Nombre Consultar localizaciones
Cliente Todos los usuarios
Prioridad Media
Descripción Se requiere realizar consultas de aquellas localizaciones del archivo
central que se encuentren vacantes u ocupados.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 18. Historias de usuario Nº 18
Identificador 18
Nombre Administrar usuarios
Cliente Katy Hernández
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 19. Historias de usuario Nº 19
Identificador 19
Nombre Mantenimiento de menús
Cliente Katy Hernández
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.
Fuente: Da Silva, Sergio (2012).
38
Tabla Nº 20. Historias de usuario Nº 20
Identificador 20
Nombre Definir roles
Cliente Katy Hernández
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 21. Historias de usuario Nº 21
Identificador 21
Nombre Asignar roles
Cliente Katy Hernández
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
Fuente: Da Silva, Sergio (2012).
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 23. Tarea Nº 2
Nombre de la tarea: Análisis del sistema propuesto
Numero de historias: 2
Fecha de inicio: 04 / 06 / 2012
Fecha de finalización: 22 / 06 / 2012
Descripción: Identificar los procesos, conocer el funcionamiento general, identificar
entradas y salidas, realizar mapa de navegación.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 24. Tarea Nº 3
Nombre de la tarea: Diseño y desarrollo de la base de datos
Numero de historias: 3
Fecha de inicio: 25 / 06 / 2012
Fecha de finalización: 13 / 07 / 2012
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.
Fuente: Da Silva, Sergio (2012).
40
Tabla Nº 25. Tarea Nº 4
Nombre de la tarea: Diseño y desarrollo del módulo “parámetros”
Numero de historias: 5
Fecha de inicio: 16 / 07 / 2012
Fecha de finalización: 18 / 07 / 2012
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 26. Tarea Nº 5
Nombre de la tarea: Diseño y desarrollo del módulo “departamentos”
Numero de historias: 6
Fecha de inicio: 19 / 07 / 2012
Fecha de finalización: 24 / 07 / 2012
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 27. Tarea Nº 6
Nombre de la tarea: Diseño y desarrollo del módulo “localizaciones”
Numero de historias: 7
Fecha de inicio: 25 / 07 / 2012
Fecha de finalización: 30 / 07 / 2012
Descripción: Diseñar y desarrollar el modulo donde el usuario podrá crear,
modificar o eliminar las localizaciones del archivo central donde se almacenan las
cajas que contienen las carpetas.
Fuente: Da Silva, Sergio (2012).
41
Tabla Nº 28. Tarea Nº 7
Nombre de la tarea: Diseño y desarrollo del módulo “valor documental”
Numero de historias: 8
Fecha de inicio: 31 / 07 / 2012
Fecha de finalización: 01 / 08 / 2012
Descripción: Diseñar y desarrollar el modulo donde el usuario podrá crear,
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 29. Tarea Nº 8
Nombre de la tarea: Diseño y desarrollo del módulo “Tipo de carpetas”
Numero de historias: 9
Fecha de inicio: 02 / 08 / 2012
Fecha de finalización: 03 / 08 / 2012
Descripción: Diseñar y desarrollar el modulo donde el usuario podrá crear,
modificar o eliminar los tipos de carpeta, los cuales estarán asignados a cada carpeta
registrada.
Fuente: Da Silva, Sergio (2012).
42
Tabla Nº 30. Tarea Nº 9
Nombre de la tarea: Diseño y desarrollo del módulo “Ingresar TRD”
Numero de historias: 10
Fecha de inicio: 06 / 08 / 2012
Fecha de finalización: 14 / 08 / 2012
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 31. Tarea Nº 10
Nombre de la tarea: Diseño y desarrollo del módulo “Modificar TRD”
Numero de historias: 11
Fecha de inicio: 15 / 08 / 2012
Fecha de finalización: 24 / 08 / 2012
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.
Fuente: Da Silva, Sergio (2012).
43
Tabla Nº 32. Tarea Nº 11
Nombre de la tarea: Diseño y desarrollo del módulo “Desincorporar”
Numero de historias: 12
Fecha de inicio: 27 / 08 / 2012
Fecha de finalización: 06 / 09 / 2012
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 33. Tarea Nº 12
Nombre de la tarea: Diseño y desarrollo del módulo “Registrar Préstamo”
Numero de historias: 13
Fecha de inicio: 07 / 09 / 2012
Fecha de finalización: 12 / 09 / 2012
Descripción: Diseñar y desarrollar el modulo donde el usuario podrá realizar una
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.
Fuente: Da Silva, Sergio (2012).
44
Tabla Nº 34. Tarea Nº 13
Nombre de la tarea: Diseño y desarrollo del módulo “Devolución Préstamo”
Numero de historias: 14
Fecha de inicio: 13 / 09 / 2012
Fecha de finalización: 14 / 09 / 2012
Descripción: Diseñar y desarrollar el modulo donde el usuario podrá registrar la
devolución de las carpetas en préstamo.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 35. Tarea Nº 14
Nombre de la tarea: Diseño y desarrollo del módulo “Admón. Usuarios”
Numero de historias: 18
Fecha de inicio: 17 / 09 / 2012
Fecha de finalización: 20 / 09 / 2012
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 36. Tarea Nº 15
Nombre de la tarea: Diseño y desarrollo del módulo “Mant. Menús”
Numero de historias: 19
Fecha de inicio: 21 / 09 / 2012
Fecha de finalización: 25 / 09 / 2012
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.
Fuente: Da Silva, Sergio (2012).
45
Tabla Nº 37. Tarea Nº 16
Nombre de la tarea: Diseño y desarrollo del módulo “Definir Roles”
Numero de historias: 20
Fecha de inicio: 26 / 09 / 2012
Fecha de finalización: 01 / 10 / 2012
Descripción: Diseñar y desarrollar el modulo donde el administrador podrá crear,
editar y eliminar los roles de usuario.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 38. Tarea Nº 17
Nombre de la tarea: Diseño y desarrollo del módulo “Asignar Roles”
Numero de historias: 21
Fecha de inicio: 02 / 10 / 2012
Fecha de finalización: 05 / 10 / 2012
Descripción: Diseñar y desarrollar el modulo donde el administrador podrá asignar o
eliminar roles a los usuarios.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 39. Tarea Nº 18
Nombre de la tarea: Diseño y desarrollo del módulo “Consultar Carpetas”
Numero de historias: 15
Fecha de inicio: 08 / 10 / 2012
Fecha de finalización: 11 / 10 / 2012
Descripción: Diseñar y desarrollar el modulo donde el usuario podrá realizar una
búsqueda detallada de las carpetas registradas en el sistema y generar un archivo en
Excel con el resultado de la búsqueda.
Fuente: Da Silva, Sergio (2012).
46
Tabla Nº 40. Tarea Nº 19
Nombre de la tarea: Diseño y desarrollo del módulo “Consultar Préstamo”
Numero de historias: 16
Fecha de inicio: 12 / 10 / 2012
Fecha de finalización: 15 / 10 / 2012
Descripción: Diseñar y desarrollar el modulo donde el usuario podrá realizar una
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.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 41. Tarea Nº 20
Nombre de la tarea: Diseño y desarrollo del módulo “Consultar localizaciones”
Numero de historias: 17
Fecha de inicio: 16 / 10 / 2012
Fecha de finalización: 17 / 10 / 2012
Descripción: Diseñar y desarrollar el modulo donde el usuario podrá realizar una
búsqueda detallada de los prestamos registrados por los distintos usuarios.
Fuente: Da Silva, Sergio (2012).
Tabla Nº 42. Tarea Nº 21
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
Fecha de inicio: 18 / 10 / 2012
Fecha de finalización: 19 / 10 / 2012
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.
Fuente: Da Silva, Sergio (2012).
47
Tabla Nº 43. Tarea Nº 22
Nombre de la tarea: Migrar la data almacenada en una hoja en formato MS-Excel a
la base de datos MySQL.
Numero de historias: 4
Fecha de inicio: 22 / 10 / 2012
Fecha de finalización: 26 / 10 / 2012
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.
Fuente: Da Silva, Sergio (2012).
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
Fuente: Da Silva, Sergio (2012).
48
Tabla Nº 45. Iteración Nº 2
Iteración Nº2
Tareas Análisis del sistema propuesto
Historias de usuario 2
Fecha de inicio 04 / 06 / 2012
Fecha de finalización 22 / 06 / 2012
Fuente: Da Silva, Sergio (2012).
Tabla Nº 46. Iteración Nº 3
Iteración Nº3
Tareas Diseño y desarrollo de la base de datos
Historias de usuario 3
Fecha de inicio 25 / 06 / 2012
Fecha de finalización 13 / 07 / 2012
Fuente: Da Silva, Sergio (2012).
Tabla Nº 47. Iteración Nº 4
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
Fecha de inicio 16 / 07 / 2012
Fecha de finalización 03 / 08 / 2012
Fuente: Da Silva, Sergio (2012).
49
Tabla Nº 48. Iteración Nº 5
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
Fecha de inicio 06 / 08 / 2012
Fecha de finalización 24 / 08 / 2012
Fuente: Da Silva, Sergio (2012).
Tabla Nº 49. Iteración Nº 6
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
Fecha de inicio 27 / 08 / 2012
Fecha de finalización 14 / 09 / 2012
Fuente: Da Silva, Sergio (2012).
50
Tabla Nº 50. Iteración Nº 7
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
Fecha de inicio 17 / 09 / 2012
Fecha de finalización 05 / 10 / 2012
Fuente: Da Silva, Sergio (2012).
Tabla Nº 51. Iteración Nº 8
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
Fecha de inicio 08 / 10 / 2012
Fecha de finalización 26 / 10 / 2012
Fuente: Da Silva, Sergio (2012).
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
Gráfico Nº 7. Diagrama Entidad-Relación.
Fuente: Da Silva, Sergio (2012). diaw.exe 0.97.1
53
Gráfico Nº 8. Diagrama Entidad-Relación.
Fuente: Da Silva, Sergio (2012). diaw.exe 0.97.1
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
Campo Tipo Longitud Descripción
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
Clave Foránea: Campos Clave:
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
Campo Tipo Longitud Descripción
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
Clave Foránea: Campos Clave:
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
Campo Tipo Longitud Descripción
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
Clave Foránea: Campos Clave:
idDpto con el campo idDpto de la tabla Departamento
idDep con el campo idDep de la tabla Dependencia
idDpto_Dep
Fuente: Da Silva, Sergio (2012).
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
Campo Tipo Longitud Descripción
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
Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro
Clave Foránea: Campos Clave:
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.
Campo Tipo Longitud Descripción
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
Clave Foránea: Campos Clave:
idUsuario con el campo idUsuario de la tabla Usuario
idDpto_Dep con el campo idDpto_Dep de la tabla
Dpto_Dep
idUsuario
idDpto_Dep
Fuente: Da Silva, Sergio (2012).
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
Campo Tipo Longitud Descripción
idRol_Usuario Entero 5 ID de acceso por usuario. Se
autoincrementa.
idUsuario Caractér 12 ID del usuario
idRol Entero 5 ID del rol
Usuario_Creador Caractér 12 ID del usuario que creó el registro
Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro
Clave Foránea: Campos Clave:
idRol con el campo idRol de la tabla Rol
idUsuario con el campo idUsuario de la tabla Usuario
idRol_Usuario
Fuente: Da Silva, Sergio (2012).
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
Campo Tipo Longitud Descripción
idRol Entero 5 ID de acceso por usuario. Se
autoincrementa.
Nombre_Rol Caractér 20 ID del usuario
Usuario_Creador Caractér 12 ID del usuario que creó el registro
Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro
Clave Foránea: Campos Clave:
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
Campo Tipo Longitud Descripción
idMenu_Rol Entero 5 ID de menú por rol. Se autoincrementa.
idMenus Entero 5 ID del menú
idRol Entero 5 ID del rol
Usuario_Creador Caractér 12 ID del usuario que creó el registro
Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro
Clave Foránea: Campos Clave:
idMenus con el campo idMenus de la tabla Menú
idRol con el campo idRol de la tabla Rol
idMenu_Rol
Fuente: Da Silva, Sergio (2012).
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
Campo Tipo Longitud Descripción
idMenus Entero 5 ID de menú por rol. Se autoincrementa.
Menú Caractér 15 ID del menú
Submenu Caractér 20 ID del rol
Usuario_Creador Caractér 12 ID del usuario que creó el registro
Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro
Clave Foránea: Campos Clave:
idMenus con el campo idMenus de la tabla Menú
idRol con el campo idRol de la tabla Rol
idMenu_Rol
Fuente: Da Silva, Sergio (2012).
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.
Campo Tipo Longitud Descripción
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
Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro
Clave Foránea: Campos Clave:
idUsuario con el campo idUsuario de la tabla Usuario
idCarpeta con el campo idCarpeta de la tabla Carpeta
idDestruccion
Fuente: Da Silva, Sergio (2012).
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
Campo Tipo Longitud Descripción
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
Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro
Clave Foránea: Campos Clave:
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.
Campo Tipo Longitud Descripción
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
Clave Foránea: Campos Clave:
idCaja con el campo idCaja de la tabla Caja
idTipoCarpeta con el campo idTipoCarpeta de la tabla
TipoCarpeta
idCarpeta
Fuente: Da Silva, Sergio (2012).
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.
Campo Tipo Longitud Descripción
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
Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro
Clave Foránea: Campos Clave:
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
Fuente: Da Silva, Sergio (2012).
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.
Campo Tipo Longitud Descripción
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
Usuario Caractér 25 Usuario que creó el registro
Fecha_Creacion aaaa/mm/dd Fecha Fecha de creación del registro
Clave Foránea: Campos Clave:
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.
Campo Tipo Longitud Descripción
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
Usuario Caractér 12 Usuario que creó el registro
Fecha_Creacion aaaa/mm/dd Fecha Fecha de creación del registro
Clave Foránea: Campos Clave:
idLocalizacion con el campo idLocalizacion de la tabla
Localizacion
idUbicacion
Fuente: Da Silva, Sergio (2012).
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.
Campo Tipo Longitud Descripción
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.
Clave Foránea: Campos Clave:
idUsuario con idUsuario de la tabla Usuario
idCaja con idCaja de la tabla Caja
idPrestamo
Fuente: Da Silva, Sergio (2012).
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.
Campo Tipo Longitud Descripción
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.
Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro.
Clave Foránea: Campos Clave:
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.
Campo Tipo Longitud Descripción
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.
Fecha_Creacion Fecha aaaa/mm/dd Fecha de creación del registro.
Clave Foránea: Campos Clave:
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.
Campo Tipo Longitud Descripción
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
Clave Foránea: Campos Clave:
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.
Fuente: Da Silva, Sergio (2012). diaw.exe 0.97.1
67
Gráfico Nº 6. Diagrama de caso de uso del usuario.
Fuente: Da Silva, Sergio (2012). diaw.exe 0.97.1
68
Gráfico Nº 7. Diagrama de caso de uso del usuario.
Fuente: Da Silva, Sergio (2012). diaw.exe 0.97.1
69
Gráfico Nº8. Diagrama de caso de uso del administrador.
Fuente: Da Silva, Sergio (2012). diaw.exe 0.97.1
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”
Fuente: Da Silva, Sergio (2012).
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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Modificar parámetro
Entradas ID de usuario
Contraseña de usuario
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 valor del parámetro aparecerá modificado 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 modifica el valor del parámetro
4. El sistema guarda la información modificada en la base de datos.
Flujo alternativo
3.1. El usuario decide cancelar la operación
Observaciones
Los campos no pueden ser nulos.
72
Tabla Nº 74. Especificación de caso de uso “Crear departamento”
Fuente: Da Silva, Sergio (2012).
Caso de uso Crear departamento
Entradas ID de usuario
Contraseña de usuario
Descripción del departamento
Descripción de la dependencia
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 departamentos.
Post-condición éxito El departamento 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 departamento y la dependencia
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.
73
Tabla Nº 75. Especificación de caso de uso “Editar departamento”
Fuente: Da Silva, Sergio (2012).
Caso de uso Editar departamento
Entradas ID de usuario
Contraseña de usuario
Descripción del departamento
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
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
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 modifica la descripción del departamento
4. El sistema guarda la información modificada en la base de datos.
Flujo alternativo
3.1. El usuario decide cancelar la operación
Observaciones
Los campos no pueden ser nulos.
74
Tabla Nº 76. Especificación de caso de uso “Eliminar departamento”
Fuente: Da Silva, Sergio (2012).
Caso de uso Eliminar departamento
Entradas ID de usuario
Contraseña de usuario
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
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.
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 decide eliminar el departamento y las dependencias asociadas a
este.
4. El sistema elimina la información en la base de datos.
Flujo alternativo
3.1. El usuario decide cancelar la operación
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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Crear dependencia
Entradas ID de usuario
Contraseña de usuario
Descripción de la dependencia
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
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
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 de la dependencia
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.
76
Tabla Nº 78. Especificación de caso de uso “Editar dependencia”
Fuente: Da Silva, Sergio (2012).
Caso de uso Editar dependencia
Entradas ID de usuario
Contraseña de usuario
Descripción de la dependencia
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
este menú.
La dependencia debe existir
Salidas Una tabla con los departamentos
Una tabla con las dependencias de ese departamento
Post-condición éxito La descripción de la dependencia aparecerá
modificado 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 modifica la descripción de la dependencia
4. El sistema guarda la información modificada en la base de datos.
Flujo alternativo
3.1. El usuario decide cancelar la operación
Observaciones
Los campos no pueden ser nulos.
77
Tabla Nº 79. Especificación de caso de uso “Eliminar dependencia”
Fuente: Da Silva, Sergio (2012).
Caso de uso Eliminar dependencia
Entradas ID de usuario
Contraseña de usuario
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
este menú.
Salidas Una tabla con los departamentos
Una tabla con las dependencias de ese departamento
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.
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 decide eliminar la dependencia
4. El sistema elimina la información en la base de datos.
Flujo alternativo
3.1. El usuario decide cancelar la operación
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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Crear localización
Entradas ID de usuario
Contraseña de usuario
Descripción del estante
Numero de fila
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
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.
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 introduce un identificador del estante y el número de fila
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. La localización no puede repetirse.
79
Tabla Nº 81. Especificación de caso de uso “Editar localización”
Fuente: Da Silva, Sergio (2012).
Caso de Uso Editar localización
Entradas ID de usuario
Contraseña de usuario
Numero de fila
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
este menú.
Salidas Una tabla con las localizaciones
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.
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 modifica el número de fila
4. El sistema guarda la información modificada en la base de datos.
Flujo alternativo
3.1. El usuario decide cancelar la operación
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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Eliminar localización
Entradas ID de usuario
Contraseña de usuario
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
este menú.
Salidas Una tabla con las localizaciones
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
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 decide eliminar la localización
4. El sistema elimina la información en la base de datos.
Flujo alternativo
3.1. El usuario decide cancelar la operación
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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Crear ubicación
Entradas ID de usuario
Contraseña de usuario
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
este menú.
Salidas Una tabla con las localizaciones
Una tabla con las ubicaciones asociadas a esa
localización
Post-condición éxito La ubicación 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 decide agregar una ubicación
4. El sistema guarda la información en la base de datos.
Flujo alternativo
3.1. El usuario decide cancelar la operación
Observaciones
82
Tabla Nº 84. Especificación de caso de uso “Editar ubicación”
Fuente: Da Silva, Sergio (2012).
Caso de uso Editar ubicación
Entradas ID de usuario
Contraseña de usuario
Estatus de la ubicación
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
este menú.
Salidas Una tabla con las localizaciones
Una tabla con las ubicaciones asociadas a esa
localización
Post-condición éxito La ubicación cambia de ocupado a vacante o
viceversa
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 modifica estatus de la ubicación
4. El sistema guarda la información modificada en la base de datos.
Flujo alternativo
3.1. El usuario decide cancelar la operación
Observaciones
83
Tabla Nº 85. Especificación de caso de uso “Crear valor”
Fuente: Da Silva, Sergio (2012).
Caso de uso Crear valor
Entradas ID de usuario
Contraseña de usuario
Descripción del valor documental
Tiempo de retención en años
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
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
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 valor documental y el tiempo de
retención en años
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
84
Tabla Nº 86. Especificación de caso de uso “Modificar valor”
Fuente: Da Silva, Sergio (2012).
Caso de uso Modificar valor
Entradas ID de usuario
Contraseña de usuario
Descripción del valor documental
Tiempo de retención en años
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
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á modificado 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 valor documental y el tiempo de
retención en años
4. El sistema guarda la información modificada en la base de datos.
Flujo alternativo
3.1. El usuario decide cancelar la operación
Observaciones
Los campos no pueden ser nulos
85
Tabla Nº 87. Especificación de caso de uso “Eliminar valor”
Fuente: Da Silva, Sergio (2012).
Caso de uso Eliminar valor
Entradas ID de usuario
Contraseña de usuario
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
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 desaparecerá de la tabla
Post-condición fallo Mensaje de error, ya que el valor documental está
asociado a una caja o carpeta.
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 decide eliminar el valor documental
4. El sistema elimina la información en la base de datos.
Flujo alternativo
3.1. El usuario decide cancelar la operación
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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Crear tipo de carpeta
Entradas ID de usuario
Contraseña de usuario
Descripción del tipo de carpeta
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
este menú.
Salidas Una tabla con los tipos de carpeta
Post-condición éxito El tipo de carpeta 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 tipo de carpeta
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
87
Tabla Nº 89. Especificación de caso de uso “Modificar tipo de carpeta”
Fuente: Da Silva, Sergio (2012).
Caso de uso Modificar tipo de carpeta
Entradas ID de usuario
Contraseña de usuario
Descripción del tipo de carpeta
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
este menú.
Salidas Una tabla con los tipos de carpeta
Post-condición éxito El tipo de carpeta aparecerá modificado 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 modifica la descripción del tipo de carpeta
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
88
Tabla Nº 90. Especificación de caso de uso “Eliminar tipo de carpeta”
Fuente: Da Silva, Sergio (2012).
Caso de uso Eliminar tipo de carpeta
Entradas ID de usuario
Contraseña de usuario
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
este menú.
Salidas Una tabla con los tipos de carpeta
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
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 decide eliminar el tipo de carpeta
4. El sistema guarda la información en la base de datos
Flujo alternativo
3.1. El usuario decide cancelar la operación
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
Entradas ID de usuario
Contraseña de usuario
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
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
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
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 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
Fuente: Da Silva, Sergio (2012).
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
Entradas ID de usuario
Contraseña de usuario
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
Capacidad de la caja
Departamento y dependencia al que pertenece la
caja
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
este menú.
Salidas La 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 cambiar la caja de ubicación, ya que no
existen ubicaciones disponibles
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 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
6. Se genera un reporte con la tabla de retención documental
92
Fuente: Da Silva, Sergio (2012).
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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Conservar carpetas
Entradas ID de usuario
Contraseña de usuario
Descripción del valor documental
Fecha de transferencia
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
este menú.
Salidas La 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 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 realiza la búsqueda de la carpeta
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
7. Se genera un reporte con la tabla de retención documental
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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Destruir carpeta
Entradas ID de usuario
Contraseña de usuario
Fecha de destrucción
Nombre del archivo digitalizado
Ruta del archivo
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
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
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 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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Registrar préstamo
Entradas ID de usuario
Contraseña de usuario
Fecha de entrega estimada
Persona que recibe (opcional)
Observación (opcional)
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
este menú.
Salidas Reporte de préstamo
Post-condición éxito Se emite un reporte del préstamo realizado
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 realiza la búsqueda de la carpeta
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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Registrar devolución de préstamo
Entradas ID de usuario
Contraseña de usuario
Número de caja
Fecha de entrega real
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
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
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 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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Consultar localizaciones
Entradas ID de usuario
Contraseña de usuario
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
este menú.
Salidas Ninguna
Post-condición éxito Se muestra un croquis con los estantes y una tabla
con las localizaciones
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 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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Consultar carpetas
Entradas ID de usuario
Contraseña de usuario
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
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
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 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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Consultar préstamo
Entradas ID de usuario
Contraseña de usuario
Precondiciones El usuario debe estar registrado
El usuario debe tener un rol que le permita acceder a
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
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 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”
Fuente: Da Silva, Sergio (2012).
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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Editar usuarios
Entradas ID de administrador
Contraseña de administrador
Nombre
Apellido
Cedula
Dependencias a las que pertenece
Precondiciones El administrador debe estar registrado
El usuario debe estar registrado
Salidas Ninguna
Post-condición éxito El usuario aparecerá en la tabla de usuarios con la
información modificada
Post-condición fallo Ninguno
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 modifica los datos del usuario en el formulario
4. El sistema modifica 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.
102
Tabla Nº 102. Especificación de caso de uso “Cambiar clave”
Fuente: Da Silva, Sergio (2012).
Caso de uso Cambiar clave
Entradas ID de administrador
Contraseña de administrador
Contraseña del usuario
Precondiciones El administrador debe estar registrado
El usuario debe estar registrado
Salidas Ninguna
Post-condición éxito Aparecerá la contraseña en un mensaje
Post-condición fallo Ninguno
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 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
2.1. El usuario cancela la operación
Observaciones
103
Tabla Nº 103. Especificación de caso de uso “Crear submenú”
Fuente: Da Silva, Sergio (2012).
Caso de uso Crear submenú
Entradas ID de administrador
Contraseña de administrador
Descripción del submenú
Precondiciones El administrador debe estar registrado
Salidas Ninguna
Post-condición éxito El submenú aparecerá en una tabla perteneciente al
menú seleccionado
Post-condición fallo Ninguno
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 selecciona un menú
4. El administrador crea un nuevo submenú ingresando su descripción
5. El sistema guarda la información en la base de datos
Flujo alternativo
4.1.El administrador cancela la operación
Observaciones
104
Tabla Nº 104. Especificación de caso de uso “Modificar submenú”
Fuente: Da Silva, Sergio (2012).
Caso de uso Modificar submenú
Entradas ID de administrador
Contraseña de administrador
Descripción del submenú
Precondiciones El administrador debe estar registrado
Salidas Ninguna
Post-condición éxito El submenú aparecerá modificado en una tabla
perteneciente al menú seleccionado
Post-condición fallo Ninguno
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 selecciona un menú
4. El administrador crea un nuevo submenú ingresando su descripción
5. El sistema guarda la información en la base de datos
Flujo alternativo
4.1.El administrador cancela la operación
Observaciones
105
Tabla Nº 105. Especificación de caso de uso “Crear rol”
Fuente: Da Silva, Sergio (2012).
Caso de uso Crear rol
Entradas ID de administrador
Contraseña de administrador
Descripción de rol
submenús
Precondiciones El administrador debe estar registrado
Salidas Ninguna
Post-condición éxito El nuevo rol aparecerá en una tabla
Post-condición fallo Ninguno
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 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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Editar rol
Entradas ID de administrador
Contraseña de administrador
Descripción de rol
submenús
Precondiciones El administrador debe estar registrado
Salidas Ninguna
Post-condición éxito El rol aparecerá modificado en la tabla
Post-condición fallo Ninguno
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 selecciona el rol y modifica la información
4. El sistema almacena los datos modificados 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ú.
107
Tabla Nº 107. Especificación de caso de uso “Eliminar rol”
Fuente: Da Silva, Sergio (2012).
Caso de uso Eliminar rol
Entradas ID de administrador
Contraseña de administrador
Precondiciones El administrador debe estar registrado
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
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 selecciona el rol y lo elimina
4. El sistema elimina el rol de la base de datos
Flujo alternativo
3.1. El administrador cancela la operación
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”
Fuente: Da Silva, Sergio (2012).
Caso de uso Asignar rol
Entradas ID de administrador
Contraseña de administrador
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
Post-condición fallo Ninguno
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 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
Fuente: Da Silva, Sergio (2012).
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
Fuente: Da Silva, Sergio (2012).
112
Gráfico Nº 15. Esquema de la base de datos
Fuente: Da Silva, Sergio (2012).
113
5.3.2. Interfaz de usuario
Gráfico Nº 16. Pantalla de ingreso al sistema
Fuente: Da Silva, Sergio (2012).
114
Gráfico Nº 17. Pantalla del menú principal
Fuente: Da Silva, Sergio (2012).
Gráfico Nº 18. Pantalla del menú “parámetros”
Fuente: Da Silva, Sergio (2012).
115
Gráfico Nº 19. Pantalla del menú “departamentos”
Fuente: Da Silva, Sergio (2012).
Gráfico Nº 20. Pantalla del menú “Localizaciones”
Fuente: Da Silva, Sergio (2012).
116
Gráfico Nº 21. Pantalla del menú “Valor Documental”
Fuente: Da Silva, Sergio (2012).
Gráfico Nº 22. Pantalla del menú “Tipo de carpetas”
Fuente: Da Silva, Sergio (2012).
117
Gráfico Nº 23. Pantalla del menú “Ingresar TRD”
Fuente: Da Silva, Sergio (2012).
Gráfico Nº 24. Pantalla del menú “Ingresar TRD”. Generación de la tabla de retención documental en PDF.
Fuente: Da Silva, Sergio (2012).
118
Gráfico Nº 25. Pantalla del menú “modificar TRD”.
Fuente: Da Silva, Sergio (2012).
Gráfico Nº 26. Pantalla del menú “Desincorporar”.
Fuente: Da Silva, Sergio (2012).
119
Gráfico Nº 27. Pantalla del menú “Desincorporar”. Opción “Conservar”
Fuente: Da Silva, Sergio (2012).
Gráfico Nº 28. Pantalla del menú “Desincorporar”. Opción “Destruir”
Fuente: Da Silva, Sergio (2012).
120
Gráfico Nº 29. Pantalla del menú “Registro de Préstamo”.
Fuente: Da Silva, Sergio (2012).
Gráfico Nº 30. Pantalla del menú “Registro de Préstamo”.
Fuente: Da Silva, Sergio (2012).
121
Gráfico Nº 31. Pantalla del menú “Registro de Préstamo”. Generación de reporte de préstamo en PDF.
Fuente: Da Silva, Sergio (2012).
Gráfico Nº 32. Pantalla del menú “Devolución de Préstamo”.
Fuente: Da Silva, Sergio (2012).
122
Gráfico Nº 33. Pantalla del menú “Consulta de préstamo”.
Fuente: Da Silva, Sergio (2012).
Gráfico Nº 34. Pantalla del menú “Consulta de carpetas”.
Fuente: Da Silva, Sergio (2012).
123
Gráfico Nº 35. Pantalla del menú “Consulta de localizaciones”.
Fuente: Da Silva, Sergio (2012).
Gráfico Nº 36. Pantalla del menú “Administración de usuarios”.
Fuente: Da Silva, Sergio (2012).
124
Gráfico Nº 37. Pantalla del menú “Administración de usuarios”. Opción “crear nuevo usuario”
Fuente: Da Silva, Sergio (2012).
Gráfico Nº 38. Pantalla del menú “Menús”.
Fuente: Da Silva, Sergio (2012).
125
Gráfico Nº 39. Pantalla del menú “Menús”. Opción “Ver menús”.
Fuente: Da Silva, Sergio (2012).
Gráfico Nº 40. Pantalla del menú “Roles”.
Fuente: Da Silva, Sergio (2012).
126
Gráfico Nº 41. Pantalla del menú “Asignación de roles”.
Fuente: Da Silva, Sergio (2012).
Gráfico Nº 42. Pantalla del menú “Asignación de roles”. Asignación de roles al usuario “sfernandez”.
Fuente: Da Silva, Sergio (2012).
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
Distribuidora Universal Kia, C.A.
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
Fuente: Da Silva, Sergio (2012).
128
Tabla Nº 110. Prueba Nº2.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo
“Parámetros”
Usuario Katy Hernández
Elemento a probar Funcionamiento de los botones
Crear y editar un parámetro
Comprobar el rol de usuario
Pasos Elemento Resultado
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
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
129
Tabla Nº 111. Prueba Nº3.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo
“Departamentos”
Usuario Katy Hernández
Elemento a probar Funcionamiento de los botones
Crear, editar y eliminar un departamento
Crear, editar y eliminar una dependencia
Comprobar el rol de usuario
Pasos Elemento Resultado
Botones Correcto
Crear departamento Correcto
Editar departamento Correcto
Eliminar departamento Correcto
Crear dependencia Correcto
Editar dependencia Correcto
Eliminar dependencia 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
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
130
Tabla Nº 112. Prueba Nº4.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo
“Localizaciones”
Usuario Katy Hernández
Elemento a probar Funcionamiento de los botones
Crear, editar y eliminar una localización
Crear y editar una ubicación
Comprobar el rol de usuario
Pasos Elemento Resultado
Botones Correcto
Crear localización Correcto
Editar localización Correcto
Eliminar localización Correcto
Crear ubicación Correcto
Editar ubicación 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 Ordenar las tablas por estante.
Colocar una barra de desplazamiento para la tabla
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
131
Tabla Nº 113. Prueba Nº5.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo “Valor
Documental”
Usuario Katy Hernández
Elemento a probar Funcionamiento de los botones
Crear, editar y eliminar un valor documental
Comprobar el rol de usuario
Pasos Elemento Resultado
Botones Correcto
Crear valor documental Correcto
Editar valor documental Correcto
Eliminar valor
documental
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
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
132
Tabla Nº 114. Prueba Nº6.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo “Tipo de
carpetas”
Usuario Katy Hernández
Elemento a probar Funcionamiento de los botones
Crear, editar y eliminar un tipo de carpeta
Comprobar el rol de usuario
Pasos Elemento Resultado
Botones Correcto
Crear un tipo de carpeta Correcto
Editar un tipo de carpeta Correcto
Eliminar un tipo de
carpeta
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
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
133
Tabla Nº 115. Prueba Nº7.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo “Ingresar
TRD”
Usuario Katy Hernández
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
Comprobar el rol de usuario
Pasos Elemento Resultado
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.
Acceso al menú Accede correctamente si el rol
del usuario se lo permite, mensaje
de error si el rol no se lo permite
Observaciones
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
134
Tabla Nº 116. Prueba Nº8.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo
“Modificar TRD”
Usuario Katy Hernández
Elemento a probar Funcionamiento de los botones y listas de selección
Búsqueda de carpetas
Editar ubicación, cajas o TRD
Generación de tabla de retención documental
Comprobar el rol de usuario
Pasos Elemento Resultado
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
Acceso al menú Accede correctamente si el rol
del usuario se lo permite, mensaje
de error si el rol no se lo permite
Observaciones Ordenar filtro de búsqueda en una lista
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
135
Tabla Nº 117. Prueba Nº9.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo
“Desincorporar”
Usuario Katy Hernández
Elemento a probar Funcionamiento de los botones
Búsqueda de carpetas
Editar ubicación, cajas o TRD
Generación de tabla de retención documental
Comprobar el rol de usuario
Pasos Elemento Resultado
Botones Correcto
Búsqueda de carpetas Correcto
Conservar carpeta Correcto, se genera la tabla de
retención documental
Eliminar carpeta Correcto
Digitalizar carpeta Funciona correctamente en la
carga de archivos menores a
25MB.
Acceso al menú Accede correctamente si el rol
del usuario se lo permite, mensaje
de error si el rol no se lo permite
Observaciones
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
136
Tabla Nº 118. Prueba Nº10.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo “Registrar
préstamo”
Usuario Katy Hernández
Elemento a probar Funcionamiento de los botones
Búsqueda de carpetas
Registrar un préstamo
Generación de reporte de préstamo
Comprobar el rol de usuario
Pasos Elemento Resultado
Botones Correcto
Búsqueda de carpetas Correcto
Registrar préstamo Correcto, se genera el reporte de
préstamo
Acceso al menú Accede correctamente si el rol
del usuario se lo permite, mensaje
de error si el rol no se lo permite
Observaciones
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
137
Tabla Nº 119. Prueba Nº11.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo
“Devolución préstamo”
Usuario Katy Hernández
Elemento a probar Funcionamiento de los botones
Búsqueda de caja en préstamo
Registrar una devolución de préstamo
Comprobar el rol de usuario
Pasos Elemento Resultado
Botones Correcto
Búsqueda de caja en
préstamo
Correcto
Registrar devolución de
préstamo
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
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
138
Tabla Nº 120. Prueba Nº12.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo
“Consultar préstamo”
Usuario Katy Hernández
Elemento a probar Funcionamiento de las listas de selección y botones
Realizar una búsqueda
Comprobar el rol de usuario
Pasos Elemento Resultado
Botones y lista de
selección
Correcto
Búsqueda de prestamos 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 Adicionar una opción para exportar búsqueda en hoja de
Excel
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
139
Tabla Nº 121. Prueba Nº13.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo
“Consultar carpetas”
Usuario Katy Hernández
Elemento a probar Funcionamiento de las listas de selección y botones
Realizar una búsqueda
Comprobar el rol de usuario
Pasos Elemento Resultado
Botones y lista de
selección
Correcto
Búsqueda de carpetas 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 Adicionar una opción para exportar búsqueda en hoja
de Excel
Adicionar la opción de realizar búsqueda de carpetas
por usuario
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
140
Tabla Nº 122. Prueba Nº14.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo
“Consultar localizaciones”
Usuario Katy Hernández
Elemento a probar Funcionamiento de botones
Realizar una búsqueda
Comprobar el rol de usuario
Pasos Elemento Resultado
Botones Correcto
Búsqueda de
localizaciones
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
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
141
Tabla Nº 123. Prueba Nº15.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo “Admón.
usuarios”
Usuario Katy Hernández
Elemento a probar Funcionamiento de botones
Validación de campos
Crear y editar cuentas de usuario
Cambio de contraseñas
Comprobar el rol de usuario
Pasos Elemento Resultado
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.
Acceso al menú Accede correctamente si el rol
del usuario se lo permite, mensaje
de error si el rol no se lo permite
Observaciones Mejorar formulario de creación de usuarios.
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
142
Tabla Nº 124. Prueba Nº16.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo “Mant. De
menús”
Usuario Katy Hernández
Elemento a probar Funcionamiento de botones
Crear y editar submenús
Comprobar el rol de usuario
Pasos Elemento Resultado
Botones Correcto
Crear submenú Correcto
Editar submenú 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 Colocar en cada tabla de submenú el menú al que
corresponden
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
143
Tabla Nº 125. Prueba Nº17.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo “definir
roles”
Usuario Katy Hernández
Elemento a probar Funcionamiento de botones
Crear, editar y eliminar roles
Comprobar el rol de usuario
Pasos Elemento Resultado
Botones Correcto
Crear rol Correcto
Editar rol Correcto
Eliminar rol 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
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
144
Tabla Nº 126. Prueba Nº18.
Prueba de verificación del sistema de control de archivos inactivos en
Distribuidora Universal Kia, C.A.
Fecha 23 / 10 / 2012
Objetivos Comprobar el correcto funcionamiento del módulo “asignar
roles”
Usuario Katy Hernández
Elemento a probar Funcionamiento de botones
Asignar y quitar roles a los usuarios
Comprobar el rol de usuario
Pasos Elemento Resultado
Botones Correcto
Asignar rol a usuario Correcto
Quitar rol a usuario 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
Supervisor Katy Hernández
Fuente: Da Silva, Sergio (2012).
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