UNIVERSIDAD SEÑOR DE SIPAN
FACULTAD DE INGENIERIA
ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS
TES I S “ IMPLEMENTACION DE UN SISTEMA INFORMÁTICO DE GESTIÓN
DOCUMENTARIA PARA MEJORAR EL SERVICIO DE ATENCION A
LOS USUARIOS DE LA MUNICIPALIDAD DISTRITAL DE JAYANCA”
PARA OPTAR EL TÍTULO PROFESIONAL
DE INGENIERO DE SISTEMAS
AUTOR:
Albertina Purisaca Vigil
ASESOR:
Ing. Martín Ampuero Pasco
PIMENTEL PERÚ
2008
“ IMPLEMENTACION DE UN SISTEMA INFORMÁTICO DE GESTIÓN
DOCUMENTARIA PARA MEJORAR EL SERVICIO DE ATENCION A
LOS USUARIOS DE LA MUNICIPALIDAD DISTRITAL DE JAYANCA”
_______________________ ________________________ Albertina Purisaca Vigl Ing. Martin Ampuero Pasco
AUTOR ASESOR
PRESENTADA A LA ESCUELA DE INGENIERÍA DE SISTEMAS DE LA
UNIVERSIDAD SEÑOR DE SIPÁN PARA OPTAR EL TÍTULO DE:
INGENIERO DE SISTEMAS
APROBADO POR:
_______________________ ________________________ Lic. Manuel Amaya Checa Msc. Manuel Sánchez Chero
Presidente Secretario
_______________________ Ing. Alberto Samillán Ayala
Vocal
DEDICATORIA
A Dios por iluminarme en mi
vida y a lo largo de mi carrera
profesional.
A mis hijos:
ROCÍO ALESANDRA y
JUAN DIEGO,
fuerza y motivo de mi existencia.
AGRADECIMIENTOS
A mi familia que me brindó su
apoyo incondicional y constante
para lograr mis metas propuestas.
A las autoridades y trabajadores
de la Municipalidad Distrital de
Jayanca, por su apoyo brindado
para el desarrollo de la presente
investigación.
RESUMEN
En el marco del gobierno electrónico y modernización de las instituciones del
estado y en beneficio de los ciudadanos, se ha planteado la implementación de un
sistema de gestión documentaria para la Municipalidad Distrital de Jayanca. Esta
investigación constituye un aporte para el logro de los objetivos estratégicos de esta
institución, y está estructurada de la siguiente manera.
En el Capítulo I, se describe la institución en estudio considerando su:
finalidad, objetivos, funciones básicas y estructura organizativa.
En el Capítulo II, se analiza el problema de investigación teniendo en cuenta
realidad problemática, la formulación del problema, la justificación e importancia de
la investigación; los objetivos de la investigación; el planteamiento de la hipótesis y
su contrastación por medio de variables e indicadores.
En el Capítulo III, se establece el marco teórico realizando una recopilación de
antecedentes de estudio e investigación, así como la definición conceptual de la
terminología empleada.
En el Capítulo IV, correspondiente al marco conceptual, se analizan tres
metodologías de desarrollo de software (Proceso Unificado de Rational RUP,
ICONIX y proceso del software orientado a objetosOOSP) considerando los
criterios: Características del proyecto y requerimientos. Posteriormente se realiza la
selección de la metodología, siendo RUP la que se consideró más apropiada para su
aplicación teniendo en cuenta que permite generar muchos artefactos finales que
pueden ser aprovechados en una reutilización de productos, modelos y procesos.
En el Capítulo V, se desarrolla la propuesta en base a la metodología RUP.
Esta se conforma de cuatro fases (Inicio, Elaboración, Construcción y Transición)
que interactúan con sus disciplinas (Modelado del Negocio, Requisitos, Análisis,
Diseño, Implementación y Pruebas).
En Capítulo VI: se ha realizado el análisis Costo Beneficio, indicando la
inversión inicial, los gastos concurrentes u operativos y los beneficios.
ABSTRACT
Under the field of electronic government and modernization of state institutions
and for the benefit of citizens, has proposed the implementation of Documentary
Management System for District Municipality of Jayanca. This research is a
contribution to achieving the strategic goals of this institution, and is structured as
follows.
In Chapter I, describes the institution of their study: purpose, objectives, core
functions and organizational structure.
In Chapter II, he examines the research problem including problematic reality,
the formulation of the problem, justification and importance of research, research
objectives, the approach of the assumptions and their scrutiny by variables and
indicators .
In Chapter III, establishes the theoretical framework doing a collection of
background study and research, as well as the conceptual definition of terminology.
In Chapter IV, which covers the conceptual framework, it analyzes three
software development methodologies (Rational Unified ProcessRUP, ICONIX and
ObjectOriented Software ProcessOOSP) considering the criteria: Characteristics of
the Project and requirements and then it chooses the methodology, being RUP the
most appropriate for application because it generates many devices that can be
seized in the reuse of products, models and processes.
In Chapter V, it developes the proposal based on the RUP methodology. This
consists of four phases (Start, Development, Construction and Transition) interacting
with their disciplines (Business Modeling, Requirements, Analysis, Design,
Implementation and Testing).
In Chapter VI: it performed the analysis Cost Benefit, indicating the initial
investment, concurrent or operational costs and benefits.
I N D I C E G E N E R A L
DEDICATORIA.
AGRADECIMIENTO.
RESUMEN.
ABSTRACT.
CAPITULO I: LA ORGANIZACIÓN. 1.1.Reseña histórica............................................................................................................... 20
1.2. Finalidad.......................................................................................................................... 20
1.3. Objetivos ......................................................................................................................... 20
1.4. Funciones Básicas........................................................................................................... 21
1.5. Estructura Organizativa.................................................................................................... 23
CAPITULO II: PROBLEMA DE INVESTIGACIÓN.
2.1. Realidad Problemática..................................................................................................... 25
2.2. Formulación del Problema ............................................................................................... 31
2.3. Justificación e Importancia de la Investigación ................................................................. 31
2.4. Objetivos ......................................................................................................................... 33
2.4.1. Objetivo General.................................................................................................... 33
2.4.2. Objetivos Específicos ............................................................................................ 33
2.5. Limitaciones de la investigación ....................................................................................... 34
2.6. Hipótesis.......................................................................................................................... 35
2.7. Variables ......................................................................................................................... 35
2.8. Contrastación de hipótesis ............................................................................................... 36
CAPÍTULO III. MARCO TEÓRICO 3.1. Antecedentes de la Investigación..................................................................................... 38
3.1.1. Investigaciones a Nivel Académico .................................................................... 38
3.1.2. Investigaciones a Nivel institucional ................................................................... 40
3.1.3. Sistema de información...................................................................................... 42
3.1.4. Seguridad en los Sistemas de Información......................................................... 45
3.1.5. Sistema informático ........................................................................................... 47
3.1.6. Gestión de la información................................................................................... 48
3.1.7. Documento ........................................................................................................ 49
3.1.8 Documento electrónico ...................................................................................... 53
3.1.9. Gestión documentaria ....................................................................................... 54
3.1.10. Sistema de Gestión documentaria ..................................................................... 57
3.1.11. Tecnología usada en sistemas informáticos ....................................................... 59
3.2.12. Usuario .............................................................................................................. 73
3.2.13. Atención al usuario ............................................................................................ 74
3.2.14. Normas del Sistema Nacional de Archivo aplicada a Municipalidades ................ 77
3.1.15. Ley de Procedimiento Administrativo General, Ley N° 27444 ............................. 78
3.1.16. Ley de Transparencia y acceso a la información pública, Nº 27806 ................... 82
3.2. Definición conceptual terminológica ................................................................................. 84
3.2.1. Sistema de Gestión documentaria ......................................................................... 84
3.2.2. Seguridad del sistema ........................................................................................... 85
3.2.3. Aspecto sobre digitalización................................................................................... 86
3.2.4. Usuario ................................................................................................................ 88
3.2.5. Atención al usuario ................................................................................................ 88
CAPÍTULO IV. MARCO CONCEPTUAL 4.1. Metodologías de desarrollo de sistemas .......................................................................... 90
4.1.1. Metodología RUP ................................................................................................. 90
4.1.2. Metodología ICONIX ............................................................................................ 91
4.1.3. Metodología OOSP (ObjectOriented Software Process): ...................................... 91
4.2. Comparación de metodologías......................................................................................... 92
4.3. Metodología elegida......................................................................................................... 94
4.3.1. Definición ............................................................................................................. 94
4.3.2. Fases de la Metodología RUP............................................................................... 94
4.3.3. RUP, Metodología basada en UML ....................................................................... 97
4.3.4. RUP y las mejores prácticas para el desarrollo de software................................. 101
CAPÍTULO V. DESARROLLO DE LA PROPUESTA 5.1. Fase inicial ...................................................................................................................... 105
5.1.1. Modelado del negocio ......................................................................................... 105
5.1.1.1. Modelo de Casos de Uso del Negocio .................................................... 105
5.1.1.2. Especificación de Casos de Uso del Negocio ......................................... 106
5.1.1.3. Modelos de objeto del negocio (MON) .................................................... 108
5.1.1.4. Modelo de dominio del problema ............................................................ 111
5.1.1.5. Glosario de términos............................................................................... 112
5.2. Fase de Elaboración........................................................................................................ 113
5.2.1. Requerimientos................................................................................................... 114
5.2.1.1. Modelo de Casos de Uso de Requerimientos (MCUR ............................. 115
5.2.1. Análisis y Diseño................................................................................................. 143
5.2.2.1. Modelo de Análisis ................................................................................. 144
5.3. Fase de construcción....................................................................................................... 159
5.3.1. Análisis y Diseño................................................................................................. 160
5.3.1.1. Modelo de Diseño................................................................................... 160
a) Interfaces del Sistemas ................................................................... 160
b) Diagramas de secuencias ............................................................... 171
c) Diagrama de Clases ........................................................................ 200
d) Diseño Físico de la Base de Datos: ................................................. 201
5.3.2. Implementación................................................................................................... 202
5.3.2.1. Diagrama de Componentes: ................................................................... 202
5.3.2.2. Diagrama de Despliegue: ....................................................................... 205
5.3.3. Medidas de Seguridad para el sistema................................................................ 206
5.3.3.1. Autenticación (identificación segura)....................................................... 206
5.3.3.2. Autorización ........................................................................................... 207
5.3.3.3. Comunicación segura............................................................................. 207
5.3.3.4. Auditoría................................................................................................. 207
5.3.3.5. Administración de perfiles....................................................................... 208
CAPITULO VI: ANALISIS COSTO BENEFICIO 6.1. Inversión inicial ................................................................................................................ 211
6.2. Gastos concurrentes u operativos.................................................................................... 212
6.3. Resumen de los costos totales de implementación .......................................................... 213
6.4. Costo/Beneficio ............................................................................................................... 213
CAPITULO VII: CONCLUSIONES
CAPITULO VIII: RECOMENDACIONES
REFERENCIAS BIBLIOGRÁFICAS
ANEXOS
I N D I C E D E I L U S T R A C I O N E S
FIGURA 1: Tipos de documentos en las oficinas Municipales.......................................................50
FIGURA 2: Edad de los documentos según la teoría de los documentos......................................53
FIGURA 3: Arquitectura de tecnología Web Clásica (Cliente Servidor) .......................................60
FIGURA 4: Cadena de digitalización ...........................................................................................72
FIGURA 5: Modelo del sistema de Gestión Documentaria para la Municipalidad
Distrital de Jayanca................................................................................................85
FIGURA 6: Fases, flujos de trabajo e iteraciones de la metodología RUP.....................................96
FIGURA 7: Mejores prácticas en la metodología RUP................................................................101
FIGURA 8: Modelo de casos de uso del negocio .......................................................................105
FIGURA 9: Modelo de objeto de negocio: administración del sistema ........................................109
FIGURA 10: Modelo de objeto de negocio: Registro de documento............................................109
FIGURA 11: Modelo de objeto de negocio: gestión de documento..............................................110
FIGURA 12: Modelo de dominio del problema............................................................................111
FIGURA 13: Modelo de caso de uso de requerimiento: administración del sistema ....................116
FIGURA 14: Modelo de caso de uso de requerimiento: registro de documento...........................123
FIGURA 15: Modelo de caso de uso de requerimiento: gestión de documento ...........................134
FIGURA Nº 16: Diagrama de colaboración: Listar serie documental ...........................................145
FIGURA Nº 17: Diagrama de colaboración: Registrar serie documental......................................146
FIGURA Nº 18: Diagrama de colaboración: Registrar grupo documental ....................................146
FIGURA Nº 19: Diagrama de colaboración: Registrar área .........................................................147
FIGURA Nº 20: Diagrama de colaboración: Listar empleado ......................................................147
FIGURA Nº 21: Diagrama de colaboración: Registrar empleado.................................................148
FIGURA Nº 22: Diagrama de colaboración: Asignar usuario y permisos .....................................148
FIGURA Nº 23: Diagrama de colaboración: Listar documentos externos registrados ..................149
FIGURA Nº 24: Diagrama de colaboración: Registrar documento externo ..................................150
FIGURA Nº 25: Diagrama de colaboración: Buscar usuario........................................................150
FIGURA Nº 26: Diagrama de colaboración: Registrar usuario.....................................................150
FIGURA Nº 27: Diagrama de colaboración: Gestionar adjuntos..................................................151
FIGURA Nº 28: Diagrama de colaboración: Gestionar referencias..............................................151
FIGURA Nº 29: Diagrama de colaboración: Derivar documento..................................................152
FIGURA Nº 30: Diagrama de colaboración: Generar ticket .........................................................152
FIGURA Nº 31: Diagrama de colaboración: Mostrar adjuntos .....................................................152
FIGURA Nº 32: Diagrama de colaboración: Listar documentos externos derivados ....................153
FIGURA Nº 33: Diagrama de colaboración: Listar documentos anulados....................................153
FIGURA Nº 34: Diagrama de colaboración: Listar documentos internos registrados ...................154
FIGURA Nº 35: Diagrama de colaboración: Registrar documento interno ...................................154
FIGURA Nº 36: Diagrama de colaboración: Listar documentos pendientes de atención..............155
FIGURA Nº 37: Diagrama de colaboración: Concluir atención ....................................................155
FIGURA Nº 38: Diagrama de colaboración: Mostrar seguimiento ...............................................156
FIGURA Nº 39: Diagrama de colaboración: Listar documentos respondidos...............................156
FIGURA Nº 40: Diagrama de colaboración: Listar documentos atendidos...................................157
FIGURA Nº 41: Diagrama de colaboración: Listar documentos archivados.................................158
FIGURA Nº 42: Diagrama de colaboración: Ubicar documento externo ......................................158
FIGURA Nº 43: Diagrama de colaboración: Ubicar documento interno .......................................159
FIGURA Nº 44: IU: Acceso al sistema ........................................................................................160
FIGURA Nº 45: IU Principal del SISGEDOC...............................................................................161
FIGURA Nº 46: Menú Administración del sistema ......................................................................161
FIGURA Nº 47: IU: Registrar área de trabajo..............................................................................162
FIGURA Nº 48: IU: Registrar empleado......................................................................................162
FIGURA Nº 49: IU: Registrar serie documental...........................................................................163
FIGURA Nº 50: IU: Listar documentos externos .........................................................................163
FIGURA Nº 51: IU: Registrar documento externo .......................................................................164
FIGURA Nº 52: IU: Derivar documento.......................................................................................164
FIGURA Nº 53: IU: Generar ticket ..............................................................................................165
FIGURA Nº 54: IU: Mostrar adjuntos de documento externo.......................................................165
FIGURA Nº 55: IU: Listar documentos enviados.........................................................................166
FIGURA Nº 56: IU: Listar documentos eliminados ......................................................................166
FIGURA Nº 57: IU: Listar documentos internos registrados ........................................................167
FIGURA Nº 58: IU: Registrar documento interno ........................................................................167
FIGURA Nº 59: IU: Listar documentos pendientes de atención...................................................168
FIGURA Nº 60: IU Listar documentos respondidos.....................................................................168
FIGURA Nº 61: IU Listar documentos atendidos.........................................................................169
FIGURA Nº 62: IU Listar documentos archivados.......................................................................169
FIGURA Nº 63: IU Ubicar documento externo ............................................................................170
FIGURA Nº 64: IU Ubicar documento interno .............................................................................170
FIGURA Nº 65: IU Mostrar documento interno............................................................................171
FIGURA Nº 66: Diagrama de secuencia: Listar serie documental ...............................................172
FIGURA Nº 67: Diagrama de secuencia: Registrar serie documental..........................................173
FIGURA Nº 68: Diagrama de secuencia: Registrar grupo documental ........................................174
FIGURA Nº 69: Diagrama de secuencia: Registrar área.............................................................175
FIGURA Nº 70: Diagrama de secuencia: Listar empleado ..........................................................176
FIGURA Nº 71: Diagrama de secuencia: Registrar empleado.....................................................177
FIGURA Nº 72: Diagrama de secuencia: Asignar usuario y permisos .........................................178
FIGURA Nº 73: Diagrama de secuencia: Listar documentos externos registrados ......................179
FIGURA Nº 74: Diagrama de secuencia: Registrar documento externo ......................................180
FIGURA Nº 75: Diagrama de secuencia: Buscar usuario ............................................................181
FIGURA Nº 76: Diagrama de secuencia: Registrar usuario.........................................................182
FIGURA Nº 77: Diagrama de secuencia: Gestionar adjuntos......................................................183
FIGURA Nº 78: Diagrama de secuencia: Gestionar referencias..................................................184
FIGURA Nº 79: Diagrama de secuencia: Derivar documento......................................................185
FIGURA Nº 80: Diagrama de secuencia: Generar ticket .............................................................186
FIGURA Nº 81: Diagrama de secuencia: Mostrar adjuntos .........................................................187
FIGURA Nº 82: Diagrama de secuencia: Listar documentos externos derivados ........................188
FIGURA Nº 83: Diagrama de secuencia: Listar documentos anulados........................................189
FIGURA Nº 84: Diagrama de secuencia: Listar documentos internos registrados .......................190
FIGURA Nº 85: Diagrama de secuencia: Registrar documento interno .......................................191
FIGURA Nº 86: Diagrama de secuencia: Listar documentos pendientes de atención..................192
FIGURA Nº 87: Diagrama de secuencia: Concluir atención ........................................................193
FIGURA Nº 88: Diagrama de secuencia: Mostrar seguimiento....................................................194
FIGURA Nº 89: Diagrama de secuencia: Listar documentos respondidos...................................195
FIGURA Nº 90: Diagrama de secuencia: Listar documentos atendidos.......................................196
FIGURA Nº 91: Diagrama de secuencia: Listar documentos archivados.....................................197
FIGURA Nº 92: Diagrama de secuencia: Ubicar documento externo ..........................................198
FIGURA Nº 93: Diagrama de secuencia: Ubicar documento interno ...........................................199
FIGURA 94: Diagrama de clases ...............................................................................................200
FIGURA 95: Diagrama físico de la base de datos.......................................................................201
FIGURA 96: Diagrama de Componentes....................................................................................203
FIGURA 97: Diagrama de despliegue.........................................................................................205
FIGURA 98: Directivas de seguridad en las tres capas del sistema ............................................206
FIGURA Nº 99: IU Auditoría de operaciones con documentos ...................................................208
I N D I C E D E C U A D R O S Y G R Á F I C O S
CUADRO 1: INDICADORES Y FÓRMULA PARA SU CÁLCULO ................................................................ 35
CUADRO 2: REDUCCIÓN DEL TIEMPO DE GESTIÓN DOCUMENTARIA ................................................. 36
CUADRO 3: INCREMENTO DE SATISFACCIÓN DE LOS USUARIOS....................................................... 36
CUADRO 4: SISTEMAS Y SUBSISTEMAS DE UN GOBIERNO LOCAL ..................................................... 44
CUADRO 5: FORMATOS DE ARCHIVO DE IMÁGENES COMUNES ......................................................... 70
CUADRO 6: TIPOS DE SERVICIOS GUBERNAMENTALES ...................................................................... 77
CUADRO 7: CARACTERÍSTICAS DEL SCANNER DE LA MUNICIPALIDAD DISTRITAL DE JAYANCA...... 87
CUADRO 8: COMPARACIÓN DE METODOLOGÍAS SEGÚN CARACTERÍSTICAS DEL PROYECTO ........ 92
CUADRO 9: COMPARACIÓN DE METODOLOGÍAS SEGÚN REQUERIMIENTOS PARA LA ADOPCIÓN .. 93
CUADRO 10: PONDERACIONES ASIGNADAS SEGÚN CRITERIOS DE ELECCIÓN DE METODOLOGÍA. 93
CUADRO 11: CRITERIOS DE SELECCIÓN Y PUNTUACIONES SEGÚN METODOLOGÍA ........................ 93
CUADRO 12: ELEMENTOS DE CONSTRUCCIÓN EN UML....................................................................... 98
CUADRO 13: ELEMENTOS DE RELACIÓN EN UML................................................................................. 99
CUADRO 14: DIAGRAMAS EN UML........................................................................................................ 100
CUADRO 15: CASO DE USO ADMINISTRACIÓN DEL SISTEMA ............................................................ 106
CUADRO 16: CASO DE USO REGISTRO DE DOCUMENTO................................................................... 107
CUADRO 17: CASO DE USO GESTIÓN DE DOCUMENTO..................................................................... 108
CUADRO 18: ESPECIFICACIÓN DE CASO DE USO LISTAR SERIE DOCUMENTARIA .......................... 117
CUADRO 19: ESPECIFICACIÓN DE CASO DE USO REGISTRAR SERIE DOCUMENTARIA .................. 117
CUADRO 20: ESPECIFICACIÓN DE CASO DE USO REGISTRAR GRUPO DOCUMENTAL.................... 118
CUADRO 21: ESPECIFICACIÓN DE CASO DE USO REGISTRAR ÁREA................................................ 118
CUADRO 22: ESPECIFICACIÓN DE CASO DE USO LISTAR EMPLEADO .............................................. 119
CUADRO 23: ESPECIFICACIÓN DE CASO DE USO REGISTRAR EMPLEADO ...................................... 119
CUADRO 24: ESPECIFICACIÓN DE CASO DE USO ACTUALIZAR EMPLEADO..................................... 120
CUADRO 25: ESPECIFICACIÓN DE CASO DE USO ASIGNAR USUARIO Y PERMISOS........................ 120
CUADRO 26: ESPECIFICACIÓN DE CASO DE USO GENERAR REPORTE DE SERIE DOCUMENTAL POR
GRUPO DOCUMENTARIO...................................................................................................................... 121
CUADRO 27: ESPECIFICACIÓN DE CASO DE USO GENERAR REPORTE DE EMPLEADOS ............... 121
CUADRO 28: ESPECIFICACIÓN DE CASO DE USO GENERAR ESTADÍSTICAS DE GESTIÓN.............. 122
CUADRO 29: ESPECIFICACIÓN DE CASO DE USO LISTAR DOCUMENTOS EXT. REGISTRADOS ..... 124
CUADRO 30: ESPECIFICACIÓN DE CASO DE USO REGISTRAR DOCUMENTO EXTERNO ................. 124
CUADRO 31: ESPECIFICACIÓN DE CASO DE USO MODIFICAR DOCUMENTO EXTERNO .................. 125
CUADRO 32: ESPECIFICACIÓN DE CASO DE USO GESTIONAR ADJUNTOS....................................... 125
CUADRO 33: ESPECIFICACIÓN DE CASO DE USO GESTIONAR REFERENCIAS................................. 126
CUADRO 34: ESPECIFICACIÓN DE CASO DE USO BUSCAR USUARIO ............................................... 126
CUADRO 35: ESPECIFICACIÓN DE CASO DE USO REGISTRAR USUARIO.......................................... 127
CUADRO 36: ESPECIFICACIÓN DE CASO DE USO DERIVAR DOCUMENTO........................................ 127
CUADRO 37: ESPECIFICACIÓN DE CASO DE USO GENERAR TICKET................................................ 128
CUADRO 38: ESPECIFICACIÓN DE CASO DE USO MOSTRAR ADJUNTOS.......................................... 128
CUADRO 39: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS EXTERNOS
REGISTRADOS....................................................................................................................................... 129
CUADRO 40: ESPECIFICACIÓN DE CASO DE USO LISTAR DOCUMENTOS EXTENOS DERIVADOS .. 129
CUADRO 41: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTA DE DOCUMENTOS DERIVADOS 130
CUADRO 42: ESPECIFICACIÓN DE CASO DE USO LISTAR DOCUMENTOS EXTENOS ANULADOS ... 130
CUADRO 43: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTA DE DOCUMENTOS ANULADOS. 131
CUADRO 44: ESPECIFICACIÓN DE CASO DE USO LISTAR DOCUMENTOS INT. REGISTRADOS ...... 131
CUADRO 45: ESPECIFICACIÓN DE CASO DE USO REGISTRAR DOCUMENTO INTERNO .................. 132
CUADRO 46: ESPECIFICACIÓN DE CASO DE USO MODIFICAR DOCUMENTO INTERNO ................... 132
CUADRO 47: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS
INTERNOS REGISTRADOS.................................................................................................................... 133
CUADRO 48: ESPECIFICACIÓN DE CASO DE USO LISTAR DOCUMENTOS PENDIENTES
DE ATENCIÓN ........................................................................................................................................ 135
CUADRO 49: ESPECIFICACIÓN DE CASO DE USO DAR PROVEÍDO.................................................... 135
CUADRO 50: ESPECIFICACIÓN DE CASO DE USO CONCLUIR ATENCIÓN.......................................... 136
CUADRO 51: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE
DOCUMENTOS PENDIENTES DE ATENCIÓN........................................................................................ 136
CUADRO 52: ESPECIFICACIÓN DE CASO DE USO MOSTRAR SEGUIMIENTO .................................... 137
CUADRO 53: ESPECIFICACIÓN DE CASO DE USO LISTAR DOCUMENTOS RESPONDIDOS .............. 137
CUADRO 54: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE
DOCUMENTOS RESPONDIDOS............................................................................................................. 138
CUADRO 55: ESPECIFICACIÓN DE CASO DE USO LISTAR DOCUMENTOS ATENDIDOS.................... 138
CUADRO 56: ESPECIFICACIÓN DE CASO DE USO ARCHIVAR DOCUMENTO..................................... 139
CUADRO 57: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE
DOCUMENTOS ATENDIDOS.................................................................................................................. 139
CUADRO 58: ESPECIFICACIÓN DE CASO DE USO LISTAR DOCUMENTOS ARCHIVADOS................. 140
CUADRO 59: ESPECIFICACIÓN DE CASO DE USO ELIMINAR ARCHIVADO ........................................ 140
CUADRO 60: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS
ARCHIVADOS......................................................................................................................................... 141
CUADRO 61: ESPECIFICACIÓN DE CASO DE USO UBICAR DOCUMENTO EXTERNO ....................... 141
CUADRO 62: ESPECIFICACIÓN DE CASO DE USO UBICAR DOCUMENTO INTERNO.......................... 142
CUADRO 63: ESPECIFICACIÓN DE CASO DE USO MOSTRAR DOCUMENTO INTERNO ..................... 142
CUADRO 64: ESPECIFICACIÓN DE CASO DE USO CONSULTAR ESTADO DE UN DOCUMENTO ....... 143
CUADRO 65: ESPECIFICACIÓN DE COMPONENTE “LÓGICA DE ACCESO A DATOS” ......................... 204
CUADRO 66: COSTOS DE SUMINISTROS ............................................................................................. 211
CUADRO 67: COSTOS DE PERSONAL .................................................................................................. 211
CUADRO 68: COSTOS DE SOFTWARE.................................................................................................. 212
CUADRO 69: COSTOS DE HARDWARE ................................................................................................ 212
CUADRO 70: GASTOS OPERATIVOS EN PERSONAL ........................................................................... 213
CUADRO 71: RESUMEN DE COSTOS DE IMPLEMENTACIÓN
GRÁFICOS
Gráfico 1: Tres aspectos más importantes que debe priorizar la municipalidad para
brindar una buena atención a sus usuarios ..................................................................................28
Gráfico 2: Nivel de Satisfacción respecto a la atención al usuario de la Municipalidad Distrital
de Jayanca ..................................................................................................................................29
Gráfico 3: Nivel de Satisfacción respecto al servicio brindado al usuario de la Municipalidad
Distrital de Jayanca......................................................................................................................30
Gráfico 4: Nivel de Satisfacción respecto a la realización de trámites por parte usuario de la
Municipalidad Distrital de Jayanca................................................................................................31
CAPITULO I: LA ORGANIZACIÓN
1.1. RESEÑA HISTÓRICA
La Municipalidad de Jayanca es creada el 2 de enero de 1857, en
conformidad de la ley orgánica del 28 de noviembre de 1856 por la
Convención Nacional de 1855. (Ver anexo 1)
La Municipalidad Distrital de Jayanca, es una entidad básica de la
organización territorial del Estado y canal inmediato de participación vecinal
en los asuntos públicos, que institucionaliza y gestiona con autonomía los
intereses propios de Jayanca; siendo elemento esencial del gobierno local,
el territorio, la población y la organización.
La Municipalidad Distrital de Jayanca, es el órgano de Gobierno promotor
del desarrollo local, con personería jurídica de derecho público, con
autonomía política, económica y administrativa en los asuntos de su
competencia y está sujeta al marco legal que regulan las actividades y
funcionamiento del sector público, siendo de observancia y cumplimiento
obligatorio.
Actualmente, se encuentra representada por el Lic. Juan Augusto Purisaca
Vigil.
1.2. FINALIDAD
La Municipalidad Distrital de Jayanca tiene por finalidad representar al
vecindario, promueve la adecuada prestación de los servicios públicos
locales y el desarrollo integral, sostenible y armónico de su circunscripción,
con participación de la población.
1.3. OBJETIVOS
La Municipalidad Distrital de Jayanca tiene como objetivos: planificar,
ejecutar e implementar a través de los organismos competentes el conjunto
de acciones destinadas a proporcionar al ciudadano el ambiente adecuado
para la satisfacción de sus necesidades en aspectos de vivienda,
salubridad, abastecimiento, educación, transporte y comunicaciones.
1.4. FUNCIONES GENERALES
La Municipalidad Distrital de Jayanca ejerce competencias y atribuciones
que le confiere la Constitución Política y la ley, así tenemos:
a). Art. 195º de la Constitución Política del Estado modificada por Ley de
Reforma Constitucional Nº 27680:
ü Aprobar su organización interna y su presupuesto.
ü Aprobar el plan de desarrollo local concertado con la sociedad civil.
ü Administrar sus bienes y rentas.
ü Crear, modificar y suprimir contribuciones, tasas, arbitrios, licencias
y derechos municipales, conforme a ley.
ü Organizar, reglamentar y administrar los servicios públicos locales
de su responsabilidad.
ü Planificar el desarrollo urbano y rural de sus circunscripciones,
incluyendo la zonificación, urbanismo y el acondicionamiento
territorial.
ü Fomentar la competitividad, las inversiones y el financiamiento para
la ejecución de proyectos y obras de infraestructura local.
ü Desarrollar y regular actividades y/o servicios en materia de
educación, salud, vivienda, saneamiento, medio ambiente,
sustentabilidad de los recursos naturales, transporte colectivo,
circulación y tránsito, turismo, conservación de monumentos
arqueológicos e históricos, cultura, recreación y deporte, conforme a
ley.
ü Presentar iniciativas legislativas en materia y asuntos de su
competencia.
ü Ejercer las demás atribuciones inherentes a su función, conforme a
ley.
b). Así como aquellas competencias señaladas en los arts. 42º y 43º de la
Ley de Bases de la Descentralización Nº 27783:
Competencias exclusivas:
ü Planificar y promover el desarrollo urbano y rural de su
circunscripción, y ejecutar los planes correspondientes.
ü Normar la zonificación, urbanismo, acondicionamiento territorial y
asentamientos humanos.
ü Administrar y reglamentar los servicios públicos locales destinados a
satisfacer necesidades colectivas de carácter local.
ü Aprobar su organización interna y su presupuesto institucional
conforme a la Ley de Gestión Presupuestaria del Estado y las Leyes
Anuales de Presupuesto.
ü Formular y aprobar el plan de desarrollo local concertado con su
comunidad.
ü Ejecutar y supervisar la obra pública de carácter local.
ü Aprobar y facilitar los mecanismos y espacios de participación,
concertación y fiscalización de la comunidad en la gestión municipal.
ü Dictar las normas sobre los asuntos y materias de su
responsabilidad y proponer las iniciativas legislativas
correspondientes.
ü Otras que se deriven de sus atribuciones y funciones propias, y las
que señale la Ley.
Competencias compartidas:
ü Educación, Participación en la gestión educativa conforme lo
determine la ley de la materia.
ü Salud pública.
ü Cultura, turismo, recreación y deportes.
ü Preservación y administración de las reservas y áreas naturales
protegidas locales, la defensa y protección del ambiente.
ü Seguridad ciudadana.
ü Conservación de monumentos arqueológicos e históricos.
ü Transporte colectivo, circulación y tránsito urbano.
ü Vivienda y renovación urbana.
ü Atención y administración de programas sociales.
ü Gestión de residuos sólidos.
ü Otras que se le agreguen o asignen conforme a ley.
1.5. ESTRUCTURA ORGÁNICA
La Municipalidad Distrital de Jayanca asegura el cumplimiento de sus
competencias y ejecución de funciones específicas a través de la estructura
orgánica siguiente:
ORGANO DE GOBIERNO
Concejo municipal.
ORGANOS DE ALTA DIRECCION
Alcaldía.
Gerencia municipal.
ORGANOS DE CONCERTACION, DE COORDINACION Y PARTICIPACION
Comisiones de regidores.
Consejo de coordinación local distrital
Juntas vecinales.
Comité distrital de defensa civil.
Comité distrital de seguridad ciudadana.
COMUDENA
ORGANO DE CONTROL
Auditoria interna. (Por crearse)
ORGANO DE DEFENSA JUDICIAL DE LA MUNICIPALIDAD
Procuraduría municipal
ORGANOS DE ASESORAMIENTO
Unidad de planificación y presupuesto.
Unidad de asesoría legal.
Unidad de informática. ORGANOS DE APOYO
Oficina de secretaria general y trámite documentario
Oficina de administración
ORGANOS EJECUTIVOS O DE LINEA
Gerencia de desarrollo económico y de servicios comunales
(GEDESC)
Gerencia de proyección y desarrollo social (GEPDES)
Gerencia desarrollo urbano rural (GEDUR)
ORGANOS DESCONCENTRADOS
Agencias municipales.
ORGANOS DESCENTRALIZADOS
Municipalidades de centros poblados
Proyectos especiales municipales.
El organigrama de la Municipalidad Distrital de Jayanca se aprecia en
el anexo 2.
CAPITULO II: EL PROBLEMA DE INVESTIGACIÓN
2.1. Realidad Problemática
El problema central es la inadecuada prestación de servicio de atención al
usuario de la Municipalidad Distrital de Jayanca, ocasionada por las siguientes
dificultades:
ü Desorganización durante el registro de la información, generación de tiempos muertos, duplicidad de documentos producidos por la gran cantidad
de papel que debe ser manejado.
ü Dificultad para la conservación, administración, organización, el acceso, la consulta y difusión de los documentos, en las diferentes áreas de la
Municipalidad.
ü Existe demora y restricciones en la recepción de documentos: Toda gestión se origina en recepción, donde se pierde mucho tiempo en registrar
documento, en forma manual. Luego se acumulan los documentos y se
derivan a la secretaria general para ubicar al área correspondiente a dar
respuesta. Cuando se consulta en esa área sobre el estado de un
documento, no puede ofrecerse una respuesta, derivando a secretaría
general para dar una solución.
ü No existe un historial de los documentos que ingresan a la municipalidad: Dada la recargada documentación que se maneja (en promedio 550
ingresos de documentos al mes), y luego las derivaciones ínteráreas, se
pierde el control de los mismos. Es muy difícil ubicar los documentos e
informar sobre el estado de los mismos.
ü No consta un seguimiento de documentos de la Municipalidad: El solicitante se ve en la necesidad de realizarle un seguimiento de forma personal,
trasladándose de oficina en oficina para determinar el lugar donde se
encuentran su documento, generándose en ocasiones traspapeleo de los
documentos recepcionados.
ü No se lleva una estadística y reporte de los documentos: No se sabe exactamente cuántos de los documentos que han sido recepcionados han
sido archivados, de donde proceden los documentos, quiénes los
atendieron, cuánto tiempo se utiliza para atender un documento.
ü No se controla la prioridad de los documentos: Algunos documentos deben ser respondidos en breves plazos, en el actual sistema, no existe un
mecanismo que le recuerde a las personas que tienen documentos en su
poder y deben ser pasados oportunamente a la instancia siguiente para su
atención, lo que origina que los documentos sean atendidos fuera de plazo.
ü La comunicación ciudadanogobierno municipal, no se aprovecha en toda su extensión, aún se necesita acudir personalmente a la municipalidad para
conocer el estado o trámite que está siguiendo un documento.
ü Incremento del archivo documental en cada oficina: A pesar que se cuenta con una fotocopiadora en la institución, esta crea una falsa apariencia de
control de la información, contribuyendo a aumentar el tamaño de los
archivos y su efectividad queda invalidada por la ausencia de un sistema
con criterio de archivo y que permita un solo almacenamiento y múltiples
consultas.
ü El archivo de los documentos se realiza en forma manual y sin ningún criterio archivístico, produciéndose pérdida y deterioro de los documentos.
Producto de estas dificultades, se utiliza mayor tiempo y recursos, y en
consecuencia insatisfacción en el ciudadano. Y por otro lado, los trabajadores
manifiestan que la gestión de los documentos en forma manual, les produce
stress y desmoralización.
En algunas ocasiones la institución ha sido sujeta a crítica por parte de la
opinión pública.
El problema fue evidenciado en la investigación que realizaramos en Enero del
presente año con el financiamiento de la Oficina Regional de Inwent –
Internationale Weiterbildung und Entwicklung gGmbH (Capacity Building
International, Germany) en la que se manifiesta que ante esta serie de
dificultades, existe un 8% de documentos que no se llegan a atender y cerca de
un 10% de documentos sufren pérdidas que obligan al ciudadano reiniciar su
gestión y, en el mejor de los casos, confusión entre otros documentos. A esto
hay que agregarle la pérdida de tiempo de los usuarios y de los trabajadores
municipales, deterioro del material documentario, producto de las consultas,
además se distraen recursos humanos y materiales para entregar información
que los ciudadanos demandan en ejercicio de su derecho al acceso a la
información pública amparado por el Artículo 2º Inc. 5º de la Constitución
Política del Estado y la Ley 27806 Ley de Transparencia y Acceso a la
Información Pública, modificada por la Ley Nº 27927.
Asimismo se presentan los resultados de la investigación antes mencionada
sobre los aspectos relacionados con la atención al usuario de la Municipalidad
Distrital de Jayanca.
GRÁFICO 1: Tres aspectos más importantes que debe priorizar la
municipalidad para brindar una buena atención a sus usuarios
80
84
62
26
53
52
31
0 20 40 60 80 100
Personal capacitado
Horarios de atenc ión
Conoc imiento de trámite
Conocimiento de servic ios
Soluc ión adecuada de consultas
Cordialidad/Amabilidad
Agilidad/Rapidez en atención
%
ALTA
BAJA
MEDIA
RANKING DE
IMPORTANCIA
Base: Total de usuarios entrevistados
Fuente: Internationale Weiterbildung und Entwicklung gGmbH (Capacity Building International,
Germany), Oficina Regional de Inwent, Evaluación del servicio de atención a los usuarios de la
Municipalidad Distrital de Jayanca – Lambayeque, Enero 2008.
GRÁFICO 2: Nivel de Satisfacción respecto a la atención al usuario de la
Municipalidad Distrital de Jayanca.
15
6
24.7
39.5
28.4
22.2
23.5
42.0
21.0
10
4
6
5
5
0 20 40 60 80 100
Agilidad /rapidez en atención
Cordialidad / amabilidad
Soluc ión adecuada de consultas
Conocim iento de servic ios
Conocimiento de trámite
Horarios de atención
Personal capacitado
%
Muy Satisfecho Satis fecho
ALTA
BAJA
MEDIA
RANKING DE IMPORTANCIA
29.7
49.5 32.4
28.2
57.0
28.5
27.0
Base: Total de usuarios entrevistados
Fuente: Internationale Weiterbildung und Entwicklung gGmbH (Capacity Building International,
Germany), Oficina Regional de Inwent, Evaluación del servicio de atención a los usuarios de la
Municipalidad Distrital de Jayanca – Lambayeque, Enero 2008.
Obsérvese la relación entre los dos gráficos anteriores, mientras que en el
primero se muestra la clasificación de aspectos por orden de importancia que
considera el usuario que debe priorizar la Municipalidad brindar una mejor
atención, en el segundo se refleja el nivel de satisfacción de los usuarios en
estos aspectos priorizados por ellos mismos.
Se observa un bajo nivel de satisfacción (29.7%) en cuanto a agilidad y rapidez
en atención, aspecto que consideran de alta importancia.
El nivel de satisfacción más bajo obtenido es 27% en el aspecto de personal
capacitado, esto podría ser producto del desconocimiento de los servicios y
procedimientos que muestran similar comportamiento con 28.2% y 28.5%
respectivamente.
En cuanto al horario de atención más de la mitad de usuarios se sienten
satisfechos (57%), puesto que siempre encuentran las puertas abiertas de la
Municipalidad, asimismo, Alcaldes y Regidores están a disposición del público
en horarios de la tarde y en algunas ocasiones en las noches.
GRÁFICO 3: Nivel de Satisfacción respecto al servicio brindado al usuario de la
Municipalidad Distrital de Jayanca.
40.7
39.5
43.2
45.7
43.2
39.5
46.9
22.2
21.0
25.9
23.5
44.4
0 20 40 60 80 100
Mantenim iento y lim pieza externos
Mantenim iento y lim pieza internos
Comodidad dentro de las oficinas
Facilidad para s aber hacia donde dir ig irs e
Cant idad de pues tos de atención
Equipos y tecnología
%
Muy Satisfecho Satisfecho
63.0 %
87.7%
66.7 %65.4 %
69.1 %
84.0%
Base: Total de usuarios entrevistados
Fuente: Internationale Weiterbildung und Entwicklung gGmbH (Capacity Building International,
Germany), Oficina Regional de Inwent, Evaluación del servicio de atención a los usuarios de la
Municipalidad Distrital de Jayanca – Lambayeque, Enero 2008.
Cuando al usuario se le pregunta que tan satisfechos se encuentran con
aspectos como equipos, tecnología, limpieza de los ambientes y otros el nivel
supera el 60%, dado que la municipalidad distrital tiene un parque informático
renovado, mantiene siempre limpios los ambientes y existe cierta comodidad al
ser atendido, pero esta satisfacción se desdibuja cuando se trata de la opinión
sobre aspectos relacionados con el trámite, como veremos en el gráfico
siguiente.
GRÁFICO 4: Nivel de Satisfacción respecto a la realización de trámites por
parte usuario de la Municipalidad Distrital de Jayanca.
7.4
13.6
19.8
17.3
19.8
24.7
23.5
6.2
8.6
6.2
7.4
4.9
0 20 40 60 80 100
Cos to de tr ám ites ?
Clar idad de form atos /s olicitud de tr ám ite?
Clar idad de la inform ación?
Cant idad de docum entación s olicitada?
Duración de tr ám ites ?
Facilidad para obtener inform ación?
%
Muy Satisfecho Satisfecho
22.2%
24.7%
24.7%
26.0%
30.9%
30.9%
Base: Total de usuarios entrevistados
Fuente: Internationale Weiterbildung und Entwicklung gGmbH (Capacity Building International,
Germany), Oficina Regional de Inwent, Evaluación del servicio de atención a los usuarios de la
Municipalidad Distrital de Jayanca – Lambayeque, Enero 2008.
Como se dijo anteriormente, el nivel de satisfacción en aspectos relacionados
con la realización del trámite (facilidad para obtener información, duración de
trámites, requisitos solicitados, claridad de la información y de los formatos, así
como el costo de los trámites) no supera el 31%, un nivel bajo muy preocupante
de satisfacción del usuario. Esto indica la necesidad urgente de mejora en
estos aspectos, motivo de nuestra investigación.
2.2. Formulación del Problema
¿Cómo mejorar el servicio de atención a los usuarios de la Municipalidad
Distrital de Jayanca?
2.3. Justificación e importancia del Problema
Esta investigación es importante porque permitirá construir una herramienta
que contribuya a una gestión efectiva de la documentación externa e interna de
la institución, lo que deviene en una disminución de la burocracia, mejorando la
atención y servicio al ciudadano.
La implementación de un sistema de gestión documentario en la Municipalidad
Distrital de Jayanca se justifica en las siguientes razones:
Razones económicas: la no disponibilidad o localización de documentos, el
trabajo manual de reparto, firma, registro y archivo de documentos provocan
costes de personal y tiempo. A esto se agrega las pérdidas de tiempo de
espera del ciudadano. Definitivamente, con el sistema de gestión
documentaria se logrará aumento de la efectividad y eficiencia
administrativa.
Razones informativas: Las buenas decisiones requieren buena información
y oportunamente, y esto se logrará tratando de evitar duplicar tareas. El
sistema de gestión documentaria, permitirá acceder inmediatamente a la
información por un conjunto de personas a la vez desde cualquier área y
disponer de mayores posibilidades para el análisis e información en general.
A esto se suma, la reducción de la circulación física de documentos, y por
tanto eliminar su pérdida.
Razones normativas: Es necesario documentar las actuaciones de las áreas
involucradas o responsables de la atención. Además de cumplir con la
normatividad vigente del Sistema Nacional de Archivo.
Además, hay que considerar que la legislación peruana reconoce la importancia
de las Tecnologías de Información y Comunicación como motor del desarrollo.
La Resolución Ministerial Nº 1812003PCM que crea la Comisión Multisectorial
para el Desarrollo de la Sociedad de la Información – CODESI, en uno de sus
considerandos señala: “el adecuado desarrollo, dirección y promoción de un
Plan para crear las bases que permitan la implementación de la Sociedad de la
Información generará mejoras en el comercio y en la industria, incrementará la
eficiencia en la prestación de los servicios públicos estatales, mejorará la
generación de productividad y de beneficios empresariales, lo que incidirá
directamente en una mejora en la competitividad del Estado en un entorno
económico caracterizado por el fenómeno de la globalización” 1
El Decreto Supremo Nº 0662001PCM que aprueba los “Lineamientos de
Políticas Generales para promover la masificación del acceso a Internet en el
Perú” en su Política General Nº 7 señala: “Las entidades de la administración
pública deberán incluir en sus planes sectoriales, así como en el desarrollo de
sus actividades, metas relacionadas con el uso de Internet y el uso de
1 Resolución Ministerial Nº 1812003PCM que crea la Comisión Multisectorial para el Desarrollo de la Sociedad de la Información – CODESI – Perú.
herramientas informáticas, a fin de agilizar la prestación de servicios
gubernamentales y propender a la prestación de servicios en línea
(gobierno electrónico) a través de paginas web y servicios de consulta
interactivos”.
Por otro lado, ante la presencia de la ley de procedimiento administrativo
general N° 27444 2 , que contiene importantes disposiciones de simplificación
administrativa que las personas naturales y jurídicas deben tener en cuenta al
realizar trámites en las instituciones y dependencias públicas, es necesario
resolver las solicitudes con la máxima dinámica posible. Los usuarios pueden
exigir el cumplimiento de los plazos.
2.4. Objetivos
2.4.1. Objetivo general
Implementar un sistema informático de gestión documentaria para
mejorar el servicio de atención a los usuarios en la municipalidad distrital de
jayanca.
2.4.2. Objetivos Específicos
• Recopilar información general sobre la institución.
• Realizar entrevistas a los trabajadores de la municipalidad distrital de
Jayanca y usuarios externos con la finalidad de conocer la realidad
problemática.
• Diagnosticar la situación respecto al sistema de gestión documentaria
en la Municipalidad Distrital de Jayanca
• Analizar los procesos que involucran la gestión documentaria en la
Municipalidad distrital de Jayanca.
• Diseñar los procesos de la gestión documentaria.
• Desarrollar los procesos de gestión documentaria.
2 Ley de Procedimiento Administrativo General N° 27444, Diario El Peruano: 11.04.01
• Plantear las medidas de Seguridad para el sistema
• Analizar el beneficio/costo de la implementación del sistema de
gestión documentaria para la municipalidad distrital de Jayanca.
2.5. Limitaciones de la investigación
Esta investigación toma en consideración tanto la digitalización de documentos
externos como la gestión de los mismos para los procedimientos con alta
demanda ciudadana y que impactan directamente en el cumplimiento de la
misión de la Municipalidad Distrital de Jayanca.
Para el caso de la documentación interna se considera el registro de las series
documentales (ordenanzas, convenios de cooperación técnica, actas de sesión de
concejos, resoluciones de alcaldía, decretos municipales, resoluciones de concejo,
acuerdos de concejo, ordenanzas municipales, etc.) con la finalidad de proteger
dicha información y para que sirvan como elementos de consulta.
La principal limitante es la inexistencia de la aplicación de la normativa en
materia de archivo que posee esta institución, así como el no sinceramiento del
TUPA (Texto Único de Procedimientos Administrativos) ni la debida actualización y
publicación en el presente año, de acuerdo a la normativa vigente, por lo que
principalmente se consideran los procedimientos no TUPA. Es necesario realizar el
rediseño de procesos, aspecto que no está contemplado en la presente
investigación.
Además sólo se considera consultas a través de un tramitador automatizado,
más no solicitudes de información en línea.
No está demás mencionar el factor limitante tiempo, puesto que la
investigadora tuvo que realizar sóla todas las actividades involucradas.
2.6. Hipótesis
Mediante la implementación de un Sistema Informático de Gestión
Documentaria se mejorará el servicio de atención a los usuarios de la
Municipalidad Distrital de Jayanca.
2.7. Variables
2.7.1. Variable independiente
Sistema Informático de Gestión Documentaria.
2.7.2. Variable dependiente
Servicio de atención a los usuarios de la Municipalidad Distrital de
Jayanca.
2.7.3. Indicadores
CUADRO 1: INDICADORES Y FÓRMULAS PARA SU CÁLCULO VARIA BLE
INDICADO RES SUBINDICADORES FÓRMULA TÉCNICA
Reducción del tiempo de gestión documen taria
ü Porcentaje de documentos atendidos en el plazo establecido (dat).
ü Tiempo promedio en el proceso de orientación y registro de documentos (Ẍ1).
ü Tiempo promedio en el proceso de derivación de documentos (Ẍ2).
ü Tiempo promedio en el proceso de consulta de documentos (Ẍ 3 ).
dat= # documentos atendidos en el plazo establecido/Total de documentos recibidos en un mes.
Ẍ 1 = ∑ tiempo en el proceso de orientación y registro/ # doc. registrados.
Ẍ2 = ∑ tiempo en el proceso de derivación/ # doc. derivados.
Ẍ3 = ∑ tiempo en el proceso de consulta/ # doc. consultados.
Observación
Servicio de
atención al
usuario
Incremento de satis facción de los usuarios
ü Porcentaje de usuarios satisfechos con la atención a su documento ingresado (% us).
ü Promedio mensual de reclamos (Ẍ4).
% us = # de usuarios satisfechos con la atención / # de usuarios atendidos.
Ẍ 4 = ∑ reclamos efectuados en un año /12
Encuesta aplicada a los usuarios.
Fuente: Elaboración propia
2.8. Contrastación de hipótesis
CUADRO 2: MEJORA DEL TIEMPO DE GESTIÓN DOCUMENTARIA
SUBINDICADOR ACTUAL PROPUESTO MEJORA Porcentaje de docu mentos atendidos en el plazo establecido por ley (dat).(mensual)
54,55% 98,18% 43,63%
Tiempo promedio en el proceso de orientación/registro de documentos ( Ẍ1 ).
6 min. 3 min. 3 min.
Tiempo promedio en el proceso de derivación de documentos (Ẍ2).
30 minutos (1) 1 min. 29 min.
Tiempo promedio en el proceso de consulta de documentos (Ẍ3).
45 minutos 1 min. 44 min.
(1) Incluye el tiempo de desplazamiento de la tramitadora, fotocopiado del documento para entregar, entrega del documento a la persona indicada, registro del documento por parte de la persona que decepciona y firma en el libro de trámite documentario.
Fuente: Elaboración propia
CUADRO 3: MEJORA DE SATISFACCIÓN DE LOS USUARIOS
SUBINDICADOR ACTUAL PROPUESTO MEJORA Porcentaje de usuarios satisfechos con la atención a su documento ingresado (% us). 3
30.9% 95.0% + 64.10%
Promedio mensual de reclamos (Ẍ4). 12 2 83.3%
Fuente: Elaboración propia
3 Información tomada de la Evaluación del servicio de atención a los usuarios de la Municipalidad Distrital de Jayanca – Lambayeque. Oficina Regional de Inwent – Internationale Weiterbildung und Entwicklung gGmbH (Capacity Building International, Germany), Enero 2008.
CAPITULO III: MARCO TEÓRICO
3.1. Antecedentes de estudio y de investigación
3.1.1. Investigaciones a Nivel Académico
ü Landa Molina, Luz Mercedes (Lima, Perú; 2002): En la investigación
“Gestión de Documentos: El Caso Consorcio SMS”, describe y analiza el
programa de gestión documental implantado por el consorcio SMS
(Sondotécnica S.A., Multiservice Engenharia Ltda. y Serconsult S.A.)
para cumplir eficiente y eficazmente sus funciones y objetivos como
inspector de las obras y estudios comprendidos en los subprogramas B y
C del programa de saneamiento básico del Perú. Concluye la
investigadora, que el diseño y aplicación de un programa de gestión
documental en las empresas, mejora sensiblemente el control y
organización de los documentos, y contribuye al logro de los objetivos
empresariales.
ü Contreras Henao, Felipe y Forero Guzmán, Felipe (Bogotá,
Colombia; 2005): En la investigación “Diseño de un modelo para la
implantación de un sistema de gestión documental en áreas u
organizaciones jurídicas”, da una idea general de las variables que
conforman un sistema de gestión documental y las implicancias que
existen al adquirir o al tratar de desarrollar uno para una determinada
empresa. Asimismo, presenta un modelo de implantación de un Sistema
de gestión documental aplicable no solo a entidades o áreas jurídicas,
sino que puede ser utilizado en cualquier ámbito empresarial que maneje
documentos y que sus áreas de negocio dependan en gran parte del
manejo de estos.
ü Orozco Sigüeñas, Juan Carlos (Lambayeque, Perú; 2005): En su
tesis “Desarrollo de un Sistema de Control documentario para el apoyo a
la gestión de la Municipalidad Provincial de Ferreñafe”, presenta un
sistema basado en el registro de seguimiento, consultas, reportes y
estadísticas de documentación. No involucra la digitalización y
preservación de los documentos, que también es parte de la gestión
documentaria y que implica toda una reingeniería en el sistema de
archivo de la municipalidad.
Concluye el autor de la tesis, que este sistema mejora sensiblemente el
control y organización de los documentos y contribuye al logro de los
objetivos y misión de la organización “promover servicios públicos de
calidad, impulsar el desarrollo económico provincial, lograr la
participación y concertación de los vecinos y de la sociedad civil”.
ü Ancajima Miñán, Víctor Angel (Piura, Perú; 2005): En la investigación
“Análisis, Diseño y Prototipos del Sistema Trámite Documentario para la
Universidad Los Ángeles de Chimbote”, resultado de un análisis de la
situación del proceso documentario en la Sede Piura de la ULADECH,
incluye análisis, diseño y algunos prototipos a fin de sustentar y
demostrar técnicamente la viabilidad de la implantación de un Sistema
de Trámite Documentario en la Sede de Piura, de la ULADECH.
ü Arenas Llontop, Cornetero Muro (Lambayeque, Perú; 2005): En su
investigación “Sistema de Gestión Documental para la Dirección de
Estudios y Desarrollo Agrícola del PEOT” presenta un sistema orientado
a controlar toda la documentación que se genera durante la elaboración
de los proyectos de inversión, así como rescatar aquellos almacenados
físicamente en el Archivo Técnico del PEOT. Para esto se planteó
escanear e indexar; capturando documentos y trasformándolos a formato
digital.
ü Diaz Castillo, Mario y Suclupe Alamas Danny (Lambayeque, Perú;
2005): En su investigación “Sistema de Información y el Plan de
Tecnología de clasificación y búsqueda de expedientes del Archivo
Regional de Lambayeque” busca mejorar el desempeño del usuario
interno en el manejo y ubicación de expedientes, para lo cual establece
el diseño de una base de datos, un módulo de registro y actualización de
información. Comprende el registro de tomos de archivos de acuerdo a
su lugar de ubicación, registro de escrituras de acuerdo a un sustento y
el módulo de consultas y reportes que permite realizar las búsquedas de
documentos a través de parámetros, emitiendo reportes y gráficos
estadísticos sobre las consultas realizadas.
3.1.2. Investigaciones a Nivel institucional
ü Ministerio de Agricultura, Servicio Nacional de Sanidad Agraria,
Dirección de Informática (Perú, 2005): Elaboraron el Sistema de
tramite documentario – SISDOC, el cual surgió como respuesta a la
problemática presentada en la ubicación de documentos y las
respectivas rutas seguidas por estos hasta su atención.
Este sistema permite realizar un registro de las actividades
(derivaciones) que se originan en las diferentes áreas del SENASA
cuando se recibe un requerimiento formulado por una entidad externa o
por otra área dentro de la institución, simplificándose de esta manera la
ubicación de documentos. Además permite el registro de derivaciones a
diferentes niveles Jefatura, Dirección General, Dirección de Línea y
Profesionales.
Asimismo, permite realizar un seguimiento eficaz de las actividades que
se originan en las diferentes áreas del SENASA cuando se recibe un
requerimiento formulado por una entidad externa o por otra área dentro
de la institución, de manera que todos los requerimientos sean
respondidos en el menor tiempo posible y dentro de los plazos
establecidos y a su vez se simplifique la ubicación de los documentos
atendidos.
Fue diseñado para realizar principalmente los siguientes procesos:
Registro de un documento, recepción de un documento, derivación de un
documento y atención y archivo de un documento. Su concepción del
sistema se basa en tres casos:
• Recepción de documentos externos
• Flujo de documentos internos
• Salida de documentos
ü Consejo Nacional de Descentralización (CND) (Perú, 2004): Se
implementó el Sistema Integrado de Gestión documentaria OFIMATIC,
cuyos objetivos fueron: Permitir el acceso al trámite de documentos
desde Internet, reducir los tiempos requeridos para la circulación de
documentos mediante el registro y distribución electrónica de estos
mediante escaneo, conocer las acciones tomadas por cada usuario en
relación al proceso de cada documento, reducir el volumen de papel que
circula en la entidad, además de integrar una agenda por cada oficina.
Este sistema ha sido desarrollado en Visual Foxpro con SQL Server, por
lo que era necesario su instalación sólo en servidores Web bajo entorno
Windows. El objetivo que no se cumplió en su totalidad fue el de la
distribución electrónica de los documentos, debido al trabajo que implica
escanear documentos y convertirlos en formato digital. La intención del
CND fue la distribución y aplicación de este software a nivel nacional en
todos los Gobiernos regionales, no obstante no llegó a concretarse este
proyecto por el requerimiento costoso de hardware y software que
implicaba su instalación y otras razones administrativas.
ü Dirección Regional de Trabajo (Lambayeque, Perú; 2003):
Implementaron el SISCADOC (Sistema de Control Automatizado de
documentos), que fue desarrollado a fines del año 2003 y se encuentra
en operación desde el año 2004. Está desarrollado en lenguaje FoxPro
2.6. Entre sus características podemos destacar lo siguiente:
Administración de usuarios con niveles de acceso, Registro y
seguimiento de documentos externos, Varios tipos de reportes y
consultas. No obstante, la tecnología usada para el desarrollo del
sistema es obsoleta no brindando la seguridad e integridad respectiva de
los datos. En este sistema no existe opción para registrar y controlar la
documentación interna tampoco un buen control de los documentos ya
procesados o archivados, el seguimiento de los documentos solo se
lleva al nivel de oficina o área y no por trabajador, no es posible
consultar los datos vía Internet.
3.1.3. Sistema de información
Effy OZ, en su libro Administración de Sistemas de información,
define este tèrmino como “ Todos los elementos que funcionan en
conjunto para procesar datos y producir información. Casi todos los sistemas de información para los negocios se componen de muchos subsistemas con sus respectivos subobjetivos, y todos contribuyen a lograr el objetivo principal de la organización” 4 .
Por otro lado, manifiesta que un sistema realiza una tarea limitada cuyo
resultado debe combinarse con el producto de otros sistemas para
alcanzar un objetivo final. A este tipo de sistema se le llama
subsistemas, y varios de ellos pueden dar lugar a un sistema.
Las características de un sistema de información son los siguientes:
• Contener información interna y externa a la organización.
• Consistencia e Integración. Asegurar una única fuente de
información de gestión para todas las áreas de la empresa.
• Facilitar la comprensión de la información mediante una
ordenación adecuada de las ideas.
• Ser utilizado por todos escalones de la estructura jerárquica. Cada
escalón obtendrá información a su nivel. Se debe evitar que la alta
dirección de la organización viva con una información creada y
manipulada para ella misma.
• Proporcionar la información al ritmo que el negocio requiera.
• Facilitar a los directivos una gestión más ágil, mediante
indicadores clave adecuados a los objetivos y estructura de la
organización.
• Rápido acceso a la información actual e histórica.
Un Sistema de Información es un conjunto de elementos que
interactúan entre sí con el fin de apoyar las actividades de una empresa o
negocio. En un sentido amplio, un sistema de información no
necesariamente incluye equipo electrónico (hardware). Sin embargo en la
práctica se utiliza como sinónimo de "sistema de información
computarizado"
Un Sistema de Información realiza cuatro actividades básicas:
4 Effy Oz, Administración de Sistemas de información, Thompson Editores, segunda edición, México, 2001
• Entrada de información: proceso en el cual el sistema toma los
datos que requiere para procesar la información, por medio de estaciones
de trabajo, teclado, diskettes, código de barras, escáner, etc.
• Almacenamiento de información: es una de las actividades más
importantes que tiene una computadora, ya que a través de esta propiedad
el sistema puede recordar la información guardad en la sesión o proceso
anterior.
• Procesamiento de la información: esta característica de los
sistemas permite la transformación de los datos fuente en información que
puede ser utilizada para la toma de decisiones, lo que hace posible, entre
otras cosas, que un tomador de decisiones genere una proyección
financiera a partir de los datos que contiene un estado de resultados o un
balance general en un año base.
• Salida de información: es la capacidad de un SI para sacar la
información procesada o bien datos de entrada al exterior. Las unidades
típicas de salida son las impresoras, graficadores, cintas magnéticas,
diskettes, la voz, etc.
Para Spencer, D. “un sistema e información es un conjunto de personas, datos y procedimientos que funcionan en conjunto. El énfasis en sistemas significa que los variados componentes buscan un objetivo común un objetivo común para apoyar las actividades de la organización. Estas incluyen las operaciones diarias de las empresas, la comunicación de los datos e informes, la administración de las actividades y la toma de decisiones” 5 .
Por otro lado, Fahsbender 6 manifiesta que el conjunto de procesos
vinculantes configuran “sistemas”, haciendo notar que se suele confundir
sistema con software y que un sistema puede ser manual o usar software,
éste último es un elemento que correctamente diseñado e implementado
puede ayudara a manejar el sistema.
Existe un elevado número de sistemas, y aunque se puede pensar
que corresponde a las unidades orgánicas o un grupo de funciones, casi
5 Spencer, D; Monzon, J. Análisis y Diseño de Sistemas Informáticos. Primera edición, Lima – Perú, 1994. 6 Fahsbender C., Juan Carlos, Desde Adentro: La organización del gobierno local, Edición Universidad de Piura, Primera edición, Perú, 2007
todos los sistemas son transversales. Los sistemas pueden estar
compuestos por subsistemas, que a su vez están compuestos por
innumerables procesos.
En el marco de definición de Effy Oz, Fahsbender clasifica los
sistemas de información de un gobierno local de acuerdo al cuadro
siguiente:
CUADRO 4: SISTEMAS Y SUBSISTEMAS DE UN GOBIERNO LOCAL SISTEMA SUBSISTEMA
Interacción con el ciudadano y portal electrónico.
Audiencias de presupuesto participativo. Audiencias de rendición de cuentas. Gestión de expedientes TUPA y No TUPA. Solicitud de audiencia con el alcalde. Agenda del alcalde. Programas de participación ciudadana. Trabajo online de la información al portal electrónico.
Sistema de ordenamiento territorial, infraestructura y transporte.
Plan Director y catastro. Licencia de obras y vinculadas. Expedientes derivados a comisión municipal. Control de proyectos en estudio. Control de obras en ejecución por administración directa. Control de obras en ejecución por contrata. Autorizaciones de rutas de transporte. Mantenimiento de señalización vial.
Sistema de desarrollo económico local.
Mapa de zonificación de la ciudad. Proyectos de inversión pública y privada. Información socioeconómica del entorno.
Sistema de servicios comerciales.
Licencias de funcionamiento. Estadísticas de negocios. Autorizaciones para eventos públicos no deportivos. Administración del mercado. Padrón de comerciantes. Control del camal municipal.
Sistema de apoyo social. Vaso de leche, Comedores y Juntas vecinales.
Sistema de servicios de medioambiente y otros.
Control de herramientas de limpieza y ornato. Control de rutas y combustible de recolectores. Registro civil.
Sistema de servicios culturales, deportivos y recreativos.
Eventos culturales. Control de stock de libros. Control de uso de locales municipales y plazas públicas.
Sistema de servicios de seguridad y control.
Turnos del personal. Incidentes y mapa de conflictos sociales. Reporte de hechos, Estadística de intervenciones. Control de material decomisado.
Sistema de planificación, presupuesto y control
Planificación, Presupuesto, Control presupuestal. Control del plan operativo institucional. Proyectos de mejora continúa, Proyectos en proceso y en SNIP.
Sistema administrativo
Administrativo. Tesorería y contabilidad, Personal y escalafón. Demandas y juicios en curso, Control de almacenes. Control de repuestos y reparaciones de vehículos. Control de combustible. Administración y control del parque tecnológico (hardware, software, telecomunicaciones). Liquidación de obras, Impuestos municipales. Multas administrativas.
Otros sistemas
Administración de proyectos informáticos. Control de actualización de procesos. Control de actualización de manuales. Control de normatividad municipal.
Control de archivo central. Sesiones y actas de consejo. Noticias en el portal electrónico. Intranet de funcionarios. Intranet de gestión interna de expedientes Procesos, TUPA , Optimización de procesos. Administración de directivas. Integral para actualización del portal electrónico.
Fuente: Fahsbender C., Juan Carlos, Desde Adentro: La organización del gobierno local, Edición
Universidad de Piura, Primera edición, Perú, 2007
3.1.4.Seguridad en los Sistemas de Información
Para la Oficina Nacional del Gobierno Electrónico e Informática
ONGEI – Perú, “…definir la seguridad de la información lo considera complejo, debido a la gran cantidad de factores que intervienen. Sin embargo da una aproximación a la definición como el conjunto de recursos (metodologías, documentos, programas y dispositivos físicos) encaminados a lograr que los recursos de cómputo disponibles en un ambiente dado, tengan acceso única y exclusivamente quienes tengan la autorización para hacerlo. Existe una medida cualitativa para la seguridad que dice: “ Un sistema es seguro, si se comporta como los usuarios esperan que lo haga” 7 .
Por otro lado, el punto de vista tradicional sobre seguridad otorga
mayor atención a los aspectos de seguridad clásicos, como son: el acceso
físico, y la seguridad de los datos. Ahora bien, este enfoque parecía
funcionar cuando las operaciones de cómputo de una entidad estaban
centralizadas, hoy en día esta situación ha cambiado.
Tomando en cuenta los párrafos anteriores, se requiere un enfoque
amplio que abarque cierto número de aspectos relacionados entre sí de
manera metódica, agrupándolos convenientemente. El escrutinio cuidadoso
de estas áreas revelará que ninguna de ellas es, por sí sola, de importancia
exclusiva. Pero puede darse el caso que en una instalación específica,
pueda tener mayor relevancia y, consecuentemente, requerir mayor
atención. Sin embargo si se incurre en el error de excluir una de estas áreas
se dejaran vacíos o poros en las estructuras referentes a administración y
control de la seguridad. El enfoque propuesto, el cual abarca
metódicamente todas estas áreas se denomina Seguridad Total.
7 Oficina Nacional del Gobierno Electrónico e Informática. ONGEI, Lima Perú
Esto indica que en toda organización debe existir un sistema de
Seguridad de Información y un personal responsable que este a cargo de la
dirección para la aplicación adecuada, metódica, organizada y controlada de
las políticas y procedimientos de seguridad física y lógica de la organización
como así también de los recursos involucrados para la consecución de los
objetivos de la compañía.
Para Coltell, O. “la Seguridad de la Información puede ser vista desde su rol estratégico en los procesos de negocio, al identificar con qué recursos (organización, procesos, tecnología), se debe contar para alcanzar la efectividad entre las actividades de resguardo o protección de los activos de información y la habilitación del acceso apropiado a los mismos. En este sentido, la Seguridad de la Información es un aspecto sumamente importante en la relación que se establece entre el negocio, sus clientes, socios, proveedores y empleados. La Seguridad de la Información es otro proceso estratégico del negocio ya que al lograr el equilibrio adecuado entre la protección y la habilitación de acceso a los activos de información en línea con los objetivos de negocio, se estarán optimizando substancialmente las operaciones. La noción de Seguridad de la Información como un habilitador de negocios es hoy día un concepto esencial para las organizaciones de cualquier sector industrial” 8 .
Como un proceso estratégico, la Seguridad de la Información pudiera estar
enfocada en proteger los activos de información de una organización contra
pérdidas o uso indebido, o focalizada a brindar acceso a los activos de
información apoyando los objetivos de negocio. Uniendo estos dos conceptos
– seguridad como “Protección” y seguridad como “Habilitador de Accesos” –
se define de manera integral un nuevo enfoque de Seguridad de la
Información en las organizaciones. La Seguridad de la Información puede ser
vista desde su rol estratégico en los procesos de negocio, al identificar con
qué recursos (organización, procesos, tecnología), se debe contar para
alcanzar la efectividad entre las actividades de resguardo o protección de los
8 Coltell, O. Desarrollo general de una auditoría. procesos, metodologías, técnicas y tecnologías. Auditoría Informática (I.T.I.G. Plan 1991) Universidad Jaume I, 2003.
activos de información y la habilitación del acceso apropiado a los mismos. En
este sentido, la Seguridad de la Información es un aspecto sumamente
importante en la relación que se establece entre el negocio, sus clientes,
socios, proveedores y empleados.
Para Microsoft, “ el diseño de una aplicación distribuida es afectado por las directivas relativas a la seguridad, que son las reglas que son las que determinan la forma en que se protege una aplicación, el modo en el que se administra, así como la forma en que los distintos componentes de una aplicación se comunican entre sí y con los servicios externos 9 ” .
3.1.5.Sistema informático Según la Norma Técnica Peruana NTPISO/IEC 12207, Tecnología
de la información, Procesos del ciclo de vida del software publicada el 28 de
julio del 2006, sistema informático es “el conjunto de elementos relacionados compuestos por uno o más procesos, hardware, software, instalaciones y personal que proporcionan la capacidad de satisfacer una necesidad u objetivo definido” 10
Un sistema informático es el conjunto de hardware, software y de un
soporte humano. Un sistema informático típico emplea una computadora
que usa dispositivos programables para capturar, almacenar y procesar
datos. La computadora personal o PC, junto con la persona que lo maneja y
los periféricos que los envuelven, resultan de por sí un ejemplo de un
sistema informático. “ Un sistema informático es un conjunto de elementos
necesarios (computador, impresoras, etc.) para la realización y explotación de aplicaciones informáticas” 11 .
Los diseñadores de sistemas informáticos no necesariamente
esperan que sus sistemas se puedan interconectar con otros sistemas. Por
otro lado, los técnicamente eruditos a menudo pueden configurar sistemas
9 Microsoft Corporation, Patterns & Practices. Directivas de seguridad, Diciembre de 2002[En línea] Disponible en <www.microsoft.com> 10 Norma Técnica Peruana NTPISO/IEC 12207, Tecnología de la información, Procesos del ciclo de vida del software Lima, Perú, 2006 [En línea] Disponible en <http://www.bvindecopi.gob.pe/normas/isoiec12207.pdf> 11 Universidad de Valparaíso. [En línea] Disponible en < mat.uv.cl/profesores/apuntes/archivos_publicos/6796172328_Informatica.ppt >, Chile.
disímiles para que se puedan comunicar entre sí usando un conjunto de
reglas y restricciones conocidas como protocolos. Los protocolos tratan
precisamente de definir la comunicación dentro de y entre sistemas
informáticos distintos pero conectados entre sí. Si dos sistemas informáticos
usan el mismo protocolo, entonces podrán ser capaces de interconectarse y
formar parte de un sistema mayor.
3.1.6. Gestión de la información
Las autoras Bustelo y Amarilla (2001) dicen que “la gestión de la información se puede definir como el conjunto de actividades realizadas con el fin de controlar, almacenar y, posteriormente, recuperar adecuadamente la información producida, recibida o retenida por cualquier organización en el desarrollo de sus actividades” 12 . En este caso, la gestión se restringe al campo de la información manejada por una organización, separándola de las demás
aspectos que abarca la gestión del conocimiento, como son los recursos
humanos y la medición de los activos intangibles.
La gestión de la información se constituye en la vertiente más importante de
la gestión del conocimiento, que abarca todos los procesos y actividades
vinculadas a la generación, procesamiento, uso y transformación de los
datos como fuentes futuras de información y posterior conocimiento.
Diversos especialistas consideran que sin una adecuada gestión de la
información es imposible llegar a la gestión del conocimiento, y la
importancia que se le otorga es de un máximo nivel cuando las autoras
Bustelo y Amarilla (2001) señalan lo siguiente: “Es por lo tanto el paso previo, que cualquier organización debería dar antes de tratar de implantar un sistema de gestión del conocimiento”. Cabe resaltar que en el centro de la gestión de la información se encuentra
la gestión de la documentación.
3.1.7. Documento
12 Bustelo Ruesta, Carlota y Amarilla Iglesias, Raquel. Gestión del conocimiento y gestión de la información [en línea]. En Boletín del Instituto Andaluz de Patrimonio Histórico, año VIII, nº 34 (marzo 2001); pp. 226230. www.infoarea.es/documentos/GC.pdf) [Consulta 2 Oct. 2007]
Un documento administrativo nace con una función administrativa
que le es inherente; con un carácter de temporalidad que viene
condicionado por la necesaria permanencia en la oficina de donde parte o
que lo gestiona; y adquiere un valor paralelo como fondo del organismo del
Estado, en cuanto puede ser objeto de utilización por parte del público ajeno
a la gestión del mismo.
Los documentos administrativos reciben diferentes nombres
dependiendo de la función que desempeñen en el procedimiento
administrativo. En una municipalidad podemos encontrar documentos
puramente administrativos, pero también otros que no se ajustarían a la
definición antes presentada. Todos sin embargo formarán el archivo de
oficina y su organización será imprescindible.
A efectos de esa organización Fernández Gil (1999) 13 manifiesta que
conviene hacer unos grandes grupos de documentos que se pueden
encontrar en todas las oficinas municipales con independencia de las
actividades que se lleven a cabo en ellas, que como explicaremos más
adelante darán lugar a una tipología documental específica. Estos grandes
grupos serían:
Figura 1: Tipos de documentos en las oficinas Municipales
13 Fernández Gil, Paloma. Manual de organización de Archivos de gestión en las Oficinas municipales, ediciones Adhara, Segunda edición, 1999
Fuente: Manual de Organización de Archivos de Gestión en las Oficinas
Municipales, Fernández Gil, Paloma, segunda edición, 1999.
• Correspondencia: Podemos definir la correspondencia como el
conjunto de cartas que recibe y emite una oficina. El diccionario de la Real
Academia de la Lengua define la palabra carta como “papel escrito, y
ordinariamente cerrado, que una persona envía a otra para comunicarse
con ella”.
La variedad de cartas que reciben o envían las municipalidades es
enorme, pero hay que considerar que una inmensa mayoría formarán parte
de un expediente.
• Expedientes: El Diccionario de Terminología Archivística define
expediente como “unidad documental formada por un conjunto de
documentos generado, orgánica y funcionalmente por un sujeto productor
en la resolución de un mismo asunto”.
• Documentos de Notificación: Denominamos documentos de
notificación a los que se envían a todas las oficinas municipales para
comunicar asuntos de interés general; o aquellos documentos dirigidos a un
empleado público o a una oficina determinada para comunicar un asunto de
su interés. En el primer caso se incluyen las Circulares, y/o Comunicados.
En el segundo puede incluirse las certificaciones de acuerdos sobre asuntos
personales.
• Documentos de Enlace: Como su nombre indica son documentos
que se utilizan para trasladar documentos de un área a otra. Generalmente
reciben el nombre de “notas de régimen interior”, “oficios de remisión” o
“relaciones de envío”.
Cuando existe una buena organización administrativa y los documentos
están correctamente elaborados, la autoría y la fecha de los escritos bien
expresados, estas notas de régimen interior sólo sirven como
acompañamiento al documento. Se archivarán en una carpeta
independiente ordenadas por oficinas. Su función será dejar constancia de
que los documentos se envían y se reciben, por lo tanto podrían ser
eliminados luego de un tiempo prudencial.
• Documentos de apoyo a la gestión: Por documentos de apoyo a la
gestión entendemos todos aquellos que recibe una oficina o elabora ella
misma para facilitar la gestión de sus asuntos. Esta documentación tiene
como característica común la de su carácter informativo efímero y su falta
de valor legal o histórico.
Los documentos administrativos estudiados hasta ahora suelen ser
sustentadores de derechos de los ciudadanos y de la propia administración
al menos durante un período de su vida, suelen ser documentos originales.
Los documentos de apoyo son copias de otros documentos o documentos
repetidos y carecen de cualquier valor, salvo el meramente informativo
inmediato, por lo que pueden ser destruidos una vez utilizados.
• Documentación informativa auxiliar: Está formada por los
diferentes textos legales, revistas especializadas, Boletines oficiales y
Catálogos que suelen recibir todas las oficinas.
Los documentos, igual que las personas, tienen una especie de vida
propia y pasan por diferentes edades. Así surge en la ciencia archivística la
llamada Teoría de las tres edades.
Según esta teoría los documentos pasan por tres etapas desde su
creación:
• Primera edad: en la que los documentos circulan y se tramitan. Su
uso es frecuente, y reunidos y organizados forman el archivo de
oficina.
• Segunda Edad: Los documentos carecen de valor administrativo,
pero su conservación es necesaria ya que tienen un valor legal y/o
fiscal y son consultados con mucha frecuencia por la
Administración o los ciudadanos. Forman el Archivo Intermedio.
• Tercera Edad: Los documentos tienen un valor histórico y su
consulta se lleva a cabo por los investigadores preferentemente.
Estos documentos forman el Archivo Histórico.
Generalmente a cada una de estas edades se le asigna un número
de años, así se dice que los documentos de primera edad tienen de 0 a 5
años, los de segunda edad de 5 a 30 años y los de tercera edad son
aquellos que superan dicha fecha. Lo que no deja de ser un
convencionalismo tal vez de necesaria aplicación en grandes
organizaciones, pero que aplicado a ámbitos más pequeños puede ir en
detrimento de la conservación de los documentos y del aprovechamiento de
los espacios administrativos.
Figura 2: Edad de los documentos según la teoría de los documentos
Fuente: Manual de Organización de Archivos de Gestión en las Oficinas Municipales, Fernández Gil, Paloma, segunda edición, 1999.
3.1.8 Documento electrónico
Para Schamber (1996, p. 669) un documento electrónico tiene una
serie de características que lo diferencian del tradicional: es
fácilmente manipulable, enlazable interna y externamente,
rápidamente transformable, intrínsecamente localizable,
instantáneamente transportable e infinitamente replicable.
El documento electrónico no es una entidad física inerte, con la
estructura lógica y las relaciones físicas interdependientes, como
sucede con el documento tradicional. Las relaciones físicas y lógicas
del documento electrónico pueden ser separadas y conservadas de
modo recíprocamente independiente.
De hecho, el documento electrónico consta de una serie de señales
digitales y, por lo tanto, tiene pocos o ninguno de los atributos físicos
del documento tradicional. Los atributos físicos del documento
electrónico, que incluirían la forma o el tipo de material cuando es
visualizado en pantalla o impreso, son en gran medida una función
del software y están separados del contenido informativo o del
contexto del documento.
Las relaciones lógicas de un documento dependen de los atributos
físicos y de otra información contextual que genera el software
(Dollar, 1992).
Todo esto, naturalmente, debe representar cambios fundamentales
para los profesionales de los archivos y la gestión de documentos:
nuevas prácticas de comunicación y nuevas formas de documentos,
con características poco definidas; y la transformación del entorno
relativamente estable de las organizaciones burocráticas y su
reemplazo por un tipo de estructura organizativa apenas esbozada en
estos momentos.
3.1.9. Gestión documentaria
En su primigenia acepción, difundida por el National Archives and
Records Administration (NARA) de Estados Unidos, la gestión de
documentos queda acotada a los documentos con valor primario, es decir a
los documentos corrientes o, para nosotros, con vigencia administrativa. Se
reconoce que tal gestión “se extiende al ciclo vital de vida completo del
documento desde su producción hasta su eliminación o envío al archivo
para su conservación permanente”
Gestión, es un término común que supone administración de recursos
con vistas a su rentabilidad a partir de la racionalidad, la simplificación y la
eficacia que, en la actualidad, se le exigen. Puede ser aplicado a cualquier
ámbito y sobre cualquier recurso.
En este sentido, gestión documentaria debe abarcar todas las
funciones y actuaciones (recojo, identificación, valoración, eliminación,
conservación, organización, descripción, difusión), en el marco de la
racionalización, sobre los documentos a lo largo de toda su existencia, con
fines de economía y eficacia, con vistas al servicio de los mismos para
cualquier usuario, incluida la Administración.
La gestión documental así entendida, supone una atención y
tratamiento continuados a los documentos que no se interrumpe, ni se
diferencia esencialmente al entrar en el estadio de la conservación
permanente. De alguna manera, lo que defendemos es que, a partir de la
sucesión de actuaciones archivísticas, éstas nos permiten dinamizar el
servicio de los documentos a lo largo de todas sus edades y conducir, sin
traumas, los documentos corrientes de hoy hasta configurar los fondos
históricos del mañana.
Por el contrario, existen posturas que parecen circunscribir el
tratamiento archivístico a los documentos históricos cuando la
documentación administrativa requiere también de todas las funciones
archivísticas que aquellos, incluso algunas más, como pueden ser, entre
otras, la selección y la eliminación. Cuando utilizamos el término gestión de
documentos, empleamos el término gestión recabando para él las notas de
dinamismo, de racionalidad, de eficacia, de normatividad, que le son
inherentes, pero no recabando esencialmente dimensión administrativa, sino
archivística con la amplitud que conlleva el término “documento” y su ciclo
vital. Es decir una gestión de documentos sin reservas, ininterrumpida a
todo lo largo de la vida de éstos.
El Diccionario de Terminología Archivística editado por el Consejo
Internacional de Archivos define el término Gestión de Documentos como un
aspecto de la Administración general relacionado con la búsqueda de la
economía y eficacia en la producción, mantenimiento, uso y destino final de
los documentos.
Dicho de manera más clara “es el conjunto de tareas y
procedimientos orientados a lograr una mayor eficacia y economía en la
explotación de los documentos por parte de las Administraciones”.
El documento, en función de la información contenida en él será
objeto de una atención especial. Desde el momento mismo de su creación.
La idea primordial de la Gestión de Documentos pasa a ser la teoría del
CICLO DE VIDA de los documentos, que en su versión más radical consiste
“en que la información registrada tiene una vida similar a la de un organismo
vivo, en el sentido que nace (fase de creación), vive (fase de mantenimiento
y uso) y muere (fase de conservación histórica o eliminación”.
Otra definición importante es la de Elisa GarcíaMorales que nos dice:
“… es la parte del sistema de información de la empresa desarrollada con el propósito de almacenar y recuperar documentos, que debe estar diseñada para coordinar y controlar todas aquellas funciones y actividades específicas que afectan a la creación, recepción, almacenamiento, acceso y preservación de los documentos, salvaguardando sus características estructurales, contextuales y, garantizando su autenticidad y veracidad” . 14
Además, indica que “.. cuando se parte de la premisa de que tratamos la gestión de la documentación como un simple conjunto de herramientas tecnológicas que permiten trabajar, producir y acceder mejor a los documentos, se está obviando todo el componente organizativo y funcional del sistema. Este es el que permite sentar las bases para que todos esos documentos, sean un conjunto coherente que de respuesta a las necesidades de la empresa a corto, mediano y largo plazo” .
Desde el punto de vista de Ricardo García y Bonifacio Martin “en la actualidad la gestión documental es entedida como un proceso global, corporativo e integral del proceso documental de una organización. Es por ello más acertado hablar de Sistemas de Gestión Integrada de la
14 GarcíaMorales, Elisa. Gestión Documental en Intranet. Disponible en: Herramientas para la gestión de los documentos electrónicos en los nuevos servicios de información y documentación [en línea] < www.cobdc.org/7es/homecas.htm> [Consulta: 2 Dic. 2007]
documentación, las cuales controlan la producción, la circulación, el almacenamiento y la recuperación de cualquier tipo de información” 15 .
Para la UNESCO la gestión documentaria es la esfera de la gestión
administrativa encaminada a conseguir la economía y la eficacia de las
operaciones con vista a la creación, mantenimiento y utilización y por último
a la eliminación de los documentos o a su conservación definitiva durante su
ciclo vital.
Duchein afirma que la gestión documental es “un sistema que pretende organizar y racionalizar la gestión de los fondos desde el mismo momento de la producción de los documentos hasta su ingreso a los archivos nacionales, interviniendo tanto en el trabajo de las oficinas y en los servicios administrativos en las distintas etapas del tratamiento de fondos” .
3.1.10. Sistema de Gestión documentaria
Para atender a los documentos en todo su ciclo de vida se deben
desarrollar programas de gestión de documentos que podríamos definir
como una actuación sobre los documentos destinada asegurar la economía
y la eficiencia en su gestión y que permita su identificación, su conservación
y la utilización de los archivos de forma sistemática.
Por otro lado, cabe mencionar que el diseño de un Sistema de
Gestión Documental implica además la determinación de los tipos
documentales disponibles y la identificación y categorización de la
producción documental de la organización.
Los sistemas de gestión documentaria son una agrupación de
herramientas y metodologías que permiten controlar y realizar una gestión
sobre el ciclo de vida y operaciones que recaen habitual o esporádicamente
sobre los documentos generados y almacenados en una organización.
Entre los objetivos que debe perseguir la implantación de todo
sistema de gestión de documentos tenemos:
15 García Caballero, Ricardo; Martín Galán, Bonifacio. Herramientas para la gestión de los documentos electrónicos en los nuevos servicios de información y documentación [en línea] <www.cobdc.org/7es/home cas.htm> [Consulta 2 Dic. 2007]
• Asegurar y facilitar el acceso a los documentos, lo que implica
recuperar los documentos verídicos y fiables entre las múltiples
copias y versiones que pueden existir.
• Garantizar el mantenimiento de los criterios de organización de
los mismos.
• Salvaguardar y preservar la evidencia de las actividades,
conocimientos y transacciones de la empresa.
• Establecer una política racional de conservación y destrucción de
documentos en función de las necesiades informativas de la
empresa.
Para Carlota Bustelo (2000) 16 los sistemas de gestión documental
pretenden que:
• Cada persona conozca qué documento tiene que guardar,
cuando, como y donde; y cómo encontrar en poco tiempo los
documentos adecuados cuando los necesita.
• Facilitar que la información se comparta y se aproveche como un
recurso colectivo, evitando que se duplique y se produzcan copias
innecesarias.
• Conservar la memoria de la organización y aprovechar el valor de
los contenidos en los que queda plasmada la experiencia,
evitando empezar de cero sobre aspectos con los que ya hay
experiencia acumulada.
Para Elisa GarcíaMorales 17 , la persona que asuma la
responsabilidad de administrar el Sistema de gestión documental debe
orientar sus funciones hacia la coordinación y supervisión de las actividades
relacionadas con:
• La producción de los documentos, en lo referente a la
estandarización de la producción.
• La conservación, archivamiento y eliminación de los
documentos, a través de la determinación de una política clara
en la materia.
16 Bustelo Ruesta, Carlota. Gestión Documental en las empresas: una aproximación práctica [En línea] En: VII Jornadas Españolas de Documentación (Fesabid 2000). Bilbao, 19.21 de octubre del 2000 <wwww.infoarea.es/documentos/feabid.pdf> [Consulta: 712008] 17 García Morales Huidobro, Elisa. Ob. Cit.
• La preservación de la integridad de los documentos de valor
para la empresa.
Típicamente un Sistema de gestión documentaria cuenta con una
arquitectura que incluye los siguientes elementos 18 :
• Elementos de entrada de documentos, por ejemplo, escáner.
• Elementos de proceso de imágenes y datos: base de datos,
aplicaciones de OCR.
• Elementos de almacenamiento: bases de datos, discos
ópticos, etc.
• Elementos de recuperación, visualización y reproducción:
aplicaciones frontend, herramientas de ofimática y de
administración de base de datos
Los sistemas de Gestión documental, son sistemas orientados al
funcionamiento dentro de un ambiente de red y de trabajo común.
3.1.11.Tecnología usadas en sistemas informáticos
3.1.11.1. Tecnología Web
La Tecnología Web 19 implica el diseño de aplicaciones en torno a procesos, es necesario entender que el trabajo ahora tiene un desarrollo incesante que nos permite atender todas las tareas involucradas en lo que podríamos decir que es gestión y diseminación de información desde la producción de la información hasta que esa información esté procesada. La tecnología Web nos plantea dos tareas: Diseñar en torno a procesos y apoyar cada proceso con Tecnologías de la Información para comunicar a las personas.
Las tecnologías Web sirven para acceder a los recursos de conocimiento disponibles en Internet o en las intranets utilizando un navegador. Están muy extendidas por muchas razones: facilitan el desarrollo de sistemas, su flexibilidad en términos de escalabilidad, es decir, a la hora de expandir el sistema; su sencillez de uso y que imitan la forma de relacionarse de las personas, al poner a disposición de todos el
18 Contreras, F, Forero, F. Diseño de un modelo para la implantación de un sistema de gestión documental en áreas u organizaciones jurídicas, Bogotá, Colombia, 2005 19 Pérez Capdevila, Javier. Las Tecnologías Web para la Gestión del Conocimiento [Disponible en http://www.sociedadelainformacion.com/9/las_tecnologias_web.htm][Consulta: 28 Set. 2007]
conocimiento de los demás, por encima de jerarquías, barreras formales u otras cuestiones.
La tecnología Web proporciona un ambiente heterogéneo, ampliamente difundido por el mundo, distribuido y en red. La plataforma Web ha evolucionado progresivamente y pasó a ser una aglomeración de documentos con información estática programados con HTML (Lenguaje de marcado de hipertexto) a un ambiente donde se pueden implementar potentes aplicaciones clienteservidor accesible desde un cliente Web o browser.
FIGURA 3: Arquitectura de tecnología Web Clásica (Cliente Servidor)
Fuente: Jiménez, Luís Marco, Introducción a las Tecnologías Web
Desde esa primera concepción del servidor HTTP como mero servidor de ficheros HTML el concepto ha ido evolucionando en dos direcciones complementarias:
• Añadir más inteligencia en el cliente.
• Añadir más inteligencia en el servidor
En las páginas dinámicas que se procesan en el cliente, toda la carga de procesamiento de los efectos y funcionalidades la soporta el navegador. El código necesario para crear los efectos y funcionalidades se incluye dentro del mismo archivo HTML y es llamado SCRIPT. Cuando una página HTML contiene scripts de cliente, el navegador se encarga de interpretarlos y ejecutarlos para realizar los efectos y funcionalidades.
Un lenguaje del lado del servidor es aquel que se ejecuta en el servidor web, justo antes de que se envíe la página a través de Internet al cliente. Las páginas que se ejecutan en el servidor pueden realizar accesos
a bases de datos, conexiones en red, y otras tareas para crear la página final que verá el cliente. Una secuencia de comandos del servidor comienza a ejecutarse cuando un explorador solicita un archivo de script al servidor Web. El servidor Web llama al procesador del archivo script, que procesa el archivo solicitado desde el principio hasta el final, ejecuta los comandos que encuentre y envía una página Web al explorador.
Puesto que las secuencias de comandos se ejecutan en el servidor y no en el cliente, el servidor Web hace todo el trabajo necesario para generar las páginas HTML que envía a los exploradores. El cliente solamente recibe una página con el código HTML resultante de la ejecución de la ASP, JSP o PHP, que tienen características similares. Las secuencias de comandos del servidor no se pueden copiar, ya que sólo se devuelve al explorador el resultado de la secuencia de comandos.
Las Tecnologías Web tienen las siguientes ventajas:
• Comunicación. Capacidad de facilitar la comunicación entre diferentes entidades. Integración de múltiples dispositivos: móviles, PDAs, etc.
• Arquitectura basada en servicios. Publicación y descubrimiento de servicios Ejemplos: Validación de tarjetas, envío de paquetes.
• Obtención de conocimiento.
• Navegación automática.
• Flexibilidad y responsabilidad: Aceptar la rapidez de cambios de contenidos.
• Nuevos modelos de procesos (persistencia, portabilidad, compensación).
• Autonomía: Procesos que se modifican a sí mismos.
• Fuentes de información confiable y trazabilidad: No toda la información de Internet es segura.
3.1.11.2. Tecnologías Cliente
Son dispositivos o herramientas con los cuales se accede a los servicios del servidor.
a) Navegador Web
• Internet Explorer
• Netscape Navigator
• Mozilla
• Konqueror
b) Tecnologías de programación 20
• HTML
HTML es el lenguaje con el que se definen las páginas Web. Básicamente se trata de un conjunto de etiquetas que sirven para definir la forma en la que se presenta el texto y otros elementos de la página.
• JavaScript / JScript
Javascript es un lenguaje de programación utilizado para crear pequeños programas encargados de realizar acciones dentro del ámbito de una página Web. Se trata de un lenguaje de programación del lado del cliente, porque es el navegador el que soporta la carga de procesamiento.
Entre las acciones típicas que se pueden realizar en Javascript tenemos dos vertientes. Por un lado los efectos especiales sobre páginas Web, para crear contenidos dinámicos y elementos de la página que tengan movimiento, cambien de color o cualquier otro dinamismo.
• VBScript
Es un lenguaje de programación de scripts del lado del cliente, pero sólo compatible con Internet Explorer. Es por ello que su utilización está desaconsejada a favor de Javascript.
Está basado en Visual Basic, un popular lenguaje para crear aplicaciones Windows. Tanto su sintaxis como la manera de trabajar están muy inspiradas en el.
• Applets Java
Es una manera de incluir programas complejos en el ámbito de una página Web. Estos applets se programan en Java y por tanto se benefician de la potencia de este lenguaje para la Red.
20 Tecnologías web [en línea] [Disponible en http://www.desarrolloweb.com/manuales/15/] [Consulta 28 Set. 2007]
La principal ventaja de utilizar applets consiste en que son mucho menos dependientes del navegador que los scripts en Javascript, incluso independientes del sistema operativo del ordenador donde se ejecutan.
• Componentes ActiveX
ActiveX es una tecnología de Microsoft para el desarrollo de páginas dinámicas. Tiene presencia en la programación del lado del servidor y del lado del cliente, aunque existan diferencias en el uso en cada uno de esos dos casos.
En el cliente: Son pequeños programas que se pueden incluir dentro de páginas Web y sirven para realizar acciones de diversa índole.
En el servidor: También existen controles ActiveX del servidor. Por ejemplo, cuando realizamos una conexión con una base de datos, estamos utilizando un control ActiveX del servidor.
• Visual Basic
Visual Basic es uno de los lenguajes de programación más extendido y utilizado en la historia de la informática y ha continuado evolucionando en los últimos años.
Haré mención sólo a las últimas versiones de este lenguaje, pues con la aparición de la tecnología Microsof .NET, Visual Basic sufrió la transformación más amplia que jamás haya tenido este lenguaje. Microsoft elaboró la primera especificación de esta evolución que ha tenido Visual Basic 7.0, y que sería la que se incorporaría a Visual Basic .NET 2002.
El VB.NET posee plenas capacidades de orientación a objetos (FullOOP), incluyendo por fin, herencia; Windows Forms o la nueva generación de formularios para aplicaciones Windows; soporte nativo de XML; gestión de errores estructurada; un modelo de objetos para acceso a datos más potente con ADO.NET; posibilidad de crear aplicaciones de consola (ventana MSDOS); programación para Internet mediante Web Forms; un entorno de desarrollo común a todas las herramientas de .NET, etc.
Poco tiempo después, la especificación del lenguaje Visual Basic sufrió pequeños retoques que se incorporaron a la especificación del lenguaje Visual Basic 7.1 y que formaría parte de Visual Basic .NET 2003.
Microsoft sin embargo, no se ha detenido aquí y así ha elaborado la especificación del lenguaje Visual Basic 8.0 que es la especificación que forma parte de Visual Basic 2005 .
Microsoft Visual Basic 2005 es una evolución del lenguaje Visual Basic que está diseñado para generar de manera productiva aplicaciones con seguridad de tipos y orientadas a objetos. Visual Basic permite a los desarrolladores centrar el diseño en Windows, el Web y dispositivos móviles. Como con todos los lenguajes que tienen por objetivo Microsoft .NET Framework, los programas escritos en Visual Basic se benefician de la seguridad y la interoperabilidad de lenguajes.
Esta generación de Visual Basic continúa la tradición de ofrecer una manera rápida y fácil de crear aplicaciones basadas en .NET Framework.
Esta versión de Visual Basic vuelve a incluir la compatibilidad para Editar y continuar e incluye nuevas características para el desarrollo rápido de aplicaciones. Una de estas características, llamada My, proporciona acceso rápido a las tareas frecuentes de .NET Framework, así como información e instancias de objeto predeterminadas que estén relacionadas con la aplicación y su entorno en tiempo de ejecución. Las nuevas características de idioma incluyen la continuación de bucle, la eliminación garantizada de recursos, la sobrecarga de operadores, los tipos genéricos y los eventos personalizados. Visual Basic también integra completamente .NET Framework y Common Language Runtime (CLR), que proporcionan interoperabilidad de lenguajes, recolección de elementos no utilizados, seguridad mejorada y control de versiones. 21
Actualmente, con varias mejoras, encontramos el Visual Basic 2008.
3.1.11.3 Tecnologías Servidor
Es cualquier recurso de cómputo dedicado a responder a los
requerimientos del cliente. Los servidores pueden estar conectados a los
clientes a través de redes LANs o WANs, para proveer de múltiples
servicios a los clientes y ciudadanos tales como impresión, acceso a bases
de datos, fax, procesamiento de imágenes, etc.
21 Microsoft, Visual Basic 2005, http://msdn.microsoft.com/eses/library/2x7h1hfk(VS.80).aspx
a. Servidor Web
• Internet Information Server (IIS)
• Apache, Apache Tomcat
• WebSphere webserver
• Motores Java, PHP.
b. Tecnologías de Programación
• PHP
Es un lenguaje para programar scripts del lado del servidor, que se incrustan dentro del código HTML. Este lenguaje es gratuito y multiplataforma.
PHP es el acrónimo de Hipertext Preprocesor. Es un lenguaje de programación del lado del servidor gratuito e independiente de plataforma, rápido, con una gran librería de funciones y mucha documentación.
Un lenguaje del lado del servidor es aquel que se ejecuta en el servidor Web, justo antes de que se envíe la página a través de Internet al cliente. Las páginas que se ejecutan en el servidor pueden realizar accesos a bases de datos, conexiones en red, y otras tareas para crear la página final que verá el cliente. El cliente solamente recibe una página con el código HTML resultante de la ejecución de PHP. Como la página resultante contiene únicamente código HTML, es compatible con todos los navegadores.
PHP se escribe dentro del código HTML, lo que lo hace realmente fácil de utilizar, al igual que ocurre con el popular ASP de Microsoft, pero con algunas ventajas como su gratuidad, independencia de plataforma, rapidez y seguridad. Existe un módulo que hace que nuestro servidor Web comprenda los scripts realizados en este lenguaje.
Es independiente de plataforma, puesto que existe un módulo de PHP para casi cualquier servidor web. Esto hace que cualquier sistema pueda ser compatible con el lenguaje y significa una ventaja importante, ya que permite portar el sitio desarrollado en PHP de un sistema a otro sin prácticamente ningún trabajo.
La seguridad, en este punto también es importante el hecho de que en muchas ocasiones PHP se encuentra instalado sobre servidores Unix o Linux, que son de sobra conocidos como más veloces y seguros que el sistema operativo donde se ejecuta las ASP, Windows NT o 2000.
Las ventajas de PHP son:
v Es un lenguaje multiplataforma.
v Capacidad de conexión con la mayoría de los manejadores de base de datos que se utilizan en la actualidad.
v Leer y manipular datos desde diversas fuentes, incluyendo datos que pueden ingresar los usuarios desde formularios HTML.
v Capacidad de expandir su potencial utilizando la enorme cantidad de módulos (llamados ext's o extensiones).
v Posee una amplia documentación en su página oficial.
v Es libre, por lo que se presenta como una alternativa de fácil acceso para todos.
v Permite las técnicas de Programación Orientada a Objetos.
v Nos permite crear los formularios para la Web.
• ASP
Es el lenguaje de scripting del lado del servidor creado por Microsoft ASP (Active Server Pages) es la tecnología desarrollada para la creación de páginas dinámicas del servidor. ASP se escribe en la misma página Web, utilizando el lenguaje Visual Basic Script o Jscript (Javascript de Microsoft).
Las páginas que se ejecutan en el servidor pueden realizar accesos a bases de datos, conexiones en red, y otras tareas para crear la página final que verá el cliente. El cliente solamente recibe una página con el código HTML resultante de la ejecución de la página ASP.
• JSP
La tecnología Java para la creación de páginas web con programación en el servidor. JSP es un acrónimo de Java Server Pages, que en castellano vendría a decir algo como Páginas de Servidor Java. Es, pues, una tecnología orientada a crear páginas web con programación en Java.
Con JSP podemos crear aplicaciones web que se ejecuten en distintos servidores web, de múltiples plataformas, ya que Java es en esencia un lenguaje multiplataforma.
3.1.11.4. Aspectos sobre digitalización
• Imagen digital
Las imágenes digitales son fotos electrónicas tomadas de una escena
o escaneadas de documentos fotografías, manuscritos, textos impresos e
ilustraciones. Se realiza una muestra de la imagen digital y se confecciona
un mapa de ella en forma de cuadrícula de puntos o elementos de la figura
(píxeles). A cada píxel se le asigna un valor tonal (negro, blanco, matices de
gris o color), el cual está representado en un código binario (ceros y unos).
Los dígitos binarios ("bits") para cada píxel son almacenados por una
computadora en una secuencia, y con frecuencia se los reduce a una
representación matemática (comprimida). Luego la computadora interpreta y
lee los bits para producir una versión analógica para su visualización o
impresión.
• Resolución
La resolución es la capacidad de distinguir los detalles espaciales
finos. Por lo general, la frecuencia espacial a la cual se realiza la muestra de
una imagen digital (la frecuencia de muestreo) es un buen indicador de la
resolución. Este es el motivo por el cual dotsperinch (puntos por pulgada)
(dpi) o pixelsperinch (píxeles por pulgada) (ppi) son términos comunes y
sinónimos utilizados para expresar la resolución de imágenes digitales.
Generalmente, pero dentro de ciertos límites, el aumento de la frecuencia de
muestreo también ayuda a aumentar la resolución.
• Dimensiones de pixel
Las dimensiones de píxel son las medidas horizontales y verticales
de una imagen, expresadas en píxeles. Las dimensiones de píxel se pueden
determinar multiplicando tanto el ancho como la altura por el dpi.
Una cámara digital también tendrá dimensiones de píxel, expresadas
como la cantidad de píxeles en forma horizontal y en forma vertical que
definen su resolución (por ejemplo: 2.048 por 3.072). Aquí se calcula el dpi
logrado dividiendo las dimensiones de un documento por la dimensión de
píxel correspondiente respecto de la cual se encuentra alineado.
• Profundidad de bits
La profundidad de bits es determinada por la cantidad de bits
utilizados para definir cada píxel. Cuanto mayor sea la profundidad de bits,
tanto mayor será la cantidad de tonos (escala de grises o color) que puedan
ser representados. Las imágenes digitales se pueden producir en blanco y
negro (en forma bitonal), a escala de grises o a color.
Una imagen bitonal está representada por píxeles que constan de 1
bit cada uno, que pueden representar dos tonos (típicamente negro y
blanco), utilizando los valores 0 para el negro y 1 para el blanco o viceversa.
Una imagen a escala de grises está compuesta por píxeles
representados por múltiples bits de información, que típicamente varían
entre 2 a 8 bits o más.
Una imagen a color está típicamente representada por una
profundidad de bits entre 8 y 24 o superior a ésta. En una imagen de 24 bits,
los bits por lo general están divididos en tres grupos: 8 para el rojo, 8 para el
verde, y 8 para el azul. Para representar otros colores se utilizan
combinaciones de esos bits. Una imagen de 24 bits ofrece 16,7 millones (2 24 ) de valores de color. Cada vez más, los escáneres están capturando 10
bits o más por canal de color y por lo general imprimen a 8 bits para
compensar el "ruido" del escáner y para presentar una imagen que se
acerque en el mayor grado posible a la percepción humana.
• Tamaño del archivo
El tamaño del archivo se calcula multiplicando el área de superficie
(altura x ancho) de un documento a ser escaneado, por la profundidad de
bits y el dpi 2 . Debido a que el archivo de imagen se representa en bytes,
que están formados por 8 bits, se divide esta cifra por 8.
Tamaño de archivo = (altura x ancho x profundidad de bits x dpi 2 ) / 8
• Formatos de archivo
Los formatos de archivo consisten tanto en los bits que comprende la
imagen como en la información del encabezamiento acerca de cómo leer e
interpretar el archivo.
Los formatos de archivo varían en términos de resolución,
profundidad de bits, capacidades de color, y soporte para compresión y
metadatos.
CUADRO 5: FORMATOS DE ARCHIVO DE IMÁGENES COMUNES
Nombre y versión actual
TIFF 6.0 (Tagged Image File Format)
GIF 89a (Graphics Interchange Format)
JPEG (Joint Photographic
Expert Group)/JFIF (JPEG File Interchange Format)
PNG 1.2 (Portable Network Graphics)
PDF 1.3 (Portable Document Format)
Extensión .tif, .tiff .gif .jpeg, jpg, .jif, .jfif .png .pdf Profundi dad de bits
Bitonal a 1 bit; escala de grises o color de paleta de 4 u 8 bits; hasta color de 64 bits
Bitonal, escala de grises o color entre 1 y 8 bits
Escala de grises a 8 bits; color a 24 bits
148 bits; color a 8 bits, escala de grises a 16 bits, color a 48 bits
Escala de grises a 4 bits; color a 8 bits; soporta hasta 64 bits para color
Compre sión
Descomprimido sin pérdida: ITUT.6, LZW, etc. Con pérdida: JPEG
Sin pérdida: LZW Con pérdida: JPEG Sin pérdida:
Sin pérdida: Deflate, derivado de LZ77
Descomprimido Sin pérdida: ITU T.6, LZW. Con pérdida: JPEG
Estándar/ patenta do
Estándar de facto Estándar de facto JPEG: ISO 10918 1/2 JFIF: estándar de facto
ISO 15948 (anticipado) [a]
Estándar Internacional ISO [b]
Gestión de color
RGB, Paleta, YCbCr, CMYK, CIE L*a*b*
Paleta YCbCr Paleta, sRGB, ICC
RGB, YCbCr, CMYK
Soporte de Web
Conexión o aplicación externa
Originario desde Microsoft® Internet Explorer, Netscape Navigator® 2
Originario desde Microsoft® Internet Explorer 2, Netscape Navigator 2
Originario desde Internet Explorer 4, Netscape Navigator.
Conexión o aplicación externa
Soporte de metada tos
Conjunto básico de rótulos etiquetados
Campo de texto libre para comentarios
Campo de texto libre para comentarios
Conjunto básico de rótulos etiquetados más rótulos definidos por el usuario.
Conjunto básico de rótulos etiquetados
Comenta rios
Acepta imágenes y archivos múltiples.
Se puede reemplazar por PNG; Soporte de entrelazado y transparencia a través de la mayoría de los navegadores Web
JPEG progresivo ampliamente soportado por los navegadores Web
Puede reemplazar a GIF
Preferido para imprimir y ver documentos de páginas múltiples; uso intensivo por parte del gobierno
[a] Aprobado por W3C para reemplazar a GIF para usar en la Web. [b] Adobe ha proporcionado suficiente información para permitir que los encargados de desarrollar programas escriban aplicaciones que lean y modifiquen archivos PDF. Sin embargo, los archivos pdf comúnmente se crean y se acceden utilizando el software Acrobat propio de Adobe. El estándar está basado en la versión 1.7 del PDF de Adobe. PDF, el formato de archivo para el software Acrobat de Adobe, ha sido utilizado ampliamente como un estándar de facto para el intercambio y visualización de archivos de negocios. Sin embargo Adobe siempre ha mantenido la propiedad del formato hasta que finalmente sucumbió a la presión de la industria y lo remitió para su estandarización el pasado mes de febrero de 2007, siendo
recientemente aprobado por la ISO como estándar internacional. El formato es abierto y accesible por cualquiera como ISO 320001.
Fuente: Biblioteca de la Universidad de Cornell/Departamento de Investigación 20002003 Biblioteca de la
Universidad de Cornell/Departamento de Investigación.
[Disponible en http://www.library.cornell.edu/preservation/tutorialspanish/technical/technicalA01.html]
• La cadena de digitalización
La tecnología necesaria para navegar desde un extremo de la
cadena de digitalización al otro consta principalmente de: hardware,
software y redes. Éstos son el centro de esta sección. Una perspectiva
integral de la infraestructura técnica también incluye protocolos y normas,
políticas y procedimientos (para el flujo de trabajo, mantenimiento,
seguridad, actualizaciones, etc.) y los niveles de habilidad y
responsabilidades del trabajo del personal de una organización.
Sin embargo, ni siquiera los aspectos básicos de la infraestructura
técnica se pueden evaluar en forma completamente aislada. Las acciones y
consideraciones relacionadas que afectarán las decisiones respecto de la
infraestructura técnica incluyen:
• Determinación de los requisitos de calidad basándose en los atributos de
los documentos (Patrón de referencia);
• Valoración de las virtudes y defectos institucionales, los horarios y el
presupuesto (Gestión);
• Comprensión de las necesidades del usuario (Presentación);
• Valoración de planes a largo plazo (Preservación digital).
FIGURA 4: Cadena de digitalización
Fuente: Biblioteca de la Universidad de Cornell/Departamento de Investigación 20002003 Biblioteca de la
Universidad de Cornell/Departamento de Investigación
[Disponible en http://www.library.cornell.edu/preservation/tutorialspanish/technical/technicalA01.html]
• Scanner
Un scanner es un dispositivo de entrada en el ordenador. Hace una
captura de una imagen, documento de texto o fotografía, y lo transfiere en
bits de información, los cuales puede entender y manejar un ordenador. De
la misma manera, una imagen de un documento escaneado, puede ser
convertido en un formato editable con un software OCR (Optical Character
Recognition).
Un scanner usa una fuente de luz para iluminar el objeto escaneado.
La luz, al incidir sobre este objeto, es reflectada al CDD (Charged Coupled
Device). El CDD colecta la información y convierte la señal analógica en
señales digitales que después pueden ser leídos y procesados por la
electrónica interna del Scanner y posteriormente por el ordenador.
Entre los tipos más comunes de scanner tenemos:
• Planos: Es el típico equipo que nos encontraremos encima de una
mesa o mueble y confundiremos con una fotocopiadora. Los precios
suelen variar dependiendo de la calidad de la resolución que tenga
aunque podemos encontrar buenos precios si miramos bien.
• De rodillo: Son pequeños y por ello bastante manejables. Escanean
las imágenes como si se tratara de un FAX común. El inconveniente
es que el escaneado se hace hoja por hoja pasando por una
abertura, por lo que escanear libros o manuales se hace complicado.
• De mano: Son los mas económicos aunque los de mas baja calidad.
También se les llama “portátiles” por su tamaño. Hoy en día están
desapareciendo.
Existe una modalidad de impresora donde el scanner viene integrado.
Son las llamadas “impresoras multifunción”.
3.1.12. Usuario
Para la Norma Técnica Peruana NTPISO/IEC 12207, Tecnología de
la información, Procesos del ciclo de vida del software publicada el 28 de
julio del 2006, usuario es “el individuo u organización que utiliza el sistema en operación para llevar a cabo una función específica. El usuario puede llevar a cabo otros papeles, tales como adquiriente, desarrollador o responsable de mantenimiento. ” 22
Para Spencer, D. los analistas emplean el término usuario final para
referirse a las personas que no son especialistas en sistemas de
información ero que utilizan las computadoras para desempeñar su trabajo.
Los usuarios finales pueden agruparse en cuatro categorías:
• Usuarios primarios, son los que interactúan con el sistema. Alimentan con
datos (entradas) o reciben salidas, quizá por medio de una terminal.
• Los usuarios indirectos, son aquellos que se benefician de los resultados o
reportes generados por estos sistemas pero que no interactúan de manera
directa con el hardware o software. Estos usuarios que utilizan el sistema,
pueden ser los gerentes encargados de las funciones de la empresa, por
ejemplo, los gerentes de mercadotecnia, son los responsables de las
aplicaciones de análisis de venta que genera los reportes mensuales de la
compañía en este ramo.
• Los usuarios gerentes, que tienen responsabilidades administrativas en los
sistemas de aplicación. Estos usuarios son gerentes de la empresa que
22 Norma Técnica Peruana NTPISO/IEC 12207, Tecnología de la información, Procesos del ciclo de vida del software Lima, Perú, 2006 [En línea] Disponible en < http://www.bvindecopi.gob.pe/normas/isoiec12207.pdf>
utilizan en gran medida los sistemas de información. Mientras estas
personas no utilicen los sistemas ya sea directa o indirectamente, no
tendrán la autoridad para aprobar o no la inversión en el desarrollo de
aplicaciones, además no tendrán la responsabilidad ante la organización
de la efectividad de los sistemas.
• Los usuarios directivos, toman cada vez mayor responsabilidad en el
desarrollo de sistemas de información. Las organizaciones bien dirigidas
consideran el posible impacto y los beneficios de los sistemas de
información cuando elaboran su estrategia competitiva.
Para Microsoft, un usuario “es la persona, organización u otra entidad que depende de los servicios de un sistema de computación para obtener un resultado deseado” 23 .
3.1.13. Atención al usuario
En nuestro país, la atención de los servicios públicos no responde, en
todos los casos, a las necesidades de los ciudadanos.
Una de las manifestaciones de eficiencia de un estado es la correcta
atención al ciudadano, y mejorar la calidad de la atención comprende una
variedad de procesos de cambio como: la desregulación, la simplificación
administrativa, mejora de la calidad de procesos de atención (eficiencia,
trato, resultados), incorporación de mecanismos para insumo y consulta de
la ciudadanía. Ejemplos son la informatización de servicios y trámites, la
consulta a beneficiarios, ventanillas ciudadanas, etc.
Una buena práctica gubernamental en Servicio de Atención al
Ciudadano (BPG) se orienta a lograr excelencia en el servicio a éste,
basándose en políticas, acciones y sistemas que permitan entablar con él la
mejor relación posible, buscando garantizar tanto la calidad de la
información brindada como la del trato ofrecido, así como la eficiencia en la
atención satisfactoria de sus demandas.
Las BPGs en Servicio de Atención al Ciudadano buscan que éste sea
el elemento esencial del proceso administrativo en el sector público y que su
bienestar sea el principio fundamental del servidor público, siguiendo el
23 Microsoft, [En línea] Disponible en < http://www.microsoft.com/latam/technet/recursos/howto/glosario/default.mspx>
principio de servicio al cliente. Ello implica un cambio de mentalidad en los
funcionarios y, en la mayoría de casos, el rediseño de procesos para la
comodidad y facilidad de acceso de los ciudadanos a los servicios. En este
aspecto son acciones pioneras la construcción de establecimientos de
atención y simplificación de procesos en municipalidades provinciales y
distritales a nivel nacional, la atención personalizada utilizando tecnologías
de información y la difusión de información para el ciudadano sobre el
quehacer institucional por todos los canales disponibles.
Los servicios de atención al ciudadano se orientan al uso de
tecnologías de la información y al desarrollo de políticas conducentes a
promover su participación mediante la demanda de información y servicios,
incrementando el tiempo y espacio de interacción del ciudadano con las
entidades públicas y reduciendo los plazos y costos para acceder a
información, todo lo cual es posible mediante el gobierno electrónico.
En este contexto, la demanda del ciudadano por más y mejores
servicios y las medidas en materia de simplificación administrativa y
transparencia emprendidas por el gobierno para la mejora de los servicios
han llevado a que el gobierno electrónico sea un canal para introducir
cambios en las formas de acceso de los ciudadanos a la información y la
prestación de los servicios de manera descentralizada e integrada. Este
canal además puede ser utilizado para una rendición de cuentas adecuada.
El servicio de atención al ciudadano de la administración pública
resulta importante porque:
ü Es un punto de contacto de las políticas y reglas gubernamentales
con el ciudadano. Las instituciones están presentes donde éste
más lo necesita, descentralizando sus oficinas y/o utilizando
tecnologías de la información (teléfono, email y/o Internet), con el
gobierno electrónico como máxima expresión.
ü Los ciudadanos pagan impuestos para sustentar los servicios que
las instituciones prestan esperando una efectiva atención de
éstas.
ü Un servicio de calidad toma en cuenta las necesidades del
ciudadano. Busca alcanzar o superar los estándares de atención
de las empresas privadas en calidad de servicio y satisfacción del
cliente, estando siempre a su disposición, simplificando procesos
y optimizando costos.
ü Las instituciones buscan al ciudadano para servirlo, incluyendo a
los relegados, geográfica y/o económicamente, informándolos,
educándolos y orientándolos para su desarrollo.
ü El rediseño en procesos que buscan mejorar la atención a los
ciudadanos, por lo general, permite optimizar el uso de los
recursos y elevar el nivel de eficiencia de la institución, así como
sus indicadores económicos y financieros. Una entidad
responsable y efectiva en la prestación de servicios crea
ciudadanos satisfechos generando bases para legitimar sus
gestiones.
ü La satisfacción de los ciudadanos con los servicios que reciben de
las instituciones contribuye a la mejora de la imagen de la entidad,
lo que a su vez tiene un impacto positivo en el clima
organizacional interno.
“Ciudadanos al día” recoge tres modelos que pretenden explicar las
relaciones entre el Estado y la ciudadanía. El primero, conocido como el
modelo del cliente, presenta a los ciudadanos como consumidores de los
servicios del Estado, esto es, como clientes de servicios gubernamentales
de calidad. El segundo modelo centrado en el costo del Estado para el
contribuyente anima a los ciudadanos a verse a sí mismos como
inversionistas que están destinando parte de su dinero a financiar la
actividad del aparato estatal y que tienen derecho a exigir resultados a
cambio. El tercero, llamado el modelo del socio o del ciudadano votante o
elector, insiste más bien en la responsabilidad que éstos tienen de tomar un
rol activo en el diseño de las políticas públicas, por lo cual promueve
mecanismos de participación ciudadana. Esto se puede apreciar en la
siguiente tabla:
CUADRO 6: TIPOS DE SERVICIOS GUBERNAMENTALES
Fuente: Ciudadanos al Día, Manual de Buenas Prácticas Gubernamentales
2006, Lima, 2006
3.1.14. Normas del Sistema Nacional de Archivo aplicadas a
Municipalidades
Los gobiernos locales son las primeras células de organización social, donde
confluye el vecino con su municipio y dentro de esta simbiosis encontramos los
archivos como sustento de la gestión y facilitadotes de la información que el
vecino requiere.
Asimismo, los gobiernos locales están sujetos a los sistemas administrativos
del Estado que por su naturaleza son de observancia y cumplimiento
obligatorio.
En este contexto ubicamos la normatividad del Sistema Nacional de Archivo,
expresado en el “ Manual de Procedimientos para Municipalidades” .
El manual de procedimientos es una herramienta que sirve como soporte
técnico operativo en la ejecución de las actividades archivísticas en las
municipalidades y su aplicación depende de la decisión en parte de
autoridades y funcionarios pero básicamente del responsable de Archivo.
El Manual de Procedimientos es un instrumento de Gestión Archivística que ha
sido elaborado teniendo en consideración la normatividad vigente aprobada por
el Archivo General de la Nación y tiene como objetivo impartir instrucciones
sobre los procedimientos que se aplicarán en los procesos archivísticos con la
finalidad de optimizar el tratamiento de los documentos de Archivo en los
procesos de Transferencia, Organización, Eliminación y Servicio, dando un
principio de unidad, racionalidad y eficiencia en los diferentes niveles de
Archivo de la Municipalidad. Comprende los procedimientos:
De transferencia de documentos.
De organización documental.
De eliminación documental
De servicio de información.
3.1.15. Ley de Procedimiento Administrativo General, Ley N° 27444
Esta Ley regula las actuaciones de la función administrativa del
Estado y el procedimiento administrativo común desarrollados en las entidades
y tiene la finalidad de establecer el régimen jurídico aplicable para que la
actuación de la Administración Pública sirva a la protección del interés general,
garantizando los derechos e intereses de los administrados y con sujeción al
ordenamiento constitucional y jurídico en general.
El procedimiento administrativo se sustenta fundamentalmente en los
siguientes principios, sin perjuicio de la vigencia de otros principios generales
del Derecho Administrativo:
• Principio de legalidad. Las autoridades administrativas deben actuar con
respeto a la Constitución, la ley y al derecho, dentro de las facultades
que le estén atribuidas y de acuerdo con los fines para los que les fueron
conferidas.
• Principio del debido procedimiento. Los administrados gozan de todos
los derechos y garantías inherentes al debido procedimiento
administrativo, que comprende el derecho a exponer sus argumentos, a
ofrecer y producir pruebas y a obtener una decisión motivada y fundada
en derecho. La institución del debido procedimiento administrativo se
rige por los principios del Derecho Administrativo. La regulación propia
del Derecho Procesal Civil es aplicable sólo en cuanto sea compatible
con el régimen administrativo.
• Principio de impulso de oficio. Las autoridades deben dirigir e impulsar
de oficio el procedimiento y ordenar la realización o práctica de los actos
que resulten convenientes para el esclarecimiento y resolución de las
cuestiones necesarias.
• Principio de razonabilidad. Las decisiones de la autoridad
administrativa, cuando creen obligaciones, califiquen infracciones,
impongan sanciones, o establezcan restricciones a los administrados,
deben adaptarse dentro de los límites de la facultad atribuida y
manteniendo la debida proporción entre los medios a emplear y los fines
públicos que deba tutelar, a fin de que respondan a lo estrictamente
necesario para la satisfacción de su cometido.
• Principio de imparcialidad . Las autoridades administrativas actúan sin
ninguna clase de discriminación entre los administrados, otorgándoles
tratamiento y tutela igualitarios frente al procedimiento, resolviendo
conforme al ordenamiento jurídico y con atención al interés general.
• Principio de informalismo . Las normas de procedimiento deben ser
interpretadas en forma favorable a la admisión y decisión final de las
pretensiones de los administrados, de modo que sus derechos e
intereses no sean afectados por la exigencia de aspectos formales que
puedan ser subsanados dentro del procedimiento, siempre que dicha
excusa no afecte derechos de terceros o el interés público.
• Principio de presunción de veracidad. En la tramitación del
procedimiento administrativo, se presume que los documentos y
declaraciones formulados por los administrados en la forma prescrita por
esta Ley, responden a la verdad de los hechos que ellos afirman. Esta
presunción admite prueba en contrario.
• Principio de conducta procedimental. La autoridad administrativa, los
administrados, sus representantes o abogados y, en general, todos los
partícipes del procedimiento, realizan sus respectivos actos
procedimentales guiados por el respeto mutuo, la colaboración y la
buena fe. Ninguna regulación del procedimiento administrativo puede
interpretarse de modo tal que ampare alguna conducta contra la buena
fe procesal.
• Principio de celeridad. Quienes participan en el procedimiento deben
ajustar su actuación de tal modo que se dote al trámite de la máxima
dinámica posible, evitando actuaciones procesales que dificulten su
desenvolvimiento o constituyan meros formalismos, a fin de alcanzar una
decisión en tiempo razonable, sin que ello releve a las autoridades del
respeto al debido procedimiento o vulnere el ordenamiento.
• Principio de eficacia. Los sujetos del procedimiento administrativo deben
hacer prevalecer el cumplimiento de la finalidad del acto procedimental,
sobre aquellos formalismos cuya realización no incida en su validez, no
determinen aspectos importantes en la decisión final, no disminuyan las
garantías del procedimiento, ni causen indefensión a los administrados.
• En todos los supuestos de aplicación de este principio, la finalidad del
acto que se privilegie sobre las formalidades no esenciales deberá
ajustarse al marco normativo aplicable y su validez será una garantía de
la finalidad pública que se busca satisfacer con la aplicación de este
principio.
• Principio de verdad material. En el procedimiento, la autoridad
administrativa competente deberá verificar plenamente los hechos que
sirven de motivo a sus decisiones, para lo cual deberá adoptar todas las
medidas probatorias necesarias autorizadas por la Ley, aun cuando no
hayan sido propuestas por los administrados o hayan acordado eximirse
de ellas.
• En el caso de procedimientos trilaterales la autoridad administrativa
estará facultada a verificar por todos los medios disponibles la verdad de
los hechos que le son propuestos por las partes, sin que ello signifique
una sustitución del deber probatorio que corresponde a éstas. Sin
embargo, la autoridad administrativa estará obligada a ejercer dicha
facultad cuando su pronunciamiento pudiera involucrar también al interés
público.
• Principio de participación. Las entidades deben brindar las condiciones
necesarias a todos los administrados para acceder a la información que
administren, sin expresión de causa, salvo aquellas que afectan la
intimidad personal, las vinculadas a la seguridad nacional o las que
expresamente sean excluidas por Ley; y extender las posibilidades de
participación de los administrados y de sus representantes, en aquellas
decisiones públicas que les puedan afectar, mediante cualquier sistema
que permita la difusión, el servicio de acceso a la información y la
presentación de opinión.
• Principio de simplicidad. Los trámites establecidos por la autoridad
administrativa deberán ser sencillos, debiendo eliminarse toda
complejidad innecesaria; es decir, los requisitos exigidos deberán ser
racionales y proporcionales a los fines que se persigue cumplir.
• Principio de uniformidad. La autoridad administrativa deberá establecer
requisitos similares para trámites similares, garantizando que las
excepciones a los principios generales no serán convertidos en la regla
general. Toda diferenciación deberá basarse en criterios objetivos
debidamente sustentados.
• Principio de predictibilidad. La autoridad administrativa deberá brindar a
los administrados o sus representantes información veraz, completa y
confiable sobre cada trámite, de modo tal que a su inicio, el administrado
pueda tener una conciencia bastante certera de cual será el resultado
final que se obtendrá.
• Principio de privilegio de controles posteriores. La tramitación de los
procedimientos administrativos se sustentará en la aplicación de la
fiscalización posterior; reservándose la autoridad administrativa, el
derecho de comprobar la veracidad de la información presentada, el
cumplimiento de la normatividad sustantiva y aplicar las sanciones
pertinentes en caso que la información presentada no sea veraz.
3.1.16. Ley de Transparencia y acceso a la información pública, Nº 27806
El Estado peruano tiene una Ley que faculta el acceso de cualquier
ciudadano a la información pública: Ley de Transparencia y Acceso a la
Información Pública Nº 27806 del 2002. Este acceso a la información tiene
dos mecanismos:
a) El derecho a solicitar información y
b) La obligación de publicar información mediante la instalación de portales
Internet institucionales y/o su difusión mediante diarios y reportes periódicos.
Gracias a esta Ley el Perú ha dado un importante paso, contando no
solo con un derecho humano, sino además con una herramienta para la
vigilancia de la gestión del Estado. Hoy en día, la ciudadanía tiene un medio
para hacer frente a la "cultura del secreto de la gestión pública" que apaña las
malversaciones de fondos. Vale subrayar que el incumplimiento de esta
obligación por las entidades públicas es sancionado como falta grave e
incluso pueden ser denunciadas penalmente por abuso de autoridad.
Sin embargo, ante una solicitud de información, la experiencia nos indica que
existen serios problemas de cumplimiento: no hay funcionario responsable, no
se da la información completa, la información es distinta a la solicitada y la
información brindada está fuera de los plazos de ley. Esto plantea una
necesidad de correctivos.
Todas las entidades públicas (a nivel nacional, regional y local) están
obligadas progresivamente, de acuerdo a su presupuesto, a tener un portal
Internet de transparencia, teniendo éste como ventaja la reducción de los
costos de transacción para el ciudadano que requiere información, lo que, a la
vez, democratiza la información.
El acceso a la información pública se sujeta al siguiente
procedimiento:
a) Toda solicitud de información debe ser dirigida al funcionario designado por
la entidad de la Administración Pública para realizar esta labor. En caso de que
éste no hubiera sido designado, la solicitud se dirige al funcionario que tiene en
su poder la información requerida o al superior inmediato.
b) La entidad de la Administración Pública a la cual se haya presentado la
solicitud de información deberá otorgarla en un plazo no mayor de 7 (siete) días
útiles; plazo que se podrá prorrogar en forma excepcional por cinco (5) días
útiles adicionales, de mediar circunstancias que hagan inusualmente difícil
reunir la información solicitada. En este caso, la entidad deberá comunicar por
escrito, antes del vencimiento del primer plazo, las razones por las que hará
uso de tal prórroga.
En el supuesto de que la entidad de la Administración Pública no posea la
información solicitada y de conocer su ubicación y destino, esta circunstancia
deberá ser puesta en conocimiento del solicitante.
c) La denegatoria al acceso a la información se sujeta a lo dispuesto en el
segundo párrafo del Artículo 13 de la Ley.
d) De no mediar respuesta en los plazos previstos en el inciso b), el solicitante
puede considerar denegado su pedido.
e) En los casos señalados en los incisos c) y d) del presente artículo, el
solicitante puede considerar denegado su pedido para los efectos de dar por
agotada la vía administrativa, salvo que la solicitud haya sido cursada a un
órgano sometido a superior jerarquía, en cuyo caso deberá interponer el
recurso de apelación para agotarla.
f) Si la apelación se resuelve en sentido negativo, o la entidad correspondiente
no se pronuncia en un plazo de diez (10) días útiles de presentado el recurso,
el solicitante podrá dar por agotada la vía administrativa.
g) Agotada la vía administrativa, el solicitante que no obtuvo la información
requerida podrá optar por iniciar el proceso contencioso administrativo, de
conformidad con lo señalado en la Ley Nº 27584 u optar por el proceso
constitucional del Hábeas Data, de acuerdo a lo señalado por la Ley Nº 26301.
3.2. Definición conceptual terminológica
3.2.1. Sistema de Gestión documentaria
Para esta investigación el Sistema de gestión documentaia es un software
elaborado en Visual Basic 2005 con SQL Server 2005 que soporta la
captura, almacenamiento, clasificación, consulta, búsqueda, y distribución
de documentos de la Municipalidad Distrital de Jayanca, salvaguardando
sus características estructurales, y contextuales, y garantizando su
autenticidad y veracidad y basado en la normatividad peruana aplicable para
la Municipalidad.
Figura 5: Modelo del sistema de Gestión Documentaria para la Municipalidad
Distrital de Jayanca
Fuente: Elaboración propia.
Antes de proceder a la elaboración de este sistema se determinaron
las series y grupos documentales más relevantes que se encuentran
disponibles y la identificación y categorización de la producción documental
de la Municipalidad distrital de Jayanca, basados en la Normatividad del
Archivo general de la Nación, para lo cual se utilizó el formato recomendado
que se muestra en el anexo 3 Formato de series y grupos documentales.
3.2.2. Seguridad del sistema
La Seguridad de la Información hoy día no es sólo un aspecto
tecnológico, por el contrario, es una solución integrada de negocio que
combina recursos organizacionales, procesos y tecnología. Si no se
cuenta con reglas, lineamientos, responsabilidades y procedimientos
predefinidos, y ante la ausencia de personal que es capacitado para la
gestión del proceso, la inversión en tecnología solamente no es más
que una pérdida de dinero. Este concepto de Seguridad de la
La información se localiza rápidamente
Entrada de documentos
Queda registrado que información es
modificada, anulada o agregada
Escáner
Se evita el acceso de personal no autorizado
Consultas
La información se almacena de
manera estructurada
Las copias de seguridad evitan las pérdidas de
información
Cada jefe de área accede a la información que
necesita. BASE DE DATOS
Modelo del sistema de Gestión Documentaria para la Municipalidad Distrital de Jayanca
Información como una solución integral es esencial para la
transformación de este nuevo enfoque, en una plataforma tangible,
pragmática y operativa de seguridad, que brinde resultados
cuantificables para el negocio.
De acuerdo a lo analizado, para esta investigación la seguridad del
sistema estará basada en función a las mejores prácticas que plantea
Microsoft en sus directivas de seguridad: Autenticación (identificación
segura), autorización (acceso a ciertas funcionalidades),
comunicación segura, auditoria y administración de perfiles.
Estos aspectos y su tratamiento serán detallados en el capítulo
siguiente: Desarrollo de la propuesta.
3.2.3. Aspecto sobre digitalización
La digitalización es el proceso mediante el cual la imagen de una
página (ya sea el anverso o el reverso) es capturada.
Como se ha visto anteriormente, las imágenes digitales son fotos
electrónicas tomadas de una escena o escaneadas de documentos
fotografías, manuscritos, textos impresos e ilustraciones.
Respecto a los formatos de archivos digitales, para esta
investigación se ha decidido digitalizar los documentos y ser almacenados en formato PD, por ser considerado recientemente como estándar
internacional y ser preferido para imprimir y ver documentos de páginas
múltiples, de acuerdo a lo que se indica en el cuadro antes mostrado sobre
formatos de archivo de imágenes comunes, visto en la sección anterior.
Asimismo, respecto a la Resolución, que es el término usado para
definir el número de pixeles o puntos (dots) que se capturan por pulgada de
papel (dots per inch: dpi), una resolución de 200 dpi es la adecuada para
desplegar con claridad tipografías de hasta 7 puntos. Por tanto, 200 dpi es
la resolución a la que la mayoría de los documentos serán digitalizados en
la Municipalidad.
Sin embargo, documentos con tipografías más finas u otros detalles
requerirán una mayor resolución, aunque será muy poco frecuente.
• Dispositivo de digitalización
La tecnología de digitalización comprende básicamente el ingreso de
los documentos; mediante el scanner; en la unidad de trámite documentario
de la Municipalidad distrital de Jayanca.
Encontramos una variedad de escáner que son utilizados para el
tratamiento de documentos, el análisis de los equipos con que se cuenta en
dicha oficina, resultan ser suficientes para llevar a cabo el ingreso de los
documentos al servidor de archivos. El equipo de escaneo con que cuenta
la Municipalidad es un escáner digital de superficie plana HP scanjet 2400,
cuyas características se mencionan en el siguiente cuadro:
CUADRO 7: CARACTERÍSTICAS DEL SCANNER HP SCANJET 2400 DE LA
MUNICIPALIDAD DISTRITAL DE JAYANCA
DATOS BÁSICOS
Modelo: HP scanjet 2400 Tipo de digitalización: Superficie plana Resolución de exploración por hardware: 1200x1200ppp Profundidad de bits: 48 bits. Velocidad de digitalización en modo de presentación preliminar: 12 seg. Conectividad estándar: USB Tipos de soporte admitidos: Papel (normal, inyección de tinta, prensa, artículos de revista), transparencias, objetos tridimensionales.
Resolución de exploración mejorada Resolución mejorada ilimitada
Niveles de escala de grises 256
INFORMACIÓN TÉCNICA ADICIONAL
Formato del archivo de digitalización Windows: BMP, JPEG, TIFF, TIFF comprimido, PNG, PCX, Flashpix (FPX), PDF, PDF buscable, RTF, HTM, TXT; Macintosh: TIFF, PICT, JPEG, GIF, FlashPix, Texto sin Formato PDF, HTML, Rich Text
Fuente: Manual de uso y especificaciones técnicas HP ScanJet 2400
De las características presentadas, podemos deducir que son
suficientes para el proceso de captura de los documentos.
3.2.4. Usuario:
Basándonos en la definición que presenta la Norma Técnica Peruana
NTPISO/IEC 12207, Tecnología de la información, Procesos del ciclo de
vida del software, definimos al usuario como la persona natural o jurídica
que utiliza el sistema de gestión documentaria para un fin específico:
consultar estado de documento, emitir documento a la Municipalidad
Distrital de Jayanca y recibir una respuesta de atención a este documento.
3.2.5. Atención al usuario
En esta investigación se tomará en cuenta el servicio Directo en el
modelo ciudadanocliente, basado en el Manual de Buenas prácticas
gubernamentales (BPGs) 2006.
Esto implica servicios concretos: El usuario no debe hacer colas, brindarle
un buen trato, una atención de calidad, agilizar los trámites, brindar
información oportuna, rendir cuentas.
Las BPGs en Servicio de Atención al Ciudadano buscan que éste sea el
elemento esencial del proceso administrativo en el sector público y que su
bienestar sea el principio fundamental del servidor público, siguiendo el
principio de servicio al cliente. Ello implica un cambio de mentalidad en los
funcionarios y, en la mayoría de casos, el rediseño de procesos para la
comodidad y facilidad de acceso de los ciudadanos a los servicios. En este
aspecto constituye un elemento de suma importancia la atención
personalizada utilizando tecnologías de información y la difusión de
información para el ciudadano sobre el quehacer institucional por todos los
canales disponibles.
CAPITULO IV: MARCO CONCEPTUAL
4.1. Metodologías de desarrollo de sistemas
Existen varias metodologías para el desarrollo de sistemas y algunas surgen de
combinaciones de otras. En la investigación se tomarán sólo las metodologías
basadas en UML.
No se trata de elegir cual es la mejor, porque todas contribuyen con ideas
importantes para el desarrollo de un sistema, sino más bien cual de ellas se
adapta a una situación determinada.
A continuación se presentan las características más relevantes de las
metodologías mas utilizadas basadas en UML:
4.1.1. Metodología RUP
El Proceso Unificado de Rational es un proceso de ingeniería del
software. Proporciona un acercamiento disciplinado a la asignación de tareas y
responsabilidades en una organización de desarrollo. Su propósito es asegurar
la producción de software de alta calidad que se ajuste a las necesidades de
sus usuarios finales con unos costos y un calendario predecibles.
En definitiva, el RUP es una metodología de desarrollo de software que intenta
integrar todos los aspectos a tener en cuenta durante todo el ciclo de vida del
software, con el objetivo de hacer abarcables tanto pequeños como grandes
proyectos software.
Las características principales de RUP son:
• Puede ser adaptado y extendido para satisfacer las necesidades de la
organización que lo adopte.
• Es guiado por casos de uso
• Es centrado en la arquitectura.
• Es iterativo e incremental.
• Utiliza UML como lenguaje de notación.
• Captura muchas de las “mejores prácticas” del desarrollo de software
moderno, por ejemplo: SCM, internal/external reviews, PM, risk
management, QA, prototipos, iterativo e incremental, etc.
4.1.2. Metodología ICONIX
ICONIX es una metodología simple que se le puede ubicar entre RUP y
la metodología XP.
Es guiado por casos de uso, como RUP, pero no posee todo la
plataforma de RUP.
Es relativamente pequeño, pero no descarta las notaciones de análisis y
diseño.
ICONIX es minimalista y se focaliza en el área que queda entre los
casos de uso y el código.
Los 3 elementos fundamentales de ICONIX son:
• Es iterativo e incremental.
• En cada paso hay una referencia a los requerimientos.
• Hace un uso estilizado de UML.
4.1.3. Metodología OOSP (ObjectOriented Software Process)
Está formada por una colección de “process patterns”. Un process
pattern es a su vez una colección de técnicas genéricas, acciones y/o tareas
que solucionan un problema específico de procesos de software considerando
las fuerzas y factores del problema.
• Phase process pattern: determina las iteracciones entre los “stage
process patterns” dentro de una fase del proceso.
• Stage process pattern: determina las tareas, usualmente llevadas a
cabo en forma iterativa, dentro de una stage del proceso.
• Task process pattern: da soluciones probadas para problemas de bajo
nivel dentro de cada stage.
Los “process patterns” describen lo que se debe hacer pero no los
detalles exactos de cómo hacerlo. Son bloques reusables a partir de los cuales
se configura un modelo de proceso de software que se encuadre en las
necesidades particulares de la organización.
4.2. Comparación de metodologías
Para efectuar la comparación de metodologías se tomó en cuenta tres aspectos
importantes antes de elegir una metodología de desarrollo de sistemas:
4.2.1. Características del proyecto.
• Tamaño esperado del proyecto.
• Tamaño del equipo de desarrollo.
• Complejidad del problema a resolver
CUADRO 8: COMPARACIÓN DE METODOLOGÍAS SEGÚN CARACTERÍSTICAS
DEL PROYECTO
METODOLOGÍA Tamaño del proyecto
Tamaño del equipo
Complejidad del problema
RUP Mediano/Grande Mediano/Grande Mediana/Alta
ICONIX Pequeño/Mediano Pequeño/Mediano Baja/Mediana
OOSP Mediano/Grande Mediano/Grande Mediana/Alta
Fuente: Pragma Consultores: ¿Agile o Unified? – UBA – Noviembre 2004
4.2.2. Requerimientos
• Curva de aprendizaje: ¿Cuanto le toma a una organización incorporar
el conocimiento necesario para aplicar correctamente el modelo?
• Herramientas: ¿Existen herramientas que den soporte a las
actividades que hay que realizar?
• Soporte externo: ¿Existe en el mercado soporte para adoptar el
modelo?
CUADRO 9: COMPARACIÓN DE METODOLOGÍAS SEGÚN REQUERIMIENTOS
METODOLOGÍA Curva de aprendizaje Herramientas Soporte
externo
RUP Lento Altamente soportadas Altamente
ICONIX Rápido Algunas disponibles
Algunas disponibles
OOSP Lento No se menciona No disponible
Fuente: Pragma Consultores: ¿Agile o Unified? – UBA – Noviembre 2004
CUADRO 10: PONDERACIONES ASIGNADAS SEGÚN CRITERIOS DE
ELECCIÓN DE METODOLOGÍA
CRITERIO DETALLE PONDERACIÓN
Tamaño del proyecto
Pequeño/Mediano Mediano/Grande
0 5
Tamaño del equipo
Pequeño/Mediano Mediano/Grande
0 5
Características del proyecto
Complejidad del problema
Baja/Mediana Mediana/Alta
0 5
Curva de aprendizaje
Lento Rápido
0 5
Herramientas No se menciona Algunas disponibles Altamente soportadas
02.55
Requerimientos
Soporte externo No disponible Algunas disponibles Altamente
02.55
Fuente: Elaboración propia
CUADRO 11: CRITERIOS DE SELECCIÓN Y PUNTUACIONES SEGÚN
METODOLOGÍA CRITERIO DETALLE RUP ICONIX OOSP
Tamaño del proyecto 5 0 5
Tamaño del equipo 5 0 5 Características del proyecto
Complejidad del problema 5 0 5
Curva de aprendizaje 0 5 0
Herramientas 5 2.5 0 Requerimientos
Soporte externo 5 2.5 0
TOTAL 25 10 15
Fuente: Elaboración propia
Dado el escenario que se presenta se eligió utilizar la metodología RUP.
4.3. Metodología elegida
4.3.1. Definición
La metodología RUP, llamada así por sus siglas en inglés
Rational Unified Process, es un proceso de ingeniería del software.
Proporciona un acercamiento disciplinado a la asignación de tareas y
responsabilidades en una organización de desarrollo. Su propósito es
asegurar la producción de software de alta calidad que se ajuste a las
necesidades de sus usuarios finales con unos costos y un calendario
predecibles.
4.3.2. Fases de la Metodología RUP
La metodología RUP divide en 4 fases el desarrollo del software:
• Inicio: Antes de iniciar un proyecto es conveniente plantearse
algunas cuestiones: ¿Cuál es el objetivo? ¿Es factible? ¿Lo
construimos o lo compramos? ¿Cuánto va a costar? La fase de
inicio trata de responder a estas preguntas y a otras más. Sin
embargo no pretendemos una estimación precisa o la captura de
todos los requisitos. Más bien se trata de explorar el problema lo
justo para decidir si vamos a continuar o a dejarlo. Generalmente no
debe durar mucho más de una semana. El Objetivo en esta etapa
es determinar la visión del proyecto.
• Elaboración: El propósito de la fase de elaboración es analizar el
dominio del problema, establecer los cimientos de la arquitectura,
desarrollar el plan del proyecto y eliminar los mayores riesgos.
Cuando termina esta fase se llega al punto de no retorno del
proyecto: a partir de ese momento pasamos de las relativamente
ligeras y de poco riesgo dos primeras fases, a afrontar la fase de
construcción, costosa y arriesgada. Es por esto que la fase de
elaboración es de gran importancia.
En esta fase se construye un prototipo de la arquitectura, que debe
evolucionar en iteraciones sucesivas hasta convertirse en el sistema
final. Este prototipo debe contener los casos de uso críticos
identificados en la fase de inicio. También debe demostrarse que se
han evitado los riesgos más graves, bien con este prototipo, bien
con otros de usar y tirar. En esta etapa el objetivo es determinar la
arquitectura óptima.
• Construcción: La finalidad principal de esta fase es alcanzar la
capacidad operacional del producto de forma incremental a través
de las sucesivas iteraciones. Durante esta fase todas los
componentes, características y requisitos, que no lo hayan sido
hecho hasta ahora, han de ser implementados, integrados y
probados, obteniéndose una versión del producto que se pueda
poner en manos de los usuarios (una versión beta). El énfasis en
esta fase se pone controlar las operaciones realizadas,
administrando los recursos eficientemente, de tal forma que se
optimicen los costes, los calendarios y la calidad.
• Transición: La finalidad de la fase de transición es poner el
producto en manos de los usuarios finales, para lo que típicamente
se requerirá desarrollar nuevas versiones actualizadas del producto,
completar la documentación, entrenar al usuario en el manejo del
producto y, en general, tareas relacionadas con el ajuste,
configuración, instalación y usabilidad del producto.
Cada una de estas etapas es desarrollada mediante el ciclo de
iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a
menor escala. Los Objetivos de una iteración se establecen en función
de la evaluación de las iteraciones precedentes. Cabe mencionar que
el ciclo de vida que se desarrolla por cada iteración, es llevada bajo dos
disciplinas:
Disciplina de Desarrollo
• Ingeniería de Negocios: Entendiendo las necesidades del negocio.
• Requerimientos: Trasladando las necesidades del negocio a un
sistema automatizado.
• Análisis y Diseño: Trasladando los requerimientos dentro de la
arquitectura de software.
• Implementación: Creando software que se ajuste a la arquitectura y
que tenga el comportamiento deseado.
• Pruebas: Asegurándose que el comportamiento requerido es el
correcto y que todo los solicitado esta presente.
Disciplina de Soporte
• Configuración y administración del cambio: Guardando todas las
versiones del proyecto.
• Administrando el proyecto: Administrando horarios y recursos.
• Ambiente: Administrando el ambiente de desarrollo.
• Distribución: Hacer todo lo necesario para la salida del proyecto
Figura 6: Fases, flujos de trabajo e iteraciones de la metodología RUP
Fuente: Pragma Consultores: ¿Agile o Unified? – UBA – Noviembre 2004
Es recomendable que a cada una de estas iteraciones se les clasifique
y ordene según su prioridad, y que cada una se convierta luego en un
entregable al cliente. Esto trae como beneficio la retroalimentación que
se tendría en cada entregable o en cada iteración.
4.3.3. RUP, Metodología basada en UML
Puesto que la metodología RUP está basada en UML, se tratará de
resumir los aspectos que involucra este lenguaje de modelado.
El UML es un lenguaje de modelado cuyo vocabulario y sintaxis están
ideados para la representación conceptual y física de un sistema. Sus modelos
son precisos, no ambiguos, completos y pueden ser trasladados directamente a
una gran variedad de lenguajes de programación , como Java, C++ o Visual
Basic, pero también a tablas de bases de datos relacionales y orientadas a
objetos. Es posible generar código a partir de un modelo UML (ingeniería
directa) y también puede construirse un modelo a partir de la implementación
(ingeniería inversa), aunque en las dos situaciones debe intervenir un mayor o
menor grado de supervisión por parte del programador, en función de lo buenas
que sean las herramientas empleadas.
Los bloques básicos de construcción de UML son tres, los elementos, las
relaciones y los diagramas.
• Los elementos son abstracciones que actúan como unidades
básicas de construcción. Hay cuatro tipos, los estructurales, los de
comportamiento, los de agrupación y los de notación. En cuanto a los
elementos estructurales son las partes estáticas de los modelos y
representan aspectos conceptuales o materiales. Los elementos de
comportamiento son las partes dinámicas de los modelos y
representan comportamientos en el tiempo y en el espacio. Los
elementos de agrupación son las partes organizativas de UML,
establecen las divisiones en que se puede fraccionar un modelo. Sólo
hay un elemento de agrupación, el paquete, que se emplea para
organizar otros elementos en grupos. Los elementos de notación son
las partes explicativas de UML, comentarios que pueden describir
textualmente cualquier aspecto de un modelo. Sólo hay un elemento
de notación principal, la nota.
CUADRO 12: ELEMENTOS DE CONSTRUCCIÓN EN UML
Clase
Describe un conjunto de objetos que comparten los mismos atributos, métodos, relaciones y semántica. Las clases implementan una o más interfaces.
Clase activa Se trata de una clase, en la que existe procesos o
hilos de ejecución concurrentes con otros elementos. Las líneas del contorno son más gruesas que en la clase “normal”
Interfa
z
Agrupación de métodos u operaciones que especifican un servicio de una clase o componente, describiendo su comportamiento, completo o parcial, externamente visible. UML permite emplear un círculo para representar las interfaces, aunque lo más normal es emplear la clase con el nombre en cursiva.
Colabor
ación
Define una interacción entre elementos que cooperan para proporcionar un comportamiento mayor que la suma de los comportamientos de sus elementos.
Caso de
uso
Describe un conjunto de secuencias de acciones que un sistema ejecuta, para producir un resultado observable de interés. Se emplea para estructurar los aspectos de comportamiento de un modelo.
E L E M E N T O S
E S T R U C T U R A L E S
Com
ponente
Parte física y por tanto reemplazable de un modelo, que agrupa un conjunto de interfaces, archivos de código fuente, clases, colaboraciones y proporciona la implementación de dichos elementos.
Nodo
Elemento físico que existe en tiempo de ejecución y representa un recurso computacional con capacidad de procesar.
Interacción Comprende un conjunto de mensajes que se
intercambian entre un conjunto de objetos, para cumplir un objetivo especifico.
Elementos de
Comporta miento
Máquinas
de
Estados Especifica la secuencia de estados por los que pasa
un objeto o una interacción, en respuesta a eventos.
Elementos de
agrupación Paquete Se emplea para organizar otros elementos en
grupos.
Elementos de
notación Nota
Partes explicativa de UML, que puede describir textualmente cualquier aspecto del modelo
Fuente: Arregui, M., Grupo Iris (Integración y Reingeniería de Sistemas), Universitat Jaume I, Castellón, Tutorial de UML, España, 2004.
• Las relaciones son abstracciones que actúan como unión entre los
distintos elementos. Hay cuatro tipos, la dependencia, la asociación,
la generalización y la realización.
CUADRO 13: ELEMENTOS DE RELACIÓN EN UML
Dependencia Es una relación entre dos elementos, tal que un cambio en uno puede afectar al otro.
Asociación Es una relación estructural que resume un conjunto de enlaces que son conexiones entre objetos.
Generaliza ción
Es una relación en la que el elemento generalizado puede ser substituido por cualquiera de los elementos hijos, ya que comparten su estructura y comportamiento.
Realización Es una relación que implica que la parte realizante cumple con una serie de especificaciones propuestas por la clase realizada (interfaces).
Fuente: Arregui, M., Grupo Iris (Integración y Reingeniería de Sistemas), Universitat Jaume I, Castellón, Tutorial de UML, España, 2004.
• Los diagramas son la disposición de un conjunto de elementos, que
representan el sistema modelado desde diferentes perspectivas. UML
tiene nueve diagramas fundamentales, agrupados en dos grandes
grupos, uno para modelar la estructura estática del sistema y otro
para modelar el comportamiento dinámico. Los diagramas estáticos
son: el de clases, de objetos, de componentes y de despliegue. Los
diagramas de comportamiento son: el de Casos de Uso, de
secuencia, de colaboración, de estados y de actividades.
CUADRO 14: DIAGRAMAS EN UML
Clases
Muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones, cubriendo la vista de diseño estática del sistema.
Obje
tos
Análogo al diagrama de clases, muestra un conjunto de objetos y sus relaciones, pero a modo de vista instantánea de instancias de una clase en el tiempo.
Com
ponentes Muestra la organización y dependencias de un
conjunto de componentes. Cubren la vista de implementación estática de un sistema. Un componente es un módulo de código, de modo que los diagramas de componentes son los análogos físicos a los diagramas de clases.
M O D E L A N
E S T R U C T U R A D
espliegue
Muestra la configuración del hardware del sistema, los nodos de proceso y los componentes empleados por éstos. Cubren la vista de despliegue estática de una arquitectura.
Casos de Uso Muestra un conjunto de casos de uso, los actores
implicados y sus relaciones. Son diagramas fundamentales en el modelado y organización del sistema.
Secuencia
Colaboración
Son diagramas de interacción, muestran un conjunto de objetos y sus relaciones, así como los mensajes que se intercambian entre ellos. Cubren la vista dinámica del sistema. El diagrama de secuencia resalta la ordenación temporal de los mensajes, mientras que el de colaboración resalta la organización estructural de los objetos, ambos siendo equivalentes o isomorfos. En el diagrama de colaboración de la figura de la izquierda, se puede ver que los elementos gráficos no son cajas rectangulares, como cabría esperar, y en su lugar encontramos sus versiones adornadas. Estas versiones tienen como finalidad evidenciar un rol específico del objeto siendo modelado. En la figura encontramos de izquierda a derecha y de arriba abajo un Actor, una Interfaz, un Control (modela un comportamiento) y una Instancia (modela un objeto de dato).
Estados Muestra una máquina de estados, con sus estados,
transiciones, eventos y actividades. Cubren la vista dinámica de un sistema. Modelan comportamientos reactivos en base a eventos.
M O D E L A N
C O M P O R T A M I E N T O
Actividades Tipo especial de diagrama de estados que muestra el
flujo de actividades dentro de un sistema.
Fuente: Arregui, M., Grupo Iris (Integración y Reingeniería de Sistemas), Universitat Jaume I, Castellón, Tutorial de UML, España, 2004.
4.3.4. RUP y las mejores prácticas para el desarrollo de software
El Proceso Unificado de Rational (RUP) describe como aplicar
efectivamente enfoques comprobados comercialmente para el desarrollo de
software. Estos enfoques son llamados "mejores prácticas" pues son utilizados
en la industria por organizaciones exitosas.
RUP provee a cada miembro del equipo de las guías de proceso,
plantillas y mentores de herramientas necesarios para que el equipo completo
tome ventaja de, entre otras, las siguientes mejores prácticas:
Figura 7: Mejores prácticas en la metodología RUP
Fuente: Pragma Consultores: ¿Agile o Unified? – UBA – Noviembre 2004
• Desarrollar software iterativamente:
En función de la cada vez mayor complejidad solicitada para los
sistemas de software, ya no es posible trabajar secuencialmente: definir
primero el problema completo, luego diseñar toda la solución, construir el
software y finalmente, testear el producto. Es necesario un enfoque iterativo,
que permita una comprensión creciente del problema a través de refinamientos
sucesivos, llegando a una solución efectiva luego de múltiples iteraciones
acotadas en complejidad.
RUP utiliza y soporta este enfoque iterativo que ayuda a atacar los
riesgos mediante la producción de releases ejecutables progresivos y
frecuentes que permiten la opinión e involucramiento del usuario.
A través de las iteraciones que generan releases ejecutables, se logra
detectar en forma temprana los desajustes e inconsistencias entre los
requerimientos, el diseño, el desarrollo y la implementación del sistema,
manteniendo al team de desarrollo focalizado en producir resultados.
• Administrar los requerimientos
Los requerimientos son las condiciones o capacidades que el sistema
debe conformar. La Administración de Requerimientos es un enfoque
sistemático para hallar, documentar, organizar y monitorear los requerimientos
cambiantes de un sistema.
La Administración de Requerimientos permite:
a) que las comunicaciones estén basadas en requerimientos claramente
definidos,
b) que los requerimientos puedan ser priorizados, filtrados y
monitoreados,
c) que sea posible realizar evaluaciones objetivas de funcionalidad y
performance,
d) que las inconsistencias se detecten más fácilmente RUP describe
como:
• Obtener, organizar y documentar la funcionalidad y restricciones
requeridas
• Documentar y monitorear las alternativas y decisiones
Las nociones de Casos de Uso y de Escenarios utilizadas en RUP han
demostrado ser una manera excelente de capturar los requerimientos
funcionales y asegurarse que direccionan el diseño, la implementación y la
prueba del sistema, logrando así que el sistema satisfaga las necesidades del
usuario.
• Utilizar arquitecturas basadas en componentes
El proceso de software debe focalizarse en el desarrollo temprano de
una arquitectura robusta ejecutable, antes de comprometer recursos para el
desarrollo en gran escala. RUP describe como diseñar una arquitectura flexible,
que se acomode a los cambios, comprensible intuitivamente y promueve una
más efectiva reutilización de software. Soporta el desarrollo de software basado
en componentes: módulos no triviales que completan una función clara. RUP
provee un enfoque sistemático para definir una arquitectura utilizando
componentes nuevos y preexistentes.
• Modelizar software visualmente
RUP muestra como modelar software visualmente para capturar la
estructura y comportamiento de arquitecturas y componentes. Las
abstracciones visuales ayudan a comunicar diferentes aspectos del software;
comprender los requerimientos, ver como los elementos del sistema se
relacionan entre sí, mantener la consistencia entre diseño e implementación y
promover una comunicación precisa. El estándar UML(Lenguaje de Modelado
Unificado), creado por Rational Software, es el cimiento para un modelado
visual exitoso.
• Verificar la calidad de software
Es necesario evaluar la calidad de un sistema respecto de sus
requerimientos de funcionalidad, confiabilidad y performance. La actividad
fundamental es el testing, que permite encontrar las fallas antes de la puesta en
producción. RUP asiste en el planeamiento, diseño, implementación, ejecución
y evaluación de todos estos tipos de testing.
El aseguramiento de la calidad se construye dentro del proceso, en todas
las actividades, involucrando a todos los participantes, utilizando medidas y
criterios objetivos, permitiendo así detectar e identificar los defectos en forma
temprana.
• Controlar los cambios al software
La capacidad de administrar los cambios es esencial en ambientes en
los cuales el cambio es inevitable. RUP describe como controlar, rastrear y
monitorear los cambios para permitir un desarrollo iterativo exitoso. Es también
una guía para establecer espacios de trabajo seguros para cada desarrollador,
suministrando el aislamiento de los cambios hechos en otros espacios de
trabajo y controlando los cambios de todos los elementos de software
(modelos, código, documentos, etc.).
CAPITULO V: DESARROLLO DE LA PROPUESTA
El desarrollo de la propuesta se ha basado en el marco conceptual descrito
anteriormente, es decir de acuerdo a la normatividad del Sistema Nacional de
Archivo aplicadas a Municipalidades, la ley del procedimiento administrativo general
y la ley de transparencia y acceso a la información pública. Se desarrolla la
propuesta basada en el Plan de Desarrollo de Software que se muestra en el anexo
4.
5.1. Fase inicial
5.1.1. Modelado del negocio
El propósito de la fase de inicio es establecer los objetivos para el ciclo
de vida del software a implementar. Durante esta fase se identificarán todos
los actores y casos de uso. Aquí se definirán el modelo del negocio y el
alcance del proyecto, siendo los artefactos desarrollados: el Modelo de Caso
de Uso del Negocio, especificación de los Caso de Uso del Negocio, Modelo
de Objetos del Negocio, Modelo de Dominio del Problema y un glosario con la
terminología clave del dominio del problema.
5.1.1.1. Modelo de casos de uso del negocio (MCUN)
Figura 8: Modelo de casos de uso del negocio Gestión Documentaria de la
Municipalidad Distrital de Jayanca
Administración del s istema Administrador
Jefatura de Área
Unidad de Trámite Documentar io
Gestión documento
Registro de documento
Usuario
Usuario Natural Usuario jur ídico
Fuente: Elaboración propia
5.1.1.2. Especificación de Casos de Uso del Negocio
CUADRO 15: CASO DE USO ADMINISTRACIÓN DEL SISTEMA
Administración del sistema
Definición del
caso de uso
Proceso en el cual se da mantenimiento a los grupos
documentales, las series documentales, los empleados, sus
áreas, así como asignar usuario y permisos a los usuarios.
Metas Gestionar eficientemente la información sobre las series
documentales, así como la información correspondiente a los
empleados, sus áreas y la asignación de usuario y permisos a los
usuarios.
Propietario Jefe de unidad informática
Riesgos Al gestionar ineficientemente el proceso de administración del
sistema se realizará incorrectamente el proceso de registro de
documento y su gestión.
Categoría Caso de Uso Principal
Flujos de
trabajo
• Registrar/Actualizar serie documental.
• Registrar/Actualizar grupo documental.
• Asignar requisitos.
• Registrar área.
• Registrar/Actualizar empleado.
• Buscar empleado.
• Asignar usuarios y permisos.
• Generar reportes (empleados, series documentales,
estadísticas de gestión documentaria).
Fuente: Elaboración propia
CUADRO 16: CASO DE USO REGISTRO DE DOCUMENTO
Registro de documento
Definición del
caso de uso
Proceso en el cual se registra un documento interno o externo, el
cual es generado por los usuarios (naturales o jurídicos),
asimismo se registran sus adjuntos, y se inicia el proceso de
derivación del documento al área responsable, culminando en la
generación de un ticket que es entregado al usuario.
Metas Registrar eficientemente la información sobre los documentos
internos y externos de la Municipalidad Distrital de Jayanca.
Propietario Tramitadora
Riesgos Al realizar el registro de los documentos ineficientemente, el
proceso de gestión del documento se realizará incorrectamente.
Categoría Caso de Uso Principal
Flujos de
trabajo
• Listar documentos externos
• Registrar documento externo
• Modificar documento externo
• Gestionar referencias
• Gestionar adjuntos
• Buscar usuario
• Registrar/Actualizar usuario
• Generar ticket
• Derivar documento externo
• Anular documento
• Listar documentos enviados
• Mostrar adjuntos
• Listar documentos anulados
• Restaurar documento
• Listar documentos internos
• Registrar documento interno
• Modificar documento interno
• Asignar adjunto
• Imprimir documentos(registrados, anulados, enviados)
Fuente: Elaboración propia
CUADRO 17: CASO DE USO GESTIÓN DE DOCUMENTO
Gestión de documento Definición del caso de uso
Proceso en el cual se gestiona el documento, derivándolo a otra área, concluyendo la atención o archivándolo. Aquí también se consideran las consultas realizadas sobre los documentos respondidos, atendidos y archivados, así como la ubicación de documentos internos o externos.
Metas Gestionar eficientemente los documentos, de manera que se produzca una rápida respuesta a los usuarios.
Propietario Jefe de área, usuario, tramitadora
Riesgos Al gestionar ineficientemente el proceso de gestión de documentos no se logrará brindar un adecuado servicio de atención al usuario.
Categoría Caso de Uso Principal
Flujos de trabajo
• Listar documentos pendientes de atención.
• Mostrar adjuntos del documento.
• Dar proveído.
• Cocluir atención del documento.
• Mostrar seguimiento del documento.
• Mostrar adjunto.
• Listar documentos respondidos.
• Listar documentos atendidos.
• Archivar documento.
• Listar documentos archivados.
• Ubicar documento externo.
• Ubicar documento interno.
• Consultar estado de un documento.
• Imprimir documentos (pendientes de atención, respondidos, atendidos y archivados)
Fuente: Elaboración propia
5.1.1.3. Modelos de objeto del negocio(MON)
Un modelo de Objetos del Negocio es un modelo interno a
un negocio y describe como cada caso de uso es llevado a cabo
por parte de un conjunto de trabajadores que utilizan un conjunto
de entidades del negocio y de unidades de trabajo. Los modelos
de objetos del negocio están asociados a cada uno de los casos
de uso del negocio descritos anteriormente.
Figura 9: Modelo de objeto del negocio: Administración del sistema
Área
Requisito
Empleado Ser ie_documental
Administrador
Registrar /Actualizar
Asignar
Registrar/Actualizar/Listar/ Asignar usuario y permisos/Buscar
Registrar / Actualizar/Listar
Grupo_documental
Registrar /Actualizar
Fuente: Elaboración propia
Figura 10: Modelo de objeto del negocio: Registro de documento
Usuario_Natural
Usuario_Jurídico Usuario
Ticket
Adjunto Documento
Tramitadora Registrar/Modificar/Listar Generar
Registrar/Mostrar/Asignar Registrar/ModificarListar/ Anular/Consultar/Derivar/
Imprimir
Documento interno Documento externo
Fuente: Elaboración propia
Figura 11: Modelo de objeto del negocio: Gestión de documento
Tramitadora
Jefe de Área Documento
Listar/Dar proveído/Concluir atención/ Archivar/Eliminar envío/Ub icar/ Listar/Consultar estado de doc.
Listar/Dar proveído/Concluir atención/ Archivar/Eliminar envío/Ubicar/Listar
Movimientos_doc
Listar
Listar
Tramitador Automatizado
Consultar estado de doc.
Listar
Fuente: Elaboración propia
5.1.1.4. Modelo de dominio del problema
Figura 12: Modelo de dominio del problema
Adjunto (f rom clases)
Área (f rom clases)
Grupo_documental (f rom clases)
Requisito (f rom clases)
Serie_documental (f rom clases)
Usuario (f rom clases)
Usuario_Jurí dico
(f rom clases)
Usuario_ Natural
(f rom clases)
Documento (f rom clases)
Movimientos_doc (f rom clases)
1..1
1..n
0..1
0..n 1..1 1..n
0..n 0..n
Referencia (f rom DC_Administrac ion del sistema) .. .)
Contrato
1..1
1..1
Ubic.geograf
1..1
0..n
1..1 1..n 1..1
1..n
Cargo 1..1
1..n
1..1
0..n
1..1 1..n
1..1
0..n
Fuente: Elaboración propia
5.1.1.5. Glosario de Términos
A continuación se presentan las definiciones de los
términos utilizados a lo largo del proyecto de implementación de
un sistema de gestión documentaria para mejorar el servicio de
atención de los usuarios de la Municipalidad Distrital de Jayanca.
Documentación Externa: Son aquellos documentos
generados por los organismos públicos, privados,
asociaciones o ciudadanos y que son recepcionados por el
área de trámite documentario, asignándole una numeración
correlativa.
Documentación Interna: Son aquellos documentos
generados por las unidades o áreas de la Municipalidad.
Estado de un documento: A una fecha determinada el
estado de un expediente puede ser la siguiente:
o Pendiente: Aquel que está pendiente para la atención del
jefe de un área determinada.
o Atendido: Aquel documento que concluyó en su atención
en una determinada área, quedando listo para ser
archivado.
o Archivado: Aquel que se mantiene en custodia, como
fuente de información.
Serie documental: Conjunto de documentos que responden a
un mismo grupo documental producido por un órgano, en el
ejercicio de una función determinada dentro de la
Municipalidad. La serie documental es un factor fundamental
para una clasificación que se rija por el principio de respeto a
la estructura en que se generan los documentos.
Unidad de Trámite documentario: La Unidad de Trámite
Documentario y Archivo está a cargo de un funcionario de
confianza, quien depende funcional y jerárquicamente del Jefe
de la Oficina de Secretaría General Su función es
recepcionar, registrar y distribuir la documentación recibida de
usuarios externos, brindar un servicio de atención
personalizada en las consultas, ubicación e información de los
110
documentos solicitados por Secretaría General, administrar el
Archivo Central de la Municipalidad, entre otras.
Secretaría General: La Oficina de Secretaría General es el
área que está a cargo de un funcionario de confianza con nivel
de Gerente, quien depende funcional y jerárquicamente del
Alcalde. El ámbito de competencia funcional de la Oficina de
Secretaría General comprende, el apoyo a las acciones
administrativas del Concejo Municipal y de la Alcaldía
conforme a la normatividad vigente, así como, garantizar el
correcto desarrollo de los procesos de trámite documentario y
el mantenimiento, uso, conservación y depuración del
patrimonio documental.
Ticket: Documento generado luego de registrar un documento
externo y que es entregado al usuario para que en base al
código generado pueda realizar su consulta.
Jefe de Área: Es aquella persona responsable de un área que
realiza la gestión de los documentos que competen a su área.
5.2. Fase de Elaboración
El objetivo general en esta fase es plantear la arquitectura para el
ciclo de vida del producto que se implementará en la Municipalidad
distrital de Jayanca. Se desarrollan prototipos que contienen los casos
de uso críticos que fueron identificados en la fase de inicio. En esta fase
se realizará la captura de la mayor parte de los requerimientos
funcionales, manejando los riesgos que interfieran con los objetivos del
sistema, acumulando la información necesaria para el plan de
construcción y obteniendo suficiente información para hacer realizable el
caso del negocio.
En esta fase se analizará el dominio del problema, planteado en el
modelado del negocio, y se establecerá los cimientos de la arquitectura,
eliminando los mayores riesgos. Cuando termina esta fase se llega al
punto de no retorno del proyecto: a partir de ese momento se pasará de
las relativamente ligeras y de poco riesgo dos primeras fases, a afrontar
la fase de construcción, que de algún modo resulta ser costosa y
111
arriesgada. Es por ello que la fase de elaboración es de gran
importancia.
Los artefactos que se presentará en esta fase serán:
• Modelo de Casos de Casos de Uso de Requerimiento.
• Diagramas de Colaboración.
• Diagramas de Secuencia.
5.2.1 Requerimientos
La etapa de Requerimientos es el segundo flujo de trabajo o
disciplina de la metodología RUP, y consiste en establecer los servicios
que el sistema debe proveer y las restricciones bajo las cuales debe
operar.
El objetivo principal de esta disciplina es establecer las funciones
que se quiere que satisfaga el sistema a construir. En esta línea los
requerimientos son el contrato que se debe cumplir, de modo que los
usuarios finales tienen que comprender y aceptar los requerimientos que
se especifiquen. Para obtener los requerimientos se deben aplicar
prácticas de licitación a los involucrados en el proyecto, anotar y validar
todas sus solicitudes.
Los principales objetivos de esta disciplina son:
• Definir el ámbito del sistema.
• Definir una interfaz de usuarios para el sistema, enfocada a
las necesidades y metas del usuario.
• Establecer y mantener un acuerdo entre clientes y otros
involucrados sobre lo que el sistema debería hacer.
• Tener un mejor entendimiento de los requerimientos del
sistema.
• Tener una base para estimar recursos y tiempo de
desarrollo del sistema.
Los requerimientos serán divididos en dos grupos: Los
funcionales, que describirán las funciones que el software va a ejecutar;
y los no funcionales, que especificarán criterios que pueden usarse para
juzgar la operación de un sistema en lugar de sus funciones específicas.
112
Para ello se ha utilizado los diagramas de casos de uso,
elaborando sus respectivas especificaciones, de modo que se pueda
tener una descripción detallada de los requisitos funcionales del sistema
a implementar.
Así mismo, los requisitos no funcionales que representan aquellos
atributos que debe exhibir el sistema, pero que no son una funcionalidad
específica; serán descritos textualmente en especificaciones
suplementarias.
5.2.1.1. Modelo de Casos de Uso de Requerimientos (MCUR)
Los Modelos de Casos de Uso capturan parte de la realidad en la
cual se está trabajando y describen el sistema y su ambiente. Teniendo
en cuenta el modelado del negocio hecho en el flujo anterior,
perteneciente a la fase de Inicio de la metodología, se han elaborado los
casos de uso de requerimientos, siendo estos divididos en tres procesos
principales:
• Administración del sistema.
• Registro de documento.
• Gestión de documentos.
A) Modelo de caso de uso de requerimientos: administración del
sistema.
Figura 13: MCUR: Administración del sistema
113
Registrar Serie documental
(from GdocCU)
Actualizar Empleado
(from GdocCU)
Registrar Grupo documental (from GdocCU)
Registrar empleado
(from GdocCU)
Asignar usuario y permisos
(from GdocCU)
Listar serie documental
(from GdocCU)
<<extend>> <<extend>>
Registrar Área
(from GdocCU)
Listar Empleado
(from GdocCU)
<<extend>>
<<extend>>
<<extend>>
Generar repor te de serie documental por grupo doc.
(from GdocCU)
Generar estadísticas de gestión doc. (fr om GdocCU)
Generar reporte de Empleado (from GdocCU)
Administrador
(from Actor es)
Fuente: Elaboración propia
A.1. Especificaciones de los Casos de Uso
CUADRO 18: ESPECIFICACIÓN DE CASO DE USO LISTAR SERIE DOCUMENTAL
114
CASO DE USO LISTAR SERIE DOCUMENTAL Descripción El sistema permite mostrar las series documentales registradas por grupo
dcoumentario o por área.
Flujo de eventos FLUJO BÁSICO
1. Luego de acceder al sistema, el administrador selecciona del menú
“Administración del sistema” la opción “Serie documental”.
2. El sistema muestra una interfase donde deberá seleccionar el criterio a
listar las series documentales ( por grupo documentario, área y/o
nombre).
Precondiciones El administrador del sistema debe haber validado su cuenta de usuario.
Post
condiciones
El sistema creará automáticamente los códigos de las series
documentales.
Punto de extensión
Al listar las series documentales el administrador del sistema puede
registrar, actualizar o eliminar una serie documental o registrar/actualizar
un grupo documental.
Fuente: Elaboración propia
CUADRO 19: ESPECIFICACIÓN DE CASO DE USO REGISTRAR
SERIE DOCUMENTAL
CASO DE USO REGISTRAR SERIE DOCUMENTAL
Descripción El sistema provee el soporte necesario para la creación o actualización de series documentales.
Flujo de eventos FLUJO BÁSICO 1. Luego de acceder al sistema, el administrador selecciona del menú
“Administración del sistema” la opción “Serie documental”. 2. El sistema muestra una interfase donde muestra un listado de las
series documentales registradas. 3. El administrador del sistema selecciona la opción “Nueva serie” y
aparecerá una interfase donde deberá registrar el nombre de la serie documental, el grupo documental al que pertenece, tipo de serie, área a la que pertenece, plazo de respuesta y seleccionar requisitos.
Precondiciones El administrador del sistema debe haber validado su cuenta de usuario.
Postcondiciones El sistema crea automáticamente los códigos de las series documentales.
Punto de extensión Ninguno.
Fuente: Elaboración propia
CUADRO 20: ESPECIFICACIÓN DE CASO DE USO REGISTRAR
GRUPO DOCUMENTAL
115
CASO DE USO REGISTRAR GRUPO DOCUMENTAL
Descripción El sistema provee el soporte necesario para la creación de nuevos grupos
documentales.
Flujo de eventos FLUJO BÁSICO
1. Luego de acceder al sistema, el administrador selecciona del menú
“Administración del sistema” la opción “Serie documental”.
2. El sistema muestra una interfase donde deberá activar la opción
grupo documentario.
3. El sistema listará los grupos registrados y aparece la opción “Nuevo”
que debe elegir el administrador del sistema.
4. El administrador debe ingresar el nombre del grupo documental.
Precondiciones El administrador del sistema debe haber validado su cuenta de usuario. Post condiciones
El sistema creará automáticamente los códigos de los grupos documentales.
Fuente: Elaboración propia
CUADRO 21: ESPECIFICACIÓN DE CASO DE USO REGISTRAR ÁREA
CASO DE USO REGISTRAR ÁREA
Descripción El sistema provee el soporte necesario para la creación de áreas a las
que pertenecen los empleados de la Municipalidad Distrital de Jayanca.
Flujo de eventos FLUJO BÁSICO
1. Luego de acceder al sistema, el administrador selecciona del menú
“Administración del sistema” la opción “Area de trabajo”.
2. El sistema muestra una interfase donde deberá registrar la
descripción del área y el área de dependencia.
Precondiciones El administrador del sistema debe haber validado su cuenta de usuario.
Postcondiciones El sistema creará automáticamente los códigos para cada área.
Fuente: Elaboración propia
CUADRO 22: ESPECIFICACIÓN DE CASO DE USO LISTAR EMPLEADO
116
CASO DE USO LISTAR EMPLEADO
Descripción El sistema permite mostrar resultados a partir del dato de búsqueda
ingresado. A partir de este resultado es posible seleccionar el empleado
y actualizar sus datos.
Flujo de eventos FLUJO BÁSICO
1. Luego de acceder al sistema, el administrador selecciona del menú
“Administración del sistema” la opción “Empleados”.
2. El sistema muestra una interfase con los datos de los empleados
de acuerdo al nombre ingresado.
Precondiciones El administrador del sistema debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Punto de
extensión
Al ingresar al listado de empleados, el administrador del sistema puede
registrar/actualizar los datos o asignar usuario y permisos.
Fuente: Elaboración propia
CUADRO 23: ESPECIFICACIÓN DE CASO DE USO
REGISTRAR EMPLEADO
CASO DE USO REGISTRAR EMPLEADO
Descripción El sistema permite registrar los datos de los empleados.
Flujo de eventos FLUJO BÁSICO
1. Al listar los empleados registrados, el administrador selecciona la
opción “Nuevo empleado”.
2. El sistema muestra una pantalla solicitando los siguientes datos:
Nombre, DNI, sexo, dirección, mail, teléfono, mail, distrito, provincia
y departamento de residencia, tipo de contrato, número de contrato,
área a la que pertenece, fecha de ingreso y cargo.
3. Luego de registrar estos datos el administrador del sistema accede
a la opción “Grabar empleado”.
Precondiciones El administrador del sistema debe haber validado su cuenta de usuario.
Postcondiciones El sistema creará automáticamente los códigos del empleado.
Fuente: Elaboración propia
CUADRO 24: ESPECIFICACIÓN DE CASO DE USO
ACTUALIZAR EMPLEADO
117
CASO DE USO ACTUALIZAR EMPLEADO
Descripción El sistema permite actualizar los datos de los empleados. Para lo cual el
administrador puede realizar una búsqueda previa de éste.
Flujo de eventos FLUJO BÁSICO
1. Al listar los empleados registrados, el administrador debe elegir
un empleado.
2. El sistema muestra una pantalla mostrando los datos del
empleado seleccionado: Nombre, DNI, sexo, dirección, mail,
teléfono, mail, distrito, provincia y departamento de residencia,
tipo de contrato, número de contrato, área a la que pertenece,
fecha de ingreso y cargo.
3. Luego de actualizar estos datos el administrador del sistema
accede a la opción “Grabar empleado”.
Precondiciones El administrador del sistema debe haber validado su cuenta de usuario.
Deben existir empleados registrados y uno seleccionado.
Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 25: ESPECIFICACIÓN DE CASO DE USO
ASIGNAR USUARIO Y PERMISOS
CASO DE USO ASIGNAR USUARIO Y PERMISOS
Descripción El sistema provee el soporte necesario para la asignación de nombre de
usuario y permisos para acceder a los menús y opciones del sistema.
Flujo de eventos FLUJO BÁSICO
1. Al listar los empleados registrados, el administrador selecciona un
empleado y luego elige la opción “Asignar login y permisos”.
2. El sistema muestra una interfase solicitando los datos: nombre de
usuario y contraseña, así como la selección de los accesos al
sistema (administración del sistema, registro de documento, gestión
de documentos internos, gestión de documentos externos).
3. Luego de ingresar y seleccionar estos datos el administrador del
sistema accede a la opción “Grabar”.
Precondiciones El administrador del sistema debe haber validado su cuenta de usuario.
Deben existir empleados registrados y uno seleccionado. Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 26: ESPECIFICACIÓN DE CASO DE USO GENERAR REPORTE
DE SERIE DOCUMENTAL POR GRUPO DOCUMENTARIO
118
CASO DE USO GENERAR REPORTE DE SERIE DOCUMENTAL
POR GRUPO DOCUMENTARIO
Descripción El sistema provee el soporte necesario para la generación del reporte de
series documentales según grupo documental.
Flujo de eventos FLUJO BÁSICO
1. Luego de acceder al sistema, el administrador selecciona del menú
“Administración del sistema” la opción “Reportes”, y luego la opción
“Serie documental”.
2. El sistema mostrará una nueva interfase con la vista previa del reporte
que muestra los datos de las series documentales registradas
agrupadas por grupo documentario y con opciones para exportar en
formato pdf o imprimir el reporte.
Precondiciones El administrador del sistema debe haber validado su cuenta de usuario.
Post condiciones
Ninguna.
Fuente: Elaboración propia
CUADRO 27: ESPECIFICACIÓN DE CASO DE USO GENERAR
REPORTE DE EMPLEADOS
CASO DE USO GENERAR REPORTE DE EMPLEADOS
Descripción El sistema provee el soporte necesario para la generación de reporte de
empleados.
Flujo de eventos FLUJO BÁSICO
1. Luego de acceder al sistema, el administrador selecciona del
menú “Administración del sistema” la opción “Reportes”, y luego la
opción “Empleados”.
2. El sistema mostrará una nueva interfase con la vista previa del
reporte. El reporte muestra el código del empleado, nombre, DNI,
dirección, mail, teléfono, área a la que pertenece, tipo de contrato,
fecha de ingreso y cargo que muestra los datos de las series
documentales registradas agrupadas por grupo documentario y
con opciones para exportar en formato pdf o imprimir el reporte.
Precondiciones El administrador del sistema debe haber validado su cuenta de usuario.
Post condiciones
Ninguna.
Fuente: Elaboración propia
119
CUADRO 28: ESPECIFICACIÓN DE CASO DE USO GENERAR
ESTADÍSTICAS DE GESTIÓN
CASO DE USO GENERAR ESTADÍSTICAS DE GESTIÓN
Descripción El sistema provee el soporte necesario para la generación de estadísticas
de gestión.
Flujo de eventos FLUJO BÁSICO
1. Luego de acceder al sistema, el administrador selecciona del
menú “Administración del sistema” la opción “Reportes”, y luego la
opción “Estadísticas de gestión”.
2. El sistema mostrará una nueva interfase con información sobre
documentos derivados por área, tiempo promedio de atención de
un documento por área, record mensual de atención de solicitudes
de acceso a la información pública.
Precondiciones El administrador del sistema debe haber validado su cuenta de usuario.
Post condiciones
Ninguna.
Fuente: Elaboración propia
120
B) Modelo de caso de uso de requerimientos: Registro de documento.
Figura 14: MCUR: Registro de documento
Registrar Usuario
(f rom GdocCU)
Buscar Usuario
(f rom GdocCU)
Gestionar adj untos
(f rom GdocCU)
Usuario Jur ídico
(f rom Actores) Usuario Natural
(f rom Acto res)
Modi ficar documento
(from GdocCU)
<<extend>>
Impr imir l istado de doc . reg. (f rom GdocCU)
Deriv ar documento
(from GdocCU)
Gestionar referenc ias (f rom GdocCU)
<<extend>>
Generar ticket
(f rom GdocCU)
Registrar Doc . externo
(f rom GdocCU)
<<extend>>
<<extend>>
Usuario
(f rom Actores)
Modi ficar doc .interno (f rom GdocCU)
Registrar doc . interno (f rom GdocCU)
Asignar Adj unto
(f rom GdocCU)
Mostrar adj unto
(f rom GdocCU)
Lis tar doc . internos reg. (from GdocCU)
<<extend>>
Lis tar documentos ext. registrados (f rom GdocCU)
<<extend>>
<<extend>>
<<extend>>
<<extend>>
Lis tar documentos eliminados (f rom GdocCU)
Lis tar documentos env iados
(f rom GdocCU)
Trami tadora
(f rom Actores)
Res taurar documento (f rom GdocCU)
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
Anular documento
(f rom GdocCU)
<<extend>>
<<extend>>
Imprimir l is tado de doc .internos (f rom GdocCU)
<<extend>>
Impr imir l istado de doc .env iados
(f rom GdocCU)
<<extend>>
Imprimir l is tado de doc. el iminados
(f rom GdocCU)
<<extend>>
<<extend>>
<<extend>>
<<include>>
<<extend>>
<<extend>>
<<include>>
Fuente: Elaboración propia
121
B.1. Especificaciones de los Casos de Uso
CUADRO 29: ESPECIFICACIÓN DE CASO DE USO LISTAR DOCUMENTOS EXTERNOS REGISTRADOS
CASO DE USO LISTAR DOCUMENTOS EXTERNOS REGISTRADOS
Descripción El sistema permite mostrar los documentos externos registrados y que aún no se han derivado para su atención.
Flujo de
eventos
FLUJO BÁSICO 1. Luego de acceder al sistema, la tramitadora selecciona el menú “Registrar
documento”. 2. El sistema muestra una interfase donde lista los últimos documentos externos
registrados que no han sido derivados. 3. El sistema permite cambiar el listado de documentos externos registrados, de
acuerdo a lo que la tramitadora elija: fecha, asunto o propietario del documento. FLUJO ALTERNATIVO 4. En el punto Nº 2, la tramitadora podrá anular el documento que seleccione o
imprimir el listado de los documentos mostrados.
Pre condiciones
La tramitadora debe haber validado su cuenta de usuario.
Post condiciones
Ninguna.
Puntos de extensión
Al ingresar a la lista de documentos externos registrados, la tramitadora puede ingresar un nuevo documento externo, modificar un documento registrado que seleccione, derivar el documento seleccionado, mostrar adjuntos del documento seleccionado, anular documento, generar ticket para el usuario, o imprimir listado.
Fuente: Elaboración propia
CUADRO 30: ESPEC. DE CASO DE USO REGISTRAR DOC. EXTERNO
CASO DE USO REGISTRAR DOCUMENTO EXTERNO
Descripción El sistema provee el soporte necesario para el ingreso de un documento externo.
Flujo de eventos FLUJO BÁSICO 1. Estando en la interfase que se muestra al ingresar al menú “Registrar
documentos externos”, la tramitadora elige la opción “Registrar documento”. 2. El sistema muestra una nueva interfase donde solicita los datos del nuevo
documento: tipo de serie documental, número de documento, fecha de ingreso, prioridad, número de folios, propietario, asunto, observaciones.
3. Luego, la tramitadora elige la opción grabar documento.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Postcondiciones El sistema creará automáticamente los códigos de los documentos registrados.
Puntos de extensión
Al registrar un nuevo documento, la tramitadora puede gestionar los archivos adjuntos y las referencias, así como registrar un nuevo propietario si el usuario es nuevo.
Fuente: Elaboración propia
122
CUADRO 31: ESPECIFICACIÓN DE CASO DE USO MODIFICAR
DOCUMENTO EXTERNO
CASO DE USO MODIFICAR DOCUMENTO EXTERNO
Descripción El sistema provee el soporte necesario para la modificación de un
documento ingresado.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase que se muestra al ingresar al menú “Registrar
documentos externos”, la tramitadora selecciona un documento
registrado y elige la opción Modificar documento.
2. El sistema muestra una nueva interfase donde muestra los datos del
documento seleccionado : tipo de serie documental, número de
documento, fecha de ingreso, prioridad, número de folios, propietario,
asunto y observaciones..
3. Luego, la tramitadora realiza los cambios que sean necesarios elige la
opción “Grabar documento”.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Deben existir documentos registrados y un seleccionado.
Post condiciones
Ninguna.
Puntos de extensión
Al modificar un documento, la tramitadora puede gestionar los archivos
adjuntos y las referencias, así como registrar un nuevo propietario si el
usuario es nuevo.
Fuente: Elaboración propia
CUADRO 32: ESPECIFICACIÓN DE CASO DE USO GESTIONAR ADJUNTOS
CASO DE USO GESTIONAR ADJUNTOS Descripción El sistema provee el soporte necesario para agregar o actualizar la
lista de los adjuntos de un documento que la tramitadora seleccione.
Flujo de eventos FLUJO BÁSICO
1. Al ingresar a la opción “Ingresar documento” o “Modificar
documento” la tramitadora elige la opción de “Gestionar
adjuntos”
2. El sistema mostrará una nueva interfase que permitirá
seleccionar un documento digitalizado en formato PDF
buscable. Asimismo la tramitadora puede eliminar un adjunto.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Fuente: Elaboración propia
123
CUADRO 33: ESPECIFICACIÓN DE CASO DE USO GESTIONAR
REFERENCIAS
CASO DE USO GESTIONAR REFERENCIAS Descripción El sistema provee el soporte necesario para registrar o actualizar la
lista de los referencias de un documento que la tramitadora
seleccione.
Flujo de eventos FLUJO BÁSICO
1. Al ingresar a la opción “Ingresar documento” o “Modificar
documento” la tramitadora elige la opción de “Gestionar
referencias”
2. El sistema mostrará una nueva interfase que permitirá agregar
o eliminar un documento de referencia.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 34: ESPECIFICACIÓN DE CASO DE USO BUSCAR USUARIO
CASO DE USO BUSCAR USUARIO
Descripción El sistema permite mostrar resultados según el tipo de persona
seleccionada: natural o jurídica y según el nombre ingresado. A partir
de este resultado es posible elegir el usuario propietario del
documento externo.
Flujo de eventos FLUJO BÁSICO
1. Luego de acceder a la opción “ingresar documento” o “actualizar
documento”, la tramitadora selecciona la opción “Buscar usuario”.
2. El sistema muestra una interfase en la cual lista los usuarios
registrados de acuerdo al tipo de persona seleccionada y al
nombre ingresado.
3. La tramitadora puede elegir de la lista un usuario para ser
asignado como propietario al documento externo.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Punto de extensión Ninguno.
Fuente: Elaboración propia
CUADRO 35: ESPECIFICACIÓN DE CASO DE USO REGISTRAR USUARIO
124
CASO DE USO REGISTRAR USUARIO Descripción El sistema permite registrar o actualizar los datos de un usuario.
Flujo de eventos FLUJO BÁSICO 1. Luego de acceder a la opción “ingresar documento” o “actualizar
documento”, la tramitadora selecciona la opción “Registrar usuario”. 2. El sistema muestra una interfase en la cual lista los usuarios
registrados de acuerdo al nombre que se ingrese. 3. La tramitadora debe elegir la opción “Nuevo” 4. El sistema solicita los datos del usuario: Nombre o razón social,
identificación (DNI o RUC), dirección, distrito, provincia y departamento de residencia, mail, mail alternativo, teléfono, teléfono alternativo.
5. La tramitadora registra los datos del usuario. FLUJO BÁSICO 6. En el paso 3, si la tramitadora decide actualizar los datos del usuario,
deberá elegir un usuario y elegir la opción Modificar.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Postcondiciones El sistema creará automáticamente los códigos del usuario.
Fuente: Elaboración propia
CUADRO 36: ESPECIFICACIÓN DE CASO DE USO DERIVAR DOCUMENTO CASO DE USO DERIVAR DOCUMENTO Descripción El sistema permite derivar un documento elegido de la lista de documentos,
permitiendo remitir el documento a un área, registrando la acción a realizar e ingresando las observaciones al respecto.
Flujo de eventos FLUJO BÁSICO 1. Estando en la interfase que se muestra al ingresar al menú registrar
documento, la tramitadora selecciona un documento y elige la opción “Derivar documento”.
2. El sistema muestra una nueva interfase solicitando los datos para el envío del documento.
3. La tramitadora deberá seleccionar el área destino del documento, la acción a tomar y las observaciones.
4. Luego se selecciona la opción de “Enviar” y el documento aparecerá en los documentos pendientes de atención del área donde fue enviado.
FLUJO ALTERNATIVO 5. En el punto 3, si la tramitadora elige colocar un plazo de respuesta puede
ingresar la fecha de plazo para responder el documento.
Precondiciones La tramitadora debe haber validado su cuenta de usuario. Deben existir documentos registrados.
Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 37: ESPECIFICACIÓN DE CASO DE USO GENERAR TICKET
125
CASO DE USO GENERAR TICKET Descripción El sistema provee el soporte necesario para la generación de un ticket,
el mismo que será entregado al usuario, para que a través del número
de documento asignado, realice una consulta sobre el estado de su
documento.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase que se muestra al ingresar al menú
registrar documento, la tramitadora selecciona un documento
registrado y elige la opción “Generar ticket”.
2. El sistema muestra una vista previa del ticket con los datos del
documento (grupo y serie documental, número de documento,
asunto, oficina donde fue enviado el documento, plazo máximo
de respuesta).
3. La tramitadora elige la opción “Imprimir ticket”, el cual será
entregado al usuario para que sirva de elemento de consulta.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 38: ESPECIFICACIÓN DE CASO DE USO MOSTRAR ADJUNTOS
CASO DE USO MOSTRAR ADJUNTOS Descripción El sistema provee el soporte necesario para visualizar los documentos
digitalizados adjuntos al documento que ha sido seleccionado.
Flujo de eventos FLUJO BÁSICO
1. Luego de mostrar el listado de los documentos, el empleado
elige la opción “Mostrar adjuntos”.
2. El sistema mostrará una nueva interfase que permitirá
seleccionar y visualizar cada uno de los adjuntos del
documento.
Precondiciones El empleado debe haber validado su cuenta de usuario.
El documento debe tener documentos adjuntos.
Postcondiciones Ninguna.
Fuente: Elaboración propia
126
CUADRO 39: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE
DOCUMENTOS EXTERNOS REGISTRADOS
CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS EXTERNOS REGISTRADOS
Descripción El sistema provee el soporte necesario para la impresión del listado de
documentos externos registrados por la tramitadora.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase que se muestra al ingresar al menú registrar
documento, la tramitadora elige la opción “Imprimir listado”.
2. El sistema mostrará una nueva interfase con la vista previa del reporte
que muestra los datos de los documentos externos registrados
ordenados por fecha de registro. Asimismo el sistema muestra las
opciones para exportar en formato pdf o imprimir el reporte.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 40: ESPECIFICACIÓN DE CASO DE USO
LISTAR DOCUMENTOS EXTERNOS DERIVADOS
CASO DE USO LISTAR DOCUMENTOS DERIVADOS
Descripción El sistema permite mostrar los documentos externos derivados.
Flujo de
eventos
FLUJO BÁSICO
1. Luego de acceder al sistema, la tramitadora selecciona el menú
“Documentos derivados”.
2. El sistema muestra una interfase donde lista los documentos externos
derivados.
3. El sistema permite cambiar el listado de documentos derivados, de
acuerdo a lo que la tramitadora elija: fecha, asunto o propietario del
documento.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Post condiciones
Ninguna.
Puntos de extensión
Al ingresar a la lista de documentos derivados, la tramitadora puede mostrar
adjuntos del documento seleccionado o imprimir listado.
Fuente: Elaboración propia
127
CUADRO 41: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE
DOCUMENTOS DERIVADOS
CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS DERIVADOS
Descripción El sistema provee el soporte necesario para la impresión del listado de
documentos derivados por la tramitadora.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase que se muestra al ingresar al menú
“Documentos derivados”, la tramitadora elige la opción “Imprimir
listado”.
2. El sistema mostrará una nueva interfase con la vista previa del
reporte que muestra los datos de los documentos derivados
ordenados por fecha de envío o derivación. Asimismo el sistema
muestra las opciones para exportar en formato pdf o imprimir el
reporte.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 42: ESPECIFICACIÓN DE CASO DE USO
LISTAR DOCUMENTOS ANULADOS
CASO DE USO LISTAR DOCUMENTOS ANULADOS
Descripción El sistema permite mostrar los documentos anulados tanto externos como internos.
Flujo de
eventos
FLUJO BÁSICO 1. Luego de acceder al sistema, la tramitadora selecciona la opción
“Documentos anulados”. 2. El sistema muestra una interfase donde lista los documentos externos e
internos que han sido anulados. 3. El sistema permite cambiar el listado de documentos anulados, de acuerdo
a lo que la tramitadora elija: fecha de registro o asunto. FLUJO ALTERNATIVO 4. En el punto Nº 2, la tramitadora podrá restaurar el documento que
seleccione o imprimir el listado de los documentos mostrados.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Post condiciones
Ninguna.
Puntos de extensión
Al ingresar a la lista de documentos anulados, la tramitadora puede restaurar el documento, mostrar adjuntos del documento seleccionado o imprimir listado de documentos anulados.
Fuente: Elaboración propia
128
CUADRO 43: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE
DOCUMENTOS ANULADOS
CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS ANULADOS
Descripción El sistema provee el soporte necesario para la impresión del listado
de documentos anulados.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase que se muestra al ingresar al menú
“Documentos anulados”, la tramitadora elige la opción
“Imprimir listado”.
2. El sistema mostrará una nueva interfase con la vista previa
del reporte que muestra los datos de los documentos
anulados ordenados por fecha de registro. Asimismo el
sistema muestra las opciones para exportar en formato pdf
o imprimir el reporte.
Precondiciones La tramitadora debe haber validado su cuenta de usuario. Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 44: ESPECIFICACIÓN DE CASO DE USO
LISTAR DOCUMENTOS INTERNOS REGISTRADOS
CASO DE USO LISTAR DOCUMENTOS INTERNOS REGISTRADOS
Descripción El sistema permite mostrar los documentos internos registrados.
Flujo de eventos FLUJO BÁSICO
1. Luego de acceder al sistema, la tramitadora selecciona el
menú “Registrar documento interno”.
2. El sistema muestra una interfase donde lista los documentos
internos registrados, de acuerdo a lo que la tramitadora elija:
fecha de registro o asunto.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Puntos de extensión
Al ingresar a la lista de documentos internos registrados, la
tramitadora puede ingresar un nuevo documento interno, modificar un
documento registrado que seleccione, anular documento o imprimir
listado de documentos internos.
Fuente: Elaboración propia
129
CUADRO 45: ESPECIFICACIÓN DE CASO DE USO REGISTRAR
DOCUMENTO INTERNO
CASO DE USO REGISTRAR DOCUMENTO INTERNO Descripción El sistema provee el soporte necesario para el ingreso de un doc. interno.
Flujo de eventos FLUJO BÁSICO 1. Estando en la interfase que se muestra al ingresar al menú “Registrar
de documentos internos”, la tramitadora elige la opción “Registrar documento”.
2. El sistema muestra una nueva interfase donde solicita los datos del nuevo documento: tipo de serie documental, número de documento, fecha de emisión, número de folios, área productora, asunto, observaciones y documento adjunto.
3. Luego, la tramitadora elige la opción grabar documento.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Postcondiciones El sistema creará automáticamente los códigos de los documentos regist.
Puntos de extensión
Al registrar un nuevo documento, la tramitadora puede asignar el adjunto al documento interno.
Fuente: Elaboración propia
CUADRO 46: ESPECIFICACIÓN DE CASO DE USO MODIFICAR
DOCUMENTO INTERNO
CASO DE USO MODIFICAR DOCUMENTO INTERNO
Descripción El sistema provee el soporte necesario para la modificación de un documento interno ingresado.
Flujo de eventos FLUJO BÁSICO 1. Estando en la interfase que se muestra al ingresar al menú “Registrar
de documentos internos”, la tramitadora elige la opción “Modificar documento”.
2. El sistema muestra una nueva interfase donde muestra los datos del documento seleccionado: tipo de serie documental, número de documento, fecha de emisión, número de folios, área productora, asunto, observaciones y documento adjunto.
3. Luego, la tramitadora realiza los cambios que sean necesarios y elige la opción “Grabar documento”.
Precondiciones La tramitadora debe haber validado su cuenta de usuario. Deben existir documentos registrados y un seleccionado.
Postcondicion. Ninguna.
Puntos de extensión
Al modificar un documento interno, la tramitadora puede asignar el adjunto al documento interno.
Fuente: Elaboración propia
130
CUADRO 47: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE
DOCUMENTOS INTERNOS REGISTRADOS
CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS INTERNOS REGISTRADOS
Descripción El sistema provee el soporte necesario para la impresión del listado de
documentos internos registrados por la tramitadora.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase que se muestra al ingresar al menú registrar
documento, la tramitadora elige la opción “Imprimir listado”.
2. El sistema mostrará una nueva interfase con la vista previa del reporte que
muestra los datos de los documentos internos registrados ordenados por
fecha de registro. Asimismo el sistema muestra las opciones para exportar
en formato pdf o imprimir el reporte.
Precondiciones La tramitadora debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Fuente: Elaboración propia
131
C) Modelo de caso de uso de requerimientos: Gestión de
documento.
Figura 15: MCUR: Gestión de documento
Mostrar adj unto
(f rom GdocCU)
Mostrar s eguimiento
(from GdocCU)
Dar prov eído
(from GdocCU)
Imprimir l is tado de doc. pend.atenc.
(f rom GdocCU)
Imprimir lis tado de doc. archiv ados
(from GdocCU)
Imprimir lis tado de doc. respondidos
(from GdocCU)
Jefe de área
(from Acto res)
Usuario
(from Actores)
Tramitador Automatizado (from Acto res)
Consultar es tado de un documento
(from GdocCU)
Tramitadora
(f rom Acto res)
Mos trar doc. interno
(f rom GdocCU) Imprimir lis tado de doc .internos (from GdocCU)
Concluir atención
(from GdocCU)
Imprimir l is tado de documentos atendidos
(from GdocCU)
Archiv ar documento
(from GdocCU)
Listar doc .pendientes de atención (from GdocCU)
<<extend>>
<<extend>>
<<include>>
<<extend>>
Listar documentos Respondidos (from GdocCU)
<<include>>
<<extend>>
<<extend>>
Listar documentos archiv ados (from GdocCU)
<<extend>>
<<include>>
Listar documentos atendidos (from GdocCU)
<<extend>>
<<extend>>
<<extend>>
<<include>>
Ubicar documento interno
(from GdocCU)
<<extend>>
<<extend>>
Ubicar documento externo
(from GdocCU)
Empleado_
Imprim ir lis tado de doc. ext. (from GdocCU)
<<extend>>
<<extend>>
Fuente: Elaboración propia
132
C.1. Especificaciones de los Casos de Uso
CUADRO 48: ESPECIFICACIÓN DE CASO DE USO LISTAR DOCUMENTOS PENDIENTES DE ATENCIÓN
CASO DE USO LISTAR DOCUMENTOS PENDIENTES DE ATENCIÓN Descripción Para gestionar un documento pendiente de atención, el jefe de área
tiene la posibilidad de listar documentos pendientes de atención.
Flujo de eventos FLUJO BÁSICO
1. El empleado elige del menú “Gestión de documentos” la opción
“Documentos pendientes de atención”.
2. El sistema mostrará la lista de estos documentos, pudiendo ser
cambiado de acuerdo a la fecha de envío y asunto.
Precondiciones El empleado debe haber validado su cuenta de usuario. Postcondiciones Ninguna.
Punto de
extensión
Al ingresar a esta lista de documentos pendientes de atención, el
empleado puede dar proveído al documento, concluir la atención,
mostrar adjuntos del documento, mostrar seguimiento del documento o
imprimir el listado de documentos pendientes.
Fuente: Elaboración propia
CUADRO 49: ESPECIFICACIÓN DE CASO DE USO DAR PROVEÍDO CASO DE USO DAR PROVEÍDO
Descripción El sistema permite dar proveído a un documento elegido en la lista de
documentos pendientes de atención, permitiendo remitir el documento
a otra área, ingresando la acción o el proveído del documento y
observaciones al respecto.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase de “Documentos pendientes de atención” el
empleado selecciona el documento al que desea darle proveído.
2. Elige la opción “Dar proveído”.
3. El sistema mostrará una interfase donde se muestran los datos del
documento elegido, solicitando datos del proveído (área de destino,
proveído y observaciones).
4. Luego se selecciona la opción de “Enviar documento” y el
documento aparecerá en los documentos pendientes de atención
en el área donde se envío el documento.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Deben existir documentos pendientes de atención. Postcondiciones Ninguna.
Punto de extensión Ninguno.
Fuente: Elaboración propia
133
CUADRO 50: ESPECIFICACIÓN DE CASO DE USO CONCLUIR ATENCIÓN
CASO DE USO CONCLUIR ATENCIÓN Descripción El sistema permite concluir la atención a un documento permitiendo
ingresar observaciones al respecto.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase de “Documentos pendientes de
atención” el empleado selecciona el documento que desea
concluir atención.
2. Elige la opción “Concluir atención”.
3. El sistema solicitará las observaciones correspondientes a la
conclusión del documento.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Deben existir documentos pendientes de atención.
Postcondiciones Ninguna.
Punto de extensión Ninguno.
Fuente: Elaboración propia
CUADRO 51: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE
DOCUMENTOS PENDIENTES DE ATENCIÓN
CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS PENDIENTES DE ATENCIÓN
Descripción El sistema provee el soporte necesario para la impresión del listado de
documentos pendientes de atención.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase que se muestra al ingresar al menú
“Documentos pendientes de atención”, la tramitadora elige la opción
“Imprimir listado”.
2. El sistema mostrará una nueva interfase con la vista previa del reporte
que muestra los datos de los documentos pendientes de atención
ordenados por fecha de envío. Asimismo el sistema muestra las
opciones para exportar en formato pdf o imprimir el reporte.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Fuente: Elaboración propia
134
CUADRO 52: ESPECIFICACIÓN DE CASO DE USO MOSTRAR SEGUIMIENTO
CASO DE USO MOSTRAR SEGUIMIENTO Descripción El sistema provee el soporte necesario para mostrar el seguimiento de
cada documento seleccionado.
Flujo de eventos FLUJO BÁSICO
1. La tramitadora selecciona un documento del cual desea mostrar su
seguimiento.
2. El sistema muestra el seguimiento de dicho documento indicando
la fecha de envío, el área origen, área destino, acciones que se
tomaron y observaciones.
3. El sistema muestra la opción “Imprimir seguimiento”
4. El empleado selecciona la opción imprimir.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 53: ESPECIFICACIÓN DE CASO DE USO
LISTAR DOCUMENTOS RESPONDIDOS
CASO DE USO LISTAR DOCUMENTOS RESPONDIDOS
Descripción El empleado puede mostrar una lista de los documentos que ha
respondido.
Flujo de eventos FLUJO BÁSICO
1. El empleado elige del menú “Gestión de documentos” la opción
“Documentos Respondidos”.
2. El sistema mostrará la lista de estos documentos, pudiendo ser
cambiado de acuerdo a la fecha de envío y asunto.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Punto de
extensión
Al ingresar a la lista de documentos respondidos, el empleado puede
mostrar adjuntos del documento, mostrar seguimiento del documento o
imprimir el listado de documentos respondidos.
Fuente: Elaboración propia
135
CUADRO 54: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE
DOCUMENTOS RESPONDIDOS
CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS RESPONDIDOS
Descripción El sistema provee el soporte necesario para la impresión del listado de
documentos respondidos.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase que se muestra al ingresar al menú “Documentos
respondidos”, la tramitadora elige la opción “Imprimir listado”.
2. El sistema mostrará una nueva interfase con la vista previa del reporte que
muestra los datos de los documentos respondidos ordenados por fecha de
respuesta. Asimismo el sistema muestra las opciones para exportar en
formato pdf o imprimir el reporte.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 55: ESPECIFICACIÓN DE CASO DE USO
LISTAR DOCUMENTOS ATENDIDOS
CASO DE USO LISTAR DOCUMENTOS ATENDIDOS
Descripción El empleado puede mostrar una lista de los documentos que ha
atendido.
Flujo de eventos FLUJO BÁSICO
1. El empleado elige del menú “Gestión de documentos” la opción
“Documentos atendidos”.
2. El sistema mostrará la lista de estos documentos, pudiendo ser
cambiado de acuerdo a la fecha de atención y asunto.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Punto de
extensión
Al ingresar a la lista de documentos atendidos, el empleado puede
mostrar adjuntos del documento, mostrar seguimiento del documento o
imprimir el listado de documentos atendidos.
Fuente: Elaboración propia
136
CUADRO 56: ESPECIFICACIÓN DE CASO DE USO ARCHIVAR DOCUMENTO
CASO DE USO ARCHIVAR DOCUMENTO Descripción El sistema provee el soporte necesario para archivar un documento
externo que haya concluido su atención.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase “Documentos atendidos”, el empleado
debe seleccionar un documento y proceder a archivar dicho
documento.
2. El sistema mostrará un mensaje de confirmación de
archivado.
3. El sistema procede a archivar el documento.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Debe haber documentos externos con atención concluida y ser
seleccionado(s).
Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 57: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE
DOCUMENTOS ATENDIDOS
CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS ATENDIDOS
Descripción El sistema provee el soporte necesario para la impresión del listado de
documentos respondidos.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase que se muestra al ingresar al menú
“Documentos atendidos”, la tramitadora elige la opción “Imprimir
listado”.
2. El sistema mostrará una nueva interfase con la vista previa del
reporte que muestra los datos de los documentos atendidos
ordenados por fecha de atención. Asimismo el sistema muestra
las opciones para exportar en formato pdf o imprimir el reporte.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Fuente: Elaboración propia
137
CUADRO 58: ESPECIFICACIÓN DE CASO DE USO
LISTAR DOCUMENTOS ARCHIVADOS
CASO DE USO LISTAR DOCUMENTOS ARCHIVADOS
Descripción El empleado puede mostrar una lista de los documentos que ha
archivado.
Flujo de eventos FLUJO BÁSICO
1. El empleado elige del menú “Gestión de documentos” la opción
“Documentos Archivados”.
2. El sistema mostrará la lista de estos documentos, pudiendo ser
cambiado de acuerdo a la fecha de archivo y asunto.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Punto de
extensión
Al ingresar a la lista de documentos archivados, el empleado puede
mostrar adjuntos del documento, mostrar seguimiento del documento,
quitar el estado de archivado o imprimir el listado de documentos
archivados.
Fuente: Elaboración propia
CUADRO 59: ESPECIFICACIÓN DE CASO DE USO ELIMINAR ARCHIVADO
CASO DE USO ELIMINAR ARCHIVADO Descripción El sistema provee el soporte necesario para eliminar el estado de
archivado de un documento externo, pasándolo a la lista de
documentos atendidos.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase “Documentos archivados”, el
empleado debe seleccionar un documento y proceder a
eliminar el archivado de dicho documento.
2. El sistema procede a quitar el estado de archivado el
documento.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Debe haber documento externo archivado y seleccionado.
Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 60: ESPECIFICACIÓN DE CASO DE USO IMPRIMIR LISTADO DE
DOCUMENTOS ARCHIVADOS
138
CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS ARCHIVADOS
Descripción El sistema provee el soporte necesario para la impresión del listado de
documentos archivados.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase que se muestra al ingresar al menú
“Documentos archivados”, la tramitadora elige la opción “Imprimir
listado”.
2. El sistema mostrará una nueva interfase con la vista previa del reporte
que muestra los datos de los documentos archivados ordenados por
fecha de archivo. Asimismo el sistema muestra las opciones para
exportar en formato pdf o imprimir el reporte.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 61: ESPECIFICACIÓN DE CASO DE USO
UBICAR DOCUMENTO EXTERNO
CASO DE USO UBICAR DOCUMENTO EXTERNO
Descripción El empleado puede mostrar una lista de los documentos externos
(anulados o no y archivados o no).
Flujo de eventos FLUJO BÁSICO
1. El empleado elige del menú “Gestión de documentos” la opción
“Ubicar documento externo”.
2. El sistema mostrará la lista de estos documentos, pudiendo ser
cambiado de acuerdo a la fecha de registro y asunto.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Punto de
extensión
Al ingresar a la lista de los documentos externos, el empleado puede
mostrar adjuntos del documento, mostrar seguimiento del documento o
imprimir el listado de documentos externos.
Fuente: Elaboración propia
CUADRO 62: ESPECIFICACIÓN DE CASO DE USO
UBICAR DOCUMENTO INTERNO
139
CASO DE USO UBICAR DOCUMENTO INTERNO
Descripción El empleado puede mostrar una lista de los documentos internos
(anulados o no).
Flujo de eventos FLUJO BÁSICO
1. El empleado elige del menú “Gestión de documentos” la opción
“Ubicar documento interno”.
2. El sistema mostrará la lista de estos documentos, pudiendo ser
cambiado de acuerdo al tipo de serie documental, la fecha de
emisión y asunto.
Precondiciones El empleado debe haber validado su cuenta de usuario.
Postcondiciones Ninguna.
Punto de
extensión
Al ingresar a la lista de los documentos internos, el empleado puede
mostrar el documento o imprimir el listado de documentos internos.
Fuente: Elaboración propia
CUADRO 63: ESPECIFICACIÓN DE CASO DE USO MOSTRAR
DOCUMENTO INTERNO
CASO DE USO MOSTRAR DOCUMENTO INTERNO Descripción El sistema provee el soporte necesario para visualizar el documento
interno digitalizado que ha sido seleccionado.
Flujo de eventos FLUJO BÁSICO
1. Estando en la interfase “Ubicar documento interno”, el
empleado selecciona la opción “Mostrar documento”
2. El sistema muestra el documento en formato PDF buscable.
Precondiciones El empleado debe haber validado su cuenta de usuario.
El documento debe tener documento adjunto.
Postcondiciones Ninguna.
Fuente: Elaboración propia
CUADRO 64: ESPECIFICACIÓN DE CASO DE USO CONSULTAR ESTADO
DE UN DOCUMENTO
140
CASO DE USO CONSULTAR ESTADO DE UN DOCUMENTO Descripción El sistema provee el soporte necesario para brindar al usuario el estado
de su documento y el seguimiento del mismo.
Flujo de eventos FLUJO BÁSICO
1. El usuario ingresa a la web municipal y elige la opción “Trámite
documentario”.
2. El tramitador automatizado muestra una pantalla solicitando el
código del trámite realizado por el usuario, el cual figura en el
ticket que entregó la tramitadora al usuario al momento de
registrar su documento.
3. El usuario ingresa el código del documento.
4. A continuación el tramitador automatizado muestra el estado del
documento, así como el seguimiento del mismo.
Precondiciones Ninguna.
Post condiciones
Ninguna.
Fuente: Elaboración propia
5.2.2. Análisis y Diseño:
El objetivo principal de esta disciplina es transformar los
requerimientos a una especificación que describa cómo implementar el
sistema en la institución. En el análisis fundamentalmente se tratará de
obtener una visión acerca de la funcionalidad del sistema de software a
desarrollar, por tal motivo este se interesa en los requerimientos
funcionales. Por otro lado, el diseño es un refinamiento que toma en
cuenta los requerimientos no funcionales, por lo cual se centra en como
el sistema cumple sus objetivos.
Los principales objetivos en esta disciplina son:
• Adaptar el diseño para que sea consistente con el entorno de
implementación.
• Desarrollar una arquitectura para el sistema.
• Transformar los requerimientos al diseño del futuro sistema.
Al principio de la fase de elaboración hay que definir una
arquitectura candidata: crear un esquema inicial de la arquitectura del
sistema, identificar clases de análisis y actualizar las realizaciones de los
Casos de Uso con las interacciones de las clases de análisis.
141
Durante la fase de elaboración se va refinando esta arquitectura
hasta llegar a su forma definitiva. En cada iteración hay que analizar el
comportamiento para diseñar componentes.
5.2.2.1. Modelo de Análisis:
A través de este modelo se representará la estructura global del
sistema, se describirá la realización de los casos de uso, servirá como
una abstracción del Modelo de Diseño y se centrará en los
requerimientos funcionales. Este modelo de análisis no es un diagrama
final que describe todos los posibles conceptos y sus relaciones, es un
primer intento por definir los conceptos claves que describen el sistema.
Su utilidad radica en que permite una apreciación global conceptual del
sistema. Puede contener: las clases y paquetes de análisis, las
realizaciones de los casos de uso, las relaciones y los diagramas.
A diferencia del Modelo de Casos de Uso que captura la
funcionalidad del sistema, el Modelo de Análisis da forma a la
arquitectura para soportar las funcionalidades que en el anterior modelo
se expresa. Para representar los diagramas del Modelo de Análisis se
empleará los diagramas UML de Colaboración.
a) Diagramas de Colaboración (DC): Un Diagrama de
Colaboración muestra una interacción organizada basándose en los
objetos que toman parte en la interacción y los enlaces entre los
mismos. Estos diagramas muestran las relaciones entre los roles de los
objetos. Cada diagrama de colaboración hará una referencia directa a
cada caso de uso mostrado en la etapa de requisitos, así como también
a cada interfase mostrada en la etapa de diseño. La secuencia de los
mensajes y los flujos de ejecución concurrentes se determinarán
explícitamente mediante números de secuencia. A continuación se
presentan los diagramas de colaboración de los principales procesos:
a.1) Administración del sistema
FIGURA Nº 16: Diagrama de colaboración: Listar serie documental
142
BSDOC : Buscador Serie documental
LSD : Listar serie documentales : Administrador
MSD : ModificadorSeriedocumental
ESD : Eliminador_seriedocumental
: Seriedocumental
BTO : Buscador todos
BXGDOC : Buscador de serie por grupo
BXAR : Buscador por área
RSD : Registradorseriedocumental
: Registra grupo documental
: Registradorseriedoc
15: Mensaje de confirmación
RGD : Registrador_grupodocumental
3: Leer() 2: Buscar serie(nombreserie)
4: Listado series
21: Registrar grupo doc.
19: Modificar seried doc.
14: Eliminar serie(codserie)
11: Buscar serie(codarea)
13: Listado series por área
5: Buscar todos
7: Listado series
8: Buscar serie (codgrupodoc)
10: Listado series por grupo
17: Registrar serie doc.
1: Registrar serie documental
20: Mostrar()
16: Eliminar()
22: Mostrar()
9: Leer()
12: Leer()
6: Leer()
18: Mostrar()
Fuente: Elaboración propia
FIGURA Nº 17: Diagrama de colaboración: Registrar serie documental
143
IGD : Indicar grupo documentario
A : Adminis trador IURSD : Registradorseriedoc
SD : Seriedocumental
IREQ : AsignarRequisitos
GD : Grupodocumental
AR : Area IAR : Indicar Area
: Requisitosseriedoc
S : Salir
: Registradorseriedocumental
11: Validar Formulario
3: Leer()
1: RegistrarSeriedoc
2: Indicar grupodoc(codgrupodoc)
4: Listar gruposdocumentarios
5: Inicar area(codarea)
7: Listar área
8: Indicarrequisitos
10: Listar requisitos
14: Salir de la interfase
12: Registrar serie documental
9: Leer()
6: Leer()
13: Guardar()
Fuente: Elaboración propia
FIGURA Nº 18: Diagrama de colaboración: Registrar grupo documental
A : Administrador RGD : Registra grupo documental
IG : Indicar grupo doc.
: Grupodocumental RGD : Regis trador_grupodocumental
MGD : Modificador_grupodocumental
1: Regis trar grupo documentario
2: Indicargrupo
4: Listado de grupos doc.
5: Regis trar grupo doc.
7: Modificar grupo doc.
3: Leer()
6: Guardar()
8: Guardar()
Fuente: Elaboración propia
FIGURA Nº 19: Diagrama de colaboración: Registrar área
144
: Administrador RAR : Registra area : Area
IAP : Indicar area padre
RAR : Registrador Area
MAR : Modificador area
1: Registrar área
2: Indicar área padre
4: Listar áreas
7: Modificar área
5: Registrar área
3: Leer()
6: Guardar()
8: Guardar()
Fuente: Elaboración propia
FIGURA Nº 20: Diagrama de colaboración: Listar empleado
BE : BuscadorEmpleado
IE : RegistradorEmpleado
ME : ModificadorEmpleado
EE : EliminadorEmpleado
E : Empleado
IURE : Regis trador_Empleado A : Adminis trador
: Regis trador_Empleado
6: Mensaje de confirmación
ALP : As ignadorloginpermisos ALP : As ignarloginpermisos
3: Leer()
9: Mostrar()
11: Mostrar()
7: Elim inar()
2: BuscarEmpleado(nombre)
4: Lis tado de Empleados
8: Registrar empleado
10: Modificar empleado
5: Elim inar empleado(codemp)
12: As ignarloginpermisos
1: Regis trarempleado
13: Mostrar()
Fuente: Elaboración propia
145
FIGURA Nº 21: Diagrama de colaboración: Registrar empleado
IA : Indicar Area
: Ubicacgeografica
: Area
: Cargo
A : Adminis trador
IC : Indicar cargo
IUG : Indicar ubicacgeografica
IURE : Regis trador_Empleado
: Regis tradorEmpleado
: ModificadorEmpleado
: Empleado
11: Validar formulario
3: Leer()
1: Registrar empleado
6: Leer()
9: Leer()
2: Indicar área
4: Listar áreas
5: Indicar cargo
7: Lis tar cargos
8: Indicar ubigeo
10: Listar dpto, prov, dis t.
12: Registrar empleado
14: Modificar empleado
13: Guardar()
15: Guardar()
Fuente: Elaboración propia
FIGURA Nº 22: Diagrama de colaboración: Asignar usuario y permisos
A : Administrador ALP : Asignadorloginpermisos PEUS : Perusuario ALP : Asignarloginpermisos
3: Valida formulario
1: Asignar login y permisos
2: Asignar login y
permisos(codemp) 4: Guardar()
Fuente: Elaboración propia
146
a.2) Registro de documentos
FIGURA Nº 23: Diagrama de colaboración: Listar documentos externos
registrados
T : Tramitadora LDR : Lis tar doc.ext.registrados
: Documento
BDOC : Buscar documento
ADOC : Anuladordedocumento
GTI : Generadordeticket
RDE : Registrador doc.externo
MDE : Modificador docexterno
DDE : Derivadordocexterno
RDE : Registradordocexterno
DDE : Derivador doc externo
GTD : Generador_ticket
6: Mensaje de confirmación
IDOC : Impresor_docextregist.
MAD : Mostrar adjuntos VAD : Visualizador de adjuntos
1: Registrar documento externo
2: Buscar documento(fechareg, asunto)
4: Lis tado doc. ext.registrados
5: Anular documento(coddoc)
8: Imprim ir lis tado doc. ext.reg.
10: Imprime reporte
11: Registrar_doc_ext
13: Modificar doc_ext
15: Derivar documento
17: Generar ticket(coddoc)
19: Mostrar adjunto(coddoc)
3: Leer()
7: Anular()
9: Leer()
18: Mostrar()
12: Mostrar()
14: Mostrar()
16: Mostrar()
20: Mostrar()
FIGURA Nº 24: Diagrama de colaboración: Registrar documento externo
147
IURD : Registradordocexterno T : Tramitadora
BUS : Buscar usuario
RUS : Registrar usuario
GAD : Gestionador adjuntos
ARE : Gestionador referencias
RDE : Registrador documento ext D : Documento
GRE : Gestionador_referencias
GAD : Gestionador_adjuntos
RUS : Registrador_usuario
MDE : Modificador documento ext
BUS : Buscador_usuario
13: Validar formulario
2: Buscar usuario(tipo,nombre)
4: Registrar usuario
5: Gestionar referencias
8: Gestionar adjuntos
10: Registrar documento externo
12: Modificar doc. ext.
1: Registrar documento
3: Mostrar()
6: Mostrar()
9: Mostrar()
7: Mostrar()
11: Grabar()
14: Grabar()
Fuente: Elaboración propia
FIGURA Nº 25: Diagrama de colaboración: Buscar usuario
BUS : Buscador_usuario T : Tram itadora : Usuario B_U : Buscar usuario
2: Buscarusuario(tipo, nombre)
4: Lis tar usuarios
1: Buscar usuario 3: Leer()
Fuente: Elaboración propia
FIGURA Nº 26: Diagrama de colaboración: Registrar usuario
T : Tramitadora RUS : Registrador_usuario
: Ubicacgeografica
RUS : Registrador usuario
MUS : Modificador usuario
IUG : Indicar ubicacgeografica
: Usuario
6: Validar formulario
1: Registrar usuario 5: Registrar usuario
8: Modificar usuario
2: Indicar Ubic. geog.
4: Leer dist., prov, dpto
7: Guardar()
9: Guardar()
3: Leer()
Fuente: Elaboración propia
148
FIGURA Nº 27: Diagrama de colaboración: Gestionar adjuntos
T : Tramitadora IUGA : Gestionador_adjuntos BAR : Agregar archivos adj ADJ : Adjunto
EAD : Eliminar adjunto
IAD : Indicar adjuntos 8: Mensaje de confirmación
1: Gestionar adjuntos 5: Agregar adj.
7: Eliminar adj.
2: Indicar adjuntos
4: Listar archivos adj.
6: Guardar()
9: Eliminar()
3: Leer()
Fuente: Elaboración propia
FIGURA Nº 28: Diagrama de colaboración: Gestionar referencias
T : Tramitadora : Gestionador_referencias ERE : Eliminar referencia
ARE : Agregar referencia REF : Referencia
BDE : Buscar documento D : Documento 6: Mensaje de confirmación
1: Gestionar referencias 5: Eliminar referencia
8: Agregar referencia
2: Buscar documento(fecharegistro, asunto)
4: Listado de documentos externos
7: Eliminar()
9: Guardar()
3: Leer
Fuente: Elaboración propia
FIGURA Nº 29: Diagrama de colaboración: Derivar documento
149
T : Tramitadora IUDD : Derivador doc externo
IA : Indicar Area A : Area
DDE : Derivadordocexterno : Documento
6: Validar formulario
1: Derivar documento
2: Indicar area destino
4: Listar áreas
5: Derivar documento
3: Leer()
7: Guardar()
Fuente: Elaboración propia
FIGURA Nº 30: Diagrama de colaboración: Generar ticket
T : Tram itadora GT : Generador_ticket
: Salir
ITI : Impresor ticket : Documento
1: Generar ticket 2: Imprimir ticket
4: Imprime ticket
5: Salir de la interfase
3: Leer()
Fuente: Elaboración propia
FIGURA Nº 31: Diagrama de colaboración: Mostrar adjuntos
T : Tramitadora IUVA : Visualizador de adjuntos
IA : Indicar adjuntos A : Adjunto
MA : Mostrador_adjunto
1: Mostrar adjuntos
2: Indicar adjuntos
4: Listar adjuntos
5: Mostrar adjunto
7: Muestra adjunto
3: Leer
6: Leer ruta
Fuente: Elaboración propia
150
FIGURA Nº 32: Diagrama de colaboración: Listar documentos externos derivados
T : Tramitadora LDD : Listar doc.ext.derivados
: Buscar documento : Documento
IDD : Impresordoc.derivados
: Mostrar adjuntos : Visualizador de adjuntos
1: Lis tar doc. ext. derivados
2: Buscar doc(fechaenvio, asunto) 3: Leer()
4: Lis tado doc.derivados
5: Imprimir listado doc. derivados 6: Leer()
7: Imprime reporte
8: Mostrar adjuntos(coddoc) 9: Mostrar()
Fuente: Elaboración propia
FIGURA Nº 33: Diagrama de colaboración: Listar documentos anulados
T : Tramitadora LDA : Listar documentos anulados
BD : Buscar documento
MA : Mostrador_adjunto : Visualizador de adjuntos
IDA : Impresor doc.anulados
: Documento
RAD : Restaurador de documento
1: Listar doc.anulados
2: Buscar doc.(tipo, fecha reg., asunto)
4: Listado de doc. anulados
8: Mostrar adjunto(codoc)
5: Imprimir listado doc.anulados
7: Imprime listado
9: Restaurar doc.(coddoc)
3: Leer()
11: Mostrar()
6: Leer()
10: Restaurar()
Fuente: Elaboración propia
FIGURA Nº 34: Diagrama de colaboración: Listar documentos internos registrados
151
T : Tramitadora LDI : Listar documentos int. reg.
BD : Buscar documento
AD : Anuladordedocumento
IDI : Impresor lis t.doc.internos
RDI : Registrador doc.interno
MDI : Modificador doc. interno
D : Documento
RDI : Registrador doc. interno
6: Mensaje de confirmación
1: Registrar doc. interno
2: Buscar doc. int.(Fecha emision, asunto)
4: Listado de doc. internos reg.
5: Anular doc. int.(coddoc)
8: Imprimir list.doc.int.
10: Imprime listado
11: Registrar doc. interno
13: Modificador doc. interno
3: Leer()
7: Eliminar()
9: Leer()
12: Mostrar()
14: Mostrar()
Fuente: Elaboración propia
FIGURA Nº 35: Diagrama de colaboración: Registrar documento interno
T : Tram itadora IURDI : Registrador doc. interno
ISD : Indicar serie documental : Seriedocumental
IAR : Indicar Area : Area
RDI : Registrador doc.interno
MDI : Modificador doc. interno
: Documento
IAA : Indicar archivo adjunto : Adjunto
1: Registrar doc. interno
2: Indicar serie doc. 3: Leer()
4: Listado serie doc.
5: Indicar área 6: Leer()
7: Listado área
8: Indicar arch. adj. 9: Leer()
10: Ruta de adjunto
11: Registrar doc. interno
12: Validar formulario
13: Grabar()
14: Modificar doc. interno 15: Grabar()
Fuente: Elaboración propia
a.3) Gestión de documentos
152
FIGURA Nº 36: Diagrama de colaboración: Listar documentos pendientes de atención
E : Empleado_ LDPA : Listar documentos pend.atenc.
BDO : Buscador documento D : Documento
IDPA : Impresor doc.pen.atenc.
EDO : Da_proveido DDE : Derivador doc externo
MAD : Mostrador_adjunto
CAT : Concl_atención CATD : Concl_atencion
VAD : Visualizador de adjuntos
MSEG : Mostrador seguimiento MSE : Mostrador_seguimiento
1: Listar doc.pend.atención
2: Buscar doc.(fecha envío, asunto)
4: Listado doc. pend. atenc.
5: Imprimir listado
7: Imprime listado
8: Dar proveido(coddoc)
10: Mostrar adjunto(coddoc)
12: Conluir atención(coddoc)
14: Mostrar seguimiento(coddoc)
3: Leer()
6: Leer()
9: Mostrar()
11: Mostrar()
13: Mostrar()
15: Mostrar()
Fuente: Elaboración propia
FIGURA Nº 37: Diagrama de colaboración: Concluir atención
E : Empleado_ CAT : Concl_atencion MOV : Movimientodoc CAT : Concl_atención
1: Concluir atención(coddoc) 2: Concluir atención doc. 3: Guardar()
Fuente: Elaboración propia
153
FIGURA Nº 38: Diagrama de colaboración: Mostrar seguimiento
E : Empleado_ MSEG : Mostrador_seguimiento MSEG : Mostrador seguimiento MOV : Movimientodoc
1: Mostrar seguimiento() 3: Leer() 2: Mostrar seguimiento(coddoc)
4: Muestra seguimiento
Fuente: Elaboración propia
FIGURA Nº 39: Diagrama de colaboración: Listar documentos respondidos
E : Empleado_ LDR : Lis tar doc.respondidos
MAD : Mostrador_adjunto
MSEG : Mostrador seguimiento MSE : Mostrador_seguim iento
IDR : Impresor doc. respondidos D : Documento
VAD : Visualizador de adjuntos
BD : Buscador documento
1: Listar doc.respondidos
8: Mostrar adjunto (coddoc)
10: Mostrar seguimiento (coddoc)
5: Imprim ir doc. respondidos
7: Imprime listado doc. respondidos
2: Buscar doc(fecha_rpta, asunto)
4: Listado doc. respondidos
9: Mostrar()
11: Mostrar()
6: Leer()
3: Leer()
Fuente: Elaboración propia
FIGURA Nº 40: Diagrama de colaboración: Listar documentos atendidos
154
E : Empleado_ LDAT : Listar documentos atendidos IDA : Impresor doc. atendidos : Documento
MA : Mostrar adjuntos VAD : Visualizador de adjuntos
ADO : Archivar documento
MS : Mostrador_seguimiento MSE : Mostrador seguimiento
BDO : Buscador documento
1: Listar documentos atendidos 7: Imprimir lis tado doc. atendidos
9: Imprime lis tado doc. atend.
10: Mostrar adjuntos(coddoc)
5: Archivar documento(coddoc)
12: Mostrar seguimiento(coddoc)
2: Buscar documento(Fechaenvio, asunto)
4: Listado doc. atendidos
8: Leer()
11: Mostrar()
6: Guardar()
13: Mostrar()
3: Leer()
Fuente: Elaboración propia
FIGURA Nº 41: Diagrama de colaboración: Listar documentos archivados
155
E : Empleado_ LDA : Listar documentos archivados
D : Documento
MSE : Mostrador_seguimiento MSE : Mostrador seguimiento
DAD : Desarchivar documento
BDO : Buscador documento
IDA : Impresor doc. archivados
: Visualizador de adjuntos : Mostrar adjuntos
1: Listar documentos archivados
5: Imprimir doc. archivados
7: Imprime lis tado doc. archivados
10: Mostrar seguimiento(coddoc)
8: Desarchivar doc(coddoc)
2: Buscar doc(fecha archivo, asunto)
4: Lis tado doc. archivados
12: Mostrar ajunto(coddoc)
6: Leer()
11: Mostrar()
9: Grabar()
3: Leer()
13: Mostrar()
Fuente: Elaboración propia
FIGURA Nº 42: Diagrama de colaboración: Ubicar documento externo
E : Empleado_ UDOC : Ubicador documento externo
BDOC : Buscador documento D : Documento
IDE : Impresor doc. externos
VAD : Visualizador de adjuntos MAD : Mostrar adjuntos
1: Ubicar doc. externo
2: Ubicar doc. externo(fecha reg., asunto)
4: Listado doc. externos
5: Imprim ir doc. externos
7: Imprime listado doc. ext.
8: Mostrar adjuntos(coddoc)
3: Leer()
6: Leer()
9: Mostrar()
Fuente: Elaboración propia
FIGURA Nº 43: Diagrama de colaboración: Ubicar documento interno
156
E : Empleado_ UDI : Ubicar doc. interno I : Impresor list.doc.internos
BDO : Buscador documento
ISD : Indicar serie documental
VA : Visualizador de adjuntos MA : Mostrar adjuntos
SD : Seriedocumental
D : Documento
1: Ubicar doc. interno(coddoc) 8: Imprimir lis t. doc. internos
10: Imprime listado doc.int.
5: Buscar documento(seriedoc, fechaemision, asunto)
7: Listar documentos internos
2: Listar serie documental
4: Listar serie documental
11: Mostrar adjunto()
9: Leer()
6: Leer()
3: Leer()
12: Mostrar()
Fuente: Elaboración propia
5.3. Fase de construcción
El objetivo general de esta fase es alcanzar la capacidad operacional del
producto de software de forma incremental a través de las sucesivas
iteraciones. En esta fase todas las características, componentes, y
requerimientos serán integrados, implementados, y probados en su totalidad,
obteniendo una versión aceptable del producto comúnmente llamada versión
beta.
Se hará énfasis en controlar las operaciones realizadas, administrando los
recursos eficientemente, de tal forma que se optimicen los costos, los
calendarios y la calidad.
Los objetivos específicos de esta fase son:
• Minimizar los costos de desarrollo mediante la optimización de recursos
y evitando el tener que rehacer un trabajo o incluso desecharlo.
• Conseguir una calidad adecuada tan rápido como sea práctico.
• Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba)
tan rápido como sea práctico.
El hito en esta fase culmina con el desarrollo del sistema con calidad de
producción y la preparación para la entrega al equipo de transición. Toda la
funcionalidad debe haber sido implementada.
157
5.3.1. Análisis y Diseño
5.3.1.1. Modelo de Diseño
Es una abstracción del Modelo de Implementación y su
código fuente, el cual fundamentalmente se empleará para representar y
documentar su diseño. Será usado como entrada esencial en las
actividades relacionadas a implementación. Representará a los casos de
uso en el dominio de la solución. Para representar los diagramas del
Modelo de Diseño se emplearán diferentes diagramas de UML tales
como: Interfases, Diagramas de Secuencia y Diagramas de Clases.
a) Interfaces del Sistemas
FIGURA Nº 44: IU: Acceso al sistema
Fuente: Elaboración propia
158
FIGURA Nº 45: IU Principal del SISGEDOC
Fuente: Elaboración propia
a.1. Administración del Sistema
FIGURA Nº 46: Menú Administración del sistema
Fuente: Elaboración propia
FIGURA Nº 47: IU: Registrar área de trabajo
159
Fuente: Elaboración propia
FIGURA Nº 48: IU: Registrar empleado
Fuente: Elaboración propia
160
FIGURA Nº 49: IU: Registrar serie documental
Fuente: Elaboración propia
a.2. Registro de documentos FIGURA Nº 50: IU: Listar documentos externos
Fuente: Elaboración propia
161
FIGURA Nº 51: IU: Registrar documento externo
Fuente: Elaboración propia
FIGURA Nº 52: IU: Derivar documento
Fuente: Elaboración propia
FIGURA Nº 53: IU: Generar ticket
162
Fuente: Elaboración propia
FIGURA Nº 54: IU: Mostrar adjuntos de documento externo
Fuente: Elaboración propia
FIGURA Nº 55: IU: Listar documentos enviados
163
Fuente: Elaboración propia
FIGURA Nº 56: IU: Listar documentos eliminados
Fuente: Elaboración propia
FIGURA Nº 57: IU: Listar documentos internos registrados
164
Fuente: Elaboración propia
FIGURA Nº 58: IU: Registrar documento interno
Fuente: Elaboración propia
a.3. Gestión de documentos FIGURA Nº 59: IU: Listar documentos pendientes de atención
165
Fuente: Elaboración propia
FIGURA Nº 60: IU Listar documentos respondidos
Fuente: Elaboración propia
FIGURA Nº 61: IU Listar documentos atendidos
166
Fuente: Elaboración propia
FIGURA Nº 62: IU Listar documentos archivados
Fuente: Elaboración propia
FIGURA Nº 63: IU Ubicar documento externo
167
Fuente: Elaboración propia
FIGURA Nº 64: IU Ubicar documento interno
Fuente: Elaboración propia
FIGURA Nº 65: IU Mostrar documento interno
168
Fuente: Elaboración propia
b) Diagramas de secuencias
Un diagrama de secuencia muestra las interacciones
entre objetos ordenadas en secuencia temporal. Muestra los objetos que
se encuentran en el escenario y la secuencia de mensajes
intercambiados entre los objetos para llevar a cabo la funcionalidad
descrita por el escenario.
A continuación se presentarán los diagramas de
secuencia que documentarán el diseño desde el punto de vista de los
casos de uso, observando qué mensajes se envían a los objetos,
componentes o casos de uso y viendo en forma estimada, cuanto tiempo
consume el método invocado. Estos diagramas ayudarán también a
identificar los cuellos de botella potenciales, para así poder eliminarlos.
b.1. Administración del Sistema
FIGURA Nº 66: Diagrama de secuencia: Listar serie documental
BSDOC : Buscador Serie documental
LSD : Listar serie documentales : Administrador MSD : ModificadorSeriedo...
ESD : Eliminador_seriedo...
RGD : Registrador_grupo...
BXGDOC : Buscador de serie por grupo
BXAR : Buscador por área
: Seriedocumental BTO : Buscador todos RSD : Registradorseriedo...
: Registra grupo documental : Registradorseriedoc
Registrar serie documental
Buscar serie(nombreserie)
Leer()
Listado series
Buscar todos
Listado series
Buscar serie (codgrupodoc)
Listado series por grupo
Buscar serie(codarea)
Listado series por área
Eliminar serie(codserie)
Mensaje de confirmación
Leer()
Leer()
Eliminar()
Registrar serie doc.
Mostrar()
Modificar seried doc.
Mostrar()
Registrar grupo doc.
Mostrar()
Leer()
Fuente: Elaboración propia
170
FIGURA Nº 67: Diagrama de secuencia: Registrar serie documental
IGD : Indicar grupo documentario
A : Administrador IURSD : Registradorseriedoc SD : Seriedocumental IREQ : AsignarRequisitos S : Salir GD : Grupodocumental AR : Area RSD : Indicar Area : Requisitosseriedoc RSD : Registradorseriedo... RegistrarSeriedoc
Indicar grupodoc(codgrupodoc)
Leer()
Listar gruposdocumentarios
Inicar area(codarea)
Leer()
Listar área
Indicarrequisitos
Leer()
Listar requisitos
Validar Formulario
Registrar serie documental
Guardar()
Salir de la interfase
Fuente: Elaboración propia
171
FIGURA Nº 68: Diagrama de secuencia: Registrar grupo documental
A : Administrador RGD : Registra grupo documental IG : Indicar grupo doc. : Grupodocumental RGD : Registrador_grupo...
MGD : Modif icador_grupod...
Registrar grupo documentario
Indicargrupo
Leer()
Listado de grupos doc.
Registrar grupo doc.
Guardar()
Modificar grupo doc.
Guardar()
Fuente: Elaboración propia
172
FIGURA Nº 69: Diagrama de secuencia: Registrar área
: Administrador RAR : Registra area : Area IAP : Indicar area padre RAR : Registrador Area MAR : Modificador area
Registrar área
Indicar área padre
Leer()
Listar áreas
Registrar área
Guardar()
Modificar área
Guardar()
Fuente: Elaboración propia
FIGURA Nº 70: Diagrama de secuencia: Listar empleado
173
BE : BuscadorEmpleado IE : RegistradorEmpleado
ME : ModificadorEmpleado
EE : EliminadorEmpleado
E : Empleado IURE : Registrador_Empleado A : Administrador : Registrador_Empleado ALP : Asignadorloginpermisos ALP : Asignarloginpermisos Registrarempleado
BuscarEmpleado(nombre)
Leer()
Listado de Empleados
Eliminar empleado(codemp)
Mensaje de confirmación
Eliminar()
Registrar empleado
Mostrar()
Modificar empleado
Mostrar()
Asignarloginpermisos
Mostrar()
Fuente: Elaboración propia
FIGURA Nº 71: Diagrama de secuencia: Registrar empleado
174
IA : Indicar Area : Ubicacgeografica : Area : Cargo A : Administrador IC : Indicar cargo IUG : Indicar ubicacgeografica
IURE : Registrador_Empleado : RegistradorEmpleado : ModificadorEmpleado : Empleado
Registrar empleado
Indicar área
Leer()
Listar áreas
Indicar cargo
Leer()
Listar cargos
Indicar ubigeo
Leer()
Listar dpto, prov, dist.
Validar formulario
Registrar empleado
Guardar()
Modificar empleado
Guardar()
Fuente: Elaboración propia
FIGURA Nº 72: Diagrama de secuencia: Asignar usuario y permisos
175
A : Administrador ALP : Asignadorloginpermisos PEUS : Perusuario ALP : Asignarloginpermisos
Asignar login y permisos
Asignar login y
permisos(codemp)
Valida formulario
Guardar()
Fuente: Elaboración propia
b.2 Registro de documentos FIGURA Nº 73: Diagrama de secuencia: Listar documentos externos registrados
176
T : Tram it adora LDR : List ar doc. ext . r egist rados : Document o BDO C : Buscador docum ent o
ADO C : Anulador dedocument o
I DO C : I mpr esor_docext regist .
G TI : G enerador det icket RDE : Regist r ador doc. ext erno
M DE : Modif icador docext er no
DDE : Der ivador docext er no
RDE : Regist rador docext erno DDE : Der ivador doc ext er no G TD : G ener ador_t icket MAD : Most r ar adjunt os VAD : Visualizador de adjunt os
Regist r ar document o ext erno
Buscar document o( f echar eg, asunt o)
Leer( )
List ado doc. ext . regist rados
Anular document o( coddoc)
Mensaje de conf irm ación
Anular ( )
I mpr im ir list ado doc. ext . r eg.
Leer( )
I m pr ime r eport e
Regist r ar _doc_ext
Most r ar ( )
Modif icar doc_ext
Most r ar ( )
Der ivar docum ent o
M ost r ar ( )
G enerar t icket ( coddoc)
Most r ar ( )
Most r ar adjunt o( coddoc)
Most r ar ( )
Fuente: Elaboración propia
FIGURA Nº 74: Diagrama de secuencia: Registrar documento externo
177
IURD : Registradordocexterno T : Tramitadora BUS : Buscar usuario RUS : Registrar usuario GAD : Gestionador adjuntos
ARE : Gestionador referencias
RDE : Registrador documento ext
D : Documento GRE : Gestionador_referencias GAD : Gestionador_adjuntos RUS : Registrador_usuario MDE : Modificador documento ext
BUS : Buscador_usuario
Registrar documento
Buscar usuario(tipo,nombre)
Mostrar()
Registrar usuario
Gestionar referencias
Mostrar()
Mostrar()
Gestionar adjuntos
Mostrar()
Registrar documento externo
Grabar()
Modificar doc. ext.
Validar formulario
Grabar()
Fuente: Elaboración propia
FIGURA Nº 75: Diagrama de secuencia: Buscar usuario
178
BUS : Buscador_usuario T : Tramitadora : Usuario B_U : Buscar usuario
Buscar usuario
Buscarusuario(tipo, nombre)
Leer()
Listar usuarios
Fuente: Elaboración propia
FIGURA Nº 76: Diagrama de secuencia: Registrar usuario
179
T : Tramitadora RUS : Registrador_usuario : Ubicacgeografica RUS : Registrador usuario
MUS : Modificador usuario
IUG : Indicar ubicacgeografica
: Usuario
Registrar usuario
Indicar Ubic. geog.
Leer()
Leer dist., prov, dpto
Registrar usuario
Validar formulario
Guardar()
Modificar usuario
Guardar()
Fuente: Elaboración propia
FIGURA Nº 77: Diagrama de secuencia: Gestionar adjuntos
180
T : Tramitadora IUGA : Gestionador_adjuntos BAR : Agregar archivos adj
EAD : Eliminar adjunto ADJ : Adjunto IAD : Indicar adjuntos
Gestionar adjuntos
Indicar adjuntos
Leer()
Lis tar archivos adj.
Agregar adj.
Guardar()
Eliminar adj.
Mensaje de confirmación
Eliminar()
Fuente: Elaboración propia
FIGURA Nº 78: Diagrama de secuencia: Gestionar referencias
181
T : Tramitadora : Gestionador_referenc ias ERE : Eliminar referencia ARE : Agregar referencia REF : Referenc ia BDE : Buscador documento
D : Documento
Gestionar referencias
Buscar documento(fecharegis tro, asunto)
Leer
Lis tado de documentos externos
Eliminar referencia
Mensaje de confirmación
Eliminar()
Agregar referenc ia
Guardar()
Fuente: Elaboración propia
FIGURA Nº 79: Diagrama de secuencia: Derivar documento
182
T : Tramitadora IUDD : Derivador doc externo IA : Indicar Area A : Area DDE : Derivadordocexterno
: Documento
Derivar documento
Indicar area destino
Leer()
Listar áreas
Derivar documento
Validar formulario
Guardar()
Fuente: Elaboración propia
183
FIGURA Nº 80: Diagrama de secuencia: Generar ticket
T : Tramitadora GT : Generador_ticket : Salir ITI : Impresor ticket : Documento
Generar ticket
Imprimir ticket
Leer()
Imprime ticket
Salir de la interfase
Fuente: Elaboración propia
FIGURA Nº 81: Diagrama de secuencia: Mostrar adjuntos
184
T : Tramitadora IUVA : Visualizador de adjuntos IA : Indicar adjuntos A : Adjunto MA : Mostrador_adjunto
Mostrar adjuntos
Indicar adjuntos
Leer
Listar adjuntos
Mostrar adjunto
Leer ruta
Muestra adjunto
Fuente: Elaboración propia
FIGURA Nº 82: Diagrama de secuencia: Listar documentos externos derivados
185
T : Tramitadora LDD : Lis tar doc.ext.derivados : Buscador documento : Documento IDD : Impresordoc .der ivados
: Mostrar adjuntos : Visualizador de adjuntos Lis tar doc. ex t. derivados
Buscar doc(fechaenv io, asunto)
Leer()
Lis tado doc.derivados
Imprimir lis tado doc. derivados
Leer()
Imprime reporte
Mostrar adjuntos(coddoc)
Mostrar()
Fuente: Elaboración propia
FIGURA Nº 83: Diagrama de secuencia: Listar documentos anulados
186
T : Tramitadora LDA : Listar documentos anulados
BD : Buscador documento
MA : Mostrador_adjunto : Visualizador de adjuntos IDA : Impresor doc.anulados
: Documento RAD : Restaurador de documento
Listar doc.anulados
Buscar doc.(tipo, fecha reg., asunto)
Leer()
Listado de doc. anulados
Imprimir listado doc.anulados
Leer()
Imprime listado
Mostrar adjunto(codoc)
Restaurar doc.(coddoc)
Restaurar()
Mostrar()
Fuente: Elaboración propia
FIGURA Nº 84: Diagrama de secuencia: Listar documentos internos registrados
187
T : Tramitadora LDI : Listar documentos int. reg.BD : Buscador documento
AD : Anuladordedocumento
IDI : Impresor list.doc.internos
RDI : Registrador doc.interno
MDI : Modificador doc. interno
D : Documento RDI : Registrador doc. interno
Registrar doc. interno
Buscar doc. int.(Fecha emision, asunto)
Leer()
Listado de doc. internos reg.
Anular doc. int.(coddoc)
Mensaje de confirmación
E liminar()
Imprimir list.doc.int.
Leer()
Imprime listado
Registrar doc. interno
Mostrar()
Modificador doc. interno
Mostrar()
Fuente: Elaboración propia
FIGURA Nº 85: Diagrama de secuencia: Registrar documento interno
188
T : Tramitadora IURDI : Registrador doc. interno ISD : Indicar serie documental
: Seriedocumental IAR : Indicar Area : A rea RDI : Registrador doc.interno
MDI : Modificador doc. interno
: Documento IAA : Indicar archivo adjunto
: Adjunto
Registrar doc. interno
Indicar serie doc.
Leer()
Listado serie doc.
Indicar área
Leer()
Listado área
Indicar arch. adj.
Leer()
Ruta de adjunto
Registrar doc. interno
Validar formulario
Grabar()
Modificar doc. interno
Grabar()
Fuente: Elaboración propia
b.3 Gestión de documentos
189
FIGURA Nº 86: Diagrama de secuencia: Listar documentos pendientes de atención
E : Empleado_LDPA : Listar documentos pend.atenc.
BDO : Buscador documento
D : Documento IDPA : Impresor doc.pen.atenc.
EDO : Da_proveido DDE : Derivador doc externoMAD : Mostrador_adjunto CAT : Concl_atención CATD : Concl_atencionVAD : Visualizador de adjuntos MSEG : Mostrador seguimientoMSE : Mostrador_seguimiento
Listar doc.pend.atención
Buscar doc.(fecha envío, asunto)
Leer()
Listado doc. pend. atenc.
Imprimir listado
Leer()
Imprime listado
Dar proveido(coddoc)
Mostrar()
Mostrar adjunto(coddoc)
Mostrar()
Conluir atención(coddoc)
Mostrar()
Mostrar seguimiento(coddoc)
Mostrar()
Fuente: Elaboración propia
FIGURA Nº 87: Diagrama de secuencia: Concluir atención
190
E : Empleado_ CAT : Concl_atencion MOV : Movimientodoc CAT : Concl_atención
Concluir atención(coddoc)
Concluir atención doc.
Guardar()
Fuente: Elaboración propia
FIGURA Nº 88: Diagrama de secuencia: Mostrar seguimiento
191
E : Empleado_ MSEG : Mostrador_seguimiento
MSEG : Mostrador seguimiento MOV : Movimientodoc
Mostrar seguimiento()
Mostrar seguimiento(coddoc)
Leer()
Muestra seguimiento
Fuente: Elaboración propia
FIGURA Nº 89: Diagrama de secuencia: Listar documentos respondidos
192
E : Empleado_ LDR : Listar doc .respondidos MAD : Mos trador_adjunto MSEG : Mos trador seguimiento MSE : Mos trador_seguimiento
IDR : Impresor doc . respondidos
D : Documento VAD : Visualizador de adjuntos BD : Buscador documento
Lis tar doc.respondidos
Buscar doc (fecha_rpta, asunto)
Leer()
Lis tado doc . respondidos
Imprimir doc . respondidos
Leer()
Imprime lis tado doc. respondidos
Mostrar adjunto (coddoc )
Mos trar()
Mos trar seguimiento (coddoc)
Mos trar()
Fuente: Elaboración propia
FIGURA Nº 90: Diagrama de secuencia: Listar documentos atendidos
193
E : Empleado_ LDAT : Listar documentos atendidos IDA : Impresor doc. atendidos
: Documento MA : Mostrar adjuntos VAD : Visualizador de adjuntos ADO : Archivar documento
MS : Mostrador_seguimiento
MSE : Mostrador seguimiento BDO : Buscador documento
Listar documentos atendidos
Buscar documento(Fechaenvio, asunto)
Leer()
Listado doc. atendidos
Archivar documento(coddoc)
Guardar() Imprimir listado doc. atendidos
Leer()
Imprime listado doc. atend.
Mostrar adjuntos(coddoc)
Mostrar()
Mostrar seguimiento(coddoc)
Mostrar()
Fuente: Elaboración propia
FIGURA Nº 91: Diagrama de secuencia: Listar documentos archivados
194
E : Empleado_ LDA : Listar documentos archivados IDA : Impresor doc. archivados
D : Documento MSE : Mostrador_seguimiento
MSE : Mostrador seguimiento DAD : Desarchivar documento
BDO : Buscador documento
: V isualizador de adjuntos : Mostrar adjuntos
Listar documentos archivados
Buscar doc(fecha archivo, asunto)
Leer()
Listado doc. archivados
Imprimir doc. archivados
Leer()
Imprime listado doc. archivados
Desarchivar doc(coddoc)
Grabar()
Mostrar seguimiento(coddoc)
Mostrar()
Mostrar ajunto(coddoc)
Mostrar()
Fuente: Elaboración propia
FIGURA Nº 92: Diagrama de secuencia: Ubicar documento externo
195
E : Empleado_ UDOC : Ubicador documento externo BDOC : Buscador documento
D : Documento IDE : Impresor doc. externos
VAD : Visualizador de adjuntos MAD : Mostrar adjuntos
Ubicar doc. externo
Ubicar doc. externo(fecha reg., asunto)
Leer()
Listado doc. externos
Imprimir doc. externos
Leer()
Imprime listado doc. ext.
Mostrar adjuntos(coddoc)
Mostrar()
Fuente: Elaboración propia
FIGURA Nº 93: Diagrama de secuencia: Ubicar documento interno
196
E : Empleado_ UDI : Ubicar doc. internoI : Impresor lis t.doc.internos
BDO : Buscador documento
ISD : Indicar serie documental
VA : Visualizador de adjuntos MA : Mostrar adjuntos SD : Seriedocumental D : Documento
Ubicar doc. interno(coddoc)
Lis tar ser ie documental
Leer()
Lis tar serie documental Buscar documento(seriedoc, fechaemision, asunto)
Leer()
Listar documentos internos
Imprimir lis t. doc. internos
Leer()
Imprime lis tado doc.int.
Mostrar adjunto()
Mostrar()
Fuente: Elaboración propia
c) Diagrama de Clases
FIGURA 94: DIAGRAMA DE CLASES Pernatural
pernatsexo : String perdni : String
leer() insertar() modif icar() Eliminar()
Distrito
nombredistrito : String
Leer()
Departamento
Nombredepa : String
Leer()
Prov incia
nombre prov incia : String
Leer() 1..*
1 1..*
1
1..* 1 1 1..*
Rubro
rubdescrip : String
Leer()
Perjuridica
perjruc : String perrptante : String percargo : String
Leer() Insertar() Modif icar() Eliminar()
0..* 1 1 0..*
Adjunto
adjlinea : Integer adjnomarchiv o : String
Leer() Insertar() Modif icar() Eliminar()
Ref erencia
docref linea : Integer docref erencia : String
Leer() Insertar() Modif icar() Eliminar()
Grupo_documental
grupodocnombre : String grupodocdetalle : String grupodocestado : String
Leer() Insertar() Modif icar() Eliminar()
Serie_documental
seriedocnombre : String seriedoctipo : String seriedocplazorpta : Integer seriedocestado : String
Leer() Insertar() Modif icar() Anular()
1..* 1 1..* 1
Requisitos
reqnombre : String reqestado : String
Leer()
0..*
1..* 1..*
0..*
Cargo
carnombre : String cardescripcion : string
Leer()
Tipocontrato
connombre : String conobserv aciones : String
Leer()
Percontrato
contipo : Integer conf echaini : Date connro : String conarea : String concargo : Integer conobserv aciones : String conlogin : String conclav e : String conaccesos : String
Leer() Insertar() Modif icar() Eliminar()
1..*
1
1..*
1
1..* 1
1..* 1
Mov imiento
mov f echaenv io : String mov accion : Date mov f echaplazoatencion : Date mov f echarecepcion : Date mov f echaatencion : Date mov proveido : String mov estado : String mov estadof echa : Date mov observ aciones : String movmarcador : String
Leer() Insertar()
Area
codigo_area_arbol : String aredescripcion : String
Leer() Insertar() Modif icar() Eliminar()
1..*
1
1..*
1
1..* 1 1..* 1
1..*
1 1
1..*
Persona
PerNombre : String pertipo : String PerDireccion : String PerTelef ono : String PerTelef ono2 : String permail : String permail2 : String PerClase : Integer perestado : Integer
Leer() Insertar() Modif icar() Eliminar()
1
1
1
1
1..* 1 1..* 1
Documento
doctipo : String docnumero : String docf echaregistro : Date docprioridad : Integer docasunto : String docnumf olios : Integer docobserv acion : String docarchiv o : Integer docf echaemision : Date docanulado : Integer docf echaarchiv o : Date
Leer() Insertar() Modif icar() Anular() Archiv ar()
0..* 1
0..* 1
0..* 1
0..* 1
0..* 1
0..* 1
1..*
1 1
1..*
Fuente: Elaboración propia
199
5.3.2. Implementación
El objetivo principal que se busca en esta disciplina es convertir
los elementos del diseño en elementos de implementación, dichos
elementos son los archivos y códigos fuentes. Otra parte de esta
disciplina son las pruebas de unidad, las cuales se limitan a los
componentes de software implementados. De esta disciplina se
obtendrá un sistema estable.
Los objetivos específicos son:
• Determinar en qué orden se implementarán los elementos de
cada subsistema.
• Integrar el sistema siguiendo el plan.
• Notificar los errores de diseño, si se encuentran, actualizando
la documentación.
La estructura de todos los elementos implementados formará el
Modelo de Implementación.
5.3.2.1. Diagrama de Componentes:
El diagrama de componentes describirá los elementos
físicos del sistema, sus relaciones y dependencias. En la figura Nº 96, se
muestra las tres capas del sistema implementadas en el Visual Basic
2005.
La capa de Presentación que contiene los formularios de
mantenimientos, transacciones y reportes.
La capa Negocio, que contiene la lógica del negocio
correspondiente a validaciones y control de transacciones.
La capa de Lógica de Acceso a Datos, que está
conformada por las clases que realizarán las consultas y transacciones
SQL a la Base de Datos, según lo solicite la capa de Negocio. Está capa
contiene también el componente de conexión donde se configura la
Base de Datos.
200
FIGURA 96: Diagrama de Componentes
LÓGICA DE NEGOCIO
LÓGICO DE ACCESO A DATOS
PRESENTACIÓN
SERVIDOR WEB
PRESENTA CIÓN
SERVIDOR DE APLICACIÓN
BDGESDOC
Fuente: Elaboración propia
201
CUADRO 65: ESPECIFICACIÓN DE COMPONENTE
“ LÓGICA DE ACCESO A DATOS”
COMPONENTE CLASE PROCEDIMIENTO ALMACENADO
Clsdocumento
Grabaactualizadocumento Grabaadjunto Grabareferencia Eliminardocumento Mostrarseguimiento Registrarenvio Registrarconcluiratenc Restaurardocumento Desarchivardocumento buscarenvio borrarefyadj Verificaradjuntos Archivardocumento Listaradjundocumento Listardocumentosext: archivados, atendidos, eliminados, enviados, pendientes, respondidos. Listardocumentosint Listarpropietariodoc Listarrefdocumento Listarticket Listardocumentoint
Clsempleado
Listarempleado Registrarempleado Eliminarempleado Existeusuario
Clsseriedoc
Elimina_serie Eliminareqseries Eliminargrupo Graba_actualizagrupo Graba_actualizaserie Grabareqserie Listar_seriesxgrupo Listarestadoreq Listargrupos Listarseries
Clsciudad Recuperaciudad
Clsusuario
Graba_actualizapersona Graba_percontrato Graba_perjuridica Graba_pernatural Listapersonasactivas Recuperararea Recuperarcargo Recuperarrubro Listarusuariosxclase Listarusuarios Actualizalogin Eliminarusuario
LÓGICA DE
ACCESO A
DATOS
Clsarea Grabaactualizaarea Listaarea Eliminararea
COMPONENTE CLASES PROC Fuente: Elaboración propia
MIENTOS ALMACENADOS
202
5.3.2.2. Diagrama de Despliegue
FIGURA 97: Diagrama de despliegue
Servidor de aplicaciones
Servidor web
Estación JA02 JA07 Jefatura de área
Estación 01Unidad de Trám. Docum.
Impresora
Switch DLink Switch DLink
Servidor que alojará todos los componentes del sistema.
Serv idor que permitirá el acceso al sistema de Consulta de documentos por parte de los usuarios.
Equipos que se encuentran distribuidos en las jefaturas de área de la Municipalidad.
Equipo que se encuentra en la Unidad de Trámite documentario.
S.O. Windows XP Sistema GESDOC
S.O. Windows XP Sistema GESDOC
S.O. Windows Server 2003 SQL Server 2005 Presentación Consulta de doc.
S.O. Windows Server 2003 SQL Server 2005 Presentación Lógi ca del Negocio Lógio de acceso a datos
TCP/IP
TCP/IP TCP/IP
TCP/IP
TCP/IP
Puerto USB
Scanner HP SCANJET 2400 Puerto USB
Fuente: Elaboración propia
203
5.3.3. Medidas de Seguridad para el sistema
El plan de seguridad se estableció en función a las mejores
prácticas que plantea Microsoft en sus directivas de seguridad:
Figura 98: Directivas de seguridad en las tres capas del sistema
Fuente: Microsoft Corporation, Patterns & Practices. Directivas de seguridad, Diciembre de 2002
5.3.3.1. AUTENTICACIÓN (identificación segura)
Existe un mecanismo de autenticación
personalizado en el que la aplicación solicita un nombre
de usuario y una contraseña, brindándole tres
oportunidades para acceder, en caso contrario se cierra
la aplicación. Para esto se utilizan las siguientes políticas
de seguridad:
• El administrador del sistema, es el único usuario
encargado de asignar las contraseñas a los nuevos
usuarios del sistema.
• El administrador del sistema, es el único usuario
encargado de la base de datos y del sistema
operativo.
• Las contraseñas no pueden ser modificadas, sólo son
reemplazadas por completo.
• Las contraseñas serán encriptadas utilizando el
algoritmo SHA1 (Secure Hash Algorithm, Algoritmo
hash seguro de 128 bits). Si bien MD5 es el algoritmo
más rápido, genera un código relativamente pequeño,
por lo que al incrementar la longitud utilizando SHA1
204
reduce la ya escasa probabilidad de que dos textos
produzcan el mismo código.
• Los usuarios que tras 3 intentos no se hayan
identificado correctamente, serán expulsados del
sistema.
5.3.3.2. AUTORIZACIÓN:
• Acceso a ciertas funcionalidades.
• Las operaciones que realicen los usuarios en las
tablas más importantes del sistema serán
monitoreados durante todo el inicio de sesión.
• Se habilitan o deshabilitan controles para la
intervención del usuario.
• En la interfaz del usuario solo puede ver los
elementos, entradas de menú o paneles sobre los que
pueda actuar según las funciones que tenga el
usuario.
5.3.3.3. COMUNICACIÓN SEGURA:
Los componentes de la interfaz de usuario
únicamente se comunican con el usuario. Se evita
mostrar información confidencial sin una advertencia. Las
contraseñas nunca se muestran o transmiten en texto sin
formato.
5.3.3.4. AUDITORÍA:
Se realiza para ejecutar el seguimiento del usuario
y su actividad en la aplicación por motivos de seguridad,
para lo cual se utilizó una tabla adicional que almacene la
información de la auditoría.
Se especifican los triggers en operaciones DDL,
proporcionando un mecanismo adicional para auditar las
acciones DDL.
205
El reporte de auditoría será mostrado para los
documentos modificados, anulados, agregados:
• Usuario.
• Fecha y hora de operación.
• Equipo desde donde se accede.
• Tipo de operación
FIGURA Nº 99: IU Auditoría de operaciones con documentos
Fuente: Elaboración propia
5.3.3.5. ADMINISTRACIÓN DE PERFILES:
Asignación de roles y funciones desde el SQL
Server.
Los roles se utilizan para que los usuarios puedan
acceder o no a los objetos de las bases de datos como
tablas, procedimientos almacenados, etc., así como
ejecutar sentencias como select.
Una función es un objeto que tiene un conjunto de
permisos y que utilizaré para administrar adecuadamente
los permisos de un grupo de usuarios. SQL Server tiene
dos tipos de funciones: estándar y de aplicación.
206
Aún no se han elaborado las funciones de aplicación
que serán utilizadas, permitiendo a la aplicación
desarrollada y a la base de datos tener los permisos
cuando ejecuten la aplicación, esto quiere decir que si un
usuario ingresa al analizador de consultas no debe tener
acceso a ninguno de los objetos de la base de datos, sin
embargo se utiliza la protección a través de la aplicación
con la clave encriptada.
207
208
CAPITULO VI: ANÁLISIS COSTO BENEFICIO
En este capítulo el proyecto será evaluado no sólo desde el punto de vista
monetario, sino también considerando los beneficios intangibles que se
obtendrán.
Primero se establecerá los costos de inversión que deberá afrontar la
institución en la etapa inicial de la implementación, luego se definirá los gastos
concurrentes u operativos y por último los beneficios intangibles obtenidos.
Ahora bien, la Municipalidad Distrital de Jayanca tiene un moderno parque
informático, entre los que se encuentra servidores recientemente adquiridos a
través de donaciones y convenios con instituciones (SUNAT, (Coordinadora
Nacional de Radio, GTZ) y otros adquiridos por compras realizadas por la
Municipalidad), lo cual hace que los costos disminuyan considerablemente. La
mayoría de Pc’s tienen licencia de Microsoft Windows XP y Microsoft Office
2003.
6.1. Inversión Inicial
CUADRO 66: Costos de suministros
Descripción Unidad Cantidad Precio unitario Total (S/.)
Papel Bond A4 Millar 4 21 84.00 CDRW 700 MB Pz 3 3.00 9.00 Impresiones Hojas 600 0.30 180.00 Fotocopias Hojas 600 0.04 240.00 Anillados Unid. 3 3.00 9.00 Empastados Unid. 3 18.00 54.00
TOTAL 576.00 Fuente: Elaboración propia
CUADRO 67: Costos de personal
Descripción Nº horas Costo por hora(S/.) Total (S/.)
Análisis y Diseño 240 12 2880.00 Implementación 300 12 3600.00 Instalación y pruebas 100 10 1000.00 Capacitación y consultoría 80 10 800.00
TOTAL 8280.00 Fuente: Elaboración propia
CUADRO 68: Costos de Software
209
Descripción Total (S/.) Microsoft .Net framework 2.0 0.00 Microsoft Visual Basic 2005 Express 0.00 Software administración de base de datos SQL Server 2005 (*)
5500.00
Sistema operativo de Servidor Microsoft Windows 2003 Server
2331.00
TOTAL 7831.00 (*) Costos obtenidos de: http://www.microsoft.com/latam/office/livecomm/howtobuy/default.mspx#EAC No se consideran costos de licencia Windows XP, puesto que ya se cuenta con éstas. Fuente: Elaboración propia
CUADRO 69: Costos de Hardware (*)
Descripción Total (S/.) Servidor de aplicación 5000.00 Estaciones de trabajo 0.00 Suministros de red 0.00 Escáner 0.00 UPS 2500 W. 734.00 TOTAL 5734.00
(*) No se consideran algunos costos, puesto que la institución tiene disponible actualmente un servidor y equipos necesarios en cada área para la implantación de la aplicación. En relación al escáner, se cuenta ya con este equipo, el cual viene cumpliendo la funcionalidad de digitalización en eventuales circunstancias. Fuente: Elaboración propia
6.2. Gastos concurrentes u Operativos
CUADRO 70: Gastos operativos en Personal
Descripción Total (S/.)
Administración del sistema (1) 0.00 Administrador del servidor (1) 0.00 Registradora (Personal del área de trámite documentario) (2)
0.00
TOTAL 0.00
(1) Recientemente la Municipalidad cuenta con un profesional designado como Jefe de la Unidad de Informática que estará a cargo de la administración de los sistemas y del servidor. (2) El personal encargado del registro y digitalización de documentos será del área de trámite documentario, por lo tanto la inversión para el recurso humano referido a estas dos personas se encuentra incluida dentro del pago mensual según las funciones establecidas que cumplen en la Municipalidad Fuente: Elaboración propia
6.3. Resumen de los costos totales de implementación
210
CUADRO 71: Resumen de costos de implementación
Descripción Total (S/.)
Costos de suministros 576.00 Costos de personal 8280.00 Costos de Hardware 5734.00 Costos de Software 7831.00 Gastos operativos en personal 0.00 TOTAL 22421.00
6.4. Costo/Beneficio
El costo beneficio del proyecto esta reflejado en los tiempos de respuesta que
el sistema brinda a los usuarios finales, por lo tanto el cálculo del VAN y TIR no
representa un cálculo determinante para medir la factibilidad del presente
proyecto. Es por ello que se ha determinado cuantitativamente en tiempo el
beneficio que se ha obtenido. Los beneficios que presentamos a continuación
son beneficios intangibles en costo.
Ø Mejora de la satisfacción del cliente en 64,10%: 95% de usuarios
satisfechos por la atención recibida, aunque se considera que para llegar
a este nivel será necesario sensibilización y difusión del nuevo sistema.
Ø Aumento de productividad de personal en las áreas involucradas.
Ø Ahorro del tiempo de usuarios que solicitan información o consulta el
estado de un documento: Si un usuario ocupaba 2 horas en promedio
para conocer el estado de su documento, con el uso del sistema la
realizará en un promedio de tres minutos. Hay que considerar que el
usuario además consume tiempo de traslado a la Municipalidad de
Jayanca.
Ø Disminución del tiempo de localización y recuperación de los
documentos al ser accesible desde el propio puesto de trabajo.
Ø Disminución del tiempo en tratamiento y gestión, el usuario no tiene que
rearchivar cada documento al trabajar con él en pantalla.
Ø Disminución de costes administrativos,
Ø Recorte del espacio de almacenamiento y reaprovechamiento del
mismo. Los originales en papel pueden enviarse al archivo de custodia.
211
Un CDROM puede almacenar 120 mil páginas de listados o 15 mil
páginas escaneadas.
Ø Eliminación de los documentos duplicados al estar accesibles en
cualquier momento desde cualquier puesto.
Ø Drástica reducción en material de archivo al suprimirse los listados en
papel y las copias.
Ø Disminución de la pérdida de oportunidad.
Ø Mayor control y seguridad; el acceso a los documentos puede
restringirse a determinados usuarios definiendo niveles de
confidencialidad.
Ø No existen documentos extraviados o perdidos.
Ø Mejora de la calidad del servicio ofrecido.
Ø Rendimiento en la consulta, con multiplicidad de criterios de
recuperación.
Estos beneficios han sido cuantificados en el capítulo II.
212
213
CAPITULO VII: CONCLUSIONES
• Se recopiló información sobre la institución que constituyó la
base para el entendimiento y análisis de la problemática en el
aspecto documentario. Utilizando entrevistas a los trabajadores
de la municipalidad distrital de Jayanca y usuarios externos.
• A partir de la información recopilada se realizó un diagnóstico de
la situación respecto al sistema de gestión documentaria en la
Municipalidad Distrital de Jayanca, para lo cual se contó con el
financiamiento de la Oficina Regional de Inwent – Internationale
Weiterbildung und Entwicklung gGmbH (Capacity Building
International, Germany). Al realizar el análisis de los procesos
administrativos se encontró inconsistencias en el TUPA.
• Los procesos básicos que involucran la gestión documentaria en
la Municipalidad distrital de Jayanca son: Registro del
documento, que incluye la digitalización del documento y
gestión del documento, que en caso de ser documento externo
inicia con el trámite del mismo, la atención y consulta del
estado del mismo, y en el caso de ser documento interno, sólo
la consulta del documento.
• Estos procesos fueron diseñados utilizando la metodología RUP
en las etapas de análisis y diseño elaborando los artefactos
establecidos por la metodología RUP.
• Puesto que se aplicó una metodología orientada a objetos en
todas sus fases y disciplinas, se realizó la implementación
(construcción) mediante esta técnica de programación,
utilizando el lenguaje de programación Visual Basic 2005,
siendo necesario realizar la separación lógica de la aplicación
en capas (presentación, negocio y datos).
• Se plantearon las medidas de Seguridad para el sistema, las
cuales estuvieron basadas en función a las mejores prácticas
214
que plantea Microsoft en sus directivas de seguridad en las tres
capas del sistema: Autenticación, Autorización, comunicación
segura, auditoria y administración de perfiles.
• La inversión inicial necesaria para la implementación del
sistema es de S/. 22421. Por otro lado el costo beneficio del
proyecto esta reflejado en los tiempos de respuesta que el
sistema brinda a los usuarios finales, por lo tanto el cálculo del
VAN y TIR no representa un cálculo determinante para medir la
factibilidad del presente proyecto. Es por ello que se determinó
cuantitativamente en tiempo el beneficio que se ha obtenido.
215
216
CAPITULO VIII: RECOMENDACIONES
ü Realizar un adecuado rediseño de los procedimientos que conduzcan a una correcta actuación administrativa y optimización de procesos que apoyen el
proceso de automatización en la Municipalidad Distrital de Jayanca.
ü Se recomienda evaluar los servicios que brinda al usuario la Municipalidad Distrital de Jayanca, después de aplicar cambios sustanciales en los
procesos administrativos, con la finalidad de conocer de manera objetiva el
grado de satisfacción ciudadano con respecto a los servicios que brinda.
ü Implantar progresivamente un workflow adecuado a la naturaleza de todos los procesos rediseñados en la Municipalidad distrital de Jayanca.
ü Se recomienda tomar en consideración los criterios de seguridad
formulados, durante la implantación del software propuesto.
217
218
REFERENCIAS BIBLIOGRÁFICAS
8.1. Bibliografía:
ü ANCAJIMA M., Víctor Angel, Análisis, Diseño y Prototipos del Sistema Trámite Documentario para la Universidad Los Ángeles de Chimbote –
Perú, 2005
ü BOZA D., Beatriz, Manual de Buenas Prácticas Gubernamentales 2006, Ciudadanos al Día, Lima, 2006.
ü CONTRERAS H, Felipe; FORERO G., Felipe, Diseño de un modelo para la implantación de un sistema de gestión documental en áreas u
organizaciones jurídicas, Bogotá, Colombia; 2005.
ü DIAZ C., Mario; SUCLUPE A., Danny. Sistema de Información y el Plan de Tecnología de clasificación y búsqueda de expedientes del Archivo
Regional de Lambayeque, Chiclayo, 2004.
ü FAHSBENDER C., Juan Carlos, Desde Adentro: La organización del gobierno local, Edición Universidad de Piura, Primera edición, Perú, 2007
ü GINESTÁ, Marc, PEÑA G. Álvaro, Ingeniería del software en entornos de Software Libre, España, 2005.
ü LANDA M., Luz M., Gestión de Documentos: El Caso Consorcio SMS, Lima, Perú; 2002.
ü LAUDON, Kaneth c.; LAUDON, Jane P., Administración de los Sistemas de Información, Organización y Tecnología, Ediciones Pretince Hall, Tercera
edición, 2001.
ü NAVAS Y., Grimaldo. Sistema de Gestión Documental para la Dirección de Estudios y Desarrollo Agrícola del PEOT. Lambayeque, 2005
ü OROZCO S., Juan Carlos. Desarrollo de un Sistema de Control
documentario para el apoyo a la gestión de la Municipalidad Provincial de
Ferreñafe”, Lambayeque Perú, 2005.
ü RUMBAUGH J, Jacobson I, Booch G., El lenguaje unificado de modelado Manual de referencia, Racional Software Corporation, Editorial Pearson,
España, 2000.
ü TAMAYO V., Mario. Metodología formal de la investigación científica. . Primera edición, 1989. Editorial Limusa S.A.
219
ü TORO G, Gilberto; CRISTANCHO M., Camilo, Gobierno Electrónico local e inclusión digital, Colombia, 2006.
8.2. Citas Electrónicas:
ü ADMINISTRATIVOS DE LA JUNTA DE ANDALUCIA. Turno libre. Temario. Volumen III. , junio 2005, editorial MAD. [Disponible en
http://books.google.com.pe] [Consulta: 18 septiembre 2007]
ü FERNÁNDEZ G., Paloma, Manual de organización de Archivos de gestión en las Oficinas municipales, ediciones Adhara, Segunda edición, 1999.
[Disponible en http://www.cemci.org/archivos.pdf] [Consulta: 19 septiembre
2007]
ü HEREDIA H, Antonia, El Debate sobre la Gestión Documental Métodos de Información, Archivo General de Andalucia, España. ∙ Vol 5 Nº 2223
EneroMarzo 1998. [Consulta: 15 septiembre 2007]
ü INEI – Perú. Conceptos de Seguridad Informática, Lima, Marzo de 2000. [Disponible en www.ongei.gob.pe] [Consulta: 20 septiembre 2007]
ü MORALES TORRES, Hilda. La importancia de los documentos en los sistemas de archivo manuales y computadorizados. Abril 2000. [Disponible
en http://sistemasdeoficina.com/impdoc.htm] [Consulta: 1 octubre 2007]
ü PRAGMA CONSULTORES.¿Agile o Unified? – UBA, Noviembre 2004. . [Disponible en http://www2.dc.uba.ar/materias/isoft2/invitados/sansano.pdf]
[Consulta: 16 Abril 2008]
ü VEGA BRICEÑO, Edgar Armando. Los Sistemas de Información y su importancia para las organizaciones y empresas. 2005. [Disponible en
http://www.monografias.com/trabajos24/ticsempresas/ticsempresas.shtml]
[Consulta: 1 octubre 2007]
220
Anexo 1: DOCUMENTO DE CREACIÓN DE LA MUNICIPALIDAD
DISTRITAL DE JAYANCA
222
Anexo 2: ORGANIGRAMA DE LA MUNICIPALIDAD
DISTRITAL DE JAYANCA
COMISIONES DE REGIDORES
CONSEJO DE COORDINACON LOCAL DISTRITAL
JUNTAS VECINALES
COMITÉ DISTRITAL DE
DEFENSA CIVIL
COMITÉ DISTRITAL DE SEG. CIUDADANA
COMUDENA
GERENCIA MUNICIPAL
UNIDAD DE PLANIFICACIÓN Y PRESUPUESTO
UNIDAD DE ASESORÍA LEGAL
OFICINA DE ADMINISTRACIÓN
GERENCIA DE DESARROLLO ECONÓMICO Y DE SERVICIOS
COMUNALES
GERENCIA DE DESARRO LLO URBANO Y RURAL
OFICINA DE
AUDITORÍA INTERNA
AGENCIAS MUNICIPALES
CONCEJO MUNICIPAL
ALCALDÍA
GERENCIA DE PROYECC. Y DESARROLLO SOCIAL
UNIDAD DE TRÁM. DOCU
MENTARIO Y ARCHIVO
SEC. GENERAL Y TRÁM.
DOCUMENTARIO
UNIDAD DE INFORMÁTICA
223
MUNICIPALIDDES DE
CENTROS POBLADOS
PROYECTOS
ESPECIALES
MUNICIPALES
224
Anexo 3: CLASIFICACIÓN DOCUMENTAL DE LA MUNICIPALIDAD DISTRITAL DE JAYANCA
CODIGO NOMBRE DE SERIE DOCUMENTAL TIPO
(Interno /Externo)
GRUPO DOCUMENTAL
PLAZO RPTA(días)
001 CONVENIOS DE COOPERACION TECNICA I 1
002 MEMORIAS ANUALES I 1
003 ACTAS DE SESION DE CONCEJOS I 1
004 RESOLUCIONES DE ALCALDIA I 1
005 DECRETOS MUNICIPALES I 1
006 RESOLUCIONES DE CONCEJO I 1
007 ACUERDOS DE CONCEJO I 1
008 ORDENANZAS MUNICIPALES I 1
009 NORMAS I 1
010 REGLAMENTOS I 1
011 LICITACIONES I 1
012 PLAN ANUAL I 1
013 PLAN DE TRIBUTACION MUNICIPAL I 1
014 REGLAM. ORGANIZ. Y FUNCIONES I 1
015 MANUAL DE ORGAN. Y FUNCIONES I 1
016 MANUAL DE PROCEDIMIENTOS I 1
017 CUADRO DE NECESIDADES I 1
018 PLAN ANUAL DE ADQUISICIONES I 1
019 PECOSA I 1
020 INVENTARIO FISICO DE BIENES I 1
021 ORDENES DE SERVICIOS I 1
022 ORDENES DE COMPRA I 1
023 CONTRATOS I 1
024 NOTAS DE PRENSA I 1
025 INFORME DE EVALUACIÓN I 2
026 INFORME DE APROBACIÓN I 2
027 INFORME DE SUPERVISIÓN I 2
028 INFORME DE INSPECCIÓN I 2
029 SOLICITUD DE ACCESO A LA INFORMACIÓN PÚBLICA E 3 7
030 RECONOCIMIENTO JUNTA VECINAL E 3
031 RECONOCIMIETO COMITÉ DE VASO DE LECHE E 3
032 USO DE LOCAL MUNICIPAL PARA ACTIVIDADES CULTURALES E 3
033 AUTORIZACIÓN DE ACTIVIDAD BAILABLE E 3
034 SOLICITUD DE APOYOS VARIOS 3
035 AUTORIZACIÓN DE TRABAJO EN CALLES 3
036 DECLARACION JURADA E 3
037 INVITACIÓN E 4
038 CARTA E 4
039 CARTA NOTARIAL E 4
Fuente: Elaboración propia basada en la normativa del Archivo General de la Nación para Municipalidades
225
Anexo 4: PLAN DE DESARROLLO DEL SISTEMA INFORMÁTICO DE GESTIÓN
DOCUMENTARIA PARA LA MUNICIPALIDAD DISTRITAL DE JAYANCA
INTRODUCCIÓN
Este documento se constituye en el plan de Desarrollo del Sistema Informático
de Gestión documentaria para la Municipalidad distrital de Jayanca, y provee
una visión global del enfoque de desarrollo propuesto.
El proyecto ha sido ofertado por Albertina Purisaca Vigil basado en una
metodología de Rational Unified Process (RUP) en la que únicamente se
procederá a cumplir con las tres primeras fases que marca la metodología,
constando únicamente en la tercera fase de dos iteraciones. Es importante
destacar esto puesto que utilizaremos la terminología RUP en este documento.
Se incluirá el detalle para las fases de Inicio y Elaboración y adicionalmente se
esbozarán las fases posteriores de Construcción y Transición para dar una
visión global de todo proceso.
El enfoque de desarrollo propuesto constituye una configuración del proceso
RUP de acuerdo a las características del proyecto, seleccionando los roles de
los participantes, las actividades a realizar y los artefactos (entregables) que
serán generados. Este documento es a su vez uno de los artefactos de RUP.
El propósito del Plan de Desarrollo de Software es proporcionar la información
necesaria para controlar el proyecto. En él se describe el enfoque de desarrollo
del software.
Los usuarios del Plan de Desarrollo del Software son:
• El jefe del proyecto: Lo utiliza para organizar la agenda y necesidades de
recursos y para realizar su seguimiento.
• Los miembros del equipo de desarrollo: Lo usan para entender lo qué deben
hacer, cuándo deben hacerlo y qué otras actividades dependen de ello.
El Plan de Desarrollo del Software describe el plan global usado para el
desarrollo del “Sistema Informático de Gestión Documentaria”. El detalle de las
iteraciones individuales se describe en los planes de cada iteración,
documentos que se aportan en forma separada. Durante el proceso de
desarrollo en el artefacto “Visión” se definen las características del producto a
desarrollar, lo cual constituye la base para la planificación de las iteraciones.
226
Para la versión 1.0 del Plan de Desarrollo del Software, nos hemos basado en
la captura de requisitos por medio del stakeholder, representante de la
Municipalidad para hacer una estimación aproximada.
El documento está organizado en las siguientes secciones:
Vista General del Proyecto — proporciona una descripción del propósito,
alcance y objetivos del proyecto, estableciendo los artefactos que serán
producidos y utilizados durante el proyecto.
Organización del Proyecto — describe la estructura organizacional del equipo
de desarrollo.
Gestión del Proceso — explica los costos y planificación estimada, define las
fases e hitos del proyecto y describe cómo se realizará su seguimiento.
I. VISIÓN GENERAL DEL PROYECTO
1.1. Propósito, Alcance y Objetivos
La información que a continuación se incluye ha sido extraída de las diferentes
reuniones que se han celebrado con el stakeholder de la empresa desde el
inicio del proyecto.
La Municipalidad Distrital de Jayanca tiene por finalidad representar al
vecindario, promueve la adecuada prestación de los servicios públicos locales y
el desarrollo integral, sostenible y armónico de su circunscripción, con
participación de la población.
Una buena práctica gubernamental en Servicio de Atención al Ciudadano
(BPG) se orienta a lograr excelencia en el servicio a éste, basándose en
políticas, acciones y sistemas que permitan entablar con él la mejor relación
posible, buscando garantizar tanto la calidad de la información brindada como
la del trato ofrecido, así como la eficiencia en la atención satisfactoria de sus
demandas.
En este contexto la Municipalidad Distrital de Jayanca considera necesario el
desarrollo del sistema informático de gestión documentaria para mejorar el
servicio de atención a los usuarios.
El proyecto debe proporcionar una propuesta para el desarrollo de los
siguientes procesos:
227
a) Administración del sistema, que incluye:
• Registrar/Actualizar serie documental.
• Registrar/Actualizar grupo documental.
• Asignar requisitos.
• Registrar área.
• Registrar/Actualizar empleado.
• Buscar empleado.
• Asignar usuarios y permisos.
• Generar reportes (empleados, series documentales, estadísticas de gestión
documentaria).
b) Registro de documento, que incluye:
• Listar documentos externos
• Registrar documento externo
• Modificar documento externo
• Gestionar referencias
• Gestionar adjuntos
• Buscar usuario
• Registrar/Actualizar usuario
• Generar ticket
• Derivar documento externo
• Anular documento
• Listar documentos enviados
• Mostrar adjuntos
• Listar documentos anulados
• Restaurar documento
• Listar documentos internos
• Registrar documento interno
• Modificar documento interno
• Asignar adjunto
• Imprimir documentos(registrados, anulados, enviados)
c) Gestión de documentos, que incluye:
• Listar documentos pendientes de atención.
• Mostrar adjuntos del documento.
• Dar proveído.
228
• Cocluir atención del documento.
• Mostrar seguimiento del documento.
• Mostrar adjunto.
• Listar documentos respondidos.
• Listar documentos atendidos.
• Archivar documento.
• Listar documentos archivados.
• Ubicar documento externo.
• Ubicar documento interno.
• Consultar estado de un documento.
• Imprimir documentos (pendientes de atención, respondidos, atendidos y archivados)
1.2. Suposiciones y Restricciones
Las suposiciones y restricciones respecto del sistema, y que se derivan
directamente de las entrevistas con el stakeholder de la empresa son:
• El sistema debe ajustarse a la normativa vigente del Archivo de la Nación.
• El sistema debe considerar formatos de archivos aprobados por la ISO como estándar internacional.
Como es natural, la lista de suposiciones y restricciones se incrementará
durante el desarrollo del proyecto, particularmente una vez establecido el
artefacto “Visión”.
1.3. Entregables del proyecto
A continuación se indican y describen cada uno de los artefactos que serán
generados y utilizados por el proyecto y que constituyen los entregables. Esta
lista constituye la configuración de RUP desde la perspectiva de artefactos, y
que proponemos para este proyecto.
Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo proceso
iterativo e incremental), todos los artefactos son objeto de modificaciones a lo
largo del proceso de desarrollo, con lo cual, sólo al término del proceso
podríamos tener una versión definitiva y completa de cada uno de ellos. Sin
embargo, el resultado de cada iteración y los hitos del proyecto están
enfocados a conseguir un cierto grado de completitud y estabilidad de los
229
artefactos. Esto será indicado más adelante cuando se presenten los objetivos
de cada iteración.
a) Plan de Desarrollo del Software
Es el presente documento.
b) Modelo de Casos de Uso del Negocio
Es un modelo de las funciones de negocio vistas desde la perspectiva de los
actores externos (Agentes de registro, solicitantes finales, otros sistemas etc.)
Permite situar al sistema en el contexto organizacional haciendo énfasis en los
objetivos en este ámbito. Este modelo se representa con un Diagrama de
Casos de Uso usando estereotipos específicos para este modelo.
c) Modelo de Objetos del Negocio
Es un modelo que describe la realización de cada caso de uso del negocio,
estableciendo los actores internos, la información que en términos generales
manipulan y los flujos de trabajo (workflows) asociados al caso de uso del
negocio. Para la representación de este modelo se utilizan Diagramas de
Colaboración (para mostrar actores externos, internos y las entidades
(información) que manipulan, un Diagrama de Clases para mostrar
gráficamente las entidades del sistema y sus relaciones, y Diagramas de
Actividad para mostrar los flujos de trabajo.
d) Glosario
Es un documento que define los principales términos usados en el proyecto.
Permite establecer una terminología consensuada.
e) Modelo de Casos de Uso
El modelo de Casos de Uso presenta las funciones del sistema y los actores
que hacen uso de ellas. Se representa mediante Diagramas de Casos de Uso.
f) Especificaciones de Casos de Uso
Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o
que no baste con una simple descripción narrativa) se realiza una descripción
detallada utilizando una plantilla de documento, donde se incluyen:
precondiciones, postcondiciones, flujo de eventos. También, para casos de
uso cuyo flujo de eventos sea complejo podrá adjuntarse una representación
gráfica mediante un Diagrama de Actividad.
g) Especificaciones adicionales
230
Este documento capturará todos los requisitos que no han sido incluidos como
parte de los casos de uso y se refieren requisitos nofuncionales globales.
Dichos requisitos incluyen: requisitos legales o normas, aplicación de
estándares, requisitos de calidad del producto, tales como: confiabilidad,
desempeño, etc., u otros requisitos de ambiente, tales como: sistema operativo,
requisitos de compatibilidad, etc.
h) Prototipos de Interfaces de Usuario
Se trata de prototipos que permiten al usuario hacerse una idea más o menos
precisa de las interfaces que proveerá el sistema y así, conseguir
retroalimentación de su parte respecto a los requisitos del sistema. Estos
prototipos se realizarán como: dibujos a mano en papel, dibujos con alguna
herramienta gráfica o prototipos ejecutables interactivos, siguiendo ese orden
de acuerdo al avance del proyecto. Sólo los de este último tipo serán
entregados al final de la fase de Elaboración, los otros serán desechados.
Asimismo, este artefacto, será desechado en la fase de Construcción en la
medida que el resultado de las iteraciones vayan desarrollando el producto
final.
i) Modelo de Análisis y Diseño
Este modelo establece la realización de los casos de uso en clases y pasando
desde una representación en términos de análisis (sin incluir aspectos de
implementación) hacia una de diseño (incluyendo una orientación hacia el
entorno de implementación), de acuerdo al avance del proyecto.
j) Modelo de Datos
Previendo que la persistencia de la información del sistema será soportada por
una base de datos relacional, este modelo describe la representación lógica de
los datos persistentes, de acuerdo con el enfoque para modelado relacional de
datos. Para expresar este modelo se utiliza un Diagrama de Clases (donde se
utiliza un profile UML para Modelado de Datos, para conseguir la
representación de tablas, claves, etc.).
k) Modelo de Implementación
Este modelo es una colección de componentes y los subsistemas que los
contienen. Estos componentes incluyen: ficheros ejecutables, ficheros de
código fuente, y todo otro tipo de ficheros necesarios para la implantación y
231
despliegue del sistema. (Este modelo es sólo una versión preliminar al final de
la fase de Elaboración, posteriormente tiene bastante refinamiento).
l) Modelo de Despliegue
Este modelo muestra el despliegue la configuración de tipos de nodos del
sistema, en los cuales se hará el despliegue de los componentes.
m) Solicitud de Cambio
Los cambios propuestos para los artefactos se formalizan mediante este
documento. Mediante este documento se hace un seguimiento de los defectos
detectados, solicitud de mejoras o cambios en los requisitos del producto. Así
se provee un registro de decisiones de cambios, de su evaluación e impacto, y
se asegura que éstos sean conocidos por el equipo de desarrollo. Los cambios
se establecen respecto de la última baseline (el estado del conjunto de los
artefactos en un momento determinado del proyecto) establecida. En nuestro
caso al final de cada iteración se establecerá una baseline.
n) Plan de Iteración
Es un conjunto de actividades y tareas ordenadas temporalmente, con recursos
asignados, dependencias entre ellas. Se realiza para cada iteración, y para
todas las fases.
o) Lista de Riesgos
Este documento incluye una lista de los riesgos conocidos y vigentes en el
proyecto, ordenados en orden decreciente de importancia y con acciones
específicas de contingencia o para su mitigación.
p) Manual de Instalación
Este documento incluye las instrucciones para realizar la instalación del
producto.
q) Material de Apoyo al Usuario Final
Corresponde a un conjunto de documentos y facilidades de uso del sistema,
incluyendo: Guías del Usuario, Guías de Operación, Guías de Mantenimiento y
Sistema de Ayuda.
r) Producto
Los ficheros del producto empaquetados y almacenadas en un CD con los
mecanismos apropiados para facilitar su instalación. El producto, a partir de la
primera iteración de la fase de Construcción es desarrollado incremental e
iterativamente, obteniéndose una nueva release al final de cada iteración.
232
Los artefactos p, q y r se generarán a partir de la fase de Construcción, con lo
cual se han incluido aquí sólo para dar una visión global de todos los artefactos
que se generarán en el proceso de desarrollo.
II. ORGANIZACIÓN DEL PROYECTO
2.1. Participantes en el Proyecto El personal que designó la Municipalidad Distrital de Jayanca para
coordinar y apoyar en el desarrollo del proyecto fue la Secretaria General.
El resto del personal del proyecto considerando las fases de Inicio, Elaboración
y la fase de Construcción, estará formado por los siguientes puestos de trabajo
y personal asociado, de acuerdo con los roles que desempeñan en RUP. En
este caso, sólo para la investigación presentada, la tesista está asumiendo
todos los roles.
CUADRO A1: ROLES Y RESPONSABILIDADES
Puesto Responsabilidad
Jefe de Proyecto
El jefe de proyecto asigna los recursos, gestiona las prioridades, coordina las interacciones con los clientes y usuarios, y mantiene al equipo del proyecto enfocado en los objetivos. El jefe de proyecto también establece un conjunto de prácticas que aseguran la integridad y calidad de los artefactos del proyecto. Además, el jefe de proyecto se encargará de supervisar el establecimiento de la arquitectura del sistema. Gestión de riesgos. Planificación y control del proyecto.
Analista de Sistemas
Captura, especificación y validación de requisitos, interactuando con el cliente y los usuarios mediante entrevistas. Elaboración del Modelo de Análisis y Diseño. Colaboración en la elaboración de las pruebas funcionales y el modelo de datos.
Programador: Construcción de prototipos. Colaboración en la elaboración de las pruebas funcionales, modelo de datos y en las validaciones con el usuario
Ingeniero de Software:
Gestión de requisitos, gestión de configuración y cambios, elaboración del modelo de datos, preparación de las pruebas funcionales, elaboración de la documentación. Elaborar modelos de implementación y despliegue.
III. GESTIÓN DEL PROCESO
3.1. Estimaciones del Proyecto
El presupuesto del proyecto y los recursos involucrados están descritos en el
informe de tesis elaborado.
233
3.2. Plan de las Fases
El desarrollo se llevará a cabo en base a fases con una o más iteraciones en
cada una de ellas. Para la fase de Construcción es sólo una aproximación
preliminar.
CUADRO A2: PLAN DE FASES
FASE NRO. ITERACIONES DURACIÓN
Fase de inicio 1 4 semanas
Fase de elaboración 1 3 semanas
Fase de construcción
2 16 semanas
Fase de transición
CUADRO A3: DESCRIPCIÓN DE HITOS SEGÚN FASE Descripción Hito Fase de Inicio
En esta fase desarrollará los requisitos del producto desde la perspectiva del usuario, los cuales serán establecidos en el artefacto Visión. Los principales casos de uso serán identificados y se hará un refinamiento del Plan de Desarrollo del Proyecto. La aceptación del cliente / usuario del artefacto Plan de Desarrollo marcan el final de esta fase.
Fase de Elaboración
En esta fase se analizan los requisitos y se desarrolla un prototipo de arquitectura (incluyendo las partes más relevantes y / o críticas del sistema). Al final de esta fase, todos los casos de uso correspondientes a requisitos que serán implementados en la primera release de la fase de Construcción deben estar analizados y diseñados (en el Modelo de Análisis / Diseño). La revisión y aceptación del prototipo de la arquitectura del sistema marca el final de esta fase. La revisión y entrega de todos los artefactos hasta este punto de desarrollo también se incluye como hito. La primera iteración tendrá como objetivo la identificación y especificación de los principales casos de uso, así como su realización preliminar en el Modelo de Análisis / Diseño, también permitirá hacer una revisión general del estado de los artefactos hasta este punto y ajustar si es necesario la planificación para asegurar el cumplimiento de los objetivos.
Fase de Construcción
Durante la fase de construcción se terminan de analizar y diseñar todos los casos de uso, refinando el Modelo de Análisis / Diseño. El producto se construye en base a 2 iteraciones, cada una produciendo una release a la cual se le aplican las pruebas y se valida con el usuario. Se comienza la elaboración de material de apoyo al usuario. El hito que marca el fin de esta fase es la versión de la release 3.0, con la capacidad operacional parcial del producto que se haya considerado como crítica, lista para ser entregada a los usuarios para pruebas beta.
Fase de Transición
En esta fase se prepararán dos releases para distribución, asegurando una implantación y cambio del sistema previo de manera adecuada, incluyendo el entrenamiento de los usuarios. El hito que marca el fin de esta fase incluye, la entrega de toda la documentación del proyecto con los manuales de instalación y todo el material de apoyo al usuario, la finalización del entrenamiento de los usuarios y el empaquetamiento del producto. Esta fase no está incluida en la investigación.
234
3.3. Calendario del Proyecto
A continuación se presenta un calendario de las principales tareas del proyecto
incluyendo sólo las fases de Inicio y Elaboración. Como se ha comentado, el
proceso iterativo e incremental de RUP está caracterizado por la realización en
paralelo de todas las disciplinas de desarrollo a lo largo del proyecto, con lo
cual la mayoría de los artefactos son generados muy tempranamente en el
proyecto pero van desarrollándose en mayor o menor grado de acuerdo a la
fase e iteración del proyecto.
CUADRO A4: CALENDARIO DEL PROYECTO – FASES INICIO Y
ELABORACIÓN
Disciplinas / Artefactos generados o modificados durante la Fase Comienzo
Modelado Del Negocio
Modelo de Casos de Uso del Negocio y Modelo de Objetos
del Negocio 07012008
Requisitos
Glosario 07012008 Modelado de casos de uso 24012008 Especificación de casos de uso 31012008 Especificaciones adicionales 25022008
Análisis/Diseño
Modelo de Análisis/Diseño 04032008 Modelo de datos 11032008
Implementación
Prototipos de interfaces de usuario 20032008 Modelo de implementación 01042008
Despliegue
Modelo de despliegue 02052008 Gestión de Cambios y Configuración Durante todo el
proyecto Gestión del proyecto
Plan de Desarrollo del Software en su versión 2.0 y
planes de las Iteraciones
07/01/2008
235
CUADRO A5: CALENDARIO DEL PROYECTO – FASE ELABORACIÓN
Disciplinas / Artefactos generados o modificados durante la Fase Comienzo
Modelado del Negocio
Modelo de Casos de Uso del Negocio y Modelo de Objetos del
Negocio 07012008
Requisitos
Glosario 07012008 Visión 24012008 Modelo de Casos de Uso 31012008 Especificación de Casos de Uso 25022008 Especificaciones Adicionales
Análisis / Diseño 04032008 Modelo de Análisis / Diseño 11032008 Modelo de Datos
Implementación 20032008 Prototipos de Interfaces de Usuario 01042008 Modelo de Implementación
Pruebas
Casos de Pruebas Funcionales
Despliegue
Modelo de Despliegue 02052008
Gestión de Cambios y Configuración Durante todo el proyecto
Gestión del proyecto
Plan de Desarrollo del Software en su versión 2.0 y planes de las
Iteraciones 15/05/2008
3.4. Seguimiento y Control del Proyecto
Gestión de Requisitos
Los cambios en los requisitos serán gestionados mediante una Solicitud
de Cambio, las cuales serán evaluadas y distribuidas para asegurar la
integridad del sistema y el correcto proceso de gestión de configuración y
cambios.
Control de Plazos
El calendario del proyecto tendrá un seguimiento y evaluación semanal
por el jefe de proyecto.
236
Control de Calidad
Los defectos detectados en las revisiones y formalizados también en una
Solicitud de Cambio tendrán un seguimiento para asegurar la conformidad
respecto de la solución de dichas deficiencias Para la revisión de cada
artefacto y su correspondiente garantía de calidad se utilizarán las guías de
revisión y checklist (listas de verificación) incluidas en RUP.
Gestión de Riesgos
A partir de la fase de Inicio se mantendrá una lista de riesgos asociados
al proyecto y de las acciones establecidas como estrategia para mitigarlos o
acciones de contingencia. Esta lista será evaluada al menos una vez en cada
iteración.
Gestión de Configuración
Se realizará una gestión de configuración para llevar un registro de los
artefactos generados y sus versiones. También se incluirá la gestión de las
Solicitudes de Cambio y de las modificaciones que éstas produzcan,
informando y publicando dichos cambios para que sean accesibles a todo los
participantes en el proyecto. Al final de cada iteración se establecerá una
baseline (un registro del estado de cada artefacto, estableciendo una versión),
la cual podrá ser modificada sólo por una Solicitud de Cambio aprobada.