UNIVERSIDAD SEÑOR DE SIPAN...software development methodologies (Rational Unified Process RUP,...

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


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


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





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


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%





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%





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


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.


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%


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.

http://www.bvindecopi.gob.pe/normas/isoiec12207.pdf

http://www.google.com.pe/url?sa=X&start=2&oi=define&q=http%3A//mat.uv.cl/profesores/apuntes/archivos_publicos/6796172328_Informatica.ppt&usg=AFQjCNHktjqLwhLDQ6XnDlzxNHeUB9j_SQ

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]

http://www.cobdc.org/7es/homecas.htm

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

http://www.library.cornell.edu/preservation/tutorial-spanish/presentation/table7-1.html

http://www.library.cornell.edu/preservation/tutorial-spanish/presentation/table7-1.html

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

http://www.library.cornell.edu/preservation/tutorial-spanish/technical/technicalA-01.html

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.

http://www.library.cornell.edu/preservation/tutorial-spanish/technical/technicalA-01.html

• 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>

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>

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


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


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


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


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).


• 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.


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


• 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


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).


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.


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)


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.


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)


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


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


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


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


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)


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.


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.


Postcondiciones El sistema crea automáticamente los códigos de las series documentales.

Punto de extensión Ninguno.



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.



“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.


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.



“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.


Postcondiciones El sistema creará automáticamente los códigos para cada área.


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.



“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.


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.


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.


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”.


Postcondiciones El sistema creará automáticamente los códigos del empleado.



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.


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”.


Deben existir empleados registrados y uno seleccionado.




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.


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”.


Deben existir empleados registrados y uno seleccionado. Postcondiciones Ninguna.


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.



“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.


Post condiciones

Ninguna.


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.


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.


Post condiciones

Ninguna.


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.


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.


Post condiciones

Ninguna.


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>>


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.


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.


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.


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.


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”.


Deben existir documentos registrados y un seleccionado.

Post condiciones

Ninguna.


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.


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.


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.




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.


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.




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.


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.





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.


Postcondiciones El sistema creará automáticamente los códigos del usuario.


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.



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.


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.




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.


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.



126


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.


1. Estando en la interfase que se muestra al ingresar al menú registrar

documento, la tramitadora elige la opción “Imprimir listado”.


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.





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.


Post condiciones

Ninguna.


Al ingresar a la lista de documentos derivados, la tramitadora puede mostrar

adjuntos del documento seleccionado o imprimir listado.


127


DOCUMENTOS DERIVADOS

CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS DERIVADOS


documentos derivados por la tramitadora.



“Documentos derivados”, la tramitadora elige la opción “Imprimir

listado”.


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.





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.


Post condiciones

Ninguna.


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.


128


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.



“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.



LISTAR DOCUMENTOS INTERNOS REGISTRADOS

CASO DE USO LISTAR DOCUMENTOS INTERNOS REGISTRADOS

Descripción El sistema permite mostrar los documentos internos registrados.


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.




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.


129


DOCUMENTO INTERNO

CASO DE USO REGISTRAR DOCUMENTO INTERNO Descripción El sistema provee el soporte necesario para el ingreso de un doc. interno.


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.


Postcondiciones El sistema creará automáticamente los códigos de los documentos regist.


Al registrar un nuevo documento, la tramitadora puede asignar el adjunto al documento interno.


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.


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.


Al modificar un documento interno, la tramitadora puede asignar el adjunto al documento interno.


130


DOCUMENTOS INTERNOS REGISTRADOS

CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS INTERNOS REGISTRADOS


documentos internos registrados por la tramitadora.


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.




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>>


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.


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.


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.


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.


Deben existir documentos pendientes de atención. Postcondiciones Ninguna.



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.


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.


Deben existir documentos pendientes de atención.





DOCUMENTOS PENDIENTES DE ATENCIÓN

CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS PENDIENTES DE ATENCIÓN


documentos pendientes de atención.



“Documentos pendientes de atención”, la tramitadora elige la opción

“Imprimir listado”.


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.




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.


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.





LISTAR DOCUMENTOS RESPONDIDOS

CASO DE USO LISTAR DOCUMENTOS RESPONDIDOS

Descripción El empleado puede mostrar una lista de los documentos que ha

respondido.



“Documentos Respondidos”.


cambiado de acuerdo a la fecha de envío y asunto.



Punto de

extensión

Al ingresar a la lista de documentos respondidos, el empleado puede


imprimir el listado de documentos respondidos.


135


DOCUMENTOS RESPONDIDOS

CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS RESPONDIDOS


documentos respondidos.


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.





LISTAR DOCUMENTOS ATENDIDOS

CASO DE USO LISTAR DOCUMENTOS ATENDIDOS


atendido.



“Documentos atendidos”.


cambiado de acuerdo a la fecha de atención y asunto.



Punto de

extensión

Al ingresar a la lista de documentos atendidos, el empleado puede


imprimir el listado de documentos atendidos.


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.


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.


Debe haber documentos externos con atención concluida y ser

seleccionado(s).




DOCUMENTOS ATENDIDOS

CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS ATENDIDOS


documentos respondidos.



“Documentos atendidos”, la tramitadora elige la opción “Imprimir

listado”.


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.




137


LISTAR DOCUMENTOS ARCHIVADOS

CASO DE USO LISTAR DOCUMENTOS ARCHIVADOS


archivado.



“Documentos Archivados”.


cambiado de acuerdo a la fecha de archivo y asunto.



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.


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.


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.


Debe haber documento externo archivado y seleccionado.




DOCUMENTOS ARCHIVADOS

138

CASO DE USO IMPRIMIR LISTADO DE DOCUMENTOS ARCHIVADOS


documentos archivados.



“Documentos archivados”, la tramitadora elige la opción “Imprimir

listado”.


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.





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).



“Ubicar documento externo”.


cambiado de acuerdo a la fecha de registro y asunto.



Punto de

extensión

Al ingresar a la lista de los documentos externos, el empleado puede


imprimir el listado de documentos externos.



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).



“Ubicar documento interno”.


cambiado de acuerdo al tipo de serie documental, la fecha de

emisión y asunto.



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.


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.


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.


El documento debe tener documento adjunto.



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.


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.


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()


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()


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()


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()


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


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()


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()


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.


14: Modificar empleado

13: Guardar()

15: Guardar()


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()


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


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


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()


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()


FIGURA Nº 26: Diagrama de colaboración: Registrar usuario

T : Tramitadora RUS : Registrador_usuario

: Ubicacgeografica

RUS : Registrador usuario

MUS : Modificador usuario


: Usuario


1: Registrar usuario 5: Registrar usuario

8: Modificar usuario

2: Indicar Ubic. geog.

4: Leer dist., prov, dpto

7: Guardar()

9: Guardar()

3: Leer()


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()


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


FIGURA Nº 29: Diagrama de colaboración: Derivar documento

149

T : Tramitadora IUDD : Derivador doc externo

IA : Indicar Area A : Area

DDE : Derivadordocexterno : Documento



2: Indicar area destino

4: Listar áreas


3: Leer()

7: Guardar()


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()


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


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()


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()


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


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


13: Modificador doc. interno

3: Leer()

7: Eliminar()

9: Leer()

12: Mostrar()

14: Mostrar()


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



: Documento

IAA : Indicar archivo adjunto : Adjunto


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



13: Grabar()

14: Modificar doc. interno 15: Grabar()


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()


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()


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


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()


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)


2: Buscar documento(Fechaenvio, asunto)

4: Listado doc. atendidos

8: Leer()

11: Mostrar()

6: Guardar()

13: Mostrar()

3: Leer()


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


IDA : Impresor doc. archivados

: Visualizador de adjuntos : Mostrar adjuntos

1: Listar documentos archivados

5: Imprimir doc. archivados

7: Imprime lis tado doc. archivados


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()


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()


FIGURA Nº 43: Diagrama de colaboración: Ubicar documento interno

156

E : Empleado_ UDI : Ubicar doc. interno I : Impresor list.doc.internos


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()


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


158

FIGURA Nº 45: IU Principal del SISGEDOC


a.1. Administración del Sistema

FIGURA Nº 46: Menú Administración del sistema


FIGURA Nº 47: IU: Registrar área de trabajo

159


FIGURA Nº 48: IU: Registrar empleado


160

FIGURA Nº 49: IU: Registrar serie documental


a.2. Registro de documentos FIGURA Nº 50: IU: Listar documentos externos


161

FIGURA Nº 51: IU: Registrar documento externo


FIGURA Nº 52: IU: Derivar documento


FIGURA Nº 53: IU: Generar ticket

162


FIGURA Nº 54: IU: Mostrar adjuntos de documento externo


FIGURA Nº 55: IU: Listar documentos enviados

163


FIGURA Nº 56: IU: Listar documentos eliminados


FIGURA Nº 57: IU: Listar documentos internos registrados

164


FIGURA Nº 58: IU: Registrar documento interno


a.3. Gestión de documentos FIGURA Nº 59: IU: Listar documentos pendientes de atención

165


FIGURA Nº 60: IU Listar documentos respondidos


FIGURA Nº 61: IU Listar documentos atendidos

166


FIGURA Nº 62: IU Listar documentos archivados


FIGURA Nº 63: IU Ubicar documento externo

167


FIGURA Nº 64: IU Ubicar documento interno


FIGURA Nº 65: IU Mostrar documento interno

168


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()


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


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()


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()


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)


Eliminar()

Registrar empleado

Mostrar()

Modificar empleado

Mostrar()

Asignarloginpermisos

Mostrar()


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()


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()


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 ( )


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()


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


FIGURA Nº 76: Diagrama de secuencia: Registrar usuario

179

T : Tramitadora RUS : Registrador_usuario : Ubicacgeografica RUS : Registrador usuario

MUS : Modificador usuario


: Usuario

Registrar usuario

Indicar Ubic. geog.

Leer()

Leer dist., prov, dpto

Registrar usuario

Validar formulario

Guardar()

Modificar usuario

Guardar()


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.


Eliminar()


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


Eliminar()

Agregar referenc ia

Guardar()


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()


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


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


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()


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()


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



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)


E liminar()

Imprimir list.doc.int.

Leer()

Imprime listado


Mostrar()

Modificador doc. interno

Mostrar()


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


: Documento IAA : Indicar archivo adjunto

: Adjunto


Indicar serie doc.

Leer()

Listado serie doc.

Indicar área

Leer()

Listado área

Indicar arch. adj.

Leer()

Ruta de adjunto


Validar formulario

Grabar()

Modificar doc. interno

Grabar()


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.


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()


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()


FIGURA Nº 88: Diagrama de secuencia: Mostrar seguimiento

191

E : Empleado_ MSEG : Mostrador_seguimiento

MSEG : Mostrador seguimiento MOV : Movimientodoc

Mostrar seguimiento()


Leer()

Muestra seguimiento


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()


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()


Mostrar()


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


: 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()

Mostrar ajunto(coddoc)

Mostrar()


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()


FIGURA Nº 93: Diagrama de secuencia: Ubicar documento interno

196

E : Empleado_ UDI : Ubicar doc. internoI : Impresor lis t.doc.internos


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()


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


Ref erencia

docref linea : Integer docref erencia : String


Grupo_documental

grupodocnombre : String grupodocdetalle : String grupodocestado : String


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


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


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


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..*


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


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


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


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.

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

http://www.microsoft.com/latam/office/livecomm/howtobuy/default.mspx

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.

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.

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.

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]

http://sistemasdeoficina.com/impdoc.htm

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.

UNIVERSIDAD SEÑOR DE SIPAN...software development methodologies (Rational Unified Process RUP,...

Documents

Transcript of UNIVERSIDAD SEÑOR DE SIPAN...software development methodologies (Rational Unified Process RUP,...