Page 1

ESCUELA MILITAR DE INGENIERÍA MCAL. ANTONIO JOSÉ DE SUCRE “BOLIVIA”

TRABAJO DE GRADO

HERRAMIENTA DE COBRO DE PATENTES MEDIANTE INTERMEDIACIÓN FINANCIERA APLICANDO ENLACE EN LÍNEA ENTRE ENTIDADES. CASO DE ESTUDIO: GOBIERNO AUTÓNOMO MUNICIPAL DE COCHABAMBA.

RODRIGO GUTIERREZ CHAVEZ

COCHABAMBA, 2013.


ESCUELA MILITAR DE INGENIERÍA MCAL. ANTONIO JOSÉ DE SUCRE “BOLIVIA”

TRABAJO DE GRADO

HERRAMIENTA DE COBRO DE PATENTES MEDIANTE INTERMEDIACIÓN FINANCIERA APLICANDO ENLACE EN LÍNEA ENTRE ENTIDADES. CASO DE ESTUDIO: GOBIERNO AUTÓNOMO MUNICIPAL DE COCHABAMBA.

RODRIGO GUTIERREZ CHAVEZ

Modalidad: Trabajo de Grado presentado como requisito para optar al título de Licenciatura en Ingeniería de Sistemas.

TUTOR: LENNY SANABRIA CASTELLÓN Ph. D.

COCHABAMBA, 2013.


ÍNCIDE DE CONTENIDO

CONTENIDO

Pág.

1

GENERALIDADES. ..................................................................................... 1

1.1

INTRODUCCIÓN. ........................................................................................ 1

1.2

ANTECEDENTES. ....................................................................................... 4

1.3

PLANTEAMIENTO DEL PROBLEMA. ........................................................ 6

1.3.1

Identificación del problema. .......................................................................... 7

1.3.1.1

Identificación de la situación problemática. ................................................ 10

1.3.1.2

Identificación de las causas........................................................................ 10

1.3.2

Formulación del problema. ......................................................................... 10

1.3.3

Análisis causa-efecto. ................................................................................ 10

1.4

OBJETIVOS Y ACCIONES........................................................................ 11

1.4.1

Objetivo general. ........................................................................................ 11

1.4.2

Objetivos específicos y acciones................................................................ 11

1.5

JUSTIFICACIÓN. ....................................................................................... 15

1.5.1

Justificación técnica. .................................................................................. 15

1.5.2

Justificación económica. ............................................................................ 15

1.5.3

Justificación social...................................................................................... 15

1.6

ALCANCE. ................................................................................................. 16

1.6.1

Alcance temático. ....................................................................................... 16

1.6.2

Alcance temporal........................................................................................ 16

1.6.3

Alcance geográfico. .................................................................................... 16

1.6.4

Alcance institucional. .................................................................................. 16 i


1.7

HIPÓTESIS. ............................................................................................... 17

1.7.1

Análisis de variables. .................................................................................. 17

1.7.2

Definición conceptual. ................................................................................ 17

1.7.3

Operativización de variables. ..................................................................... 19

1.8

MATRIZ DE CONSISTENCIA. ................................................................... 20

2

MARCO TEÓRICO. ................................................................................... 21

2.1

MÉTODOS Y TÉCNICAS DE RECOLECCIÓN DE DATOS. ..................... 21

2.1.1

La observación. .......................................................................................... 21

2.1.1.1

Clasificación de la observación. ................................................................. 21

2.1.2

Las encuestas. ........................................................................................... 22

2.1.2.1

Cuestionario. .............................................................................................. 22

2.1.2.2

Entrevista. .................................................................................................. 23

2.2

INTERMEDIACIÓN FINANCIERA. ............................................................ 24

2.2.1

Entidades de Intermediación Financiera. ................................................... 25

2.2.1.1

Servicios de remesa ................................................................................... 26

2.2.2

Empresa. .................................................................................................... 27

2.2.2.1

Institución pública. ...................................................................................... 27

2.2.2.2

Patente. ...................................................................................................... 29

2.2.2.3

Normativas de los patentes. ....................................................................... 34

2.2.3

Enlace. ....................................................................................................... 34

2.2.3.1

Arquitectura cliente-servidor. ...................................................................... 35

2.2.3.2

Cliente. ....................................................................................................... 36

2.2.3.3

Servidor. ..................................................................................................... 37

2.2.4

Seguridad en la intermediación financiera. ................................................ 40 ii


2.2.4.1

Seguridad SSL. .......................................................................................... 41

2.2.4.2

S-HTTP. ..................................................................................................... 42

2.2.4.3

Firewall. ...................................................................................................... 43

2.2.4.4

Normas de seguridad. ................................................................................ 45

2.3

INGENIERÍA DE SOFTWARE. .................................................................. 46

2.3.1

Modelos del proceso del software. ............................................................. 47

2.3.1.1

Modelo incremental. ................................................................................... 47

2.3.1.2

Desarrollo evolutivo. ................................................................................... 48

2.3.1.3

Modelo de desarrollo basado en componentes. ......................................... 50

2.3.2

Metodologías de desarrollo de software. .................................................... 51

2.3.2.1

Proceso unificado de desarrollo de software (UP). .................................... 52

2.3.2.2

Programación extrema (Extreme Programming, XP). ................................ 57

2.3.2.3

SCRUM. ..................................................................................................... 59

2.3.3

Lenguaje de modelamiento de software. .................................................... 62

2.3.3.1

UML. ........................................................................................................... 62

2.3.4

Pruebas de software. ................................................................................. 68

2.3.4.1

Pruebas unitarias. ...................................................................................... 69

2.3.4.2

Pruebas funcionales o de entrega. ............................................................. 72

2.3.4.3

Pruebas de carga o rendimiento ................................................................ 74

2.4

HERRAMIENTAS DE DESARROLLO DE SOFTWARE. .......................... 75

2.4.1

Lenguajes de programación. ...................................................................... 75

2.4.1.1

C Sharp. ..................................................................................................... 75

2.4.1.2

PHP. ........................................................................................................... 77

2.4.1.3

Java ............................................................................................................ 79 iii


2.4.2

Base de datos. ........................................................................................... 80

2.4.2.1

Sistema gestor de base de datos. .............................................................. 81

2.4.2.2

Manejadores de bases de datos. ............................................................... 81

2.4.2.3

Réplicas en la base de datos. .................................................................... 84

3

MARCO PRÁCTICO. ................................................................................. 86

3.1

DETERMINACIÓN DEL FUNCIONAMIENTO ACTUAL DEL SISTEMA DE COBRO DE PATENTES DEL GOBIERNO AUTÓNOMO MUNICIPAL DE COCHABAMBA. ........................................................................................ 86

3.1.1

Procedimiento actual de cobro de patentes. .............................................. 86

3.1.1.1

Modelado de negocio actual....................................................................... 87

3.1.1.2

Deficiencias del proceso actual de cobro de patentes. .............................. 90

3.1.2

Procedimiento propuesto del cobro de patentes. ....................................... 90

3.1.2.1

Modelado de negocio alternativo................................................................ 90

3.1.3

Análisis de fórmulas y requerimientos utilizados en el sistema de cobro de patentes...................................................................................................... 94

3.2

IDENTIFICACIÓN DE LA METODOLOGÍA DE DESARROLLO DE SOFTWARE PARA LA PROPUESTA. ...................................................... 95

3.2.1

Análisis y selección de metodología de desarrollo de software.................. 95

3.2.2

Análisis y selección de modelo de desarrollo de software. ........................ 96

3.3

DESARROLLO DEL MÓDULO WEB PARA LA OBTENCIÓN DE PROFORMAS DE PAGO........................................................................... 97

3.3.1

Aplicación de la metodología elegida al módulo web. ................................ 97

3.3.1.1

Identificación de diagramas UML para UP. ................................................ 97

3.3.1.2

Fase de inicio. ............................................................................................ 98

3.3.1.3

Fase de elaboración. ................................................................................ 103

3.3.1.4

Fase de construcción. .............................................................................. 109 iv


3.3.1.5

Fase de transición. ................................................................................... 122

3.4

IDENTIFICACIÓN DE LOS REQUERIMIENTOS DE ENTIDADES FINANCIERAS RESPECTO A LA INTERMEDIACIÓN FINANCIERA. ... 131

3.4.1

Análisis de normas que establece la Autoridad de Supervisión del Sistema Financiero (ASFI), respecto a la intermediación financiera. ..................... 131

3.4.1.1

Aspectos de las clausulas a considerar en la intermediación según la circular SB/466/2004............................................................................................. 131

3.4.1.2

Aspectos de seguridad en la intermediación financiera según la circular SB/466/2004............................................................................................. 132

3.4.1.3

Análisis y selección de entidad financiera. ............................................... 133

3.4.1.4

Requerimientos para otorgar la intermediación financiera (Fondo Financiero Privado Fassil). ......................................................................................... 134

3.4.1.5

Sistema de recepción de pagos ............................................................... 135

3.4.2

Diseño de la arquitectura del enlace en línea........................................... 135

3.4.2.1

Arquitectura cliente-servidor (entidad financiera y alcaldía). .................... 135

3.4.2.2

Esquema del enlace entre la entidad financiera y alcaldía. ...................... 136

3.5

DESARROLLO DE LA HERRAMIENTA DE COBRO DE PATENTES SITUADO EN LA ENTIDAD FINANCIERA.............................................. 138

3.5.1

Aplicación de la metodología elegida a la herramienta de cobro de patentes. ................................................................................................................. 138

3.5.1.1

Fase de inicio. .......................................................................................... 138

3.5.1.2

Fase de elaboración. ................................................................................ 144

3.5.1.3

Fase de construcción. .............................................................................. 152

3.5.1.4

Fase de transición. ................................................................................... 193

3.6

PRUEBAS DE LA HERRAMIENTA DE COBRO DE PATENTES Y MÓDULO WEB. ........................................................................................................ 204

3.6.1

Pruebas de carga o rendimiento. ............................................................. 204

3.6.1.1

Prueba de carga al módulo web. .............................................................. 204 v


3.6.1.2

Prueba de carga a la herramienta de cobro de patentes. ........................ 206

3.7

DEMOSTRACIÓN DE LA HIPÓTESIS. ................................................... 209

3.7.1

Demostración de las variables dependientes. .......................................... 211

3.7.1.1

Demostración de la primera variable dependiente. .................................. 211

3.7.1.2

Demostración de la segunda variable dependiente.................................. 213

3.7.1.3

Demostración de la tercera variable dependiente. ................................... 216

3.7.2

Demostración de variable independiente ................................................. 217

3.7.2.1

Definición de la hipótesis. ......................................................................... 220

3.7.2.2

Calculo del estadístico T. ......................................................................... 221

4

ANALISIS DE VIABILIDAD. .................................................................... 224

4.1

VIABILIDAD TÉCNICA. ........................................................................... 224

4.1.1

Requerimientos del sistema. .................................................................... 225

4.1.1.1

Servidor. ................................................................................................... 225

4.1.1.2

Cliente. ..................................................................................................... 227

4.1.2

Requerimientos del enlace en línea. ........................................................ 228

4.2

VIABILIDAD ECONÓMICA...................................................................... 230

4.2.1

Costos por tecnología. ............................................................................. 230

4.2.1.1

Servidor. ................................................................................................... 230

4.2.1.2

Cliente. ..................................................................................................... 231

4.2.1.3

Canal de comunicación. ........................................................................... 232

4.2.2

Costos por mano de obra ......................................................................... 234

4.2.2.1

Módulo 1: Herramienta de cobro de patentes. ......................................... 236

4.2.2.2

Módulo 2: Módulo web de obtención de proformas de pago. ................... 239

4.3

VIABILIDAD OPERATIVA. ...................................................................... 247 vi


5

CONCLUSIONES Y RECOMENDACIONES. .......................................... 249

5.1

CONCLUSIONES. ................................................................................... 249

5.2

RECOMENDACIONES. ........................................................................... 251

5.2.1

Recomendación para la herramienta de cobro de patentes. .................... 251

5.2.2

Recomendaciones para el módulo web de obtención de proformas de pago. ................................................................................................................. 252

BIBLIOGRAFÍA. ..................................................................................................... 253 ANEXOS ..................................................................................................................... 1

vii


ÍNDICE DE TABLAS

Tabla Nº 1:

Patente por espacio ocupado de contribuyentes minoristas, artesanos, vivanderos y número de patentes cancelados actualmente. ................ 8

Tabla Nº 2:

Objetivos específicos y acciones. ....................................................... 12

Tabla Nº 3:

Operativización de variables. .............................................................. 19

Tabla Nº 4:

Selección de metodología de desarrollo de software.......................... 95

Tabla Nº 5:

Identificación del modelo de desarrollo de software. .......................... 96

Tabla Nº 6:

Escenario: Ingresar a la página web (primera iteración). .................... 99

Tabla Nº 7:

Escenario: Ingresar a la página web (segunda iteración). ................ 105

Tabla Nº 8:

Prueba funcional: Ingresar a la página web (segunda iteración). ..... 108

Tabla Nº 9:

Escenario: Ingresar a la página web (tercera iteración). ................... 111

Tabla Nº 10: Selección de gestor de base de datos. ............................................. 116 Tabla Nº 11: Selección del lenguaje de programación para el módulo web. ......... 117 Tabla Nº 12: Prueba funcional: Ingresar a la página web (tercera iteración). ........ 121 Tabla Nº 13: Prueba funcional: Ingresar a la página web (cuarta iteración). ......... 130 Tabla Nº 14: Selección de entidad financiera. ....................................................... 133 Tabla Nº 15: Escenario: Ingresar a la herramienta de cobro de patentes ............. 140 Tabla Nº 16: Escenario: Administrar cobro de patentes. ....................................... 147 Tabla Nº 17: Escenario: Realizar cobro de patente. .............................................. 155 Tabla Nº 18: Prueba funcional: Realizar cobro de patentes (tercera iteración) ..... 161 Tabla Nº 19: Selección del lenguaje de programación para la herramienta de cobro de patentes. ...................................................................................... 174 Tabla Nº 20: Pruebas unitarias .............................................................................. 191 Tabla Nº 21: Escenario: Gestionar reporte de patentes. ....................................... 195 viii


Tabla Nº 22: Escenario: Gestionar cajero y sucursales. ........................................ 195 Tabla Nº 23: Pruebas funcionales de la propuesta. ............................................... 201 Tabla Nº 24: Observaciones de la prueba de carga al módulo web. ..................... 205 Tabla Nº 25: Resultado prueba de carga a la herramienta de cobro de patentes. 207 Tabla Nº 26: Observaciones de la prueba de carga a la herramienta de cobro de patentes. ........................................................................................... 208 Tabla Nº 27: Operativización de variables. ............................................................ 210 Tabla Nº 28: Puntos de cobro de patentes. ........................................................... 211 Tabla Nº 29: Número de patentes cancelados. ..................................................... 213 Tabla Nº 30: Patente por espacio ocupado de contribuyentes minoristas, artesanos, vivanderos y número de patentes cancelados actualmente. ............ 214 Tabla Nº 31: Patente por espacio ocupado de contribuyentes minoristas, artesanos, vivanderos y número de patentes cancelados con la implantación del sistema. ............................................................................................ 215 Tabla Nº 32: Análisis del número de patentes cancelados. ................................... 215 Tabla Nº 33: Pasos a seguir para la obtención de la proforma de pago ................ 216 Tabla Nº 34: Resumen de los tiempos para el proceso de obtención de la proforma de pago. ............................................................................................ 217 Tabla Nº 35: Tabla comparativa de beneficios del sistema propuesto. ................. 218 Tabla Nº 36: Requerimientos mínimos y recomendados del Servidor. .................. 225 Tabla Nº 37: Requerimientos mínimos y recomendados para el cliente de entidad financiera. ......................................................................................... 227 Tabla Nº 38: Requerimientos mínimos y recomendados del cliente contribuyente. ................................................................................... 228 Tabla Nº 39: Requerimientos para el enlace en línea............................................ 229 Tabla Nº 40: Precio de los componentes para el servidor ..................................... 230 Tabla Nº 41: Precio de los componentes para el cliente de entidad financiera. .... 231 ix


Tabla Nº 42: Precio de componente para el cliente contribuyente. ....................... 232 Tabla Nº 43: Precio del canal de comunicación entre entidades. .......................... 232 Tabla Nº 44: Lista de costos por tecnología. ......................................................... 233 Tabla Nº 45: Módulos del sistema. ........................................................................ 235 Tabla Nº 46: Ponderación de parámetros de medición – LDC. ............................. 236 Tabla Nº 47: Valores de factores de ajuste –LDC. ................................................ 237 Tabla Nº 48: Factores de costo en COCOMO II .................................................... 238 Tabla Nº 49: Ponderación de parámetros de medición – LDC. ............................. 239 Tabla Nº 50: Valores de factores de ajuste –LDC. ................................................ 240 Tabla Nº 51: Factores de costo en COCOMO II .................................................... 241 Tabla Nº 52: Factor de escala. .............................................................................. 242 Tabla Nº 53: Tabla final de COCOMO II ................................................................ 245 Tabla Nº 54: Tabla final de viabilidad económica. ................................................. 246

x


ÍNDICE DE FIGURAS

Figura Nº 1 :

Matriz de consistencia. ................................................................... 20

Figura Nº 2 :

Fórmula para el cálculo de la patente de funcionamiento permanente. ................................................................................... 31

Figura Nº 3 :

Fórmula para el cálculo de la patente de funcionamiento eventual. ......................................................................................... 32

Figura Nº 4 :

Fórmula para el cálculo de la patente de funcionamiento por actividades eventuales. .................................................................. 32

Figura Nº 5 :

Fórmula para el cálculo de la patente de funcionamiento por actividades de temporada. .............................................................. 33

Figura Nº 6 :

Clientes ligeros y pesados .............................................................. 36

Figura Nº 7 :

Cliente/servidor con servidor de base de datos. ............................. 37

Figura Nº 8 :

Cliente/servidor con servidor de aplicaciones. ................................ 38

Figura Nº 9 :

Interacción entre los componentes del cliente y servidor de BD .... 40

Figura Nº 10 :

S-HTTP sobre SSL. ........................................................................ 43

Figura Nº 11 :

Firewall. .......................................................................................... 44

Figura Nº 12 :

Modelo incremental. ....................................................................... 48

Figura Nº 13 :

Desarrollo evolutivo. ....................................................................... 49

Figura Nº 14 :

Modelo de desarrollo basado en componentes. ............................. 50

Figura Nº 15 :

Ciclo de vida del proceso unificado. ............................................... 52

Figura Nº 16 :

Ciclo con fases e iteraciones del proceso unificado. ...................... 53

Figura Nº 17 :

Modelo del proceso unificado. ........................................................ 54

Figura Nº 18 :

Los cinco flujos de trabajo. ............................................................. 55

Figura Nº 19 :

Ciclo de entrega en la programación extrema. ............................... 57

Figura Nº 20 :

Flujo general del proceso Scrum. ................................................... 60 xi


Figura Nº 21 :

Modelo general del proceso de pruebas de software. .................... 69

Figura Nº 22 :

Pruebas de unidad.......................................................................... 70

Figura Nº 23 :

Entorno de prueba de unidad. ........................................................ 72

Figura Nº 24 :

Pruebas de entrega o caja negra.................................................... 73

Figura Nº 25 :

Replicación de datos. ..................................................................... 84

Figura Nº 26 :

Modelado de negocio actual. .......................................................... 88

Figura Nº 27 :

Nivel de sistema de información actual. ......................................... 89

Figura Nº 28 :

Modelado de negocio alternativo. ................................................... 91

Figura Nº 29 :

Nivel de sistema de información alternativo (Módulo Web) ............ 92

Figura Nº 30 :

Nivel de sistema de información alternativo (Herramienta de cobro de patentes)......................................................................................... 93

Figura Nº 31 :

Fórmula del código tributario para el cálculo de cobro de patentes. ......................................................................................... 94

Figura Nº 32 :

Identificación de diagramas UML para el trabajo. ........................... 97

Figura Nº 33 :

Actores del módulo web: primera iteración. .................................... 98

Figura Nº 34 :

Caso de uso: Ingresar a la página web (primera iteración) ............ 99

Figura Nº 35 :

Diagrama de colaboración: Ingresar a la página web (primera iteración). ...................................................................................... 100

Figura Nº 36 :

Diagrama de secuencia: Ingresar a la página web (primera iteración). ...................................................................................... 101

Figura Nº 37 :

Diagrama de clases: Ingresar a la página web (primera iteración). ...................................................................................... 101

Figura Nº 38 :

Diseño de la interfaz de inicio de sesión de la web. (primera iteración). ...................................................................................... 102

Figura Nº 39 :

Diagrama de componente: Ingresar a la página web (primera iteración). ...................................................................................... 102

Figura Nº 40 :

Actores del módulo web: segunda iteración ................................. 104 xii


Figura Nº 41 :

Caso de uso: Ingresar a la página web (segunda iteración). ........ 104

Figura Nº 42 :

Diagrama de colaboración: Ingresar a la página web (segunda iteración). ...................................................................................... 105

Figura Nº 43 :

Diagrama de secuencia: Ingresar a la página web (segunda iteración). ...................................................................................... 106

Figura Nº 44 :

Diagrama de clases: Ingresar a la página web (segunda iteración). ...................................................................................... 106

Figura Nº 45 :

Diseño de la interfaz sitio municipal del contribuyente. ................ 107

Figura Nº 46 :

Diagrama de componente: Ingresar a la página web. .................. 108

Figura Nº 47 :

Actores del módulo web: tercera iteración. ................................... 110

Figura Nº 48 :

Caso de uso: Ingresar a la página web (tercera iteración). .......... 110

Figura Nº 49 :

Diagrama de colaboración: Ingresar a la página web (tercera iteración). ...................................................................................... 112

Figura Nº 50 :

Diagrama de secuencia: Ingresar a la página web (tercera iteración). ...................................................................................... 112

Figura Nº 51 :

Diagrama de clases: Ingresar a la página web (tercera iteración). ...................................................................................... 113

Figura Nº 52 :

Diseño de la página de inicio de la web (tercera iteración)........... 113

Figura Nº 53 :

Diseño de la interfaz de inicio de sesión de la web. (tercera iteración). ...................................................................................... 114

Figura Nº 54 :

Diseño de la interfaz sitio municipal del contribuyente. ................ 114

Figura Nº 55 :

Ventana sitio municipal del contribuyente (tercera iteración) ........ 115

Figura Nº 56 :

Diagrama de componente: Ingresar a la página web (tercera iteración) ....................................................................................... 115

Figura Nº 57 :

Interfaz menú principal (tercera iteración). ................................... 118

Figura Nº 58 :

Interfaz de autenticación del contribuyente. (tercera iteración) .... 119

Figura Nº 59 :

Interfaz del sitio municipal del contribuyente. (tercera iteración) .. 119

Figura Nº 60 :

Interfaz de proforma de pago. (tercera iteración) ......................... 120 xiii


Figura Nº 61 :

Diagrama de colaboración: Ingresar a la página web. .................. 122

Figura Nº 62 :

Diagrama de secuencia: Ingresar a la página web. (cuarta iteración). ...................................................................................... 123

Figura Nº 63 :

Diagrama de clases: Ingresar a la página web (cuarta iteración). 123

Figura Nº 64 :

Diseño de la página de inicio de la web (cuarta iteración). ........... 124

Figura Nº 65 :

Diseño de la interfaz de inicio de sesión de la web. (cuarta iteración). ...................................................................................... 124

Figura Nº 66 :

Diseño de la interfaz sitio municipal del contribuyente (cuarta iteración) ....................................................................................... 125

Figura Nº 67 :

Ventana sitio municipal del contribuyente (cuarta iteración) ......... 126

Figura Nº 68 :

Diagrama de componentes: Ingresar a la página web (cuarta iteración). ...................................................................................... 126

Figura Nº 69 :

Interfaz menú principal (cuarta iteración)...................................... 127

Figura Nº 70 :

Interfaz de autenticación del contribuyente. (cuarta iteración)...... 128

Figura Nº 71 :

Interfaz del sitio municipal del contribuyente. (cuarta iteración) ... 128

Figura Nº 72 :

Interfaz de proforma de pago. (cuarta iteración) ........................... 129

Figura Nº 73 :

Esquema del enlace entre la entidad financiera y alcaldía. .......... 137

Figura Nº 74 :

Actores de la herramienta de cobro de patente: primera iteración139

Figura Nº 75 :

Caso de uso: Ingresar a la herramienta de cobro de patentes. .... 140

Figura Nº 76 :

Diagrama de colaboración: Ingresar a la herramienta de cobro de patentes. ....................................................................................... 141

Figura Nº 77 :

Diagrama de secuencia: Ingresar a la herramienta de cobro de patentes. ....................................................................................... 142

Figura Nº 78 :

Diagrama de clases: Ingresar a la herramienta de cobro de patentes. ....................................................................................... 143

Figura Nº 79 :

Diseño de la interfaz de autenticación. ......................................... 143

Figura Nº 80 :

Diagrama de componentes: Ingresar a la herramienta de cobro de patentes. ....................................................................................... 144 xiv


Figura Nº 81 :

Actores de la herramienta de cobro de patente: segunda iteración. ....................................................................................... 145

Figura Nº 82 :

Caso de uso: Administrar cobro de patentes. ............................... 146

Figura Nº 83 :

Diagrama de colaboración: Administrar cobro de patentes. ......... 148

Figura Nº 84 :

Diagrama de secuencia: Administrar cobro de patentes. ............. 149

Figura Nº 85 :

Diagrama de clases: Administración de cobro de patentes. ......... 150

Figura Nº 86 :

Diseño de interfaz de la administración de cobro de patentes. .... 150

Figura Nº 87 :

Diagrama de componentes: Administrar cobro de patentes. ........ 151

Figura Nº 88 :

Implementación de la interfaz del administrador de la alcaldía. ... 152

Figura Nº 89 :

Actores de la herramienta de cobro de patente: tercera iteración.153

Figura Nº 90 :

Caso de uso: Realizar cobro de patente....................................... 154

Figura Nº 91 :

Diagrama de colaboración: Realizar cobro de patentes ............... 156

Figura Nº 92 :

Diagrama de secuencia: Realizar cobro de patentes. .................. 157

Figura Nº 93 :

Diagrama de clases: Administración de cobro de patentes. ......... 158

Figura Nº 94 :

Diseño de la interfaz: menú principal. ........................................... 159

Figura Nº 95 :

Diseño de la interfaz de proceso de pago y emisión de comprobante. ................................................................................ 159

Figura Nº 96 :

Diagrama de componente: Realizar cobro de patentes ................ 160

Figura Nº 97 :

Implementación de la interfaz de realizar cobro de patentes........ 161

Figura Nº 98 :

Actores de la herramienta de cobro de patente: cuarta iteración. 163

Figura Nº 99 :

Diagrama de casos de uso general. ............................................. 165

Figura Nº 100 : Diagrama de colaboración: Administrar cobro de patentes. ......... 166 Figura Nº 101 : Diagrama de colaboración: Realizar cobro de patentes ............... 166 Figura Nº 102 : Diagrama de secuencia: Administrar cobro de patentes. ............. 167 Figura Nº 103 : Diagrama de secuencia: Realizar cobro de patentes. .................. 168 xv


Figura Nº 104 : Diagrama de clases general. ........................................................ 169 Figura Nº 105 : Diseño de la base de datos. ......................................................... 170 Figura Nº 106 : Diseño de la interfaz de autenticación. ......................................... 171 Figura Nº 107 : Diseño de interfaz de la administración de cobro de patentes. .... 171 Figura Nº 108 : Diseño de la interfaz: menú principal. ........................................... 171 Figura Nº 109 : Diseño de la interfaz de proceso de pago y emisión de comprobante. ................................................................................ 172 Figura Nº 110 : Diagrama de componente: Gestionar cajeros y sucursales. ......... 173 Figura Nº 111 : Autenticación de cajero a la herramienta de cobro de patentes. .. 175 Figura Nº 112 : Ingreso de la UFV. ........................................................................ 175 Figura Nº 113 : Autenticación del administrador de la entidad financiera a la herramienta de cobro de patentes. ............................................... 176 Figura Nº 114 : Autenticación del administrador de la alcaldía a la herramienta de cobro de patentes. ........................................................................ 176 Figura Nº 115 : Interfaz menú principal. ................................................................ 177 Figura Nº 116 : Interfaz de proceso de pago y emisión de comprobante. ............. 178 Figura Nº 117 : Interfaz de reporte diario de cajero ............................................... 179 Figura Nº 118 : Interfaz de administrador de entidad financiera. ........................... 180 Figura Nº 119 : Reporte de los pagos realizados en la entidad financiera. ........... 180 Figura Nº 120 : Interfaz del administrador de la alcaldía. ...................................... 182 Figura Nº 121 : Interfaz de sitios municipales. ....................................................... 183 Figura Nº 122 : Reporte detallado de entidades financieras. ................................. 184 Figura Nº 123 : Reporte general de entidades financieras. ................................... 185 Figura Nº 124 : Interfaz de registro de contribuyentes........................................... 185 Figura Nº 125 : Activación SSL y HTTPS al módulo web. ..................................... 187 xvi


Figura Nº 126 : Certificado SSL del módulo web. .................................................. 187 Figura Nº 127 : Interfaz de logs de la herramienta de cobro de patentes .............. 189 Figura Nº 128 : Pruebas unitarias mediante Framework NUnit ............................. 192 Figura Nº 129 : Actores de la herramienta de cobro de patente: quinta iteración .. 194 Figura Nº 130 : Caso de uso: Gestionar reporte de patentes. ............................... 194 Figura Nº 131 : Diagrama de colaboración: Gestionar reporte de patentes. ......... 196 Figura Nº 132 : Diagrama de colaboración: Gestionar cajeros y sucursales. ........ 196 Figura Nº 133 : Diagrama de secuencia: Gestionar reporte de patentes............... 197 Figura Nº 134 : Diagrama de secuencia: Gestionar cajeros y sucursales. ............ 197 Figura Nº 135 : Herramienta del lado del cliente (entidad financiera). ................... 198 Figura Nº 136 : Herramienta del lado del servidor (alcaldía). ................................ 199 Figura Nº 137 : Diagrama de componente: Gestionar reporte de patentes. .......... 200 Figura Nº 138 : Diagrama de Componente: Gestionar cajero y sucursales. .......... 200 Figura Nº 139 : Prueba de carga al módulo web. .................................................. 205 Figura Nº 140 : Prueba de carga a la herramienta de cobro de patentes. ............. 206 Figura Nº 141 : Campana de Gauss para la demostración de la hipótesis............ 223

xvii


ÍNDICE DE ANEXOS

ANEXO A : Proformas y comprobantes de pago. ANEXO B : Encuesta del proceso actual de cobro de patentes. ANEXO C : Organigrama, conexión de comunas Y CEMAC al servidor del G.A.M.C. ANEXO D : Cuadros para el cálculo de patentes. ANEXO E : Normativas y aranceles de la ordenanza municipal de patentes. ANEXO F : Seguridad del módulo web, configuraciones de PHP y apache. ANEXO G : Circulares SB/443/2003 y SB/466/2004 del ASFI. ANEXO H : Encuesta para obtener información sobre requerimientos de entidades financieras. ANEXO I

: Registro de transacciones del cobro de patentes, medidas de seguridad para el enlace en línea.

ANEXO J : Pruebas de la herramienta de cobro de patentes y módulo web. ANEXO K : Encuesta para obtener información del fondo financiero privado Fasill. ANEXO L : Valores críticos para la distribución T-Student. ANEXO M : Certificación del Gobierno Autónomo Municipal de Cochabamba.

xviii


1

GEN ER ALID AD ES.

1.1 INTRODUCCIÓN. Hoy en día tanto empresas como instituciones se han caracterizado por relacionarse con las personas y la sociedad en general, estas relaciones sufrieron cambios constantes debido a la evolución de los diferentes medios de comunicación, con el surgimiento de internet se da una gran revolución en cuanto a la forma de comunicarse. Entre los propósitos de emplear estrategias tecnológicas estas ofrecen alternativas tales como páginas web donde las personas interactúan a través de una interfaz de usuario, y así comparten información con un interés en común. Es por eso que las empresas e instituciones tienen por objeto mejorar e implementar estrategias sólidas que se puedan adaptar a los cambios del mercado proporcionando enormes beneficios a las personas, para ello tienen como principal estrategia obtener mejores bienes a través de las entidades financieras, las cuales ofrecen alternativas diferentes a sus clientes, donde estas actúan como empresas remesadoras1 con el fin de facilitar el proceso de cobranza o pago de algún servicio básico, es por eso que la ventaja de obtener este tipo de servicios por parte de las entidades financieras den lugar a la denominada “Intermediación Financiera” 2, la cual permite que las entidades bancarias puedan realizar operaciones económicas a nombre de la institución interesada mediante un contrato deliberado. Las entidades financieras se enfocan ya sea en presentación de servicios en línea 3, conforme la tecnología y el canal de negocio que se van consolidando, a esto surge nuevas necesidades, el caso más representativo es el de las empresas que han buscado una solución para su gestión financiera y contable. (Gutiérrez, 2011) Para que una entidad financiera establezca el convenio con la empresa, básicamente tienen la opción de realizar la sincronización a través de un enlace en línea, donde se basan principalmente en aplicaciones cliente, mediante una arquitectura Cliente –

1

Empresa remesadora: Persona jurídica autorizada a realizar de forma habitual el servicio de remesas, debiendo suscribir contratos para efectuar tal servicio. 2 Intermediación financiera: La Intermediación Financiera es una actividad realizada sólo por una entidad financiera autorizada, consistente en la mediación entre la oferta y demanda de recursos financieros prestables. 3 Servicios en línea: Son servicios que los bancos ofrecen a la ciudanía a través de internet.

1 de 255


Servidor 4 , esta consiste fundamentalmente en un cliente (entidad financiera) que realiza peticiones a otro programa (servidor de la empresa). En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, donde el servidor no se ejecuta necesariamente sobre una sola maquina ni es necesariamente un sólo programa, los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. (Blake, 2009). Este enlace en línea está orientado técnicamente al uso de la arquitectura cliente/servidor mencionado en el párrafo anterior, donde principalmente se relaciona mediante una red de comunicaciones en la que los clientes requieren servicios del servidor, ya que este último centraliza diversos recursos y aplicaciones con los que cuenta; poniendo a disposición de los clientes cada vez que estos son solicitados. (Orfali, 2002). Teniendo en cuenta la arquitectura se puede establecer el enlace en línea donde permite la comunicación mediante tres elementos importantes: •

Cliente: Permite al usuario enviar solicitudes o peticiones al servidor mediante una interfaz gráfica de usuario, espera y recibe las respuestas del servidor. Una vez ejecutado el enlace permite al operario enviar solicitudes de búsqueda de datos de la persona al servidor y registrar la transacción comercial, así mismo visualizar el estado de cuentas de la persona, todo mediante la interfaz de usuario.

Servidor: Provee servicios y solicitudes de procesamiento de los clientes. Proporciona servicios de gestión, administración y protección de la información (datos) a través de conexiones de red, gobernadas por protocolos definidos y a los que acceden los usuarios, de modo concurrente, es decir múltiples conexiones desde un gran número de clientes. Esto permite que el servidor pueda gestionar el envío de registro de las transacciones comerciales por parte del cliente y lo almacene en una Base de datos como también el resto de las solicitudes.

4

Arquitectura cliente- servidor: Es una forma de dividir y especializar programas y equipos de cómputo con el fin de que la tarea sea eficiente.

2 de 255


Canal de comunicaciones: Es el medio por el cual se conecta el cliente con el servidor para el intercambio de información mutua. Esto es efectuado por servicios de comunicación como: RPC, MOM y ORB, mediante protocolos de red como: TCP/IP, IPX/SPX, DCE y puertos específicos. (Orfali, 2002).

Para obtener el servicio de una entidad financiera existen procesos administrativos y requisitos legales que se deben cumplir en ambas entidades, por ejemplo en la parte técnica, la entidad financiera requiere de una herramienta o un acceso limitado a la base de datos 5 que la empresa le otorga. Se pueden establecer distintas modalidades mediante un enlace en línea, donde permiten que él envió de información de operaciones económicas entre la entidad financiera y la empresa se efectué mediante un canal de comunicaciones, entre estas modalidades se encuentran: • Débito automático. El débito automático es el servicio que ofrece la entidad financiera para realizar el pago de servicios que son facturables regularmente. Por lo mismo, su conveniencia reside en pagar en tiempo y forma, sin necesidad de estar atentos a su pago. (Fassil, 2013). • Pago en ventanilla. Solamente se deberá indicar al funcionario de caja el apellido de la persona o el código otorgado por la Institución. No se necesita ningún tipo de documento o autorización adicional para identificarlo. Realizado el pago se entrega al cliente su factura y el estado de cuenta actualizado. (Fassil, 2013). • Pago en plataforma de negocios. Permite a los clientes realizar sus pagos de cuotas mediante plataforma de atención al cliente, como ser: el pago total con débito en cuenta, donde se realiza el pago completo de las cuotas deseadas debidamente todo el monto completo de su caja de ahorros. (Fassil, 2013)

5

Base de datos: Conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso.

3 de 255


1.2 ANTECEDENTES. La ciudad de Cochabamba fue fundada el 23 de enero de 1826 durante la llegada del Mariscal Antonio José de Sucre y para su respectiva cancelación de bienes e inmuebles, territorio e impuestos en todo el municipio se creó el edificio de la ALCALDÍA MUNICIPAL DE COCHABAMBA en la época de la colonia conocida como “Cabildo y/o Ayuntamiento”. El cual tiene una estructura de estilo renacentista muy bien conservado la cual está ubicado en la Plaza 14 de septiembre en la acera este. (Fassil, 2013). Una de las tantas entidades que trabaja con un número masivo de clientela es el denominado actualmente GOBIERNO AUTONOMO MUNICIPAL DE COCHABAMBA el cual tiene funciones gubernamentales muy importantes, las cuales son: •

Desarrollo humano.- Unidad especializada, que impulsa y promueve la formulación de políticas, estrategias y acciones locales, destinadas a lograr la promoción, desarrollo y fomento de la equidad social, la igualdad de derechos y oportunidades de hombres y mujeres del municipio.

Desarrollo económico.- Unidad cuyo fines el de apoyar y coadyuvar al desarrollo económico local aplicando el trabajo de controlar impuestos dentro la ciudadanía, promoviendo y fortaleciendo el desarrollo de iniciativas y emprendimientos públicos y privados para la producción de bienes y servicios de calidad, con énfasis en la pequeña, mediana industria y la artesanía local.

Cultura.- Unidad especializada en promover, fomentar, proteger, revalorizar y difundir las expresiones artísticas, las prácticas culturales y el patrimonio cultural del Municipio de Cercado-Cochabamba.

Turismo.- Unidad encargada Apoyar y coadyuvar a turistas extranjeros, que residen en Cochabamba promoviendo y fomentando a la exhibición de lugares históricos que son considerados patrimonios de la humanidad.

Estas funciones gubernamentales manejan documentación significativa, es así que el Municipio del Cercado trabaja con volúmenes de información enormes.

4 de 255


En el año 1994 se comenzó a cobrar el impuesto de patentes a personas del comercio, en ese tiempo al patente se lo denominaba sentaje, esto se refería al asentamiento que ocupaba un contribuyente 6 del territorio municipal. El municipio alquilaba una cierta superficie a las personas que ocupaban en mercados o en diferentes puntos de la ciudad, como ser micro mercados, tiendas de barrio, kioscos, etc. Este cobro de alquiler se lo realizaba mensualmente. Sin embargo hoy en día este alquiler se conoce como asentamiento de superficie de área y el pago se conoce como patente única municipal, entre los tipos de patentes se encuentran los siguientes: a) Patentes de sitios municipales o vías. b) Patentes de sitios comerciales. c) Patentes de publicidad y propaganda exterior. d) Patente eventual de publicidad y propaganda exterior. Por cada patente existe una cantidad de contribuyentes (16,700, 21,200, 5,500) respectivamente. (VER ANEXO B). Teniendo un total de 43,400 contribuyentes que deben pagar la patente cada 6 meses según ordenanza municipal. En la actualidad el GOBIERNO AUTONOMO MUNICIPAL DE COCHABAMBA cuenta con las instalaciones del CEMAC 7 ubicada en la plaza Colón acera este, donde permite realizar trámites como ser: impuestos de vehículos, cancelación de inmuebles y actividades económicas (cobro de patentes). El área de actividades económicas se trabaja con un sistema de cobro de patentes el cual es soportado con un administrador de base de datos Access. El presente trabajo de grado tiene por objeto facilitar el cobro de la patente al contribuyente mediante la intermediación financiera aplicando un enlace en línea entre entidades, y así poder cancelar esta patente en cualquier entidad bancaria, como también facilitar al contribuyente ver su estado de cuentas y obtener la proforma mediante web.

6 7

Contribuyente: Persona física o jurídica con derechos y obligaciones, frente a un ente público. CEMAC: Centro municipal de atención al contribuyente.

5 de 255


1.3 PLANTEAMIENTO DEL PROBLEMA. El contribuyente que realiza una actividad comercial y que dispone de una o más patentes o sitios municipales, debe aproximarse a las instalaciones del CEMAC. Dentro de las oficinas de dirección de ingresos municipales la demanda de contribuyentes para el cobro de patentes se aprecia cuando están por cumplir las fechas límites que son de 6 meses, por consiguiente existe: • Un área de proformas 8 que cuenta únicamente con 2 ventanillas, las cuales son atendidas por funcionarios de la alcaldía, donde el contribuyente se acerca y provee sus datos: código de licencia, papeleta original del anterior cobro o simplemente el nombre completo, posteriormente se le entrega una proforma impresa donde puede verificar cuánto debe cancelar según los impuestos determinados. (VER ANEXO A). • Teniendo la proforma el contribuyente se acerca al área de cancelación de bienes e inmuebles y actividades económicas donde existen 2 ventanillas, caja 1 y caja 2, los cuales son atendidos por funcionarios de la alcaldía, el contribuyente realiza la cancelación correspondiente y finalmente se le entrega el comprobante 9 de pago. (VER ANEXO A). Al momento de cancelar el monto indicado, existen 3 copias del comprobante de pago, el original se entrega al contribuyente, los otros 2 se quedan como respaldo, uno en archivos y otro en caja. Esta documentación de respaldo sirve para calcular cuánto se recaudado por mes y posteriormente esta información va dirigida a la unidad de finanzas del municipio del cercado. Toda la recaudación generada por día, se deposita a una cuenta de la alcaldía, denominada “Cuenta de Recursos Propios”, (Depósito a plazo fijo) seguidamente este depósito es sustentado al momento del traslado del dinero a la entidad financiera por la seguridad de la empresa “Brinks” 10 que brinda servicios para el transporte de fondos monetarios a entidades públicas y privadas. (Datos obtenidos mediante encuesta) (VER ANEXO B). 8

Proforma: Hoja del detalle de la patente por cada contribuyente. Comprobante: Hoja de respaldo de la cancelación de la patente. 10 Brinks: Empresa de servicios Integrales que ofrece transporte de valores. 9

6 de 255


1.3.1 Identificación del problema. En las instalaciones de la plaza Colón del GOBIERNO AUTONOMO MUNICIPAL DE COCHABAMBA se encuentra el CEMAC el cual se encarga de manejar el sistema de cobro de patentes. La demanda de contribuyentes para el cobro de patentes se incrementa cuando están por cumplir las fechas límites, estas fechas límites se vencen cada 6 meses después de la aprobación de la ordenanza municipal, cabe mencionar que esta ordenanza se pone a disposición cada gestión siendo dirigida a todo contribuyente que realiza alguna actividad comercial y que disponen de 1 o más patentes. El plazo para el pago de la patente municipal vence dentro de los ciento ochenta (180) días (6 meses) siguientes al perfeccionamiento del hecho generador 11, mediante la sustentación y en acuerdo con la unidad de dirección de recaudaciones de la alcaldía así como también con el respaldo del código tributario, y teniendo una resolución expresada se podrá ampliar con carácter general el plazo para la cancelación de la patente hasta el 31 de diciembre. Quiere decir que se establece un descuento del 10% a los contribuyentes que realicen el pago de la patente dentro del primer plazo (180 días), y los contribuyentes que cancelen pasado el plazo de los 6 meses (posterior a la fecha de vencimiento) estarán sujetos al pago adicional de accesorios (mantenimiento de valor, multa por incumplimiento de deberes formales e intereses) de conformidad a lo dispuesto por el código tributario 12. (Ordenanza Municipal 4369, 2012). Los contribuyentes en varias ocasiones realizan largas colas para ser atendidos, y la atención por día es limitada (8 horas de trabajo según lo establecido), primeramente se dirigen al área de proforma esto lleva a ocasionar largas filas y la espera del cliente, ya que sólo existe 2 únicas ventanillas que atienden un número aproximado de 100 personas en cada ventanilla haciendo un total de 200 por día, variando el impuesto que se está cancelando. (VER ANEXO B).

11

Hecho Generador: Es el uso o aprovechamiento de bienes de dominio público así como la obtención de autorización o permiso anual o eventual para la realización de toda actividad económica. 12 Código Tributario: Es el conjunto de normas que establecen el ordenamiento jurídico-tributario.

7 de 255


La demanda de contribuyentes que van a cancelar sus impuestos es un aproximado de 500 personas por día que se acercan a las ventanillas para recibir la proforma correspondiente, lo cual refleja que supera el número de atendidos por día, ya que las ventanillas atienden un total de 200 personas por día. De las 500 personas que realizan cola para la obtención de la proforma sólo 150 son pertenecientes al impuesto de la patente, son muchas las ocasiones en que el contribuyente realiza largas filas sólo para ver el detalle de cuánto debe cancelar según la proforma, teniendo esta información no realiza la cancelación y se retira, siendo así que de cada 500 contribuyentes que se encuentran haciendo cola para adquirir su proforma, sólo un aproximado de 100 personas logran acceder a ventanillas de caja y realizan el pago correspondiente. Lo cual provoca retraso de cancelación en los contribuyentes (VER ANEXO B). En la tabla Nº 1 se puede apreciar cuanto es el número de patente cancelados actualmente. Tabla Nº 1: Patente por espacio ocupado de contribuyentes minoristas, artesanos, vivanderos y número de patentes cancelados actualmente.

FUENTE: [Elaboración Propia]

De acuerdo a la tabla Nº1, sobre los datos obtenidos de la unidad de recaudaciones de la Alcaldía durante la gestión 2012, se puede determinar que el número de patente 8 de 255


cancelados es de 1000 por 6 meses, cifra que percibe el municipio del cercado por la disposición de 2 únicas ventanillas. Teniendo que el número de contribuyentes de sitios municipales, comerciantes, publicidad y propaganda sea un total de 43,400 contribuyentes realizando una comparación con el número de patentes cancelados actualmente sea de 1200 patentes en comparación con el número de contribuyentes es una cifra mínima que percibe la alcaldía en el tiempo límite de 6 meses. De acuerdo a todo lo expuesto anteriormente, se puede determinar que existe necesidad de ampliar los puntos de cancelación del impuesto de patentes y así poder incrementar el número de patentes cancelados. El sistema de cobro de patentes utiliza como un sistema de gestión de base de datos Microsoft Access 13, el cual tiene tiempos de respuesta críticos (5 min) al momento de buscar el nombre o código del contribuyente que está cancelando su impuesto. Suele existir pérdida de información al instante que se está realizando el mantenimiento o el backup 14 correspondiente, ya que la base de datos se encuentra llena por la cantidad de información guardada. El sistema de cobro de patentes depende del código tributario y la ordenanza municipal, para el cálculo de la patente se basan en fórmulas establecidas por ordenanza municipal, el contribuyente tiene acceso a verificar su estado de cuánto debe (proformas), pero en varias ocasiones tiene dudas del porqué de los montos, ya que las ordenanzas municipales se actualizan cada gestión, en especial la fórmula de UFV`s 15 establecida por el código tributario, la cual se actualiza diariamente para realizar el cálculo de la patente. Es así que el cobro de patentes es manejado por el código tributario y las ordenanzas municipales las que se actualizan cada gestión incluyendo actualización de multas e intereses, cabe mencionar que estas ordenanzas dependen del cambio de código tributario.

13

Microsoft Access: Gestor de datos que recopila información relativa a un asunto o propósito particular. 14 Backup: Es el respaldo o copia de seguridad de la información. 15 UFV: La Unidad de Fomento de Vivienda (UFV) es una unidad de cuenta reajustada según la inflación usado en Bolivia.

9 de 255


1.3.1.1 Identificación de la situación problemática. Al momento de realizar la cancelación de la patente existen demoras por la cantidad mínima de ventanillas y el número no proporcional de contribuyentes para el pago de la patente, lo que origina retrasos y la percepción mínima de cancelación de la patente, ya que el CEMAC es el único punto de cobranza que existe.

1.3.1.2 Identificación de las causas. Las causas identificadas son: • La atención al contribuyente tiene un límite por día. ya que existe bastante demanda. • El Gobierno Autónomo Municipal De Cochabamba espera incrementar el número de patentes cancelados actualmente. • Durante los últimos años en las instalaciones del CEMAC se apreció en lo que respecta al sistema de cobro de patentes, la pérdida de información, confusión de códigos de los contribuyentes, cancelaciones retrasadas, por el administrador de base de datos que utilizan actualmente, lo cual dio como resultado que no paguen en las fechas y gestión actual. • El contribuyente para tener el conocimiento del detalle de su patente tiene necesariamente que aproximarse a las instalaciones del CEMAC para obtener su proforma.

1.3.2 Formulación del problema. El proceso centralizado y el número reducido de ventanillas a disposición del contribuyente que desea cancelar y visualizar su estado de cuentas sobre patentes, origina retrasos de pago, largas filas y limitada cancelación de las mismas al GOBIERNO AUTONOMO MUNICIPAL DE COCHABAMBA.

1.3.3 Análisis causa-efecto. CAUSA.- El proceso centralizado y el número reducido de ventanillas a disposición del contribuyente que desea cancelar y visualizar su estado de cuentas sobre patentes. EFECTO.- Retrasos de pago, largas filas y limitada cancelación de las mismas.

10 de 255


1.4 OBJETIVOS Y ACCIONES. 1.4.1 Objetivo general. Desarrollar una herramienta de cobro de patentes mediante intermediación financiera aplicando enlace en línea entre entidades y un módulo web de estado de cuentas del contribuyente, para extender puntos de cobranza, incrementar el número de patentes cancelados al municipio del cercado y mejorar el tiempo de obtención de la proforma de pago.

1.4.2 Objetivos específicos y acciones. • Determinar el funcionamiento actual del sistema de cobro de patentes de la alcaldía de Cochabamba. • Identificar la metodología de desarrollo de software para la propuesta. • Desarrollar el módulo web que permita la obtención de proformas de pago para el cobro de patentes orientado a la propuesta. • Identificar los requerimientos de entidades financieras respecto a la intermediación financiera. • Desarrollar la herramienta de cobro de patentes que estará situado en la entidad financiera y permita la conexión con el servidor y actualización de datos en línea. • Realizar la verificación y pruebas para el funcionamiento correcto de la herramienta de cobro de patentes y módulo web.

11 de 255


Tabla Nº 2: Objetivos específicos y acciones. OBJETIVO

ACCIONES

Realizar el estudio del proceso aplicado actualmente, así como también el análisis del modelado de negocio actual.

Determinar

el

funcionamiento

actual del sistema de cobro de patentes

de

la

alcaldía

de

Realizar

el

Modelado

de

negocio

propuesto.

Cochabamba.

Analizar

fórmulas

y

requerimientos

utilizados actualmente en el sistema de cobro de patentes. •

Analizar las diferentes metodologías de desarrollo de software.

Seleccionar la metodología adecuada para la propuesta.

Identificar

la

metodología

de

desarrollo de software para la propuesta.

12 de 255


OBJETIVO

ACCIONES

Diseñar la interfaz web para la obtención de proformas.

Diseñar

el

módulo

web

mediante

diagramas UML. Desarrollar el módulo web que permita la obtención de proformas

programación adecuado.

de pago para el cobro de patentes orientado a la propuesta.

Analizar y seleccionar el lenguaje de

Analizar y seleccionar el gestor de base de datos adecuado para el módulo web.

Implementar la interfaz web para la obtención de proformas de pago.

Analizar e identificar las normas que establece la ASFI así como la ley de bancos y entidades financieras sobre la intermediación financiera.

Identificar los requerimientos de

Diseñar la conexión (enlace en línea)

entidades financieras respecto a la

entre la herramienta de cobro de patentes

intermediación financiera.

(Cliente) y el servidor de Base de Datos. •

Determinar características de seguridad para el enlace entre la entidad financiera y empresa.

13 de 255


OBJETIVO

ACCIONES

Diseñar la interfaz para la herramienta de cobro de patente

Diseñar la herramienta de cobro de patentes mediante diagramas UML.

Desarrollar la herramienta de cobro de patentes que estará situado en la entidad financiera y permita la conexión

con

el

servidor

Analizar y seleccionar el lenguaje de programación adecuado.

y

actualización de datos en línea. •

Implementar la interfaz de la herramienta de cobro de patentes.

Realizar el enlace entre entidad financiera y alcaldía.

Realizar la verificación y pruebas para el funcionamiento correcto de la

herramienta

de

patentes y módulo web.

cobro

Identificar los tipos de prueba adecuada.

Aplicar las pruebas identificadas.

de

FUENTE: [Elaboración Propia]

14 de 255


1.5 JUSTIFICACIÓN. 1.5.1 Justificación técnica. La elaboración de la herramienta de cobro de patentes mediante intermediación financiera aplicando enlace en línea entre entidades y un módulo web de estado de cuentas del contribuyente, para el GOBIERNO AUTONOMO MUNICIPAL DE COCHABAMBA facilitara el cobro del impuesto de la patente al usuario, estableciendo puntos de cobranza dentro del municipio del cercado, permitirá que el estado de cuentas del contribuyente se pueda obtener mediante el módulo web, este documento denominado proforma de pago. Lo que brindara la herramienta de cobro de patentes que estará situada en una entidad financiera es que el contribuyente pueda cancelar el impuesto con mayor comodidad y facilidad, mediante la página web poder verificar su estado de cuentas y la obtención de la proforma de pago.

1.5.2 Justificación económica. La herramienta de cobro de patentes mediante intermediación financiera aplicando enlace en línea entre entidades y un módulo web de estado de cuentas del contribuyente, brindara al GOBIERNO AUTONOMO MUNICIPAL DE COCHABAMBA incrementar recaudaciones, siendo así que el contribuyente pueda cancelar el impuesto de la patente en el tiempo establecido, es por eso que la herramienta ayudara de forma eficiente y accesible económicamente al municipio del cercado.

1.5.3 Justificación social. La implementación de la herramienta de cobro de patentes mediante intermediación financiera aplicando enlace en línea entre entidades y un módulo web de estado de cuentas del contribuyente, facilitara al contribuyente poder realizar la cancelación del patente desde una entidad financiera sin necesidad de aproximarse a las instalaciones del CEMAC, y este a su vez poder alcanzar el tiempo límite que tiene para cancelar su impuesto del patente, así como también poder visualizar el detalle del mismo mediante web, lo que ocasionaría un impacto positivo en el GOBIERNO AUTONOMO MUNICIPAL DE COCHABAMBA.

15 de 255


1.6 ALCANCE. El presente trabajo describe los diferentes alcances del tema. • La herramienta estará enfocado principalmente al cobro de patentes de sitios comerciales. • Estará centrado al enlace entre la entidad financiera y empresa (alcaldía). • Dentro del enlace en línea entre la entidad financiera y empresa el presente trabajo considerara que la herramienta se encontrará en la entidad bancaria. • Contribuyente podrá obtener su proforma de pago mediante la página web.

1.6.1 Alcance temático. El área en la que se ubica el presente trabajo es el área Seguridad de Sistemas, Ingeniería de Software, Análisis y diseño de sistemas, Sistema de Gestión de Base de Datos.

1.6.2 Alcance temporal. La implementación de la herramienta asumirá una duración de nueve meses en la presente gestión 2013.

1.6.3 Alcance geográfico. La herramienta de cobro de patentes mediante intermediación financiera aplicando enlace en línea entre entidades será utilizada para el GOBIERNO AUTONOMO MUNICIPAL DE COCHABAMBA, el cual cuenta con servicios básicos como ser de telefonía e internet, sin ninguna restricción en el alcance territorial.

1.6.4 Alcance institucional. El siguiente trabajo estará enfocado para el actual sistema de cobro de patentes ubicado en el CEMAC correspondiente al GOBIERNO AUTONOMO MUNICIPAL DE COCHABAMBA.

16 de 255


1.7 HIPÓTESIS. Herramienta de cobro de patentes mediante intermediación financiera aplicando enlace en línea entre entidades y un módulo web de estado de cuentas del contribuyente, permitirá extender puntos de cobranza, incrementar el número de patentes cancelados al municipio del cercado y mejorar el tiempo de obtención de la proforma de pago.

1.7.1 Análisis de variables. Variable independiente. • Herramienta de cobro de patentes mediante intermediación financiera aplicando enlace en línea entre entidades y un módulo web de estado de cuentas del contribuyente. Variable dependiente. • Extender puntos de cobranza. • Incrementar el número de patentes cancelados. • Obtención de la proforma de pago.

1.7.2 Definición conceptual. Variable independiente. Herramienta de cobro de patentes considerando la intermediación financiera y la cual estará situada en la entidad financiera con la que se establecerá un enlace en línea a la empresa, será utilizada por el cajero mediante una interfaz donde podrá realizar el cobro correspondiente de la patente, además el contribuyente podrá realizar la obtención de la proforma de pago mediante la página web, facilitando al usuario pagar su impuesto en una entidad financiera y obtener su proforma de pago mediante web.

17 de 255


Variable dependiente. 1. Extender puntos de cobranza. Involucra incrementar puntos de cobranza para la cancelación de la patente. 2. Incrementar el número de patentes cancelados. Involucra el aumento de patentes canceladas por el número de ventanillas puestas a disposición del contribuyente. 3. Obtención de la proforma de pago. Involucra el tiempo para la obtención del detalle de la patente denominado proforma de pago mediante la página web.

18 de 255


1.7.3 Operativización de variables. Tabla Nº 3: Operativización de variables. Variable

Dimensión

Indicador

Variable independiente. Herramienta

de

cobro

de Cobro y actualización Herramienta

patentes

mediante de datos en línea.

implementada

intermediación

financiera

testeada.

y

aplicando enlace en línea entre entidades. Variable dependiente.

Punto de cobranza con

Extender puntos de cobranza.

Puntos de cobranza.

dos ventanillas de caja actuales, con

comparado

el

puntos

número de

de

cobranza

propuesto. Incrementar

el

número

de Patentes cancelados.

patentes cancelados.

Número

de

patentes

canceladas actualmente

en

las

oficinas de Alcaldía de Cochabamba patentes

y

canceladas

con la implantación en los puntos de cobranza en Fassil. Obtención de la Proforma de Tiempo en el proceso Horas utilizadas para el Pago

de obtención de la proceso de obtención proforma de pago. FUENTE: [Elaboración Propia]

19 de 255

del detalle de la patente.


1.8 MATRIZ DE CONSISTENCIA. Figura Nº 1 : PROBLEMA

Matriz de consistencia. OBJETIVO

HIPOTESIS

HERRAMIENTA DE COBRO DE PATENTES MEDIANTE NTERMEDIACIÓN FINANCIERA APLICANDO ENLACE EN LÍNEA ENTRE ENTIDADES. CASO DE ESTUDIO: GOBIERNO AUTÓNOMO MUNICIPAL DE COCHABAMBA.

El proceso centralizado y el número reducido de ventanillas a disposición del contribuyente que desea cancelar y visualizar su estado de cuentas sobre patentes.

Desarrollar una herramienta de cobro de patentes mediante intermediación financiera aplicando enlace en línea entre entidades y un módulo web de estado de cuentas del contribuyente.

El desarrollo de una herramienta de cobro de patentes

mediante

intermediación financiera

aplicando

enlace en línea entre entidades y un módulo web

de

estado

cuentas

de del

contribuyente.

PROVOCA

PERMITIRÁ

PARA

Extender

puntos

de

Extender

puntos

de

Retrasos de pago,

cobranza, incrementar el

cobranza, incrementar el

largas filas y limitada

número

número

cancelación de las

cancelados al municipio

cancelados al municipio

del cercado y mejorar el

del cercado y mejorar el

tiempo de obtención de la

tiempo de obtención de

proforma de pago.

la proforma de pago.

mismas.

de

patentes

FUENTE: [Elaboración Propia]

20 de 255

de

patentes


2

MARC O T EÓR ICO.

2.1 MÉTODOS Y TÉCNICAS DE RECOLECCIÓN DE DATOS. Para el presente trabajo de grado se utilizan métodos y técnicas con el propósito de recopilar los datos, que ayudaran a sustentar una investigación completa, para ello se emplearan métodos o técnicas tales como: Entrevistas, cuestionarios y observación.

2.1.1 La observación. La observación permite ver más cosas de las que se evidencian a simple vista, es una técnica útil para el analista en su progreso de investigación, consiste en observar a las personas cuando efectúan su trabajo. Como técnica de investigación, la observación tiene amplia aceptación científica. El propósito es múltiple: permite al analista determinar que se está haciendo, como se está haciendo, quien lo hace, cuando se lleva a cabo, cuánto tiempo toma, dónde se hace y por qué se hace. (Barrantes, 2000).

2.1.1.1 Clasificación de la observación. De acuerdo a la intervención del investigador, la observación puede clasificarse según criterio de grado de intervención del investigador en: natural, estructurada, experimento de campo y observación participante. a) Observación natural: La observación natural es cuando el investigador es un mero espectador de una situación, sin que intervenga en modo alguno a los acontecimientos observados. Es una situación natural en el sentido que se produce dentro del contexto usual en que surge el fenómeno de interés. b) Observación estructurada: Cuando se decide intervenir y se estructura una situación en aras de obtener claridad en los datos, se está frente a la observación estructurada. Pero hay muchas situaciones intermedias entre observación natural y estructurada. c) Observación de experimento de campo: El nivel de estructuración es mucho mayor, aunque se mantiene el propósito de realizar la observación en el contexto natural, de ahí su nombre. d) Observación participante: En la observación participante el observador es parte de la situación observada, lo que le permite tener acceso a información que se le escaparía a cualquier observador externo 21 de 255


Para tener una observación clara y bien definida se tiene tres asuntos que se deben tener en cuenta cuando se va a observar: • Nunca se debe observar algo sino se tiene, previamente, una pregunta que responder. • Una vez formulada la pregunta, se elige el nivel o niveles de análisis adecuados para buscar la respuesta. • Dedicar un tiempo previo para hacer observación ordenada durante la cual se recoja la información de forma descriptiva. Así tener la posibilidad de establecer las categorías, para la descripción del problema. (Barrantes, 2000).

2.1.2 Las encuestas. Hay dos tipos principales de encuestas; las cuales se aplican en forma escrita y que se denominan cuestionario y las que aplican oralmente y se les llama entrevista. El uso de encuestas en una investigación, requiere de ciertas reglas que nos permitan acceder a la información en forma científica. La regla principal es que debe ser un proceso sistemático, o sea, que cualquier investigador que repita su aplicación obtenga los mismos resultados. (Barrantes, 2000).

2.1.2.1 Cuestionario. Puede decirse que el cuestionario es un instrumento que consta de una serie de preguntas escritas para ser resuelto sin intervención del investigador. El contenido de las preguntas de un cuestionario puede ser tan variados como los aspectos que se midan por medio de este. Hay dos tipos básicos preguntas: cerradas o abiertas.  Preguntas cerradas: Ofrecen al usuario que va a ser evaluado todas las alternativas posibles, o al menos todas aquellas que mejor responden a la situación que deseamos conocer. El sujeto tienen que elegir alguna o algunas de las alternativas, poniendo una señal convenida: una cruz, redondear con un circulo, subrayar, a veces suelen ser der preguntas con la opción afirmativa y negativa.

22 de 255


 Preguntas abiertas: No ofrecen ninguna categoría para elegir. Solo contienen la pregunta y no ofrecen ningún tipo de respuesta, dejando ésta a consideración del sujeto que completa el cuestionario. Las funciones básicas del cuestionario son: obtener, por medio de la formulación de preguntas adecuadas, las respuestas que suministren los datos necesarios para cumplir con los objetivos de la investigación. Para ello, se debe obtener información pertinente, valida y confiable. Para lograr esto, el investigador debe conocer muy bien el problema, los objetivos propuestos (o hipótesis), las variables y sus indicadores o la operacionalización de estas. Este proceso debe ser cuidadoso, no deben excluirse preguntas claves, ni deben incluirse aquellas que no sean relevantes, lo que no solo economiza tiempo y dinero, sino que también puede evitar el cansancio del informante. El cuestionario consta de tres partes fundamentales: • La introducción: Donde se explicita el objetivo del instrumento, la institución que lo patrocina, la petición de colaboración para responderlo y se agradece de antemano la valiosa participación del que responderá. • Las instrucciones: Son tan importantes como las preguntas y deben ser tan claras que todos los que respondan entiendan que deben hacer. Pueden ser instrucciones para todo el cuestionario, para un grupo de preguntas similares o para cada pregunta, si estas son de diferente tipo de respuesta. • El cuerpo o grupo de preguntas: No puede ser tan corto que se pierda información o tan largo que por tedioso no se responda o se haga parcialmente. (Barrantes, 2000).

2.1.2.2 Entrevista. Es una conversación, generalmente oral entre dos personas, de las cuales uno es el entrevistador y el otro el entrevistado. El papel de ambos puede variar según sea el tipo de entrevista. Esencialmente existen dos tipos de entrevistas a) La guiada, controlada, estructurada, dirigida La entrevista dirigida, sigue un procedimiento fijo, de antemano, por un cuestionario o guía, o sea una serie de preguntas que el entrevistador prepara previamente.

23 de 255


b) La no dirigida o no estructurada. La entrevista no dirigida deja la iniciativa al entrevistado, permitiéndole que vaya narrando sus experiencias, sus puntos de vista. El entrevistador puede hacer alguna pregunta inicial con miras a que el entrevistado exprese sus puntos de vista. Hay diferentes técnicas utilizadas para entrevistar las cuales son: • El panel: Consiste en repetir a intervalos las mismas preguntas o las mismas personas. Se busca estudiar la evolución de las opciones, durante periodos cortos. Es necesario que el entrevistador varíe la forma de las preguntas de una entrevista a otra, con el fin de que el entrevistador no distorsione las respuestas por efectos de la repetición. • La entrevista repetida: Es parecida al panel, pero con la diferencia de que para la entrevista repetida son sacadas muestras distintas de lo largo del tiempo. • La entrevista múltiple: Las personas son entrevistadas repetidas veces para anotar sus recuerdos o reacciones. Es un proceso en que el entrevistado acepta ser sometido a repetidas interrogaciones. Se utiliza mucho en psicología. • Ráfaga de preguntas: Se plantean las preguntas tan rápidamente como el entrevistado sea capaz de entender y responder. Es una técnica poco probada y no muy convincente. (Barrantes, 2000).

2.2 INTERMEDIACIÓN FINANCIERA. La Intermediación Financiera es una actividad realizada sólo por una entidad financiera autorizada, consistente en la mediación entre la oferta y demanda de recursos financieros prestables. Entendida así como la captación de recursos del público con el fin de colocarlos en operaciones activas o de otorgamientos de créditos. (Ley Nº 1488 LBEF, 1993). La intermediación financiera es efectuada mediante un contrato expreso de mandato financiero, el cual define una relación entre la entidad financiera y el solicitante de servicio (Institución o Empresa). (Circular 150 ASFI, 2012). La Autoridad de Supervisión del Sistema Financiero (ASFI) otorga la autorización a la entidad financiera para proporcionar servicios financieros de manera que estas 24 de 255


entidades autorizadas pasan a ser las denominadas: Entidades de Intermediación Financiera. (Ley Nº 1488 LBEF, 1993).

2.2.1 Entidades de Intermediación Financiera. Es la denominación que reciben las instituciones financieras autorizadas por la Autoridad de Supervisión del Sistema Financiero (ASFI), para realizar operaciones de capacitaciones de captación de ahorros y colocación de créditos. Las entidades de intermediación financiera (EIF), brindar a los clientes y usuarios los servicios financieros, estas adecuando sus operaciones financieras para ofrecer diversas opciones que permitan al cliente ahorrar tiempo y disponer de fácil acceso a estos servicios. En el sistema financiero establece que las entidades de intermediación financiera pueden estar clasificadas de tres diferente maneras: las entidades financieras bancarias, las entidades financieras no bancarias y las entidades financieras matriz. (Ley Nº 1488 LBEF, 1993). •

Entidad financiera bancaria: Son entidades autorizadas, de origen nacional o extranjero, dedicada a realizar operaciones de intermediación financiera y, a prestar servicios financieros al público en el marco de la ley, tanto en el territorio nacional como en el exterior del país. A esta categoría pertenecen los Bancos.

Entidad financiera no bancaria: Son el resto de entidades que intermedian en el mercado financiero y que no pudiendo generar “dinero”, canalizan el ahorro privado hacia diferentes activos financieros creados por ellas mismas, minimizando los riesgos inherentes y retribuyendo mediante intereses a sus partícipes. Esta categoría está constituida por fondos financieros privado, cooperativas de ahorro y crédito o mutual de ahorro y préstamo.

Entidad financiera matriz: Entidad autorizada que posee más del cincuenta por ciento del capital de otra entidad financiera denominada filial. (Ley Nº 1488 LBEF, 1993).

Entre las entidades de intermediación financiera de acuerdo a autorización de la ASFI, las cuales se caracterizan básicamente por la captación de depósitos y la concesión de créditos, se encuentran: 25 de 255


 Banco.  Fondo financiero privado.  Cooperativa de ahorro y crédito.  Mutual de ahorro y préstamo.

 Banco: Es una entidad autorizada, de origen nacional o extranjero, dedicada a realizar operaciones de intermediación financiera y, a prestar servicios financieros al público en el marco de Ley de Bancos y Entidades Financieras tanto en el territorio nacional como en el exterior.  Fondo financiero privado (FFP): Entidad de intermediación financiera no bancaria, constituida como sociedad anónima, autorizada a realizar operaciones de intermediación financiera y, a prestar servicios financieros al público dentro del territorio nacional.  Cooperativa de ahorro y crédito: Asociación autorizada para la captación de recursos del público en forma de depósitos y para otorgar créditos sólo a sus socios. Son entidades de crédito cuyo objetivo social es servir a las necesidades financieras de sus socios y de terceros mediante el ejercicio de las actividades propias de dichas entidades.  Mutual de ahorro y préstamo: Entidad de intermediación financiera no bancaria, constituida como asociación civil, autorizada a realizar operaciones de intermediación financiera y, a prestar servicios financieros al público. La entidad financiera actúa como intermediario financiero mediante la prestación de un servicio financiero a la empresa o institución interesada. (Ley Nº 1488 LBEF, 1993).

2.2.1.1 Servicios de remesa Una entidad de intermediación financiera puede ser una empresa remesadora, la cual puede realizar las siguientes operaciones: 1. Envió y pago de remesas al interior y exterior del país. 2. Envió y pago de giros a nivel nacional

26 de 255


3. Envió y pago de giros al exterior. 4. Compra y/o venta de moneda extranjera derivada de la prestación del servicio de remesas y/o giros. 5. Cobro de servicios básicos. Con el objeto de que los servicios de la empresa remesadora, en este caso la entidad de intermediación financiera ofrezca a nombre y por cuenta del contratante, operaciones y/o servicios financieros o de servicios auxiliares financieros, a nombre de la institución dentro de un ámbito territorial expresamente delimitado, por un tiempo determinado y a cambio de comisión previamente pactada. (Circular 150 ASFI, 2012). • Cobro de servicios básicos. Actividad que permite a la empresa remesadora prestar servicios de cobranza por el uso de servicios básicos públicos y/o privados, de energía eléctrica, agua, telecomunicaciones y gas, por cuenta de los proveedores de los diferentes servicios. (Circular 150 ASFI, 2012).

2.2.2 Empresa. Es la institución que solicita el servicio de remesa de la entidad de intermediación financiera, a través de la operación: cobro de servicios básicos, principalmente enfocada al cobro de patentes de la institución Pública del Gobierno Autónomo Municipal de Cochabamba.

2.2.2.1 Institución pública. El GOBIERNO AUTONOMO MUNICIPAL DE COCHABAMBA está encargada de cumplir funciones gubernamental importantes, entre estas se mencionan las siguientes: • Desarrollo humano.- Unidad especializada, que impulsa y promueve la formulación de políticas, estrategias y acciones locales, destinadas a lograr la promoción, desarrollo y fomento de la equidad social, la igualdad de derechos y oportunidades de hombres y mujeres del municipio. • Desarrollo económico.- Unidad cuyo fines el de apoyar y coadyuvar al desarrollo económico local aplicando el trabajo de controlar impuestos dentro la ciudadanía, 27 de 255


promoviendo y fortaleciendo el desarrollo de iniciativas y emprendimientos públicos y privados para la producción de bienes y servicios de calidad, con énfasis en la pequeña, mediana industria y la artesanía local. • Cultura.- Unidad especializada en promover, fomentar, proteger, revalorizar y difundir las expresiones artísticas, las prácticas culturales y el patrimonio cultural del Municipio de Cercado-Cochabamba. • Turismo.- Unidad encargada Apoyar y coadyuvar a turistas extranjeros, que residen en Cochabamba promoviendo y fomentando a la exhibición de lugares históricos que son considerados patrimonios de la humanidad. Para destacar la organización del Gobierno autónomo municipal de Cochabamba (GAMC) se tiene un organigrama el cual representa las estructuras departamentales así como las relaciones jerárquicas, señalando también que existe una unidad encargada de administrar los diferentes sistemas dentro del Municipio, Denominada Unidad de Sistemas (VER ANEXO C). La Alcaldía de Cochabamba cuenta con las instalaciones del CEMAC (Centro Municipal de Atención al Contribuyente), encargada de cobrar los diferentes impuestos como ser: •

Impuestos de vehículos,

Inmuebles y actividades económicas (cobro de patentes).

A continuación de describirá la unidad encargada del cobro de los diferentes impuestos así como también las jefaturas que administran esta área. CEMAC: Nació con el propósito de fortalecer las capacidades estratégicas de recaudación y atención al ciudadano así como lograr un relacionamiento armónico y atento entre la ciudadanía y la Alcaldía de Cochabamba a efectos de elevar la calidad de los servicios prestados, facilitando la realización de los trámites que realizan los ciudadanos y mejorando las actividades de los procesos utilizados. El CEMAC brinda servicios de realización de trámites de vehículos, inmuebles y actividades económicas, mejorando continuamente las actividades de los procesos utilizados, actualmente existen 2 jefaturas:

28 de 255


Actividades económicas: Encargada de cobrar las patentes de sitios y mercados.

Publicidad externa: Encargada de cobro de patentes de publicidad como ser: letreros, Publicadores luminosos, así también esta jefatura está encargada de emitir nuevas licencias de funcionamiento para los funcionarios.

El CEMAC se encuentra conectado al servidor principal de la alcaldía, en conjunto con las diferentes comunas con las que cuenta el GAMC (VER ANEXO C). A continuación se explicara a que se refiere con patentes, las consideraciones a tomar para los patentes y normativas que tiene esta.

2.2.2.2 Patente. Una patente es un derecho de propiedad otorgado por el gobierno a la sociedad ya sean a personas físicas o jurídicas, que desea realizar una actividad laboral o comercial. En la adquisición de una patente se toma en cuenta el espacio o superficie que está ocupando la persona física o jurídica. Dentro de los patente se tiene en cuenta una seria de consideraciones para su respectivo cobro, estas son: a) Ordenanza municipal. b) Código tributario. c) Y para enfocar más a los patentes se tiene una clasificación de esta. a) Ordenanza municipal. El órgano legislativo municipal así como el Concejo Municipal, es el que emite Ordenanzas Municipales en base a las competencias que le han sido otorgadas mediante Ley No 2028 de Municipalidades. Mediante Ordenanza Municipales se aprueba el área urbana del municipio, el catastro municipal, las zonas tributarias, se emiten normas de ordenamiento territorial, de ordenamiento de tráfico vehicular, de tasas y patentes municipales, de ordenamiento de mercados y sobre las normas que se deben cumplir para el funcionamiento de las actividades económicas. Mediante resoluciones municipales también emitidas por el Concejo Municipal es que normalmente se reglamenta la aplicación de las Ordenanza Municipales. 29 de 255


b) Código tributario. El Código Tributario es el conjunto de normas que establecen el ordenamiento jurídicotributario. El año 2003 el código Tributario distingue entre la patente municipal, que grava el uso o aprovechamiento de bienes de dominio público y la obtención de autorizaciones para la realización de actividades económicas; y la tasa, que grava los supuestos en los que la Administración presta un servicio o realiza actividades sujetas a normas de derecho público. c) Tipos de patentes De acuerdo al Artículo 13º de la Ordenanza Municipal de Patentes 4369 de 2012 los tipos de patentes se clasifican de la siguiente manera: A. Patentes de funcionamiento. A1. Patente de funcionamiento permanente. A2. Patente única municipal. A3. Patente de funcionamiento eventual. A4. Patente de funcionamiento por actividades eventuales para el uso y aprovechamiento de bienes públicos con fines económicos por ocupación a sitios destinados a graderías y sillas. A5. Patente eventual por la temporada. A6. Patente temporal de uso y aprovechamiento de bienes de dominio público con fines económicos en vías. B. Patente a los espectáculos públicos y recreaciones públicas. C. Patente de publicidad y propaganda. C1. Patente de publicidad y propaganda exterior.

A. Patentes de funcionamiento. Las actividades económicas clasifican a las patentes de funcionamiento en permanente y eventual.

30 de 255


A1. Patente de funcionamiento permanente. La patente de funcionamiento permanente, es la autorización o permiso anual para el funcionamiento de toda actividad económica. La base de cálculo de la patente de funcionamiento permanente estará en función al tipo de actividad económica, ubicación, y superficie cuya forma de aplicación será determinada utilizando factores y parámetros expresados en el (ANEXO D) en relación de los cuadros Nº 1 y 2. La fórmula para el cálculo de la patente de funcionamiento permanente se ilustra en la Figura Nº 2. Figura Nº 2 : Fórmula para el cálculo de la patente de funcionamiento permanente.

FUENTE: [Ordenanza Municipal 4369,2012]

A2. Patente única municipal. El hecho generador 16 de esta patente es la autorización o permiso que otorga el Gobierno Autónomo Municipal de Cercado – Cochabamba, por el uso de bienes públicos como ser calzadas, calles, mercados y simultáneamente la autorización para la realización de actividades económicas en esos espacios. El cálculo para la determinación de la patente única municipal, se realiza en función a las variables y sub categorías según el cuadro Nº 6 del (ANEXO D). A3. Patente de funcionamiento eventual. La patente de funcionamiento eventual, es la autorización o permiso temporal que se otorga por actividades realizadas en lugares o espacios autorizados por el Gobierno Autónomo Municipal, cuyos montos serán expresados en tablas (VER ANEXO D).

16

Hecho Generador: Es el uso o aprovechamiento de bienes de dominio público así como la obtención de autorización o permiso anual o eventual para la realización de toda actividad económica.

31 de 255


El cobro de la patente de funcionamiento por las actividades económicas eventuales, se aplica para superficies que van en un rango de cero a diez metros cuadrados (0 – 10 Mts. 2), de acuerdo a la Figura Nº 3 y en relación con el cuadro Nº 3 del ANEXO D. Figura Nº 3 : Fórmula para el cálculo de la patente de funcionamiento eventual.

FUENTE: [Ordenanza Municipal 4369,2012]

A4. Patente de funcionamiento por actividades eventuales para el uso y aprovechamiento de bienes públicos con fines económicos por ocupación a sitios destinados a graderías y sillas. La patente de funcionamiento por actividades eventuales se refiere por la realización de actividades económicas que eventualmente se efectúan, como ser carnaval de la concordia, carnavales zonales, entrada universitaria, fiestas patrias, cívicas, patronales y otras similares, en espacios públicos, vías, aceras y calzadas, para la instalación de silla, baquetas, graderías y similares, en módulos, debidamente autorizadas por el Gobierno Municipal. El cobro de la patente de funcionamiento eventual por ocupación de sitios destinados a graderías y sillas, se aplicara de acuerdo a la Figura Nº 4 y en relación con el cuadro Nº 4 del (ANEXO D). Figura Nº 4 : Fórmula para el cálculo de la patente de funcionamiento por actividades eventuales.

FUENTE: [Ordenanza Municipal 4369, 2012]

32 de 255


A5. Patente eventual por la temporada. La patente eventual por la temporada establece por la realización de actividades económicas que temporalmente se efectúan como ser venta de : comidas rápidas, frutas (maní, durazno, uva, naranja, pera, ciruelo, damasco y otros afines), tubérculos (papa, papa liza, yuca, oca, chuño, camote y otros derivados), hortalizas (cebollas, lechuga, haba, arveja, tomate, zanahoria, remolacha, repollo, pimentón y otros afines) y otras similares, en espacios públicos, vías, aceras, y calzadas debidamente autorizadas por el Gobierno Autónomo Municipal del cercado en coordinación con la intendencia. El cobro de la patente de funcionamiento eventual por la temporada, se aplicada de acuerdo a la Figura Nº 5 y en relación con el cuadro Nº 3.1 del ANEXO D. Figura Nº 5 : Fórmula para el cálculo de la patente de funcionamiento por actividades de temporada.

FUENTE: [Ordenanza Municipal 4369,2012]

A6. Patente temporal de uso y aprovechamiento de bienes de dominio público con fines económicos en vías. Esta patente establece por la realización de actividades económicas en los espacios públicos como ser calzadas, y aceras. El mecanismo de cobro según la característica establecida para el efecto, de manera mixta (Actividad con domicilio Fiscal – Patente Máxima, según el cuadro Nº 1 y de manera independiente por avance en aceras y calzadas a las actividades en predios municipales, según cuadro Nº 7 del (ANEXO D). B. Patentes a los espectáculos y recreaciones públicas. Esta patente establece para la realización de espectáculos públicos eventuales como: teatrales, cinematográficos, actuaciones artísticas, deportivas, veladas escolares o de

33 de 255


instituciones culturales, bailes, circos, parques de diversiones, kermesse y otros similares, con o sin fines de lucro. La base del cálculo de la patente de funcionamiento a los espectáculos y recreaciones publicas estará en función al tipo de espectáculo, cuya forma de aplicación será determinada utilizando factores y parámetros expresados de acuerdo al cuadro Nº 5 (VER ANEXO D). C. Patente de publicidad y propaganda. La exhibición y difusión de la publicidad en el ámbito promocional, permanente o eventual en anuncios luminosos, no luminosos, murales y otros de características similares, en lugares o espacios expresamente autorizados, accesos a la ciudad, paseos y en lugares privados; genera la obligación de pagar la patente anual o eventual. Las personas naturales o jurídicas que instalen letreros de identificación del local o establecimiento comercial en el frente del inmueble que ocupan, están exentas de esta patente, estos letreros contendrán exclusivamente la razón social o rótulo comercial, nombre o profesión, sin ninguna otra manifestación adicional. (Ordenanza Municipal 4369, 2012).

2.2.2.3 Normativas de los patentes. Para considerar el cobro de la patente se tiene en cuenta un proyecto de ordenanza municipal es cual es remitido por el Ejecutivo Municipal el cual consta con una Parte Normativa dispuesto en 3 capítulos y 49 artículos siendo este el Anexo I de la ordenanza municipal a ser emitida por este órgano deliberante y un Anexo II en su Parte Arancelaria dispuesto en 11 cuadros de detalle especifico. (Ordenanza Municipal 4369, 2012). (VER ANEXO E).

2.2.3 Enlace. Un enlace también llamado conexión o liga, es un elemento de comunicación donde se pueden realizar peticiones a otro recurso. A su vez un enlace técnicamente se puede referir a la aplicación de la arquitectura Cliente/Servidor ya que principalmente se relaciona mediante una red de

34 de 255


comunicaciones en la que todos los clientes están conectados a un servidor. Este tipo de red comúnmente denominado red de igual a igual (Peer to Peer) (Blake, 2009). Por tanto para el enlace entre entidad financiera y empresa se priorizara utilizar las aplicaciones propias de cada una, para ello describiremos la arquitectura clienteservidor.

2.2.3.1 Arquitectura cliente-servidor. El enlace entre la entidad financiera y empresa desde el punto de vista técnico se basa en la arquitectura cliente servidor, es un modelo de aplicación distribuida 17 donde las transacciones se dividen en procesos independientes que cooperan entre sí para intercambiar información entre servidor (proveedor de recursos o servicios) y cliente (demandante que solicita servicios). (Orfali, 2002). Esta arquitectura debe contener las características descritas a continuación: • Servicio: La arquitectura cliente/servidor es ante todo una relación entre procesos que se ejecutan en máquinas independientes una de la otra. El proceso servidor es un proveedor de servicios. En esencia, la tecnología cliente/servidor provee una clara separación de funciones con base en la idea de servicio. • Recursos compartidos: Un servidor puede servir a varios clientes al mismo tiempo y regular su acceso a recursos compartidos. • Protocolos asimétricos: Existe una relación de muchos a uno entre varios clientes y un servidor. Los clientes siempre empiezan el dialogo al solicitar un servicio, los servidores esperan de modo pasivo a que les lleguen solicitudes de los clientes. • Intercambios basados en mensajes: Clientes y servidores son sistemas acoplados sin grandes restricciones que interactúan mediante un mecanismo de intercambio de mensajes, así estos se convierten en el mecanismo de entrega para las solicitudes y respuestas de servicio. • Escalabilidad: Los sistemas cliente/servidor pueden escalarse horizontal o verticalmente. El escalamiento horizontal implica que al agregar o quitar estaciones de trabajo clientes sólo se produce un pequeño efecto en el desempeño. El 17

Aplicación distribuida: Aplicaciones con distintos componentes que se ejecutan en entornos separados y que envían información entre ellos mediante protocolos de comunicación.

35 de 255


escalamiento vertical significa migrar a una máquina servidor más grande y rápida o distribuir la carga de procesamiento entre varios servidores. El servidor es el proveedor de servicios al cliente, estos servicios son diferentes en cada servidor por ese motivo se dividen por la naturaleza de sus servicios y se puede contar con: Servidores de archivos, web, transacciones, DNS, etc. (Orfali, 2002).

2.2.3.2 Cliente. Permite al usuario enviar solicitudes o peticiones al servidor mediante una interfaz gráfica de usuario, espera y recibe las respuestas del servidor. Como se puede ver en la Figura Nº 6, existen dos tipos de clientes: Clientes pesados: Donde la mayor parte de la aplicación se ejecuta del lado cliente, estos clientes se usan para el soporte de las decisiones y el software personal. El servidor solamente es responsable de la gestión de los datos. El software del cliente implementa la lógica de la aplicación y las interacciones con el usuario del sistema. Clientes ligeros: Todo procesamiento de las aplicaciones y la gestión de los datos se lleva a cabo en el servidor. El cliente simplemente es responsable de la capa de presentación del software. (Orfali, 2002). Figura Nº 6 :

Clientes ligeros y pesados

FUENTE: [Robert Orfali, 2002]

36 de 255


2.2.3.3 Servidor. El servidor proporciona un puerto de comunicación por el cual se deben conectar todos los clientes que deseen obtener dicho servicio. Para ello se tienen los servidores de base de datos y los servidores de aplicaciones. Servidores de base de datos: Proporciona servicios de gestión, administración y protección de la información (datos) a través de conexiones de red, gobernadas por unos protocolos definidos y a los que acceden los usuarios, de modo concurrente, a través de aplicaciones clientes (bien sean herramientas del propio sistema como aplicaciones de terceros). Como se muestra en la Figura Nº 7. Figura Nº 7 :

Cliente/servidor con servidor de base de datos.

Aplicación

Solicitudes en SQL

Servidor

DBMS del servidor

Aplicación FUENTE: [Robert Orfali, 2002]

Los servidores de bases de datos surgen con motivo de la necesidad de las empresas de manejar grandes y complejos volúmenes de datos, al tiempo que requieren compartir la información con un conjunto de clientes. Con el conjunto de clientes, se requiere de uno el cual pasa como mensaje, solicitudes escritas en SQL al servidor, el resultado de cada comando SQL se devuelve por la red. El código que procesa la solicitud de SQL reside en la misma máquina, lo mismo que

37 de 255


la información. EL servidor emplea su poder de procesamiento para encontrar los datos solicitados en vez de entregar todos los registros al cliente. (Orfali, 2002). Servidor de aplicaciones: Proporciona servicios de aplicación a las computadoras cliente, gestiona la mayor parte (o la totalidad) de las funciones de lógica de negocio y de acceso a los datos de la aplicación, como se muestra en la Figura Nº 8. De esta manera centraliza y disminuye la complejidad en el desarrollo de aplicaciones. (Orfali, 2002). Figura Nº 8 : Cliente/servidor con servidor de aplicaciones.

FUENTE: [Robert Orfali, 2002].

Servidor Web IIS: Internet Information service (IIS) es un conjunto de servicios que hacen que un ordenador, normalmente preparado para ello, se convierta en un servidor web, es decir que en las computadoras que tienen este servicio instalado se puedan publicar páginas web tanto local como remotamente. Para que una maquina pueda ser servidor en una red de internet o intranet debe tener un sistema operativo que soporte todo lo necesario para ello en este caso Windows 2003 server es una buena opción o alguna versión superior del mismo, incluso Windows XP profesional es capaz de tener instalada una versión de IIS algo más reducida y limitada.

38 de 255


Los servicios de Internet Information Services proporcionan las herramientas y funciones necesarias para administrar de forma sencilla un servidor web seguro. (Políticas de Seguridad, 2013). Los servicios que IIS aporta a la maquina servidor son: •

FTP: File Transfer Protocol. Este servicio nos ofrece la opción de transferir archivos en una arquitectura de cliente/servidor de tal forma que el cliente pueda tanto subir como descargar archivos de la máquina servidor.

SMTP: Simple Mail Tranfer Protocol. Protocolo simple de transferencia de correo, nos da la posibilidad de intercambiar mensajes de correo electrónico entre los ordenadores.

NNTP: Network News Transfer Protocol. “Protocolo para la transferencia de noticias en red” es un protocolo creado para la lectura y la escritura de noticias o artículos en la red.

HTTP/HTTPS: Hyper Text Transfer Protocol. Es el protocolo de transferencia de hipertexto se utiliza para cada una de las transacciones realizadas en las páginas web, este protocolo define la forma de comunicarse de los elementos de la red y sigue el esquema de petición-respuesta entre cliente y servidor. (Servidor IIS, 2013).

Servidor HTTP Apache. El servidor HTTP Apache es un servidor web HTTP de código abierto, para plataformas Unix (BSD, GNU/Linux, etc.), Microsoft Windows, Macintosh y otras, que implementa el protocolo HTTP/1.12 y la noción de sitio virtual. Apache presenta entre otras características altamente configurables, bases de datos de autenticación y negociado de contenido, pero fue criticado por la falta de una interfaz gráfica que ayude en su configuración. La mayoría de las vulnerabilidades de la seguridad descubiertas y resueltas tan sólo pueden ser aprovechadas por usuarios locales y no remotamente. Sin embargo, algunas se pueden accionar remotamente en ciertas situaciones, o explotar por los 39 de 255


usuarios locales malévolos en las disposiciones de recibimiento compartidas que utilizan PHP como módulo de Apache. 2.2.3.3.1 Canal de comunicaciones. En lo que respecta de la intermediación financiera es el medio de comunicación por donde se envían las transacciones correspondientes mediante el cliente (que está en la entidad financiera) hacia el servidor (que está en la institución). Este envió es efectuado mediante un middleware de comunicaciones que proporciona los medios mediante los cuales los clientes y servidores se comunican para realizar funciones específicas. En la Figura Nº 9, se puede ver un ejemplo de interacción entre los componentes del cliente y servidor Figura Nº 9 : Interacción entre los componentes del cliente y servidor de BD

FUENTE: [Rob, 2004]

El middleware es el sistema nervioso de la infraestructura cliente/servidor. Empieza con el conjunto de API en el lado cliente que se utiliza para llamar a un servicio, y comprende la transmisión de la solicitud por la red y la respuesta que se le da. El middleware no incluye el software que provee el verdadero servicio, pues este reside en el dominio del programa servidor, tampoco incluye una base de datos. En el lado del cliente el middleware no incluye la interfaz de usuario, la cual que pertenece a la esfera de la aplicación cliente. (Orfali, 2002).

2.2.4 Seguridad en la intermediación financiera. En el envío de información entre la entidad financiera y empresa existe la probabilidad de personas maliciosas que puedan corromper los datos, por lo cual es necesario que existan mecanismos de seguridad que protejan la información y garanticen el envío de datos desde el cliente hasta el servidor.

40 de 255


Para ello se mencionaran los siguientes mecanismos de seguridad: •

Seguridad SSL.

S-HTTP.

Firewall.

Normas de Seguridad.

2.2.4.1 Seguridad SSL. SSL son las siglas en inglés de Secure Socket Layer (en español capa de conexión segura). Es la norma para la autenticación y encriptación entre navegadores y servidores web. Empleado para realizar conexiones seguras entre un cliente (como lo es un navegador de Internet) y un servidor, así también SSL verifica que el contenido del mensaje no haya sufrido alteraciones. Se puede ver a SSL como el proveedor de una capa de seguridad, la cual no ocasiona ningún perjuicio entre el transporte de TCP/IP y los sockets 18. Dicho de otro modo SSL brinda un enlace seguro de comunicación que comprende las aplicaciones que lo convocan. Por ejemplo, la existencia de SSL es transparente para el correo electrónico o HTTP. Los servidores de este último protocolo que implementan SSL deben ejecutarse en el puerto 443 y no en el puerto normal, el 80. El protocolo SSL proporciona: •

Interacciones privadas entre cliente y servidor mediante encriptación.

Autenticación de servidor.

Intercambios confiables entre cliente y servidor a través de revisiones de la integridad de los mensajes que detectan la alteración.

Cuando un cliente y un servidor empiezan a comunicarse, convienen una versión del protocolo SSL, eligen los algoritmos criptográficos, optativamente se autentican el uno al otro y utilizan técnicas de encriptación de llave pública para generar secretos compartidos.

18

Sockets: Constituyen el mecanismo para la entrega de paquetes de datos provenientes entre 2 programas los cuales pueden intercambiar cualquier flujo de datos, generalmente de manera fiable y ordenada.

41 de 255


El protocolo de saludo de SSL debe concluir primero su labor antes de que una aplicación pueda transmitir o recibir su primer byte de información. Este protocolo permite al cliente y al servidor autenticarse entre sí y negociar el algoritmo de cifrado (encriptación). En general, el navegador debe asegurarse de que el servidor emplea un certificado válido. Los servidores también pueden ocupar SSL para verificar las credenciales (o certificados) del cliente. Una sesión de SSL podría comprender varias conexiones seguras; además, es posible tener varias sesiones simultáneas. La encriptación acordad entre el cliente y el servidor permanece válida durante las varias conexiones. SSL usa autenticación de llave pública y tecnología de encriptación RSA, La implementación para la exportación emplea un algoritmo de encriptación de flujo RC4 de llave de 40 bits. (Orfali, 2002)

2.2.4.2 S-HTTP. S-HTTP es la variante con seguridad mejorada del protocolo de transporte de hipertexto (HTTP) de internet. S-HTTP añade encriptación y seguridad en el nivel de aplicaciones sobre comunicaciones basadas en conexiones comunes. El cliente y el servidor se comunican por una sesión ordinaria de HTTP y luego negocian sus requisitos de seguridad; usa un protocolo semejante a MIME para encriptar el contenido de sus mensajes. S-HTTP ofrece las siguientes revisiones de seguridad: •

Autentica a clientes y servidores.

Revisa si no se han revocado los certificados que presenta el servidor.

Soporta encadenamiento y jerarquías de certificados.

Permite que las aplicaciones negocien los grados de seguridad que necesitan.

Proporciona comunicaciones seguras por firewalls empresariales.

S-HTTP y SSL enfocan el problema de la seguridad desde dos ópticas diferentes. El primero rotula documentos individuales (o páginas web) como privadas o como firmadas. El segundo, por su parte, asegura que el canal de comunicación entre dos partes, se puede decir que es privado y esta autenticado. Las capas de seguridad SSL 42 de 255


están debajo de los protocolos de aplicación, en tanto que S-HTTP agrega seguridad basada en los mensajes encima de HTTP. SSL y S-HTTP pueden coexistir sin problemas de un modo muy complementario, al colocar al primero debajo del segundo, como se muestra en la Figura Nº 10. En consecuencia, es posible obtener mucha mejor seguridad de la que brindaría cualquier enfoque por sí solo. (Orfali, 2002). Figura Nº 10 : S-HTTP sobre SSL.

FUENTE: [Orfali, 2002]

2.2.4.3 Firewall. Es una parte de un sistema o una red que está diseñada para bloquear el acceso no autorizado, permitiendo al mismo tiempo comunicaciones autorizadas. Se encarga de proteger esta última mediante el filtrado del tránsito que va hacia Internet y que proviene de esta, de acuerdo con políticas establecidas. Los firewalls se emplean para definir quién pueden entrar en la red y cuándo. Por lo común, proporcionan dos interfaces de red: una que hace la conexión con la red interna protegida y otra que la hace con la red externa sin proteger, en la Figura Nº 11, se observa cómo trabaja el firewall desde un punto de vista de red interna. (Orfali, 2002).

43 de 255


Figura Nº 11 : Firewall.

FUENTE: [Orfali, 2002]

Los firewalls ofrecen un solo punto de entrada en el que es posible imponer controles de acceso, además de auditar el tránsito de la red. Existen dos tipos de firewalls: •

Compuertas de aplicación basadas en servidores de validación: Estos firewalls también conocidos como firewalls de aplicaciones, son los más seguros. Ejecutan un pequeño número de programas, denominados de validación o proxys, que pueden ser seguros y confiables. Todo el tránsito que provienen de Internet se pasa a la compuerta de validación apropiada ya sea para correo, HTTP, FTP, IIOP, etc. En seguida, los servidores de validación transfieren esa información a la red interna, de acuerdo con derechos de acceso del usuario. Como el servidor de validación es una aplicación, toma sus decisiones con base en el contexto y en reglas de autorización y autenticación, no en direcciones IP. Esto significa que el firewall funciona en el nivel más alto de la pila de protocolos, lo cual permite la implementación de políticas de seguridad fundadas en un conjunto mayor de medidas de protección.

Enrutadores de filtrado de paquetes: Un filtro de paquetes es un mecanismo que suministra un grado básico de seguridad en la red en el nivel de IP. En general, los filtros de paquetes se implementan en los enrutadores y se les configura utilizando tablas complejas con el objeto de establecer qué protocolos de comunicaciones pueden entrar y salir de una red en particular.

44 de 255


2.2.4.4 Normas de seguridad. Las normas son un conjunto de lineamientos, reglas, recomendaciones y controles con el propósito de dar respaldo a las políticas de seguridad y a los objetivos desarrollados por éstas, a través de funciones, delegación de responsabilidades y otras técnicas, con un objetivo claro y acorde a las necesidades de seguridad establecidas para el entorno administrativo de la red organizacional. Una norma de seguridad establece unos requisitos que se sustentan en la política y que regulan determinados aspectos de seguridad. Son por tanto, declaraciones a satisfacer. Una norma debe ser clara, concisa y no ambigua en su interpretación. (Políticas de Seguridad, 2013). Para reflejar más a cerca de las normas que se establecerán en el presente trabajo consideraremos las siguientes: •

Estándar de seguridad (ISO/IEC 17799/2005).

Circulares del ASFI.

 Estándar de seguridad (ISO/IEC 17799/2005). Es un estándar internacional de alto nivel para la administración de la seguridad de la información, fue publicado por la ISO (International Organization for Standardization) en diciembre de 2000 con el objeto de desarrollar un marco de seguridad sobre el cual trabajen las organizaciones. La ISO/IEC 17799 proporciona recomendaciones de las mejores prácticas en la “Gestión de la seguridad de la información” a todos los interesados y responsables en iniciar, implantar o mantener sistemas de gestión de la seguridad de la información. La seguridad de la información se define en el estándar como:  Confidencialidad.- Asegurar que únicamente personal autorizado tenga acceso a la información.  Integridad.- Garantizar que la información no será alterada, eliminada o destruida por entidades no autorizadas.  Disponibilidad.- Asegurar que los usuarios autorizados tendrán acceso a la información cuando la requieran. (ISO/IEC 17799, 2005).

45 de 255


 Circulares del ASFI. Las Circulares son documentos que ponen en vigencia las actualizaciones realizadas a la recopilación de normas, manual de cuentas y legislación vigente de la industria financiera dentro el territorio Boliviano. (Circulares ASFI, 2013). Para el presente trabajo se tomaron en cuenta dos circulares: La SB/466/2004 y SB/443/2003, las cuales son detalladas en el ANEXO G.

2.3 INGENIERÍA DE SOFTWARE. La ingeniería de software es una disciplina de la ingeniería que comprende todos los aspectos de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza. Se puede mencionar que existen 2 frases claves para tomar en cuenta dentro de la ingeniería de software, las cuales son: 1.- Disciplina de la ingeniería. Los ingenieros hacen que las cosas funcionen. Aplican teorías, métodos y herramientas donde sean convenientes, pero las utilizan de forma selectiva y siempre tratando de descubrir soluciones a los problemas, aun cuando no existan teorías y métodos aplicables para resolverlos. Los ingenieros también saben que deben trabajar con restricciones financieras y organizacionales, por lo que buscan soluciones tomando en cuenta estas restricciones. 2.- Todos los aspectos de producción de software. La ingeniería del software no sólo comprende los procesos técnicos del desarrollo de software, sino también con actividades tales como la gestión de proyectos de software y el desarrollo de herramientas, métodos y teorías de apoyo a la producción de software. En general, los ingenieros de software adoptan un enfoque sistemático y organizado en su trabajo, ya que es la forma más efectiva de producir software de alta calidad. Sin embargo, aunque la ingeniería consiste en seleccionar el método más apropiado para un conjunto de circunstancias, un enfoque más informal y creativo de desarrollo podría ser efectivo en algunas circunstancias. El desarrollo informal es apropiado para el desarrollo de sistemas basados en Web, los cuales requieren una mezcla de técnicas de software y de diseño gráfico. (Somerville, 2005). 46 de 255


2.3.1 Modelos del proceso del software. Un modelo del proceso del software es una representación abstracta de un proceso del software. Cada modelo de proceso representa un proceso desde una perspectiva particular, y así proporciona sólo información parcial sobre ese proceso. Estos modelos generales no son descripciones definitivas de los procesos del software. Más bien, son abstracciones de los procesos que se pueden utilizar para explicar diferentes enfoques para el desarrollo de software. (Somerville, 2005). Entre los modelos de proceso de software podemos mencionar: •

Modelo incremental.

Desarrollo evolutivo.

Modelo de desarrollo basado en componentes.

2.3.1.1 Modelo incremental. Hay muchas situaciones en las que los requerimientos iniciales del software están razonablemente bien definidos, pero el alcance general del esfuerzo de desarrollo imposibilita un proceso lineal. En tales casos, se elige un modelo de proceso diseñado para producir el software en incrementos. El modelo incremental combina elementos de los flujos de proceso lineal y paralelo como se muestra en la Figura Nº 12, el modelo incremental aplica secuencias lineales en forma escalonada a medida que avanza el calendario de actividades. Cada secuencia lineal produce “Incrementos” de software susceptibles de entregarse, de manera parecida a los incrementos producidos en un flujo de proceso evolutivo. Tomando como ejemplo podemos mencionar un software para procesar textos que se elaboren con el paradigma incremental tuviéramos los siguientes incrementos: 1.-Las funciones básicas de administración de archivos, edición y producción del documento. 2.-Se entregara herramientas más sofisticadas de edición y producción del documento. 3.-Separación de palabras y revisión de la ortografía. 4.-Se proporcionara la capacidad para dar formato avanzado a las páginas.

47 de 255


Figura Nº 12 :

Modelo incremental.

FUENTE: [Roger S. Pressman, 2002]

Cuando se utiliza un modelo incremental, es frecuente que el primer incremento sea el “producto fundamental”. Es decir, que se abordan los requerimientos básicos, pero no se proporcionan muchas características suplementarias. El cliente usa el producto fundamental (o lo somete a una evaluación detallada). Como resultado del uso y/o evaluación se desarrolla un plan para incrementos que sigue. El plan incluye la modificación del producto fundamental para cumplir mejor las necesidades del cliente, así como la entrega de características adicionales y más funcionales. Este proceso se repite después de entregar cada incremento, hasta terminar el producto final. El modelo de proceso incremental se centra en que cada incremento se entrega un producto que ya opera. Los primeros incrementos son versiones desnudas del producto final, pero proporcionan capacidad que sirve al usuario y también le dan una plataforma de evaluación. (Pressman, 2012).

2.3.1.2 Desarrollo evolutivo. El desarrollo evolutivo se basa en la idea de desarrollar una implementación inicial, exponiéndola a los comentarios del usuario y refinándola a través de las diferentes versiones hasta que se desarrolla un sistema adecuado. Como se muestra en la Figura Nº 13. Las actividades de especificación desarrollo y validación se entrelazan en vez de separarse, con una rápida retroalimentación entre éstas. Existen dos tipos de desarrollo evolutivo: 48 de 255


1. Desarrollo exploratorio: Donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente. 2. Prototipos desechables: Donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo. Figura Nº 13 : Desarrollo evolutivo.

FUENTE: [Somerville Ian, 2005]

La ventaja de un proceso del software que se basa en un enfoque evolutivo es que la especificación se puede desarrollar de forma creciente. Tan pronto como los usuarios desarrollen un mejor entendimiento de su problema, éste se puede reflejar en el sistema software. Sin embargo, desde una perspectiva de ingeniería y de gestión el enfoque evolutivo tiene dos problemas: 1. El proceso no es visible. Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema. 2. A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea difícil y costosa. 49 de 255


Para sistemas pequeños y de tamaño medio (hasta 500.000 líneas de código), el enfoque evolutivo de desarrollo es el mejor. Los problemas del desarrollo evolutivo se hacen particularmente agudos para sistemas grandes y complejos con un periodo de vida largo, donde diferentes equipos desarrollan distintas partes del sistema. Es difícil establecer una arquitectura del sistema estable usando este enfoque, el cual hace difícil integrar las contribuciones de los equipos. (Somerville, 2005).

2.3.1.3 Modelo de desarrollo basado en componentes. El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo en espiral. Es de naturaleza evolutiva y demanda un enfoque iterativo para la creación del software. Sin embargo, el modelo de desarrollo basado en componentes construye aplicaciones a partir de fragmentos se software prefabricados. Las actividades de modelado y construcción comienzan con la identificación de candidatos de componentes. Estos pueden diseñarse como módulos de software convencionales o clases orientadas a objetos o paquetes de clases. Sin importar la tecnología usada para crear los componentes. (Pressman, 2012). Este enfoque basado en la reutilización se compone de una gran base de componentes software reutilizables y de algunos marcos de trabajo de integración para éstos. En la Figura Nº 14 se muestra el modelo del modelo de desarrollo basado en componentes. Figura Nº 14 : Modelo de desarrollo basado en componentes.

FUENTE: [Somerville Ian, 2005]

50 de 255


Aunque la etapa de especificación de requerimientos y la de validación son comparables con otros procesos, las etapas intermedias en el proceso orientado a la reutilización son diferentes. Estas etapas son: 1. Análisis de componentes: Dada la especificación de requerimientos, se buscan los componentes para implementar esta especificación. Por lo general, no existe una concordancia exacta y los componentes que se utilizan sólo proporcionan parte de la funcionalidad requerida. 2. Modificación de requerimientos: En esta etapa, los requerimientos se analizan utilizando información acerca de los componentes que se han descubierto. Entonces, estos componentes se modifican para reflejar los componentes disponibles. Si las modificaciones no son posibles, la actividad de análisis de componentes se puede llevar a cabo nuevamente para buscar soluciones alternativas. 3. Diseño del sistema con reutilización: En esta fase se diseña o se reutiliza un marco de trabajo para el sistema. Los diseñadores tienen en cuenta los componentes que se reutilizan y organizan el marco de trabajo para que los satisfaga. Si los componentes reutilizables no están disponibles, se puede tener que diseñar nuevo software. 4. Desarrollo e integración: Para crear el sistema, el software que no se puede adquirir externamente se desarrolla, y los componentes se integran. En este modelo, la integración de sistemas es parte del proceso de desarrollo, más que una actividad separada. La ingeniería del software basada en componentes tiene la ventaja de reducir la cantidad de software a desarrollarse y así reduce los costos y los riesgos. Por lo general, también permite una entrega más rápida del software. Sin embargo, los compromisos en los requerimientos son inevitables, y esto puede dar lugar a un sistema que no cumpla las necesidades. (Somerville, 2005).

2.3.2 Metodologías de desarrollo de software. Las metodología de desarrollo de software son un conjunto de procedimientos, técnicas para el desarrollo de un producto software. Entre las metodologías de desarrollo de software podemos mencionar las siguientes: 51 de 255


Proceso unificado de desarrollo de software (UP)

Programación Extrema (XP)

Scrum.

2.3.2.1 Proceso unificado de desarrollo de software (UP). La tendencia actual en el software lleva a la construcción de sistemas más grandes y más complejos. Esto es al hecho de que los computadores son más pequeños potentes cada año, y los usuarios, esperan más de ellos. Queremos un software que esté mejor adaptado a nuestras necesidades. Pero esto, a su vez, simplemente hace el software más complejo. También lo queremos más rápido, el tiempo de salida al mercado es otro conductor importante. El problema del software se reduce a la dificultad que afrontan los desarrolladores para coordinar las múltiples cadenas de trabajo de un gran proyecto de software. Se necesita un proceso que integre las múltiples facetas del desarrollo. Se necesita un método común, un proceso que: • Proporcione una guía para ordenar las actividades de un equipo • Dirija las tareas de cada desarrollador por separado y del equipo como un todo • Especifique los artefactos que deben desarrollarse • Ofrezca criterios para el control y la medición de los productos y actividades del proyecto. (Jacobson and Booch, 2006). a) Ciclo de vida del proceso unificado. El proceso unificado se repite a lo largo de una serie de ciclos que constituye en la vida de un sistema. Cada ciclo concluye con una versión del producto. Como se muestra en la Figura Nº 15. (Jacobson and Booch, 2006). Figura Nº 15 : Ciclo de vida del proceso unificado.

FUENTE: [Ivar Jacobson, Grady Booch, James Rumbaugh, 2006]

52 de 255


Donde cada ciclo consta de cuatro fases: inicio, elaboración, construcción y transición. Cada fase se subdivide a su vez en iteraciones, mencionado anteriormente, en la Figura Nº 16 se ilustra el ciclo con fases e iteraciones del proceso unificado. Figura Nº 16 : Ciclo con fases e iteraciones del proceso unificado.

FUENTE: [Ivar Jacobson, Grady Booch, James Rumbaugh, 2006]

El proceso unificado toma en cuenta dos aspectos muy importantes para el ciclo de vida, como ser: •

Producto

Fases dentro un ciclo.

1. El producto. Cada ciclo produce una nueva versión del sistema y cada versión, es un producto preparado para su entrega. Consta de un cuerpo de código fuente incluido en componentes que puede compilarse y ejecutarse. Sin embargo el producto no solo debe ajustarse a las necesidades de los usuarios, sino también a la de todos los interesados, es decir, toda la gente que trabajará con el producto. El producto terminado incluye los requisitos, casos de uso, especificaciones no funcionales y casos de prueba. Incluye el modelo de la arquitectura y el modelo visual –artefactos modelados con el lenguaje unificado de modelado.

53 de 255


A medida que el objetivo del sistema se comprende mejor, los propios requisitos pueden cambiar, cuando uno de estos requisitos cambia no denominadas constantes del desarrollo de software, como se muestra en la Figura Nº 17. Figura Nº 17 : Modelo del proceso unificado.

FUENTE: [Ivar Jacobson, Grady Booch, James Rumbaugh, 2006]

 Un modelo de casos de uso, con todos los casos de uso y su relación con los usuarios.  Un modelo de análisis, con dos propósitos: refinar los casos de uso con más detalles y establecer la asignación inicial de funcionalidad del sistema a un conjunto de objetos que proporcionan el comportamiento.  Un modelo de diseño, que define la estructura estática del sistema en la forma de subsistemas, clases e interfaces y los casos de uso reflejados como colaboradores entre los subsistemas, clases e interfaces.  Un modelo de implementación, que incluye componentes, que representan el código fuente y la correspondencia de las clases con los componentes.  Un modelo de despliegue, que define los nodos físico (ordenadores) y la correspondencia de los componentes con esos nodos.  Un modelo de prueba, que describe los casos de prueba que verifican los casos de uso. (Jacobson and Booch, 2006).

54 de 255


2. Fases dentro de un ciclo. Cada ciclo se desarrolla a lo largo del tiempo. Este tiempo, a su vez, se divide en cuatro fases. Dentro de cada fase, los directores o los desarrolladores pueden descomponer adicionalmente el trabajo en iteraciones con sus incrementos resultantes. Al final se obtiene un conjunto de datos a partir del seguimiento del tiempo y esfuerzo consumido en cada fase. Estos datos son útiles en la estimación del tiempo y los recursos humanos para otros proyectos, en la asignación de los recursos durante el tiempo que dura el proyecto y en el control del progreso contrastado con las planificaciones. En la Figura Nº 18 se muestra en la columna izquierda los flujos de trabajo, requisitos, análisis, diseño, implementación y prueba, las curvas son una aproximación de hasta donde se llevan a cabo los flujos de trabajo en cada fase, la fase se divide normalmente en iteraciones o mini-proyectos. Una iteración típica pasa por los cinco flujos de trabajo, para una iteración de fase de elaboración. Figura Nº 18 : Los cinco flujos de trabajo.

FUENTE: [Ivar Jacobson, Grady Booch, James Rumbaugh, 2006]

1.- Durante la fase de inicio: Se desarrolla una descripción del producto final a partir de una buena idea y se presenta el análisis de negocios para el producto. 2.- Durante la fase de elaboración: Se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema. La relación 55 de 255


entre la arquitectura del sistema y del propio sistema es primordial. Una manera simple de expresarlo es decir que la arquitectura es análoga al esqueleto cubierto por la piel pero con muy poco músculo (el software) entre los huesos y la piel, solo lo necesario para permitir que el esqueleto haga movimientos básicos. Al final de la fase de elaboración, el director de proyecto está en disposición de planificar las actividades y estimar los recursos necesarios para terminar el proyecto. 3.- Durante la fase de construcción: Se crea el producto se añaden los músculos (software terminado) al esqueleto (la arquitectura). En esta fase, la línea base de la arquitectura crece hasta convertirse en el sistema completo. La descripción evoluciona hasta convertirse en un producto preparado para ser entregado a la comunidad de usuarios. 4.- La fase de transición: Cubre el periodo durante el cual el producto se convierte en versión beta. En la versión beta un número reducido de usuarios con experiencia prueba el producto e informa de defectos y deficiencias. Los desarrolladores corrigen los problemas e incorporan algunas de las mejoras sugeridas en una versión general dirigida a la totalidad de la comunidad de usuarios. (Jacobson and Booch, 2006).

b) Características de UP. •

Dirigido por casos de uso: Se dice que es dirigido por casos de uso, porque estos representan los requisitos funcionales y definir los contenidos de las iteraciones. Estos casos de uso guían el diseño de un sistema, implementación y prueba.

Centrado en la arquitectura: La arquitectura en un sistema software se describe mediante diferentes vistas del sistema en construcción. El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema.

Iterativo e incremental: Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos al crecimiento del producto. Para una efectividad máxima las iteraciones deben estar controladas, esto quiere decir que; deben seleccionarse y ejecutarse de una forma planificada. (Jacobson and Booch, 2006). 56 de 255


2.3.2.2 Programación extrema (Extreme Programming, XP). XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico. (Canós, 2005). En la programación extrema, todos los requerimientos se expresan como escenarios (llamados historias de usuario), los cuales se implementan directamente como una serie de tareas. Los programadores trabajan en parejas y desarrollan pruebas para cada tarea antes de escribir el código. Todas las pruebas se deben ejecutar satisfactoriamente cuando el código nuevo se integre al sistema. Existe un pequeño espacio de tiempo entre las entregas del sistema. En la Figura Nº 19 se ilustra el proceso de la XP para producir un incremento del sistema que se está desarrollando. (Somerville, 2005). Figura Nº 19 : Ciclo de entrega en la programación extrema.

FUENTE: [Somerville Ian, 2005]

En un proceso de la XP, los clientes están fuertemente implicados en la especificación y establecimiento de prioridades de los requerimientos del sistema. Los requerimientos no se especifican como una lista de funciones requeridas del sistema. Más bien, los 57 de 255


clientes del sistema son parte del equipo de desarrollo y discuten escenarios con otros miembros del equipo. Desarrollan conjuntamente una “tarjeta de historias” (story cara) que recoge las necesidades del cliente. El equipo de desarrollo intentará entonces implementar ese escenario en una entrega futura del software. (Somerville, 2005). a) Las historias de usuario. Son la técnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinámico y flexible. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas. (Canós, 2005). b) Roles XP. Los roles de acuerdo con la propuesta original de Beck son:  Programador. El programador escribe las pruebas unitarias y produce el código del sistema.  Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio.  Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.  Encargado de seguimiento (Tracker). Proporciona realimentación al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteración.  Entrenador (Coach). Es responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente.  Consultor. Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas.

58 de 255


 Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación. (Canós, 2005).

c) Características XP. •

Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión.

Programación en parejas.

Frecuente integración del equipo de programación con el cliente o usuario.

Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento.

Propiedad del código compartida, quiere decir en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto.

Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario.

2.3.2.3 SCRUM. Scrum es un método de desarrollo ágil de software concebido por Jeff Sutherland y su equipo de desarrollo a principios de la década de 1990. Los principios de Scrum son congruentes con el manifiesto ágil y se utiliza para guiar actividades de desarrollo de un proceso de análisis que incorporan las siguientes actividades estructurales: requerimientos, análisis, diseño, evolución y entrega. Dentro de cada actividad estructural, las tareas del trabajo ocurren con un patrón del proceso llamado Sprint. El trabajo es realizado dentro de un sprint (el número de estos que requiere cada actividad estructural variara en función de la complejidad y tamaño del producto) se adapta al problema en cuestión y se define, y con frecuencia se modifica, en tiempo real por parte del equipo Scrum. En la Figura Nº 20 se muestra el flujo general del proceso Scrum. (Pressman, 2012).

59 de 255


Figura Nº 20 : Flujo general del proceso Scrum.

Cada 24 Horas

Retraso del sprint: Característica(s) Asignadas para el

Aspectos con retrasos ampliados por el equipo

30 días

Scrum: reunión diaria de 15 minutos. Los miembros del equipo responden a preguntas básicas: 1) ¿Qué hiciste desde la última reunión Scrum? 2) ¿Tienes algún obstáculo? 3) ¿Qué harás antes de la próxima reunión?

Al final del sprint se demuestra la nueva Retraso del producto funcionalidad Características del producto que desea el cliente con prioridad

FUENTE: [Roger S. Pressman, 2002]

Scrum acentúa el uso de un conjunto de patrones de proceso del software que han demostrado ser eficaces para proyectos con plazos de entrega muy apretados, requerimientos cambiantes y negocios críticos. Cada uno de estos patrones de proceso define un grupo de acciones de desarrollo:  Retraso: Lista de prioridades de los requerimientos o características del proyecto que dan al cliente un valor de negocio. Es posible agregar en cualquier momento otros aspectos al retraso (esta es la forma en la que se introducen los cambios). El gerente del proyecto evalúa el retraso y actualiza las prioridades según se requiera.  Sprint: Consiste en unidades de trabajo que se necesitan para alcanzar un requerimiento definido en el retraso que debe ajustarse en una caja de tiempo predefinida (lo común son 30 días). Durante el sprint no se introducen cambios (por ejemplo: aspectos de trabajo retrasado). Así el sprint permite a los miembros del equipo trabajar en un ambiente de corto plazo estable.

60 de 255


 Reuniones Scrum: Son reuniones breves (de 15 minutos, por lo general) que el equipo scrum efectúa a diario. Hay tres preguntas claves que se pide que respondan todos los miembros del equipo:  ¿Qué hiciste desde la última reunión del equipo?  ¿Qué obstáculos estas encontrando?  ¿Qué planeas hacer mientras llega la siguiente reunión del equipo?  Maestro Scrum: Dirige la junta y evalúa las respuestas de cada persona. La junta Scrum ayuda al equipo a descubrir los problemas potenciales tan pronto como sea posible. Así mismo estas juntas diarias llevan a la “Socialización del conocimiento”.  Demostraciones preliminares: Entregar el incremento de software al cliente de modo que la funcionalidad que se haya implementado pueda demostrarse al cliente y esta pueda evaluarla. Es importante notar que las demostraciones preliminares no contienen toda la funcionalidad planeada, sino que estas se entregaran dentro de la caja de tiempo establecida. (Pressman, 2012).

a) Roles SCRUM. 1.-Roles principales •

Product Owner: El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

Equipo de desarrollo: El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).

2.-Roles auxiliares Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint. 61 de 255


Stakeholders (Clientes, Proveedores, Vendedores, etc): Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirán el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.

Administradores (Managers): Es la gente que establece el ambiente para el desarrollo del producto.

b) Características de SCRUM •

Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable.

Creación de equipos auto organizado impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.

Reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn).

Fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

2.3.3 Lenguaje de modelamiento de software. En lenguaje de modelamiento de software es una técnica para tratar con la complejidad de los sistemas y mediante un lenguaje de modelado se puede visualizar el sistema a construir. Para ello se tiene el lenguaje unificado de modelado UML.

2.3.3.1 UML. El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual que se usa para especificar, visualiza, construir y documentar artefactos de un sistema de software. Captura decisiones y conocimiento sobre los sistemas que se deben construir. Se usa para entender, diseñar, hojear, configurar, mantener y controlar la información sobre tales sistemas. Está pensando para usarse con todos los métodos de desarrollo, etapas del ciclo de vida, dominio de aplicaciones y medios. 62 de 255


UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. Un sistema se modela como una colección de objetos discretos que interactúan para realizar un trabajo que finalmente beneficia a un usuario externo. La estructura estática define los tipos de objetos importantes para un sistema y para su implementación, así como las relaciones entre los objetos. UML no es un lenguaje de programación. Las herramientas pueden ofrecer generadores de código de UML para una gran variedad de lenguajes de programación, así como construir modelos por ingeniería inversa a partir de programas existentes. (Booch and Rumbaugh, 2006). Bloques de construcción de UML. UML tiene tres clases de bloques de construcción: 1.- Elementos en UML. a. Elementos estructurales: Los elementos estructurales son los nombres de los modelos UML. En su mayoría son las partes estáticas de un modelo, y representan conceptos o cosas materiales. b. Elementos de comportamiento: Son las partes dinámicas de los modelos, son los verbos y representan comportamiento en el tiempo y el espacio. c. Elementos de agrupación: Son las partes organizativas de los modelos, son cajas en las que puede descomponerse un modelo. d. Elementos de anotación: Son las partes explicativas de los modelos., pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento de un modelo. 2.- Relaciones en UML. a. Dependencia: Es una relación semántica entre dos elementos, en la cual un cambio a un elemento independiente puede afectar a la semántica del otro elemento dependiente. b. Asociación: Es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. c. Generalización: Es una relación de especialización / generalización en la cual los objetos del elemento especializado (hijo) pueden sustituir a los objetos del elemento general (padre).

63 de 255


d. Realización: Es una relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá.

3.- Diagramas. Un diagrama es la representación gráfica de un conjunto de elementos, visualizado la mayoría de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Son 9 los diagramas que incluye UML (Rumbaugh and Jacobson, 2006). Entre los cuales se dividen en diagramas estructurales y diagramas de comportamiento: A. Diagramas estructurales:  Diagrama de clases.  Diagrama de componentes.  Diagrama de objetos.  Diagrama de despliegue. B. Diagramas de comportamiento:  Diagrama de actividades.  Diagrama de interacción.  Diagrama de secuencia.  Diagrama de colaboración.  Diagrama de casos de uso.  Diagrama de estados. A. Diagramas estructurales. Los diagramas estructurales de UML tienen una vista estática, porque no describe el comportamiento del sistema dependiente del tiempo, los diagramas estructurales son los siguientes: (Rumbaugh and Jacobson, 2006).  Diagrama de clases: Muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones, cubren la vista de diseño estático de un sistema, este 64 de 255


diagrama no solo es importante para visualizar, especificar y documentar modelos estructurales, sino también ejecutables, aplicando ingeniería directa o inversa. Los diagramas de clase contienen normalmente los siguientes elementos: • Clases. • Interfaces. • Relación de dependencia, generalización y asociación. Al igual que lo otros diagramas, los diagramas de clases pueden contener notas y restricciones. Los diagramas de clases también pueden contener paquetes o subsistemas, los cuales se usan para agrupar los elementos de un modelo en partes más grandes. Un modelo se representa como una clase especial de paquete, Un subsistema es orto paquete especial. Representa una porción de un sistema, con una interfaz perfectamente determinada, que puede ser implementado como un componente distinto. Generalmente, la información de gestión del modelo se representa en diagramas de clases. (Rumbaugh and Jacobson, 2006).  Diagrama de componentes: Muestra la organización y las dependencias entre un conjunto de componentes, cubren la vista de implementación estática, se relacionan con diagramas de clase en que un componente se corresponde con una o más clases, interfaces o colaboraciones. Los diagramas de componentes muestra los tipos de componentes del sistema; una configuración particular de la aplicación puede tener más de una copia de un componente. Un círculo pequeño con un nombre es una interfaz, un conjunto coherente de servicio, una línea sólida que va desde un componente a una interfaz, indica que el componente proporciona los servicios de la interfaz. Una flecha de guiones de un componente a una interfaz, indica que el componente requiere los servicios proporcionados por interfaz. (Rumbaugh and Jacobson, 2006).

65 de 255


 Diagrama de objetos: Muestra un conjunto de objetos y sus relaciones representan instantáneas de instancias de los elementos encontrados en los diagramas de clase. Cubren la vista de diseño y proceso estático de un sistema. Un diagrama de objetos es tipo especial de diagrama y comparte las propiedades comunes al resto de los diagramas. Lo que diferencia a un diagrama de objetos de los otros tipos de diagramas es su contenido particular los cuales son: •

Objetos.

Enlaces.

A veces se colocaran clases en los diagramas de objetos, especialmente cuando se quiera mostrar la clase que hay detrás de cada instancia. (Rumbaugh and Jacobson, 2006).  Diagrama de despliegue: Muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos, su relación con los diagramas de componentes en que un nodo incluye, uno o más componentes. Los diagramas de despliegue se utilizan para visualizar los aspectos estáticos de estos nodos físicos y sus relaciones, normalmente los diagramas de despliegue contienen: •

Nodos.

Relaciones de dependencia y asociación.

Los diagramas de despliegue pueden contener artefactos, cada uno de los cuales debe residir en algún nodo, así también pueden contener paquetes o subsistemas, los cuales se utilizan para agrupar elementos del modelo en bloques grandes. (Rumbaugh and Jacobson, 2006). B. Diagrama de comportamiento. Los diagramas de comportamiento de UML se emplean para visualizar, especificar y documentar los aspectos dinámicos de un sistema. (Rumbaugh and Jacobson, 2006).  Diagrama de actividades: Muestra el flujo de actividades dentro de un sistema. Cubren la vista dinámica, son importantes al modelar el funcionamiento de un sistema y resaltan el flujo de control de objetos.

66 de 255


Un diagrama de actividades es un tipo especial de diagrama y comparte las propiedades comunes al resto de los diagramas. Lo que lo distingue a un diagrama de actividades de los otros tipos de diagramas es su contenido: •

Acciones.

Nodos de actividad.

Flujos.

Objetos valor. (Rumbaugh and Jacobson, 2006).

 Diagramas de interacción: Muestran una interacción concreta, un conjunto de objetos y sus relaciones, entre los diagramas de interacción se encuentran el diagrama de secuencia y el diagrama de colaboración.  Diagrama de secuencia: Es un diagrama de interacciones que resalta la ordenación temporal de los mensajes. Un diagrama de secuencia se forma colocando en primer lugar los objetos o roles que participan en la interacción en la parte superior del diagrama, a lo largo del eje horizontal, normalmente se coloca a la izquierda el objeto o rol que inicia la interacción, y los objetos o roles subordinados a la derecha.  Diagrama de colaboración: Un diagrama de colaboración es un diagrama de clases que contiene roles de clasificador y roles de asociación en lugar de solo clasificarlos y asociarlos,  Diagrama de casos de uso: Muestra un conjunto de casos de uso y actores y sus relaciones Cubren la vista de casos de uso estática de un sistema. Estos diagramas son especialmente importantes en el modelado y organización del comportamiento de un sistema. Un diagrama de casos de uso es un tipo especial de diagrama y comparte las propiedades comunes al resto de los diagramas. Lo que lo distingue a un diagrama de casos de uso es su contenido en partículas: •

Sujetos.

Casos de uso.

Actores.

67 de 255


Relación de dependencia, generalización y asociación. (Rumbaugh and Jacobson, 2006).

 Diagrama de estados: Muestra una máquina de estados, que consta de estados transiciones, eventos y actividades. Cubren la vista dinámica de un sistema y el comportamiento de una interfaz, una clase o una colaboración y resaltan el comportamiento dirigido por eventos de un objeto. Un diagrama de estados es un tipo especial de diagrama y comparte las propiedades comunes al resto de los diagramas (es decir, un nombre y un contenido grafico que es una proyección de un modelo). Lo que distingue a un diagrama de estados de los otros tipos de diagramas es su contenido en particular: •

Estados simples y compuestos.

Transiciones, incluyendo eventos y acciones. (Rumbaugh and Jacobson, 2006).

2.3.4 Pruebas de software. El objetivo de la etapa de la prueba es descubrir defectos probando componentes de programa individuales. Estos componentes pueden ser funciones, objetos o componentes reutilizables. Durante las pruebas del sistema, estos componentes se integran para formar subsistemas o el sistema completo. La prueba del sistema debería centrarse en establecer que el sistema satisface sus requerimientos funcionales y no funcionales y no se comporta de forma inesperada. El proceso de pruebas como tal tiene dos objetivos: •

Demostrar al desarrollador y al cliente que el software satisface sus requerimientos.

Descubrir defectos en el software en que el comportamiento de éste es incorrecto, no deseable o no cumple su especificación.

Un modelo general del proceso de pruebas se muestra en la Figura Nº 21. Los casos de prueba son especificaciones de las entradas para la prueba y la salida esperada del sistema más una afirmación de lo que se está probando. Los datos de prueba son las entradas que han sido ideadas para probar el sistema.

68 de 255


Figura Nº 21 : Modelo general del proceso de pruebas de software.

FUENTE: [Ian Sommerville, 2005]

Las pruebas del sistema implican integrar dos o más componentes que implementan funciones del sistema o características y a continuación se prueba este sistema integrado. En un proceso de desarrollo iterativo, las pruebas del sistema se ocupan de probar un incremento que va a ser entregado al cliente, en un proceso en cascada, las pruebas del sistema se ocupan de probar el sistema completo. (Somerville, 2005). Dentro de las pruebas de software podemos mencionar las siguientes:  Pruebas unitarias.  Pruebas funcionales o de entrega.  Pruebas de carga o rendimiento.

2.3.4.1 Pruebas unitarias. La prueba de unidad enfoca los esfuerzos de verificación en la unidad más pequeña del diseño de software: el componente o módulo de software. Al usar la descripción del diseño de componente como guía, las rutas de control importantes se prueban para descubrir errores dentro de la frontera del módulo. La relativa complejidad de las pruebas y los errores que descubren están limitados por el ámbito restringido que se establece para la prueba de unidad. Las pruebas de unidad se enfocan en la lógica de procesamiento interno y de las estructuras de datos dentro de las fronteras de un componente. Este tipo de pruebas puede realizarse en paralelo para múltiples componentes.

69 de 255


1. Consideraciones de las pruebas de unidad. Las pruebas de unidad se ilustran de manera esquemática en la Figura Nº 22. La interfaz del módulo se prueba para garantizar que la información fluya de manera adecuada hacia y desde la unidad de software que se está probando. Las estructuras de datos locales se examinan para asegurar que los datos almacenados temporalmente mantienen su integridad durante todos los pasos en la ejecución de un algoritmo. Todas las rutas independientes a través de la estructura de control se ejercitan para asegurar que todos los estatutos en un módulo se ejecuten al menos una vez. Las condiciones de frontera se prueban para asegurar que el módulo opera adecuadamente en las fronteras establecidas para limitar o restringir el procesamiento. Y finalmente, se ponen a prueba todas las rutas para el manejo de errores. Figura Nº 22 : Pruebas de unidad.

FUENTE: [Roger S. Pressman, 2002]

El flujo de datos a través de la interfaz de un componente se prueba antes de iniciar cualquiera otra prueba. Si los datos no entran y salen de manera adecuada, todas las demás pruebas son irrelevantes. Además, deben ejercitarse las estructuras de datos locales y averiguarse (si es posible) el impacto local sobre los datos globales durante las pruebas de unidad. 70 de 255


Es muy probable que los casos de prueba que ejercitan la estructura de datos, el flujo de control y los valores de datos justo abajo y arriba de máximos y mínimos descubran errores. Entre los potenciales errores que deben ponerse a prueba cuando se evalúa el manejo de errores están: 1) La descripción de error ininteligible. 2) El error indicado no corresponde con el error que se encuentra. 3) La condición del error causa la intervención del sistema antes de manejar el error. 4) El procesamiento excepción-condición es incorrecto. 5) La descripción del error no proporciona suficiente información para auxiliar en la localización de la causa del error. 2. Procedimientos de prueba de unidad. Las pruebas de unidad por lo general se consideran como adjuntas al paso de codificación. El diseño de las pruebas de unidad puede ocurrir antes de comenzar la codificación o después de generar el código fuente. La revisión de la información del diseño proporciona una guía para establecer casos de prueba que es probable que descubran errores en cada una de las categorías analizadas anteriormente. Cada caso de prueba debe acoplarse con un conjunto de resultados esperados. Puesto que un componente no es un programa independiente, con frecuencia debe desarrollarse software controlador y/o de resguardo para cada prueba de unidad. En la Figura Nº 23, se ilustran los entornos de prueba de unidad. En la mayoría de las aplicaciones, un controlador no es más que un “programa principal” que acepta datos de caso de prueba, pasa tales datos al componente (que va a ponerse a prueba) e imprime resultados relevantes.

71 de 255


Figura Nº 23 : Entorno de prueba de unidad.

FUENTE: [Roger S. Pressman, 2002]

Las pruebas de unidad se simplifican cuando se diseña un componente con alta cohesión. Cuando un componente aborda una sola función, el número de casos de prueba se reduce y los errores pueden predecirse y descubrirse con mayor facilidad de datos locales se examinan para asegurar que los datos almacenados temporal

2.3.4.2 Pruebas funcionales o de entrega. Las pruebas de entregas son el proceso de probar una entrega del sistema que será distribuida a los clientes. El principal objetivo de este proceso es incrementar la confianza del suministrador en que el sistema satisface sus requerimientos. Si es así, éste puede entregarse como un producto o ser entregado al cliente. Para demostrar que el sistema satisface sus requerimientos, tiene que mostrarse que éste entrega la funcionalidad especificada, rendimiento y confiabilidad, y que no falla durante su uso normal. Las pruebas de entregas son normalmente un proceso de pruebas de caja negra en las que las pruebas se derivan a partir de la especificación del sistema. El sistema se trata como una caja negra cuyo comportamiento sólo puede ser determinado estudiando sus entradas y sus salidas relacionadas. Otro nombre para esto es pruebas funcionales, debido a que al probador sólo le interesa la funcionalidad y no la 72 de 255


implementación del software. En la Figura Nº 24, se ilustra el modelo de un sistema que se admite en las pruebas de caja negra. El probador presenta las entradas al componente o al sistema y examina las correspondientes salidas. Si las salidas no son las esperadas (es decir, si las salidas pertenecen al conjunto Se, entonces la prueba ha detectado un problema con el software. (Somerville, 2005). Figura Nº 24 : Pruebas de entrega o caja negra.

FUENTE: [Somerville Ian, 2005]

La forma de incrementar la probabilidad de que las pruebas de defectos tengan éxito son: •

Elegir entradas que fuerzan a que el sistema genere todos los mensajes de error.

Diseñar entradas que hacen que los búferes de entrada se desborden.

Repetir la misma entrada o series de entrada varias veces.

Forzar a que se generen las salidas inválidas.

Forzar los resultados de los cálculos para que sean demasiado grande o demasiado pequeños.

73 de 255


Para validar que el sistema satisface los requerimientos, la mejor aproximación a utilizar es la prueba basada en escenarios, en la que se idean varios escenarios y se desarrollan casos de prueba a partir de estos escenarios.

2.3.4.3 Pruebas de carga o rendimiento Una vez que un sistema se ha integrado completamente, es posible probar las propiedades emergentes del sistema, tales como rendimiento y fiabilidad. Las pruebas de rendimiento tienen que diseñarse para asegurar que el sistema pueda procesar su carga esperada. Esto normalmente implica planificar una serie de pruebas en las que la carga se va incrementando regularmente hasta que el rendimiento del sistema se hace inaceptable. Las pruebas de rendimiento se ocupan tanto de demostrar que el sistema satisface sus requerimientos como de descubrir problemas y defectos en el sistema. Para probar si los requerimientos de rendimiento son alcanzados. Las pruebas de rendimiento implican estresar el sistema (de ahí el nombre de pruebas de estrés) realizando demandas que están fuera de los límites del diseño del software. Las pruebas de estrés van realizando pruebas acercándose a la máxima carga del diseño del sistema hasta que el sistema falla. Este tipo de pruebas tienen dos funciones: 1. Prueba el comportamiento de fallo de ejecución del sistema. Pueden aparecer circunstancias a través de una combinación no esperada de eventos en donde la carga sobre el sistema supere la máxima carga anticipada. En estas circunstancias, es importante que un fallo de ejecución del sistema no provoque la corrupción de los datos o pérdidas inesperadas de servicios de los usuarios. Las pruebas de estrés verifican que las sobrecargas en el sistema provocan “fallos ligeros” en lugar de colapsarlo bajo su carga. 2. Sobrecargan el sistema y pueden provocar que se manifiesten defectos que normalmente no serían descubiertos. Aunque se puede argumentar que estos defectos es improbable que causen fallos de funcionamiento en un uso normal, puede haber combinaciones inusuales de circunstancias normales que las pruebas de estrés pueden reproducir. 74 de 255


Las pruebas de estrés son particularmente relevantes para los sistemas distribuidos basados en una red de procesadores. Estos sistemas exhiben a menudo una degradación grave cuando son sobrecargados. La red se satura con datos de coordinación que los diferentes procesos deben intercambiar, de forma que los procesos son cada vez más lentos a medida que esperan los datos requeridos de otros procesos (Somerville, 2005).

2.4 HERRAMIENTAS DE DESARROLLO DE SOFTWARE. En este punto se darán a conocer las herramientas que se utilizarán para la realización del software del presente Trabajo de Grado, Para esto se considera herramientas como ser: los lenguajes de programación y gestores de base de datos.

2.4.1 Lenguajes de programación. Un lenguaje de programación es aquel elemento dentro de la informática que nos permite crear programas mediante un conjunto de instrucciones, operadores y reglas de sintaxis; que pone a disposición del programador para que este pueda comunicarse con los dispositivos hardware y software existentes. Actualmente se utilizan los lenguajes de cuarta generación, los cuáles se relacionan menos con procedimientos y que son aún más parecidos al lenguaje. Algunas características incluyen capacidades de consulta y base de datos, de creación de códigos y capacidades gráficas. Entre los lenguajes de programación podemos mencionar los siguientes: 3. C Sharp. 4. PHP. 5. Java.

2.4.1.1 C Sharp. C# es un lenguaje de programación que se ha diseñado para compilar diversas aplicaciones que se ejecutan en .NET Framework. C# es simple, eficaz, con seguridad de tipos y orientado a objetos. Las numerosas innovaciones de C# permiten desarrollar aplicaciones rápidamente y mantener la expresividad y elegancia de los lenguajes de estilo de C.

75 de 255


Visual C# es una implementación del lenguaje de C# de Microsoft. Visual Studio ofrece compatibilidad con Visual C# con un completo editor de código, un compilador, plantillas de proyecto, diseñadores, asistentes para código, un depurador eficaz y de fácil uso y otras herramientas. La biblioteca de clases de .NET Framework ofrece acceso a numerosos servicios de sistema operativo y a otras clases útiles y adecuadamente diseñadas que aceleran el ciclo de desarrollo de manera significativa. (Ferguson and Patterson and Beres, 2003). a) Asp.net: Es un framework, para la creación de aplicaciones web, donde se puede programar en cualquiera de los lenguajes de .NET. Apareció en el año 2002 y es la tecnología sucesora de ASP (Active Server Pages). Asp.net se integra totalmente con .NET y sus páginas se pueden programar en cualquiera de los lenguajes de .NET (Visual básic, C Sharp) haciendo uso de la programación orientada a eventos. Las páginas de Asp.net se denominan web formas (formularios web) y son archivos con extensión .aspx. Estos archivos están formados básicamente por marcas XHTML estático y también por marcas ASPX que le dan el comportamiento dinámico. (Ferguson and Patterson and Beres, 2003). b) Características de C Sharp.  Sencillez de uso: C# elimina muchos elementos añadidos por otros lenguajes y que facilitan su uso y compresión, como por ejemplo ficheros de cabecera, o ficheros fuentes IDL1 .12. Es por ello que se dice que C# es autocontenido. Además, no se incorporan al lenguaje elementos poco útiles.  Modernidad: Al ser C# un lenguaje de última generación, incorpora elementos que se ha demostrado a lo largo del tiempo que son muy útiles para el programador, como tipos decimales o booleanos, un tipo básico string, así como una instrucción que permita recorrer colecciones con facilidad(instrucción foreach).  Orientado a objetos: C# como lenguaje de última generación, y de propósito general, es orientado a objetos. C# no permite la inclusión de funciones ni

76 de 255


variables globales que no estén incluidos en una definición de tipos, por lo que la orientación a objetos es más pura y clara que en otros lenguajes como C++.  Orientado a componentes: La propia sintaxis de C# incluye elementos propios del diseño de componentes que otros lenguajes tienen que simular. La sintaxis de C# incluye por ejemplo formas de definir propiedades, eventos o atributos.  Recolección de basura: Todo lenguaje incluido en la plataforma .NET tiene a su disposición el recolector de basura del CLR. Esto implica que no es necesario incluir instrucciones de destrucción de objetos en el lenguaje.  Seguridad de tipos: C# incluye mecanismos de control de acceso a tipos de datos, lo que garantiza que no se produzcan errores difíciles de detectar como un acceso a memoria de ningún objeto. (Ferguson and Patterson and Beres, 2003).

2.4.1.2 PHP. Es un lenguaje de programación para crear web dinámicas. Como es rico en características que facilitan el diseño y la programación web, PHP se usa en más de 13 millones de dominios, además que este es un lenguaje de programación diseñado específicamente para ser usado en la web. PHP significa PHP: HyperText Preprocessor/ Preprocesador de Hipertexto. Cuando se desarrolló a un lenguaje completo, el nombre se le cambio para que este estuviera más a tono con su funcionalidad expandida. PHP es un lenguaje de alto nivel que se ejecuta en el servidor. La sintaxis del lenguaje PHP es parecida a la sintaxis de C. La habilidad de PHP para interactuar con bases de datos es particularmente fuerte, ya que esta puede trabajar con prácticamente todas las bases de datos de las cuales existe actualmente, con solo escribir el nombre de la base de datos, PHP se encarga de los detalles y el reconocimiento con el entorno de base de datos que se desea trabajar, se conecta a la base de datos, para las diferentes instrucciones y le trae de vuelta una respuesta de la base de datos. (Pavon, 2007).

77 de 255


a) Como funciona PHP. PHP es un lenguaje de programación empotrado cuando se usa en páginas web. Esto quiere decir que el código PHP esta encajado en código HTML. Donde se puede utilizar etiquetas de HTML para encapsular el lenguaje PHP que empotra en sus archivo HTML, del mismo modo en que se usa otras etiquetas HTML, se puede crear y editar páginas web que contengan PHP del mismo en que se crean y editan las páginas HTML comunes. El software PHP funciona en conjunto con el servidor web. El servidor web es el software que entrega las páginas web al mundo, el cual responde enviando el archivo solicitado. Cuando se está iniciando PHP, el servidor web se configura para esperar ciertas extensión de archivo que contienen instrucciones en lenguaje PHP, esta extensión suele ser: php o .phtml, pero se puede usar cualquier extensión. Cuando el servidor web recibe una solicitud de un archivo con la extensión designada, envía las instrucciones HTML, sin modificación, pro las instrucciones PHP las procesa el software PHP antes de enviarlas al solicitante. Cuando se procesan las instrucciones PHP, en el servidor web solo envía el resultado al explorador web. Las instrucciones en el lenguaje PHP no se incluyen en el resultado que se envía al explorador, así que el código PHP es seguro y transparente para el usuario PHP y el servidor deben trabajar en equipo, PHP no está integrado a todos los servidores web, pero trabaja con muchos de los servidores web más populares. PHP fue desarrollado como un proyecto de la fundación de software apache; en consecuencia, trabaja mejor con apache. Este también funciona con Microsoft IIS/PWS. (Pavon, 2007). b) Características de PHP.  Orientado al desarrollo de aplicaciones web dinámicas con acceso a información almacenada en una base de datos.  Lenguaje fácil de aprender, ya que en su desarrollo se simplificaron distintas especificaciones. 78 de 255


 El código fuente escrito en PHP es invisible al navegador web y al cliente, ya que es el servidor el que se encarga de ejecutar el código y enviar su resultado HTML al navegador.  Capacidad de conexión con la mayoría de los motores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL y PostgreSQL.  Capacidad de expandir su potencial utilizando módulos (llamados ext's o extensiones). (Pavon, 2007).

2.4.1.3 Java Java es un lenguaje de desarrollo de propósito general, y como tal es válido para realizar todo tipo de aplicaciones profesionales. Incluye una combinación de características que lo hacen único y está siendo adoptado por multitud de fabricantes como herramienta básica para el desarrollo de aplicaciones comerciales de gran repercusión. Una de las características más importantes es que los programas “ejecutables”, creados por el compilador de Java, son independientes de la arquitectura. Se ejecutan indistintamente en una gran variedad de equipos con diferentes microprocesadores y sistemas operativos. Permite escribir Applets (pequeños programas que se insertan en una página HTML) y se ejecutan en el ordenador local. Se pueden escribir aplicaciones para intra redes, aplicaciones cliente/servidor, aplicaciones distribuidas en redes locales y en Internet., así también es fácil de aprender y está bien estructurado. Podemos mencionar que dentro las aplicaciones de java se pueden controlar la seguridad frente al acceso a recursos del sistema y es capaz de gestionar permisos y criptografía. (Elmasri and Navathe, 2004). Características de Java.  Es básicamente orientado a objetos.  Funciona perfectamente en red.  Aprovecha características de la mayoría de los lenguajes modernos evitando sus inconvenientes. En particular los del C++.

79 de 255


 Tiene una gran funcionalidad gracias a sus librerías (clases).  No tiene punteros manejables por el programador, aunque los maneja interna y transparentemente.  El manejo de la memoria no es un problema, la gestiona el propio lenguaje y no el programador.  Genera aplicaciones con pocos errores posibles.  Incorpora Multi-Threading (para permitir la ejecución de tareas concurrentes dentro de un mismo programa). (Elmasri and Navathe, 2004). 2.4.2 Base de datos. La base de datos y su tecnología están teniendo un impacto decisivo sobre el creciente uso de los computadores. Podemos mencionar que las bases de datos desempañan un papel crucial casi en todas las áreas de aplicación de los computadores, como los negocios, la ingeniería, la medicina, el derecho, la educación y la biblioteconomía. Una base de datos es un conjunto de datos relacionados entre sí. Por datos entendemos hechos conocidos que pueden registrarse y que tienen un significado implícito. Una base de datos tienen las siguientes propiedades implícitas: •

Una base de datos representa algún aspecto del mundo real, en ocasiones llamado mini mundo o universo de discurso. Las modificaciones del mini mundo se reflejan en la base datos.

Una base de datos es un conjunto de datos lógicamente coherente, con cierto significado inherente. Una colección aleatoria de datos no puede considerarse propiamente una base de datos.

Toda base de datos se diseña, construye y prueba con datos para un pronóstico especifico. Está dirigida a un grupo de usuarios y tiene ciertas aplicaciones preconcebidas que interesan a dichos usuarios.

En otras palabras, una base de datos tiene una fuente de la cual se derivan los datos, cierto grado de interacción con los acontecimientos del mundo real y un público que esta activamente interesado en el contenido de la base de datos. (Elmasri and Navathe, 2004).

80 de 255


2.4.2.1 Sistema gestor de base de datos. Un sistema gestor de bases de datos (SGBD) consiste en una colección de datos interrelacionados y un conjunto de programas para acceder a dichos datos. La colección de datos, normalmente denominada base de datos, contiene información relevante para una empresa. El objetivo principal de un SGBD es proporcionar una forma de almacenar y recuperar la información de una base de datos de manera que sea tanto práctica como eficiente. Los sistemas de bases de datos se diseñan para gestionar grandes cantidades de información. La gestión de los datos implica tanto la definición de estructuras para almacenar la información como la provisión de mecanismos para la manipulación de la información. Además, los sistemas de bases de datos deben proporcionar la fiabilidad de la información almacenada, a pesar de las caídas del sistema o los intentos de acceso sin autorización. Si los datos van a ser compartidos entre diversos usuarios, el sistema debe evitar posibles resultados anómalos. Dado que la información es tan importante en la mayoría de las organizaciones, los científicos informáticos han desarrollado un amplio conjunto de conceptos y técnicas para la gestión de los datos. (Silberschatz, 2002).

2.4.2.2 Manejadores de bases de datos. Los sistemas manejadores de base de datos (SGBD), en inglés Data Base Management System (DBMS), son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. El propósito general de los sistemas manejadores de base de datos es el de manejar de manera clara, sencilla y ordenada un conjunto de datos que posteriormente se convertirán en información relevante para una organización. (Elmasri and Navathe, 2004). Entre los manejadores de base de datos podemos mencionar:  Microsoft SQL Server.  PostgreSQL.  MySQL.

81 de 255


a) Microsoft SQL Server. SQL Server es un sistema para la gestión de bases de datos producido por Microsoft basado en el modelo relacional. Es un elemento fundamental de la Plataforma de Datos de Microsoft, capaz de gestionar cualquier tipo de datos, en cualquier sitio y en cualquier momento. Permite almacenar datos de documentos estructurados, semi estructurados o no estructurados como son las imágenes, música y archivos directamente dentro de la base de datos. SQL Server 2 le ayuda a obtener más rendimiento de los datos, poniendo a su disposición una amplia gama de servicios integrados como son consultas, búsquedas, sincronizaciones, informes y análisis. Sus datos pueden almacenarse y recuperarse desde sus servidores más potentes del Data Center hasta los desktops y dispositivos móviles, permitiéndole tener un mayor control sobre la información sin importar dónde se almacena físicamente. (Pando, 2009). Características de Microsoft SQL Server. • Soporte de transacciones. • Escalabilidad, estabilidad y seguridad. • Incluye un potente entorno gráfico de administración, que permite el uso de comandos DDL y DML gráficamente. • Permite trabajar en modo cliente-servidor, donde la información y datos se alojan en el servidor y los terminales o clientes de la red sólo acceden a la información. • Además permite administrar información de otros servidores de datos. (Pando, 2009).

b) PostgreSQL. Es un sistema de gestión de bases de datos, distribuido bajo licencia BSD (licencia de software libre) y con su código fuente disponible libremente. Es el sistema de gestión de bases de datos de código abierto más potente del mercado y en sus últimas versiones no tiene nada que envidiarle a otras bases de datos comerciales. PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de multihilos para garantizar la estabilidad del sistema. Un fallo en uno de los procesos no afectará el resto y el sistema continuará funcionando. (Rob, 2004). 82 de 255


Características. Las características más importantes y soportadas por PostgreSQL son las siguientes:  Integridad referencial.  Tablespaces.  Replicación asincrona / streaming replication - Hot Standby.  Copias de seguridad en caliente (Online/hot backups).  Múltiples métodos de autentificación.  Acceso encriptado vía SSL.  Actualización in-situ integrada.  Licencia BSD. (Rob, 2004). c) MySQL. Es un sistema de administración de bases de datos relacional, la cual archiva datos en tablas separadas en vez de colocar todos los datos en un gran archivo. Esto permite velocidad y flexibilidad. Las tablas están conectadas por relaciones definidas que hacen posible combinar datos de diferentes tablas sobre pedido. MySQL es un software de fuente abierta, es decir que es posible para cualquier persona usarlo y modificarlo. Cualquier persona puede bajar el código fuente de MySQL y usarlo sin pagar. Cualquier interesado puede estudiar el código fuente y ajustarlo a sus necesidades. MySQL usa el GPL (GNU General Public License) para definir qué puede hacer y que no puede hacer con el software en diferentes situaciones. Si usted no se ajusta al GPL o requiere introducir código MySQL en aplicaciones comerciales, usted puede comprar una versión comercial licenciada. (Pavon, 2007). Características de MySQL. • Soporte a multiplataforma. • Procedimientos almacenados. • Disparadores (triggers). • Motores de almacenamiento independientes (MyISAM para lecturas rápidas, InnoDB para transacciones e integridad referencial). • Réplica con un maestro por esclavo, varios esclavos por maestro, sin soporte automático para múltiples maestros por esclavo. (Pavon, 2007). 83 de 255


2.4.2.3 Réplicas en la base de datos. Se refiere al almacenamiento de copias de datos en sitios múltiples servidos por una red de computadoras. Pueden guardarse copias de fragmentos en varios sitios para satisfacer requerimientos de información específicos. Como la existencia de copias de fragmentos puede mejorar la disponibilidad de los datos y el tiempo de respuesta, estas copias reducen los costos de comunicación y de consulta totales. Si existe una base de datos A y está dividida en dos fragmentos, A1 y A2. Dentro de una base de datos distribuida replicada, es posible el escenario ilustrado en la Figura Nº 25, el fragmento A1 se guarda en los sitios S1 y S2, mientras que A2 se guarda en los sitios S2 y S3. (Rob, 2004). Figura Nº 25 : Replicación de datos.

FUENTE: [Rob, 2004]

Los datos replicados se someten a la regla de consistencia mutua. La regla de consistencia mutua requiere que todas las copias de fragmentos de datos sean idénticas. Aunque la replicación tiene algunos beneficios. También exige más complejidad de procesamiento del sistema gestor de base de datos, porque cada copia de datos debe ser mantenida por el sistema. •

Si la base de datos está fragmentada, el SGBD debe decidir qué copia accesar.

Una operación de lectura selecciona la copia más cercana para satisfacer la transacción. Una operación de escritura requiere que todas las copias se seleccionen y actualicen para satisfaces la regla de consistencia mutua. 84 de 255


El procesador de transacciones envía una solicitud de datos a cada procesador de datos para su ejecución

El procesador de datos recibe y ejecuta cada solicitud y envía los datos de vuelta al procesador de transacciones.

El procesador de transacciones arma las respuestas del procesador de datos.

Existen tres escenarios de replicación; una base de datos puede ser totalmente replicada, parcialmente replicada o no replicada. (Rob, 2004). •

Base de datos totalmente replicada: Guarda varias copias de cada fragmento de la base de datos en varios sitios. En este caso, los fragmentos de la base de datos están replicados. Una base de datos totalmente replicada puede no ser práctica debido a la cantidad de carga impuesta al sistema.

Base de datos parcialmente replicada: Guarda múltiples copias de algunos fragmentos de la base de datos en múltiples sitios. Esto se refiere a replicar fragmentos de la base de datos, de los cuales existen fragmentos verticales, horizontales y mixtos. La mayoría de los SGBD son capaces de manejar bien la base de datos parcialmente replicada.

Base de datos no replicada: Guarda cada fragmento de base de datos en un solo sitio. Por consiguiente, no existen fragmentos de base de datos duplicados. (Rob, 2004).

Fases generales para implementar y supervisar la replicación. A pesar de que existen varias formas de implementar y supervisar la replicación, y el proceso de replicación es diferente según el tipo y las opciones elegidas, en general, la replicación se compone de las siguientes fases: •

Configuración de la replicación: Se refiere a la configuración de la base de datos para ser replicada mediante el gestor de base de datos.

Generación y aplicación de la instantánea inicial: Se refiere a la selección de los datos a replicar.

Sincronización y propagación de los datos: Se refiere a comprobar que los la base de datos original este sincronizada con la réplica, es decir que si se realiza algún cambio en la base de datos original (maestra), los datos también se deben modificar en la base de datos réplica (esclava). (Rob, 2004). 85 de 255


3

MARC O PRÁCTIC O.

3.1 DETERMINACIÓN DEL FUNCIONAMIENTO ACTUAL DEL SISTEMA DE COBRO DE PATENTES DEL GOBIERNO AUTÓNOMO MUNICIPAL DE COCHABAMBA. En esta sección se describirá el funcionamiento actual, fórmulas y requerimientos que utiliza el sistema de cobro de patentes así como también como el modelado de negocio actual y la propuesta del modelado de negocio alternativo.

3.1.1 Procedimiento actual de cobro de patentes. El procedimiento actual estará representado por el modelado de negocio actual, para tal efecto en primera instancia se procederá a describir el proceso de cobro de patente que se realiza actualmente en la alcaldía de Cochabamba mediante las oficinas del CEMAC. •

El contribuyente llega a las instalaciones del CEMAC (Centro Municipal de atención al contribuyente).

Se aproxima a las oficinas de Dirección de Ingresos Municipales, donde encuentra 2 áreas: Área de proformas, Área de cancelación de bienes e inmuebles y actividades económicas (Caja).

El contribuyente tiene la opción de aproximarse al área de proforma para recoger su documento de estado de cuentas, donde existen 2 únicas ventanillas, brinda sus datos al funcionario tales como: código de licencia o la papeleta de pago anterior (el cual sirve para que el funcionario de área de proformas obtenga el código de licencia del contribuyente).

Para que el funcionario del área de proforma ingrese al sistema se tiene que autenticar en el sistema de cobro de patentes, una vez realizada la operación ingresa el código del contribuyente, sistema realiza una búsqueda en la base de datos, y se hace entrega de la proforma al contribuyente, el cual es un documento que muestra el detalle de la patente.

La otra opción es en la que el contribuyente se dirige al área de caja para realizar la respectiva cancelación de la patente.

86 de 255


Cuando el contribuyente se aproxima al área de caja, existen 2 únicas ventanillas, donde provee sus datos al funcionario de caja tales como: Código de licencia o la papeleta del pago anterior (el cual sirve para que el funcionario de caja obtenga el código de licencia del contribuyente).

De igual manera para que el funcionario de caja ingrese al sistema se tiene que autenticar, una vez realizada la operación ingresa los datos del contribuyente mencionado anteriormente, sistema realiza una búsqueda en la base de datos.

El funcionario de caja le informa al contribuyente las gestiones que tiene adeudadas, y si desea pagar, el contribuyente tiene la opción de pagar la patente o retirarse.

Cuando el contribuyente accede al pago de su patente, el cajero realiza el cobro de la gestión que debe el contribuyente, se registra el mismo en la base de datos, y cajero le hace entrega de un Comprobante de pago.

Al momento de emitir el Comprobante de pago existen 3 copias del mismo, el original se le entrega al contribuyente, los otros 2 se quedan como respaldo, uno en archivos y otro en caja.

3.1.1.1 Modelado de negocio actual. El siguiente modelado de negocio actual se realizó mediante el método BMM (Business Modeling Method) 19, el cual se refleja tres niveles: Nivel de objetivos, nivel de proceso de negocio y nivel de sistema de información, como se muestra en la Figura Nº 26.

19

Business Modeling Method: Método de modelado de negocios orientado al desarrollo de sistemas de información empresarial (Modelado de Negocios, 2013), Ref: pag. 20.

87 de 255


Figura Nº 26 : Modelado de negocio actual. Meta

NIVEL DE OBJETIVOS DE NEGOCIO ACTUAL

Obtener la recaudación de los contribuyentes en las fechas limites de pago.

ALCALDIA - CEMAC

Misión

Visión

Brindar un servicio de calidad al Ser el mejor aliado del contribuyente, facilitando la realización ciudadano, ofreciendo un de los tramites de vehículos, inmuebles servicio de calidad en la atención a quienes interactúan y actividades económicas. con la Alcaldía de Cochabamba,

Contribuyente se aproxima a las Instalaciones del CEMAC

Contribuyente tiene la opción de aproximarse al Área de Proformas o al Área de Caja CEMAC

NIVEL DE PROCESO DE NEGOCIO ACTUAL

Área Proforma

Cajero de hace entrega de

2do un documento Paso denominado “Proforma”

El contribuyente puede recoger su documento de estado de cuentas, es decir el detalle del patente al cual es acreedor, brindando sus datos como ser: 1er • Código de Licencia. ó Paso • Papeleta de pago anterior

Cajero de hace entrega de un documento denominado “Comprobante de Pago”

Área Caja

O bien el área de caja donde el contribuyente realiza la cancelación del patente según la gestión que debe, brindando sus datos como ser: 1er • Código de Licencia ó Paso • Papeleta de pago anterior

2do Paso

Sistema de Cobro de Patentes

NIVEL DE SISTEMA DE INFORMACION Documentos

Base de Datos Diagramas

FUENTE: [Elaboración Propia]

Para tener una mejor visualización, en la Figura Nº 27, se ilustra con detalle el nivel de sistema de información. 88 de 255


Figura Nº 27 : Nivel de sistema de información actual. NIVEL DE SISTEMA DE INFORMACION ACTUAL.

SI

X

ENVIAR CRITERIO DE BUSQUEDA (CÓDIGO DE LICENCIA)

¿VER ESTADO DE CUENTAS?

¿FUNCIONARIO INGRESÓ AL SISTEMA?

NO

SI

NO

X SI

NO Y

INGRESA LOGIN Y PASSWORDINGRESA "UFV" DEL DIA ACTUAL

CAJERO HACE ENTREGA AL CONTRIBUYENTE LA PROFORMA DE PAGO

INICIA

CONTRIBUYENTE BRINDA DATOS DE PATENTE

NO

CAJERO INGRESA LOS DATOS DEL CONTRIBUYENTE: • CODIGO DE LICENCIA Ó • PAPELETA DE PAGO ANTERIO (DONDE SE ENCUENTRA EL CODIGO DE LICENCIA)

SI CAJERO REGISTRA LA GESTION O GESTIONES CANCELADAS, Y EMITE EL COMPROBANTE DE PAGO

NO Z

CONTRIBUYENTE RECIBE COMPROBANTE DE PAGO

NO

AL MOMENTO DE EMITIR COMPROBANTE EXISTEN 3 COPIAS, EL ORIGINAL SE ENTREGA AL CONTRIBUYENTE, LAS OTRAS 2 QUEDAN COMO RESPALDO

A

SI

Fase

SI

CAJERO LE INFORMA AL CONTRIBUYENTE LAS GESTIONES Y SEGUN A ELLO EL MONTO POR CADA GESTION A LA QUE ES DEUDOR, Y LE PREGUNTA SI DESEA PAGAR ALGUNA GESTION

¿CONTRIBUYENTE DESEA PAGAR?

¿SALIR?

¿FUNCIONARIO CAJERO INGRESÓ AL SISTEMA?

INICIA

REGISTRO DE COBRO REALIZADO EN LA BASE DE DATOS

CONTRIBUYENTE PUEDE ACCER AL AREA DE CAJA O BIEN RETIRARSE

Y

BUSCAR CONTRIBUYENTE SEGUN CRITERIO (Código de Licencia)

CONTRIBUYENTE SE APROXIMA AL AREA DE CAJA, BRINDA SUS DATOS O HACE ENTREGA DE LA PROFORMA DE PAGO

INGRESA LOGIN Y PASSWORDINGRESA "UFV" DEL DIA ACTUAL

INGRESA LOS DATOS DEL CONTRIBUYENTE: • CODIGO DE LICENCIA Ó • PAPELETA DE PAGO ANTERIO (DONDE SE ENCUENTRA EL CODIGO DE LICENCIA)

BASE DE DATOS

ENVIAR RESPUESTA DE BÚSQUEDA

FUNCIONARIO DE EMISION DE PROFORMA EN PRIMERA INSTANCIA INGRESA AL SISTEMA

Z,A

¿INGRESAR AL AREA DE CAJA?

FUNCIONARIO CAJERO

ENVIAR CRITERIO DE BUSQUEDA (CÓDIGO DE LICENCIA)

CONTRIBUYENTE SE APROXIMA A CEMAC

FUNCIONARIO DE EMISION DE PROFORMA

ENVIAR RESPUESTA DE BÚSQUEDA

CONTRIBUYENTE

FIN

FUENTE: [Elaboración Propia]

89 de 255


3.1.1.2 Deficiencias del proceso actual de cobro de patentes. Existe bastante demanda de contribuyentes que desean cancelar su patente, un aproximado de 500 personas se aproximan a las instalaciones del CEMAC diariamente para cancelar su impuesto y para ello solo existen 2 únicas ventanillas de caja, la atención es limitada, ya que solo atienden un aproximado de 200 personas por día y solo acceden al área de caja un cierto número de contribuyentes.

3.1.2 Procedimiento propuesto del cobro de patentes. El procedimiento propuesto del cobro de patentes estará enfocado mediante el modelado de negocio alternativo, con el que se pretende evitar las deficiencias del modelado de negocio actual.

3.1.2.1 Modelado de negocio alternativo. El siguiente modelado de negocio alternativo al igual que el modelado de negocio actual, refleja los tres niveles del método BMM (Business Modeling Method). En la Figura Nº 28 se ilustra el modelado de negocio alternativo.

90 de 255


Figura Nº 28 : Modelado de negocio alternativo.

Objetivo Extender puntos de

NIVEL DE OBJETIVOS DE NEGOCIO PROPUESTO

NIVEL DE PROCESO DE NEGOCIO PROPUESTO

Visión

ALCALDIA

Ser el mejor aliado del ciudadano, ofreciendo un servicio de calidad en la atención a quienes interactúan con la Alcaldía de Cochabamba,

Teniendo la información de su patente, el contribuyente puede aproximarse a una entidad financiera para cancelar su impuesto

Misión

Brindar un servicio de calidad al contribuyente, facilitando la realización de los tramites de vehículos, inmuebles y actividades económicas.

Contribuyente ingresa su C.I. y Contraseña

Interfaz de Información de Patente Entidad Financiera

Contribuyente se Aproxima a Entidad Financiera

Cajero ingresa al Modulo de Cobro de Patente Replica BD mediante Login y Password Contribuyente brinda sus datos a cajero: • Código de licencia ó BD Central • Nombre

Entidades Financieras

cobranza e incrementar el número de patentes cancelados al Municipio del Cercado.

Mediante la web, el contribuyente puede ver su estado de cuentas, un detalle de su patente: Gestiones, intereses, multas, etc.

Contribuyente Ingresa a la Página Web Página Web Se Registran los pagos en la Replica y posteriormente los datos se actualiza en la BD Central

Cajero de hace entrega de un documento denominado “Comprobante de Pago”

Mediante la página web el contribuyente tendrá la opción de verificar el estado de cuentas de su patente o sitio municipal

Módulo de Cobro de Patentes Situado en la Entidad Financiera

NIVEL DE SISTEMA DE INFORMACION

ENTIDAD FINANCIERA (CLIENTE)

Réplica BD Enlace Entre Entidad Financiera y Empresa

Caja 1 Caja 2 Caja 3

ALCALDIA (SERVIDOR)

Página Web

Base de Datos Alcaldía

FUENTE: [Elaboración Propia]

Para tener una mejor visualización, en la Figura Nº 29, se ilustra con detalle el nivel de sistema de información del módulo web.

91 de 255


Figura Nº 29 : Nivel de sistema de información alternativo (Módulo Web) NIVEL DE SISTEMA DE INFORMACION ALTERNATIVO (MÓDULO WEB) CONTRIBUYENTE

PAGINA WEB

ADMINISTRADOR ALCALDÍA

CONTRIBUYENTE SE AUTENTICA INGRESANDO EL NÚMERO DE LA CÉDULA DE IDENTIDAD

CONTRIBUYENTE INGRESA A LA PÁGINA WEB

ENVIAR CRITERIO DE BÚSQUEDA (CÉDULA DE IDENTIDAD )

BASE DE DATOS CENTRAL (ALCALDIA)

BUSQUEDA DEL CONTRIBUYENTE SEGUN CRITERIO (CÉDULA DE IDENTIDAD)

ENVIAR RESPUESTA DE BÚSQUEDA

A

MEDIANTE LA PAGINA WEB EL CONTRIBUYENTE PUEDE OBTENER EL DETALLE DE SU PATENTE

SESION ACTIVA

¿VER ESTADO DE CUENTAS?

NO

B

SI

UNA VEZ AUTENTICADO EL CONTRIBUYENTE SE HABILITA UNA PESTAÑA DENOMINADA "SITIOS MUNICIPALES"

CONTRIBUYENTE SELECCIONA EL SITIO MUNICIPAL

INTERFAZ SELECCIONADO EL SITIO MUNICIPAL SE MUESTRA EN LA INTERFAZ DE LA PAGINA WEB EL DETALLE DE SU PATENTE: • GESTIONES NO CANCELADAS • INTERESES • MULTAS, ETC

EL CONTRIBUYENTE TIENE LA OPCION DE IMPRIMIR ESTA INFORMACION LA CUAL VIENE A SER LA "PROFORMA DE PAGO"

B

¿VER OPCIÓN DE AYUDA?

¿IMPRIMIR PROFORMA DE PAGO?

NO

SI

EL CONTRIBUYENTE OBTIENE SU PROFORMA DE PAGO, CON ESTE DOCUMENTO PUEDE APROXIMARSE A LAS ENTIDADES FINANCIERAS A LAS QUE ESTA ASOCIADA LA ALCALDIA

A EL CONTRIBUYENTE PUEDE ELEGIR LA OPCION DE AYUDA UBICADA EN LA INTERFAZ PRINCIPAL DE LA PÁGINA WEB, A TRAVEZ DE ELLA LE INDICA LOS PASO QUE DEBE SEGUIR PARA RECABAR INFORMACION DEL COBRO DE PATENTES

Fase

FIN

SI

NO

ADMINISTRADOR DE LA ALCALDIA ES ENCARGADO DE PUBLICAR LAS FECHAS LIMITES PARA LA CANCELACION DEL PATENTE, ASI COMO INSENTIVAR AL CONTRIBUYENTE A REALIZAR SUS PAGOS EN LAS DIFERENTES ENTIDADES FINANCIERA CON LAS QUE ESTA ASOCIADA LA ALCALDIA

SI

NO

¿SALIR PÁGINA WEB?

PUBLICACION EN LA PAGINA WEB POR PARTE DEL ADMINISTRADOR DE LA ALCALDIA

FUENTE: [Elaboración Propia]

En la Figura Nº 30 se ilustra con detalle el nivel de sistema de información de la herramienta de cobro de patentes.

92 de 255


Figura Nº 30 : Nivel de sistema de información alternativo (Herramienta de cobro de patentes) NIVEL DE SISTEMA DE INFORMACIÓN ALTERNATIVO (HERRAMIENTA DE COBRO DE PATENTES) CONTRIBUYENTE

RÉPLICA BASE DE DATOS

CAJERO ENTIDAD FINANCIERA

BASE DE DATOS CENTRAL (ALCALDÍA)

ADMINISTRADOR ENTIDAD FINANCIERA

ADMINISTRADOR ALCALDÍA

CONTRIBUYENTE SE APROXIMA A CAJA

¿CAJERO INGRESÓ AL SISTEMA?

SI

NO

INGRESA LOGIN Y PASSWORD DE AUTENTICACIÓNINGRESA "UFV" DEL DÍA ACTUAL

CONTRIBUYENTE BRINDA SU CÓDIGO DE LICENCIA O NOMBRE COMPLETO

INICIA

A: ENVIAR MENSAJE DE CONFIRMACIÓN

CANAL DE COMUNICACIONES

C

¿CAMBIAR NÚMERO DE DOSIFICACIÓN?

SI

SE VERIFICA EL NÚMERO DE DOSIFICACIÓN ACTUAL CON LA NUEVA NUMERACION Y SE GUARDA LOS CAMBIOS REALIZADOS

NO

3:4: ENVIAR REGISTRO DE DATOS

Y

¿OPCIÓN: REGISTRAR CONTRIBUYENTES? SI

NO

α α i: ENVIAR MENSAJE DE CONFIRMACIÓN

β

NO

B

¿ANULAR COMPROBANTE DE PAGO?

β

iv: ENVIAR CRITERIOS DE REPORTES

4: ENVIAR RESPUESTA DE COMPROBANTE ANULADO

SI

NO

ADMINISTRADOR ALCALDIA BUSCA EL SITIO MUNICIPAL POR CÓDIGO DE LICENCIA O BIEN POR NOMBRE DEL CONTRIBUYENTE, ADEMAS TIENE LA OPCIÓN DE MODIFICAR EL SITIO MUNICIPAL Y ASIGNAR EL SITIO A UN NUEVO CONTRIBUYENTE QUE DESEA REALIZAR UNA ACTIVIDAD COMERCIAL

ADMINISTRADOR DE LA ENTIDAD FINANCIERA PUEDE REALIZAR EL REPORTE GENERAL DE LOS PAGOS REALIZADOS DURANTE EL DÍA, MOSTRANDO EN PANTALLA EL DETALLE POR CAJERO Y CÓDIGO DE SUCURSAL

¿OPCIÓN: PAGOS POR GESTIÓN?

TAMBIEN TIENE LA OPCION DE REALIZAR LOS REPORTES POR SUCURSALES Y POR RANGO DE FECHAS

ADMINISTRADOR ALCALDÍA INGRESA LOS NUEVOS DATOS PARA LA NUEVA GESTIÓN

NO

¿SALIR?

NO

NO

¿OPCIÓN GESTIONAR ENTIDADES FINANCIERAS?

X

SI ADMINISTRADOR ALCALDÍA REALIZA LA CREACION DE ENTIDADES FINANCIERAS, COMO LA MODIFICACIÓN O ELMINACIÓN

FIN ii: ENVIAR DATOS DE REGISTRO NO ii: ENVIAR MENSAJE DE CONTRIBUYENTE REGISTRADO

REGISTRO DE DATOS EN LA BASE DE DATOS CENTRAL

GUARDA LOS CAMBIOS REALIZADOS EN LA BASE DE DATOS CENTRAL

iii: ENVIAR CRITERIOS DE CAMBIOS A REALIZAR ¿GENERAR REPORTES?

iii: ENVIAR RESPUESTA DE CAMBIOS REALIZADOS

SI

FIN

¿OPCIÓN: GESTIONAR SITIOS MUNICIPALES?

SI i: ENVIAR LOGIN Y PASSWORD

4: ENVIAR CAMBIOS A REALIZAR

¿SALIR?

GUARDA EL REGISTRO DEL CONTRIBUYENTE EN LA BASE DE DATOS CENTRAL

NO

¿OPCIÓN REPORTE ENTIDAD FINANCIERA?

iv: ENVIAR RESPUESTA DE CRITERIOS DE REPORTES

A,C

NO

SI

AL MOMENTO DE EMITIR COMPROBANTE EXISTEN 3 COPIAS, EL ORIGINAL SE ENTREGA AL CONTRIBUYENTE, UNO SE QUEDA COMO RESPALDO PARA LA ENTIDAD FINANCIERA, Y EL ULTIMO PARA ENTREGAR A LA ALCALDIA

NO

ADMINISTRADOR ALCALDÍA REALIZA EL REGISTRO DEL CONTRIBUYENTE LLENANDO LOS CAMPOS INDICADOS

LOS CAMBIOS SE GUARDAN EN LA RÉPLICA DE LA BASE DATOS

CAJERO REGISTRA LA GESTIÓN O GESTIONES PAGADAS, Y EMITE EL COMPROBANTE DE PAGO

CONTRIBUYENTE RECIBE COMPROBANTE DE PAGO

¿OPCIÓN: CREAR, MODIFICAR O ELIMINAR?

B: ENVIAR RESPUESTA DE CAMBIOS REALIZADOS

CONSULTA A LA BASE DE DATOS CENTRAL

EL CAJERO TAMBIÉN TIENE LA OPCIÓN DE ANULAR EL COMPROBANTE DE PAGO, YA SEA POR COBROS INDEBIDOS, O RAZONES A CAUSA DEL CONTRIBUYENTE. SE REALIZA LA ANULACIÓN DEL COMPROBANTE SEGUN AL NÚMERO DEL COMPROBANTE Y EL MOTIVO DE LA ANULACIÓN

ADMINISTRADOR ENTIDAD FINANCIERA VERIFICA LAS SUCURSALES EN DONDE PUEDE CREAR, MODIFICAR Y ELIMINAR

B: ENVIAR CRITERIOS DE CAMBIOS A REALIZAR

3: ENVIAR RESPUESTA DE PAGO REGISTRADO

CAJERO TIENE LA OPCIÓN DE CAMBIAR EL NÚMERO DE DOSIFICACIÓN PARA LA EMISIÓN DEL COMPROBANTE DE PAGO

ADMINISTRADOR TIENE LAS OPCIONES DE REGISTRAR CONTRIBUYENTES, GESTIONAR LOS SITIOS MUNICIPALES, GENERAR PAGOS POR GESTIÓN, GESTIONAR ENTIDADES FINANCIERAS, GENERAR REPORTES TALES COMO: • ESTADOS FINANCIEROS DEL CONTRIBUYENTE • POR ENTIDADES FINANCIERAS

¿OPCIÓN: SUCURSALES Y CAJEROS?

REGISTRO DE DATOS EN LA RÉPLICA DE BASE DATOS

3: ENVIAR REGISTRO DE PAGO DEL CONTRIBUYENTE

SI

α

X

SISTEMA REALIZA UNA BÚSQUEDA DEL CONTRIBUYENTE CON EL CRITERIO DE LOS DATOS MENCIONADOS

NO

ADMINISTRADOR DE LA ALCALDÍA INGRESA A LA HERRAMIENTA MEDIANTE LOGIN Y PASSWORD

α

EL ADMINISTRADOR DE LA ENTIDAD FINANCIERA PUEDE ACCEDER A CREAR/MODIFICAR Y ELIMINAR SUCURSALES Y CAJEROS, COMO REALIZAR UN REPORTE SOBRE LOS PAGOS QUE SE REALIZARON EN LA ENTIDAD FINANCIERA

REGISTRO DE DATOS EN LA BASE DE DATOS CENTRAL

CAJERO INGRESA LOS DATOS DEL CONTRIBUYENTE: • CÓDIGO DE LICENCIA Ó • NOMBRE DEL CONTRIBUYENTE

¿CONTRIBUYENTE DESEA PAGAR?

ADMINISTRADOR DE LA ENTIDAD FINANCIERA INGRESA A LA HERRAMIENTA MEDIANTE LOGIN Y PASSWORD

A: ENVIAR LOGIN Y PASSWORD CONSULTAS EN LA RÉPLICA DE BASE DATOS

3:4: ENVIAR REGISTRO DE DATOS

A

2: ENVIAR CRITERIO DE BUSQUEDA

NO

SI

2: ENVIAR RESPUESTA DE BUSQUEDA

¿INGRESAR A LA ENTIDAD FINANCIERA?

1: ENVIAR LOGIN Y PASSWORD

CONTRIBUYENTE QUE DESEA PAGAR SU PATENTE SE APROXIMA A LA ENTIDAD FINANCIERA (CON LAS QUE ESTA ASOCIADA LA ALCALDÍA)

1: ENVIAR MENSAJE DE CONFIRMACIÓN

B

SE ANULA EL COMPROBANTE Y SE REGISTRA LOS CAMBIOS EN LA RÉPLICA DE BASE DE DATOS

β β

CAJERO PUEDE REALIZAR EL REPORTE DIARIO DE CAJA, EN LA QUE SE DETALLA LOS COBROS REALIZADOS ASI COMO LOS COMPROBANTES ANULADOS

REPORTES DE ESTADOS FINANCIEROS DEL CONTRIBUYENTE NO

REPORTE DE ENTIDADES FINANCIERAS

Y

NO

¿SALIR?

Fase

SI

FIN

FUENTE: [Elaboración Propia]

93 de 255


3.1.3 Análisis de fórmulas y requerimientos utilizados en el sistema de cobro de patentes. En el proceso de cobro de patentes existen fórmulas para que estas calculen la patente según la gestión y la actividad que está realizando el contribuyente como se pudo observar el (Capitulo 2, Sección 2.2.2.2 Página 31). Así también el cobro de patentes trabaja con cuadros definidos por la Ordenanza Municipal como se muestra en el (ANEXO D), además el cobro de patentes se basa en la fórmula que establece el Código Tributario ilustrado en la Figura Nº 31, mediante esta fórmula se calculan las deudas tributarias de cada contribuyente. Figura Nº 31 : Fórmula del código tributario para el cálculo de cobro de patentes.

FUENTE: [Código Tributario Boliviano]

Donde: DT:

Deuda Tributaria.

TO:

Tributo Omitido.

r:

Tasa Anual de interés activa promedio

360: Es la cantidad de días del año tomada en cuenta por el código tributario. n:

número de días de mora.

M:

Multas.

94 de 255


3.2 IDENTIFICACIÓN

DE

LA

METODOLOGÍA

DE

DESARROLLO DE SOFTWARE PARA LA PROPUESTA. 3.2.1 Análisis y selección de metodología de desarrollo de software. Para la selección de la metodología, se presentará en la Tabla Nº 4 un resumen de algunas características consideradas principales para la identificación de la metodología. Tabla Nº 4: Selección de metodología de desarrollo de software.

FUENTE: [Elaboración Propia]

95 de 255


En base a las características y el criterio de ponderación de cada metodología, se ha determinado la elección de la metodología de desarrollo de software UP, como la más indicada para el presente trabajo ya que mencionada la arquitectura, esta provee la estructura sobre la cual guía el trabajo en iteraciones, mientras que los casos de uso definen las metas y dirigen el trabajo en cada iteración, la ventaja sobre las demás metodologías es que UP realiza una temprana retroalimentación que se ajusten a las necesidades reales.

3.2.2 Análisis y selección de modelo de desarrollo de software. Para la selección del modelo de desarrollo de software, se muestra en la Tabla Nº 5 las características más relevantes para la identificación del modelo a utilizar en el presente trabajo. Tabla Nº 5: Identificación del modelo de desarrollo de software.

FUENTE: [Elaboración Propia]

96 de 255


Realizado el análisis tomando como base características y consideraciones de cada modelo, se ha determinado elegir el modelo basado en componentes para el desarrollo de la herramienta en el presente trabajo, en lo cual refleja que el modelo basado en componentes utiliza partes del sistema la cuales pueden ser actualizas y trabajan independientemente de otros componentes lo cual reduce costos y riesgos al momento de la entrega final del producto.

3.3 DESARROLLO

DEL

MÓDULO

WEB

PARA

LA

OBTENCIÓN DE PROFORMAS DE PAGO. 3.3.1 Aplicación de la metodología elegida al módulo web. 3.3.1.1 Identificación de diagramas UML para UP. Realizada la identificación de la metodología de desarrollo, en la Figura Nº 32 se presentan la serie de flujos de trabajo que se utilizaran en cada fase según la iteración.

MModdello dde

Definiendo el modelo de análisis, diseño, implementación y pruebas de acuerdo al flujo de trabajo de UP.

Figura Nº 32 : Identificación de diagramas UML para el trabajo.

FUENTE: [Elaboración Propia]

97 de 255


3.3.1.2 Fase de inicio. Para la fase de inicio primeramente se estableció el modelado de negocio propuesto el cual se describe en la Página 92, y posteriormente se realización las iteraciones correspondientes aplicando los flujos de trabajo según UP. • Primera iteración: Acceso a la página web. A continuación se detallarán los requerimientos funcionales y no funcionales para la primera iteración del módulo web. • Análisis de requerimiento del módulo web. Para realizar el análisis de requerimiento vamos a mencionar los puntos mediante los requerimientos funcionales y requerimientos no funcionales.  Requerimientos funcionales. •

Ingreso al módulo web mediante cédula de identidad (C.I.)

 Requerimientos no funcionales. •

El módulo web pretende evitar errores de validación y contención de tipos de datos que se ingresan mediante la interfaz de autenticación

El módulo web debe visualizarse y funcionar correctamente en todos los navegadores web.

1. Modelo de casos de uso  Identificación de actores. Se denomina actor o actores a los usuarios que cumplen un determinado rol dentro del sistema. Para el desarrollo de la primera iteración del módulo web, se identificó el siguiente actor, ilustrados en la Figura Nº 33. Figura Nº 33 : Actores del módulo web: primera iteración.

FUENTE: [Elaboración Propia]

98 de 255


 Descripción de actores. •

Contribuyente: Es la persona que ingresa a la página web mediante su cédula de identidad.

 Diagrama de casos de uso. En la Figura Nº 34, se muestra el diagrama de casos de uso del ingreso o autenticación del contribuyente a la página web. •

Caso de uso: Ingresar a la página web. Actor: Contribuyente. Figura Nº 34 : Caso de uso: Ingresar a la página web (primera iteración)

FUENTE: [Elaboración Propia]

Escenario de casos de uso: Ingresar a la página web (primera iteración). Tabla Nº 6: Escenario: Ingresar a la página web (primera iteración).

Nombre:

Ingresar a la página web.

Actor:

Contribuyente

Función:

Permitir el acceso a la página web al contribuyente.

Descripción: El contribuyente puede ingresar a la página web mediante su cédula de identidad. Cuando contribuyente se autentica, primeramente se establece una conexión con la base de datos central, donde se realiza una búsqueda y devuelve su estado de cuentas, habilitando una pestaña en la interfaz web denominada “Sitios Municipales”. FUENTE: [Elaboración Propia]

99 de 255


2. Modelo de análisis.  Diagrama de colaboración. Los diagramas de colaboración muestran cómo el control pasa de un objeto a otro a medida que se lleva a cabo el caso de uso, y los mensajes que se envían entre los objetos. A continuación se describe el diagrama de colaboración ingresar a la página web, ilustrado en la Figura Nº 35. •

Caso de uso: Ingresar a la página web. Actor: Contribuyente.

Figura Nº 35 : Diagrama de colaboración: Ingresar a la página web (primera iteración).

FUENTE: [Elaboración Propia]

3. Modelo de Diseño.  Diagrama secuencia. A continuación se presentan el diagrama de secuencia de acceso a la página web con los objetos de diseño en una secuencia temporal como se muestra en la Figura Nº 36. •

Ingresar a la página web

100 de 255


Figura Nº 36 : Diagrama de secuencia: Ingresar a la página web (primera iteración). : Gestor Usuario

: IU Pagina Web

: Gestionar Estado de Cuentas

:IU Proforma de Pago

: Base de Datos

Seleccionar la opción Ingresar

Contribuyente

Ingresar Cédula de Identidad Enviar y Comprobar Dato en la Base de Datos

Enviar Resultados

FUENTE: [Elaboración Propia]

 Diagrama de clases. En los diagramas de clases, como se ilustra en la Figura Nº 37, muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Figura Nº 37 : Diagrama de clases: Ingresar a la página web (primera iteración).

Contribuyente idcontribuyente Persona Sitio Municipal FUENTE: [Elaboración Propia]

 Diseño de interfaces. En la Figura Nº 38, se puede observar el ingreso o autenticación del contribuyente a la página web, en donde el usuario tendrá que acceder mediante su cédula de identidad.

101 de 255


Figura Nº 38 : Diseño de la interfaz de inicio de sesión de la web. (primera iteración).

FUENTE: [Elaboración Propia]

4. Modelo de implementación.  Diagrama de componentes. Un diagrama de componentes muestra la realización de un conjunto de interfaces, las cuales permiten implementar un componente utilizando componentes más pequeños, en la Figura Nº 39, se ilustra el diagrama de componentes de la página web. Figura Nº 39 : Diagrama de componente: Ingresar a la página web (primera iteración).

FUENTE: [Elaboración Propia]

102 de 255


5. Modelo de pruebas. Para este modelo no se realizó ningún tipo de pruebas, ya que en esta etapa de inicio solo se refleja lo que corresponde a la información y según la metodología en dichas fases indica que no existe ninguna prueba.

3.3.1.3 Fase de elaboración. • Segunda iteración: Acceso a la página web y gestionar estado de cuentas. A continuación se detallarán los requerimientos funcionales y no funcionales para la segunda iteración del módulo web. • Análisis de requerimiento del módulo web. Para realizar el análisis de requerimiento vamos a mencionar los puntos mediante los requerimientos funcionales y requerimientos no funcionales.  Requerimientos funcionales. •

Ingreso al módulo web mediante cédula de identidad (C.I.).

Gestionar estado de cuentas.

 Requerimientos no funcionales. •

El módulo web pretende evitar errores de validación y contención de tipos de datos que se ingresan mediante la interfaz de autenticación

El módulo web debe visualizarse y funcionar correctamente en todos los navegadores web.

1. Modelo de casos de uso  Identificación de actores. Se denomina actor o actores a los usuarios que cumplen un determinado rol dentro del sistema. Para el desarrollo de la segunda iteración del módulo web, se identificó el siguiente actor, ilustrados en la Figura Nº 40.

103 de 255


Figura Nº 40 : Actores del módulo web: segunda iteración

FUENTE: [Elaboración Propia]

 Descripción de actores. •

Contribuyente: Es la persona que verifica su estado de cuentas (Proforma) en la página web, ingresando su cédula de identidad accede a verificar las gestiones, el interés, etc.

 Diagrama de casos de uso. En la Figura Nº 41, se muestra el diagrama de casos de uso del ingreso o autenticación del contribuyente a la página web así como también el de gestionar estado de cuentas. •

Caso de uso: Ingresar a la página web. Actor: Contribuyente. Figura Nº 41 : Caso de uso: Ingresar a la página web (segunda iteración).

FUENTE: [Elaboración Propia]

Escenario de casos de uso: Ingresar a la página Web (segunda iteración).

104 de 255


Tabla Nº 7: Escenario: Ingresar a la página web (segunda iteración). Nombre:

Ingresar a la página web.

Actor:

Contribuyente.

Función:

Acceso a la página web, visualizar estado de cuentas.

Descripción: El contribuyente puede ingresar a la página web mediante su cédula de identidad Cuando contribuyente se autentica, primeramente se establece una conexión con la base de datos central, donde se realiza una búsqueda y devuelve su estado de cuentas, habilitando una pestaña en la interfaz web denominada “Sitios Municipales”. Gestionar estado de cuentas es cuando se habilita la opción de sitios municipales, ingresa a dicha opción y obtiene el detalle del estado del contribuyente. FUENTE: [Elaboración Propia]

2. Modelo de análisis.  Diagrama de colaboración. Los diagramas de colaboración muestran cómo el control pasa de un objeto a otro a medida que se lleva a cabo el caso de uso, y los mensajes que se envían entre los objetos. A continuación se describe el diagrama de colaboración ingresar a la página web, ilustrado en la Figura Nº 42. •

Caso de uso: Ingresar a la página web. Actor: Contribuyente.

Figura Nº 42 : Diagrama de colaboración: Ingresar a la página web (segunda iteración).

FUENTE: [Elaboración Propia]

105 de 255


3. Modelo de diseño.  Diagrama secuencia. A continuación se presentan el diagrama de secuencia de acceso a la página web y el de gestionar estado de cuentas con los objetos de diseño en una secuencia temporal como se muestra en la Figura Nº 43. •

Ingresar a la página web Figura Nº 43 : Diagrama de secuencia: Ingresar a la página web (segunda iteración). : IU Pagina Web

: Gestor Usuario

: Gestionar Estado de Cuentas

:IU Proforma de Pago

: Base de Datos

Seleccionar la opción Ingresar

Contribuyente

Ingresar Cédula de Identidad Enviar y Comprobar Dato en la Base de Datos

Enviar Resultados

Mostrar Interfaz de Usuario Seleccionar Opción “Sitios Municipales”

FUENTE: [Elaboración Propia]

 Diagrama de clases. En los diagramas de clases, como se ilustra en la Figura Nº 44, muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Figura Nº 44 : Diagrama de clases: Ingresar a la página web (segunda iteración). SitioMunicipal Persona -apellidoMaterno: String -apellidoPaterno: String -ci: String -direccion: String -id: int -nombre: String

Contribuyente -id: int -persona: Persona -sitioMunicipales: SitioMunicipales[]

FUENTE: [Elaboración Propia]

106 de 255

-codigoLic: String -descripcion: String -direccion: String -estado: String -fechaInicio: Date -pagos: Pagos[] -sindicato: String -superficie: int -tipo: String


 Diseño de interfaces. Cuando el contribuyente inicia sesión mediante su cédula de identidad, se habilita una pestaña denominada Sitio Municipal, como se muestra en la Figura Nº 45, en la cual se observa los sitios municipales que tiene el contribuyente. Figura Nº 45 : Diseño de la interfaz sitio municipal del contribuyente.

FUENTE: [Elaboración Propia]

4. Modelo de implementación.  Diagrama de componentes. Un diagrama de componentes muestra la realización de un conjunto de interfaces, las cuales permiten implementar un componente utilizando componentes más pequeños, en la Figura Nº 46, se ilustra el diagrama de componentes del estado de cuentas.

107 de 255


Figura Nº 46 : Diagrama de componente: Ingresar a la página web.

FUENTE: [Elaboración Propia]

5. Modelo de pruebas. Para la segunda iteración se realizó la prueba funcional del caso de uso Ingresar a la Página web, la cual se describe en la Tabla Nº 8. Tabla Nº 8: Prueba funcional: Ingresar a la página web (segunda iteración). Caso de prueba

Datos

Acción esperada

introducidos

Resultado

El contribuyente tiene

que

autenticarse Ingresar

a

Página Web.

la mediante Cédula

su de

Identidad oprimir

(C.I.)

Seleccionando municipal

se

un observa

sitio en

pantalla el detalle de las Satisfactorio gestiones

deudoras

contribuyente

“Ingresar”.

FUENTE: [Elaboración Propia]

108 de 255

del


3.3.1.4 Fase de construcción. • Tercera iteración: Acceso a la página web, gestionar estado de cuentas, emisión de proforma de pago, publicar noticias y fechas de pago. A continuación se detallarán los requerimientos funcionales y no funcionales para la tercera iteración del módulo web. • Análisis de requerimiento del módulo web. Para realizar el análisis de requerimiento vamos a mencionar los puntos mediante los requerimientos funcionales y requerimientos no funcionales.  Requerimientos funcionales. •

Ingreso al módulo web mediante cédula de identidad (C.I.).

Gestionar estado de cuentas.

Emisión de proforma de pago de la patente o sitio municipal.

Publicar noticias y fechas pago.

 Requerimientos no funcionales. •

El módulo web pretende evitar errores de validación y contención de tipos de datos que se ingresan mediante la interfaz de autenticación

El módulo web debe visualizarse y funcionar correctamente en todos los navegadores web.

1. Modelo de casos de uso  Identificación de actores. Se denomina actor o actores a los usuarios que cumplen un determinado rol dentro del sistema. Para el desarrollo de la tercera iteración del módulo web, se identificaron los siguientes actores, ilustrados en la Figura Nº 47.

109 de 255


Figura Nº 47 : Actores del módulo web: tercera iteración.

FUENTE: [Elaboración Propia]

 Descripción de actores. •

Administrador alcaldía: Es la persona encarga de administrar la página web, tiene un acceso a las funcionalidades del módulo, encargado de realizar anuncios y publicar las fechas límites de cancelación del impuesto.

Contribuyente: Es la persona que verifica su estado de cuentas (Proforma) en la página web, ingresando su cédula de identidad accede a verificar las gestiones, el interés, la actividad comercial que realiza y la opción de imprimir este detalle de su estado de cuentas.

 Diagrama de casos de uso. En la Figura Nº 48, se muestra el diagrama de casos de uso del ingreso o autenticación del contribuyente como del administrador de la alcaldía a la página web. •

Caso de uso: Ingresar a la página web. Actor: Administrador alcaldía, Contribuyente Figura Nº 48 : Caso de uso: Ingresar a la página web (tercera iteración).

FUENTE: [Elaboración Propia]

110 de 255


Escenario de casos de uso: Ingresar a la página web (tercera iteración). Tabla Nº 9: Escenario: Ingresar a la página web (tercera iteración).

Nombre:

Ingresar a la página web.

Actor:

Administrador alcaldía, Contribuyente

Función:

Permitir el acceso a la página web al administrador y al contribuyente.

Descripción: El contribuyente puede ingresar a la página web mediante su cédula de identidad. Cuando contribuyente o usuario administrador se autentica, primeramente se establece una conexión con la base de datos central, donde se realiza una búsqueda y devuelve su estado de cuentas, habilitando una pestaña en la interfaz web denominada “Sitios Municipales”. Gestionar estado de cuentas es cuando se habilita la opción de sitios municipales, ingresa a dicha opción y obtiene el detalle del estado del contribuyente. El administrador de la alcaldía es encargado de publicar las fechas plazo para que el contribuyente pueda pagar la patente. FUENTE: [Elaboración Propia]

2. Modelo de análisis.  Diagrama de colaboración. Los diagramas de colaboración muestran cómo el control pasa de un objeto a otro a medida que se lleva a cabo el caso de uso, y los mensajes que se envían entre los objetos. A continuación se describe el diagrama de colaboración ingresar a la página web con toda sus funcionalidades ilustrado en la Figura Nº 49. •

Caso de uso: Ingresar a la página web. Actor: Contribuyente, Administrador alcaldía.

111 de 255


Figura Nº 49 : Diagrama de colaboración: Ingresar a la página web (tercera iteración).

FUENTE: [Elaboración Propia]

3. Modelo de diseño.  Diagrama secuencia. A continuación se presentan el diagrama de secuencia de acceso a la página web con los objetos de diseño en una secuencia temporal como se muestra en la Figura Nº 50. •

Ingresar a la página web

Figura Nº 50 : Diagrama de secuencia: Ingresar a la página web (tercera iteración). : IU Pagina Web

: Gestor Usuario

: Gestionar Estado de Cuentas

:IU Proforma de Pago

Seleccionar la opción Ingresar

Contribuyente, Administrador Alcaldía

Ingresar Cédula de Identidad Enviar y Comprobar Dato en la Base de Datos

Enviar Resultados

Mostrar Interfaz de Usuario Seleccionar Opción “Sitios Municipales” Emitir Proforma de Pago

FUENTE: [Elaboración Propia]

112 de 255

: Base de Datos


 Diagrama de clases. En los diagramas de clases, como se ilustra en la Figura Nº 51, muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Figura Nº 51 : Diagrama de clases: Ingresar a la página web (tercera iteración). Usuario -Email: String -id: Int -login: String -password: String -persona: Persona

SitioMunicipal Persona -apellidoMaterno: -apellidoPaterno: -ci: String -direccion: String -id: int -nombre: String

String String

Contribuyente -id: int -persona: Persona -sitioMunicipales: SitioMunicipales[]

-codigoLic: String -descripcion: String -direccion: String -estado: String -fechaInicio: Date -pagos: Pagos[] -sindicato: String -superficie: int -tipo: String

FUENTE: [Elaboración Propia]

 Diseño de interfaces. En la Figura Nº 52, se puede observar el diseño de la página principal de la web, en donde el contribuyente tendrá la información de la fecha límite para el pago de su patente, así como las entidades financieras a las cuales puede aproximarse para realizar el pago de su impuesto. Figura Nº 52 : Diseño de la página de inicio de la web (tercera iteración).

FUENTE: [Elaboración Propia]

113 de 255


a) Diseño de interfaz de ingreso a la página web En la Figura Nº 53, se puede observar el ingreso o autenticación del contribuyente a la página web, en donde el usuario tendrá que acceder mediante su cédula de identidad. Figura Nº 53 : Diseño de la interfaz de inicio de sesión de la web. (tercera iteración).

FUENTE: [Elaboración Propia]

b) Diseño de la interfaz sitio municipal del contribuyente. Cuando el contribuyente inicia sesión mediante su Cédula de identidad, se habilita una pestaña denominada Sitio Municipal, como se muestra en la Figura Nº 54, en la cual se observa los sitios municipales que tiene el contribuyente. Figura Nº 54 : Diseño de la interfaz sitio municipal del contribuyente.

FUENTE: [Elaboración Propia]

114 de 255


c) Diseño de la interfaz de impresión de proforma de pago. El contribuyente puede acceder a ver el detalle de su patente, accediendo a cualquiera de los sitios municipales al cual es acreedor se puede visualizar la proforma de pago, como se muestra en la Figura Nº 55, donde tiene la opción de imprimir este documento. Figura Nº 55 : Ventana sitio municipal del contribuyente (tercera iteración)

FUENTE: [Elaboración Propia]

4. Modelo de implementación.  Diagrama de componentes. Un diagrama de componentes muestra la realización de un conjunto de interfaces, las cuales permiten implementar un componente utilizando componentes más pequeños, en la Figura Nº 56, se ilustra el diagrama de componentes de la página web. Figura Nº 56 : Diagrama de componente: Ingresar a la página web (tercera iteración)

FUENTE: [Elaboración Propia]

115 de 255


 Análisis de selección del gestor de base de datos. Para la selección del gestor de base datos, se ilustra en la Tabla Nº 10, las características más relevantes para la identificación y selección del gestor para el presente trabajo. Tabla Nº 10: Selección de gestor de base de datos.

FUENTE: [Elaboración Propia]

Considerando las características y criterio de ponderación, se ha determinado que el gestor de base de datos MySQL es el adecuado para el presente trabajo ya que la alcaldía actualmente maneja un servidor de base de datos MySQL, además que facilita el realizar réplicas que será empleado entre entidad financiera y empresa. 116 de 255


 Análisis de selección del lenguaje de programación para el módulo web. Para realizar la selección del lenguaje de programación del módulo web, se consideró las características principales para la identificación del lenguaje a utilizar las cuales se muestra en la Tabla Nº 11. Tabla Nº 11: Selección del lenguaje de programación para el módulo web.

FUENTE: [Elaboración Propia]

Considerando las características y criterio de ponderación, se ha determinado que el lenguaje de programación PHP es el adecuado para el desarrollo de la página web de cobro de patentes, ya que tiene una gran conectividad con los gestores de base de datos actuales. 117 de 255


 Implementación de las interfaces del módulo web para la obtención de proformas de pago. a) Interfaz principal. En la Figura Nº 57, se muestra la interfaz principal en la cual se encuentran 3 pestañas (Inicio, Ingresar y ayuda), en la pestaña de inicio se observa las diferentes entidades financieras a la cual está sujeto el cobro de patentes, en la segunda pestaña se encuentra la autenticación del contribuyente para que pueda obtener el detalle de su patente según el sitio municipal, y en la tercera se encuentra un texto de ayuda en donde indica al contribuyente como puede imprimir su proforma de pago mediante la web. Figura Nº 57 : Interfaz menú principal (tercera iteración).

FUENTE: [Elaboración Propia]

b) Interfaz de autenticación del contribuyente. Mediante la siguiente interfaz como se muestra en la Figura Nº 58, el contribuyente primeramente tiene que autenticarse mediante su cédula de identidad (C.I.), para ver el detalle de su patente dependiendo el número de sitios municipales que tenga el contribuyente.

118 de 255


Figura Nº 58 : Interfaz de autenticación del contribuyente. (tercera iteración)

FUENTE: [Elaboración Propia]

c) Interfaz de sitio municipal del contribuyente. Cuando el contribuyente realizó la autenticación se habilita una nueva pestaña denominada “Sitios Municipales”, como se muestra en la Figura Nº 59, en la cual se muestra los sitios municipales que tiene el contribuyente, donde para cada sitio municipal existe un código de licencia, el cual es único. Figura Nº 59 : Interfaz del sitio municipal del contribuyente. (tercera iteración)

FUENTE: [Elaboración Propia]

119 de 255


d) Interfaz del detalle de la patente e impresión de proforma de pago. Una vez seleccionado el sitio municipal, el contribuyente puede apreciar el detalle de su patente, con las gestiones pendientes a pagar, el monto por cada una de ellas y el historial de pagos como se muestra en la Figura Nº 60. Para ilustrar como ejemplo se ingresará al primer sitio municipal. Figura Nº 60 : Interfaz de proforma de pago. (tercera iteración)

FUENTE: [Elaboración Propia]

120 de 255


5. Modelo de pruebas. Para la tercera iteración se realizó la prueba funcional del caso de uso ingresar a la página web, la cual se describe en la Tabla Nº 12. Tabla Nº 12: Prueba funcional: Ingresar a la página web (tercera iteración). Caso de prueba

Datos

Acción esperada

introducidos

Resultado

Se despliega en la página principal

la

pestaña

denominada

“Sitios

Municipales” en donde se

Satisfactorio

observa el sitio o los sitios del contribuyente.

El contribuyente tiene

que

a

Página Web.

la mediante

detalle

Identidad

de

pantalla las

el

gestiones

Satisfactorio

su de Existe

Carnet

en

deudoras del contribuyente

autenticarse Ingresar

Observar

una

(C.I.) denominada

pestaña “Ayuda”

en

oprimir

donde indica al contribuyente

“Ingresar”.

los pasos para obtener su

Satisfactorio

proforma de pago.

Si los datos introducidos son erróneos el sistema muestra mensaje de error.

FUENTE: [Elaboración Propia]

121 de 255

Satisfactorio


3.3.1.5 Fase de transición. • Cuarta iteración: Acceso a la página web, gestionar estado de cuentas, emisión de proforma de pago, publicar noticias y fechas de pago.

1. Modelo de casos de uso En el respectivo modelo de casos de uso perteneciente al flujo de trabajo, se mencionaran solo los puntos los cuales se detallaron en las anteriores fases de acuerdo a la metodología UP.  Identificación de actores.  Administrador alcaldía.  Contribuyente. 2. Modelo de análisis.  Diagrama de colaboración. Los diagramas de colaboración muestran cómo el control pasa de un objeto a otro a medida que se lleva a cabo el caso de uso, y los mensajes que se envían entre los objetos. A continuación se describe el diagrama de colaboración ingresar a la página web, ilustrado en la Figura Nº 61. •

Caso de uso: Ingresar a la página web. Actor: Contribuyente, Administrador alcaldía. Figura Nº 61 : Diagrama de colaboración: Ingresar a la página web.

FUENTE: [Elaboración Propia]

122 de 255


3. Modelo de diseño.  Diagrama secuencia. A continuación se ilustra el diagrama de secuencia de acceso a la página web con los objetos de diseño en una secuencia temporal como se muestra en la Figura Nº 62. •

Ingresar a la página web

Figura Nº 62 : Diagrama de secuencia: Ingresar a la página web. (cuarta iteración). : IU Pagina Web

: Gestor Usuario

: Gestionar Estado de Cuentas

:IU Proforma de Pago

: Base de Datos

Seleccionar la o pció n Ingresar

Contribuyente, Administrador Alcaldía

Ingresar Cédula de Identidad Enviar y Comprobar Dato en la Base de D ato s

Enviar Resultados

Mo strar Interfaz de Usuario Seleccionar Opción “Sitios Municipales” Emitir Proforma de Pago

FUENTE: [Elaboración Propia]

 Diagrama de clases. En los diagramas de clases, como se ilustra en la Figura Nº 63, muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Figura Nº 63 : Diagrama de clases: Ingresar a la página web (cuarta iteración). Usuario -Email: String -id: Int -login: String -password: String -persona: Persona

SitioMunicipal Persona -apellidoMaterno: String -apellidoPaterno: String -ci: String -direccion: String -id: int -nombre: String

Contribuyente -id: int -persona: Persona -sitioMunicipales: SitioMunicipales[]

FUENTE: [Elaboración Propia]

123 de 255

-codigoLic: String -descripcion: String -direccion: String -estado: String -fechaInicio: Date -pagos: Pagos[] -sindicato: String -superficie: int -tipo: String


 Diseño de interfaces. En la Figura Nº 64, se puede observar el diseño de la página principal de la web, en donde el contribuyente tendrá la información de la fecha límite para el pago de su patente, así como las entidades financieras a las cuales puede aproximarse para realizar el pago de su impuesto. Figura Nº 64 : Diseño de la página de inicio de la web (cuarta iteración).

FUENTE: [Elaboración Propia]

a) Diseño de interfaz de Ingreso a la página web En la Figura Nº 65, se puede observar el ingreso o autenticación del contribuyente a la página web, en donde el usuario tendrá que acceder mediante su cédula de identidad. Figura Nº 65 : Diseño de la interfaz de inicio de sesión de la web. (cuarta iteración).

FUENTE: [Elaboración Propia]

124 de 255


b) Diseño de la interfaz sitio municipal del contribuyente. Cuando el contribuyente inicia sesión mediante su Cédula de identidad, se habilita una pestaña denominada Sitio Municipal, como se muestra en la Figura Nº 66, en la cual se observa los sitios municipales que tiene el contribuyente. Figura Nº 66 : Diseño de la interfaz sitio municipal del contribuyente (cuarta iteración)

FUENTE: [Elaboración Propia]

c) Diseño de la interfaz de impresión de proforma de pago. El contribuyente puede acceder a ver el detalle de su patente, accediendo a cualquiera de los sitios municipales al cual es acreedor se puede visualizar la proforma de pago, como se muestra en la Figura Nº 67, donde tiene la opción de imprimir este documento.

125 de 255


Figura Nº 67 : Ventana sitio municipal del contribuyente (cuarta iteración)

FUENTE: [Elaboración Propia]

4. Modelo de implementación.  Diagrama de componentes. Un diagrama de componentes muestra la realización de un conjunto de interfaces, las cuales permiten implementar un componente utilizando componentes más pequeños, en la Figura Nº 68, se ilustra el diagrama de componentes de la página web. Figura Nº 68 :

Diagrama de componentes: Ingresar a la página web (cuarta iteración).

FUENTE: [Elaboración Propia]

126 de 255


 Implementación de las interfaces del módulo web para la obtención de proformas de pago. En la Figura Nº 69, se muestra la interfaz principal en la cual se encuentran 2 pestañas (Inicio e Ingresar), en la pestaña de inicio se observa las diferentes entidades financieras a la cual está sujeto el cobro de patentes, en la segunda pestaña el contribuyente se tiene que autenticar para ver el detalle de su patente según el sitio municipal. Figura Nº 69 : Interfaz menú principal (cuarta iteración).

FUENTE: [Elaboración Propia]

a) Interfaz de autenticación del contribuyente. Mediante la siguiente interfaz como se muestra en la Figura Nº 70, el contribuyente primeramente tiene que autenticarse mediante su cédula de identidad (C.I.), para ver el detalle de su patente dependiendo el número de sitios municipales que tenga el contribuyente.

127 de 255


Figura Nº 70 : Interfaz de autenticación del contribuyente. (cuarta iteración)

FUENTE: [Elaboración Propia]

b) Interfaz de sitio municipal del contribuyente. Cuando el contribuyente realizó la autenticación se habilita una nueva pestaña denominada “Sitios Municipales”, como se muestra en la Figura Nº 71, en la cual se muestra los sitios municipales que tiene el contribuyente, donde para cada sitio municipal existe un código de licencia, el cual es único. Figura Nº 71 : Interfaz del sitio municipal del contribuyente. (cuarta iteración)

FUENTE: [Elaboración Propia]

128 de 255


c) Interfaz del detalle de la patente e impresión de proforma de pago. Una vez seleccionado el sitio municipal, el contribuyente puede apreciar el detalle de su patente, con las gestiones pendientes a pagar y el monto por cada una de ellas, como se muestra en la Figura Nº 72. Para ilustrar como ejemplo se ingresará al primer sitio municipal. Figura Nº 72 : Interfaz de proforma de pago. (cuarta iteración)

FUENTE: [Elaboración Propia]

129 de 255


5. Modelo de pruebas. Para la cuarta iteración se realizó la prueba funcional del caso de uso Ingresar a la Página Web, la cual se describe en la Tabla Nº 13. Tabla Nº 13: Prueba funcional: Ingresar a la página web (cuarta iteración). Caso de prueba

Datos

Acción esperada

introducidos

Resultado

Se despliega en la página principal

la

pestaña

denominada

“Sitios

Municipales” en donde se

Satisfactorio

observa el sitio o los sitios del contribuyente.

El contribuyente tiene

que

a

Página Web.

la mediante

detalle

Identidad

de

pantalla las

el

gestiones

Satisfactorio

su de Existe

Carnet

en

deudoras del contribuyente

autenticarse Ingresar

Observar

una

(C.I.) denominada

pestaña “Ayuda”

en

oprimir

donde indica al contribuyente

“Ingresar”.

los pasos para obtener su

Satisfactorio

proforma de pago.

Si los datos introducidos son erróneos el sistema muestra mensaje de error.

FUENTE: [Elaboración Propia]

130 de 255

Satisfactorio


3.4 IDENTIFICACIÓN ENTIDADES

DE

LOS

REQUERIMIENTOS

FINANCIERAS

RESPECTO

A

DE LA

INTERMEDIACIÓN FINANCIERA. 3.4.1 Análisis de normas que establece la Autoridad de Supervisión del Sistema Financiero (ASFI), respecto a la intermediación financiera. Para realizar el enlace entre la entidad financiera y empresa se prioriza obtener los requerimientos necesarios que brinda la entidad bancaria. Estos requerimientos son normados por la Autoridad de Supervisión del Sistema Financiero (ASFI). El ASFI proporciona una serie de requisitos técnicos para el enlace entre ambas entidades a través de la intermediación financiera, esta última permite a la entidad bancaria realizar el cobro de servicios de impuestos (para tal caso el cobro de patentes) u otro tipo de servicios, como también indica que las instituciones o empresas externas que desean realizar este tipo de conexión con la entidad financiera, son denominadas proveedoras de tecnologías de información y para ello establece el ASFI la circular SB/466/2004 la cual hace referencia a los “REQUISITOS MÍNIMOS DE SEGURAD INFORMÁTICA”. A su vez existe la circular SB/443/2003 donde indica los requisitos técnicos de seguridad que la entidad financiera debe cumplir cuando emplea sistemas informáticos en sus instalaciones. (VER ANEXO G).

3.4.1.1 Aspectos de las clausulas a considerar en la intermediación según la circular SB/466/2004 Se han considerado las siguientes clausulas: •

Programas fuente: La alcaldía entregará los programas fuente

de la

herramienta que está en conjunto acuerdo con la entidad financiera. •

Propiedad intelectual: Una vez que se entregue la herramienta a la entidad financiera aclarando esta que la propiedad intelectual sobre la herramienta de cobro de patentes es exclusiva de quien lo haya desarrollado.

131 de 255


Plataforma de desarrollo: La plataforma de desarrollo utilizada en el sistema es la siguiente:

-

Servidor de la alcaldía : Windows x64

-

Sistema operativo: Windows

-

Lenguaje de Programación: C Sharp

-

El motor de base datos: MySQL 5.6.12

Formalización de recursos humanos: Cuando la entidad financiera lo requiera, se le brindará una hoja de vida de los funcionarios que participen en el servicio de soporte técnico y la actualización de la herramienta, si existiera.

Cronograma y plan de trabajo: Se asume presentar a la entidad financiera el respectivo cronograma de trabajo de cada solución de desarrollo de software.

Atrasos y riesgos: Establecimiento de multas por atraso de entregar la herramienta a la entidad financiera, también indemnización por daños y perjuicios en caso de fraudes o atentados cibernéticos.

Acceso remoto: El acceso a la réplica de la BD central de la Alcaldía por parte de la entidad financiera es remoto, Las normas de seguridad de esta conexión son descritas en el siguiente apartado.

3.4.1.2 Aspectos de seguridad en la intermediación financiera según la circular SB/466/2004 Los aspectos de seguridad que han sido considerados son los siguientes: •

Las políticas, normas y procedimientos de seguridad informática.Establecidas en el servidor de la Alcaldía mediante la herramienta a desarrollar.

Desarrollo de sistemas de información y programas: Efectuado por personal de la Alcaldía siguiendo el cronograma de plan de trabajo establecido.

Mantenimiento de sistemas y programas: Efectuado por personal de sistemas de la Alcaldía cada vez que lo vea conveniente

Seguridad física sala de servidores: Está a disposición del personal capacitado de la Alcaldía

Respaldos y recuperación de información: Se ha dispuesto de una base de datos réplica situada en el servidor de la Alcaldía.

132 de 255


Respaldo y recuperación de bases de datos: Misma disposición que en el anterior punto.

Control y políticas de administración de antivirus: Se ha dispuesto de una base de datos réplica situada en el servidor de la Alcaldía.

Administración de licencias de software y programas: La Alcaldía cuenta con las licencia del software que será otorgado a la entidad financiera y también del gestor de base de datos utilizado por el sistema.

Administración y control de equipos de seguridad: Se ha dispuesto de un firewall (software) que el filtre el acceso a la red del enlace en línea.

Así mismo es importante mencionar que es de responsabilidad de la entidad financiera, verificar la seguridad informática del proveedor a través de una metodología que cumpla con este objetivo.

3.4.1.3 Análisis y selección de entidad financiera. Mediante la aplicación de una encuesta realizada a entidades financieras (VER ANEXO G) se obtuvo ciertos puntos a considerar para la realización del enlace en línea, como se muestra en la Tabla Nº 14, la cual sustentara para la selección de la entidad financiera la cuál proporcionara el servicio financiero (de intermediación financiera) al Gobierno Autónomo Municipal de Cochabamba. Tabla Nº 14: Selección de entidad financiera. Criterio de selección

Cuenta bancaria.

Banco unión

Fondo Financiero Fassil

Se requiere la creación

Se requiere la creación de al

de al menos una cuenta

menos una cuenta de la

de la Alcaldía en el

Alcaldía en Fassil.

banco. • Constitución legal. • Personería jurídica.

Requerimientos legales

• Registro de comercio.

de la entidad financiera.

• Registro de inscripción al padrón de contribuyentes. • Documento de identificación del representante legal de

la alcaldía (Fotocopia). 133 de 255


Criterio de selección

Requerimientos económicos.

Banco unión

Fondo Financiero Fassil

La cuenta de la Alcaldía No hay restricción respecto al deberá poseer un monto mínimo en la cuenta de promedio de al menos 70 la Alcaldía mensualmente mil

dólares

mensualmente

Costo por transacción realizada.

No hay costo si el monto mínimo en la cuenta se mantiene mensualmente.

Costo por transacción es de 1 bs

FUENTE: [Elaboración Propia]

Mencionada la tabla del análisis de las entidades financieras, la opción más adecuada para realizar el enlace, tomando como referencia el costo por transacción realizada y los requerimientos económicos, se tiene como preferencia al Fondo Financiero Fassil.

3.4.1.4 Requerimientos para otorgar la intermediación financiera (Fondo Financiero Privado Fassil). De acuerdo al instructivo I007 del Fondo Financiero Privado Fassil considera la intermediación financiera según el nombre de “Sistema de recepción de pagos”. Para la adquisición de este servicio, la Alcaldía del Cercado debe entregar la siguiente documentación a Fassil: •

Constitución legal (Documentación legalizada de la escritura pública de la institución).

Registro de comercio (Documento que acredita el registro de la institución ante la organización Fundempresa).

Certificado de inscripción al padrón nacional de contribuyentes (Documento que acredita el registro de la institución en el Servicio de Impuestos Nacionales, el cuál le otorga un NIT del mismo).

Registro municipal (Documento que otorga la licencia de funcionamiento y certificación de apertura de la actividad económica de la institución).

Fotocopia de carnet de identidad legal del representante de la institución.

134 de 255


En lo que respecta a los requerimientos técnicos de la entidad financiera, son mencionados mediante una encuesta realizada a Fassil (VER ANEXO H).

3.4.1.5 Sistema de recepción de pagos La entidad financiera Fassil, por la prestación de este servicio cobra a la institución el monto de Bs 1.- Fassil realizará el cobro de patentes de la Alcaldía. La modalidad de pago para los contribuyentes es la de pago en ventanilla debido a la cantidad de puntos de cobros que tiene la entidad financiera. En esta modalidad de pago del contribuyente es: Contribuyente se aproxima al cajero de Fassil e indica el Código de licencia de la patente de esta manera el cajero consultará al sistema las gestiones que debe el contribuyente de su patente. Una vez realizado el pago le entregará el comprobante de pago correspondiente y el estado de pagos será actualizado.

3.4.2 Diseño de la arquitectura del enlace en línea. 3.4.2.1 Arquitectura cliente-servidor (entidad financiera y alcaldía). El enlace el cual brinda la intermediación financiera se basa principalmente en la arquitectura cliente servidor, el cual es un modelo de aplicación distribuida donde las transacciones se dividen en procesos independientes que cooperan entre sí para intercambiar información entre servidor (proveedor de recursos o servicios) y cliente (demandante que solicita servicios). En donde existen partes que conforman dicha arquitectura las cuales son:  Cliente. Es la herramienta de cobro de patentes que estará situada en las terminales (computadoras) de los funcionarios de caja en las diferentes agencias de la entidad financiera. Esta herramienta se conecta a través de la red de comunicaciones de la entidad financiera hacia la base de datos réplica gestionada por el servidor de Base de datos en la Alcaldía.  Servidor. El servidor permite la administración de la base de datos principal está situado en la Alcaldía. Este recibe las solicitudes enviadas por el lado del cliente (Entidad

135 de 255


Financiera) y almacena las transacciones en la base de datos. Como medida de seguridad se cuenta con una base de datos réplica que resguarda los datos de la base de datos principal.  Canal de comunicación. La conexión entre cliente y servidor es mediante un canal de datos dedicado. Es recomendable que el tipo de canal sea de fibra óptica para garantizar la rapidez de las transacciones enviadas de la entidad financiera a la Alcaldía. El protocolo usado en el canal de datos es TCP/IP. Estos tres elementos están relacionados con las tres partes del enlace en línea, de la siguiente manera:

Medio de registro de las transacciones  Cliente

Medio de almacenamiento de transacciones  Servidor

Medio de comunicación  Canal de comunicación

Así mismo la relación existente entre la arquitectura cliente/servidor y la intermediación financiera es la siguiente: •

Entidad financiera (cliente).

Empresa/institución (servidor).

Enlace en línea (Canal de comunicación entre cliente y servidor).

3.4.2.2 Esquema del enlace entre la entidad financiera y alcaldía. Para enfocar de manera clara el enlace en línea que permite la intermediación financiera a un nivel técnico, en la Figura Nº 73 se muestra un esquema que describe esta conexión y el envío de las transacciones de la entidad financiera hacia la Alcaldía.

136 de 255


Figura Nº 73 : Esquema del enlace entre la entidad financiera y alcaldía.

FUENTE: [Elaboración Propia]

137 de 255


3.5 DESARROLLO DE LA HERRAMIENTA DE COBRO DE PATENTES SITUADO EN LA ENTIDAD FINANCIERA. 3.5.1 Aplicación de la metodología elegida a la herramienta de cobro de patentes. Aplicando las fases las cuales se describen según la Figura Nº 18 en la sección 2.3.2.1 del Marco Teórico, se realizó la herramienta de cobro de patentes cumpliendo la metodología elegida.

3.5.1.1 Fase de inicio. Para la fase de inicio primeramente se estableció el modelado de negocio en cual se describe en la Página 93, y posteriormente se realización las iteraciones correspondientes aplicando los flujos de trabajo según UP. • Primera iteración: Autenticación de usuario cajero, administrador entidad financiera y administrador alcaldía. A continuación se detallarán los requerimientos funcionales y no funcionales para la primera iteración de la herramienta de cobro de patentes, así como la identificación de los actores y sus respectivos diagramas UML. • Análisis de requerimiento de la herramienta de cobro de patentes.  Requerimientos funcionales. •

Ingreso a la herramienta mediante un login y password, ingreso de la UFV actual del día por parte del cajero.

Conexión con la réplica de base datos situado en la alcaldía.

 Requerimientos no funcionales. •

La Herramienta de cobro de patentes utilizará un DBMS MySQL.

La Herramienta no debe demorar más de 5 segundos en mostrar los resultados de una búsqueda. Caso contrario se detendrá la búsqueda y se visualizará los resultados encontrados.

Utilizar arquitectura cliente servidor para estructurar el sistema.

138 de 255


1. Modelo de Casos de Uso.  Identificación de actores. Se denomina actor o actores a los usuarios que cumplen un determinado rol dentro del sistema. Para el desarrollo de la primera iteración de la herramienta de cobro de patentes, se identificaron los siguientes actores, ilustrados en la Figura Nº 74. Figura Nº 74 : Actores de la herramienta de cobro de patente: primera iteración

FUENTE: [Elaboración Propia]

 Descripción de actores. •

Administrador alcaldía: El administrador de la alcaldía accede a las funcionalidades de cobro de patentes mediante su cuenta de usuario.

Administrador entidad financiera: Es la persona encargada de ingresar mediante un login y password a la administración de la entidad financiera.

Cajero Entidad financiera: Es la persona encargada de ingresar a la herramienta de cobro de patentes mediante un login y password para realizar los cobros correspondientes y otras funcionalidades.

 Diagrama de Casos de Uso. En la Figura Nº 75, se muestra el diagrama de casos de uso del ingreso o autenticación del cajero de la entidad financiera, administrador de la entidad financiera como del administrador de la alcaldía a la herramienta de cobro de patente.

139 de 255


Caso de uso: Ingresar a la herramienta de cobro de patentes. Actor: Cajero entidad financiera, Administrador alcaldía, Administrador entidad financiera.

Figura Nº 75 : Caso de uso: Ingresar a la herramienta de cobro de patentes.

FUENTE: [Elaboración Propia]

Escenario de Casos de Uso: Ingresar a la herramienta de cobro de patentes. Tabla Nº 15: Escenario: Ingresar a la herramienta de cobro de patentes

Nombre:

Ingresar a la herramienta de cobro de patentes.

Actor:

Administrador alcaldía, Cajero entidad financiera, Administrador entidad financiera

Función:

Permite el acceso al administrador de la entidad financiera, cajero de la entidad financiera a la herramienta mediante la conexión con la réplica de Base de datos, y al Administrador de la Alcaldía mediante una conexión con la base de datos central.

Descripción: En este caso de uso se realiza la autenticación para ingresar a la herramienta mediante un login y password, ya sea el Administrador de la alcaldía, Cajero de la Entidad Financiera y Administrador de la entidad financiera. El cajero de la entidad financiera ingresa a la herramienta de cobro de patentes en primera instancia.

140 de 255


Descripción: El Administrador de la alcaldía podrá tener el acceso a la herramienta, para gestionar las entidades financieras, Gestionar los sitios municipales, realizar los reportes de los cobros realizados en las entidades financieras, así como verificar las gestiones de contribuyentes. El Administrador de la entidad financiera tendrá el acceso a la herramienta de cobro de patentes, para realizar reporte diario del cobro realizado en la entidad financiera, y en las sucursales. FUENTE: [Elaboración Propia]

2. Modelo de análisis.  Diagramas de colaboración. Los diagramas de colaboración muestran cómo el control pasa de un objeto a otro a medida que se lleva a cabo el caso de uso, y los mensajes que se envían entre los objetos. A continuación se describe el diagrama de colaboración ingresar a la herramienta de cobro de patentes, ilustrado en la Figura Nº 76. •

Caso de uso: Ingresar a la herramienta de cobro de patentes. Actor: Administrador alcaldía, Cajero entidad financiera, Administrador entidad financiera

Figura Nº 76 : Diagrama de colaboración: Ingresar a la herramienta de cobro de patentes.

FUENTE: [Elaboración Propia]

141 de 255


3. Modelo de diseño.  Diagramas de secuencia. Muestran la interacción de mensajes entre objetos en una secuencia temporal. Como se muestra en el diagrama de la Figura Nº 77. •

Ingresar a la herramienta de cobro de patentes

Figura Nº 77 : Diagrama de secuencia: Ingresar a la herramienta de cobro de patentes. : IU Ingreso a la Herramienta

:Gestor Usuario

:Replica de Base de Datos

Ingresar Nombre de usuario y contraseña Enviar Nombre de usuario y contraseña Enviar Nombre de usuario y contraseña

Cajero Entidad Financiera

Buscar Usuario y Contraseña Conexión mediante puerto 3306 MySQL Enviar Mensaje de Confirmacion

Mostrar Interfaz Herramienta de Cobranza Ingresar UF V

Enviar Mensaje: “Cuenta Aceptada”

Ingresar Nombre de usuario y contraseña

Administrador Entidad Financiera

Enviar Nombre de usuario y contraseña Enviar Nombre de usuario y contraseña

Buscar Usuario y Contraseña Conexión mediante puerto 3306 MySQL Enviar Mensaje de Confirmacion

Mostrar Interfaz de Administración de Entidad Financiera

Enviar Mensaje: “Cuenta Aceptada”

Ingresar Nombre de usuario y contraseña

Administrador Alcaldía

Enviar Nombre de usuario y contraseña Buscar Nombre de usuario y Contraseña

Mostrar Interfaz de Administración de la Alcaldía

Enviar Mensaje de Confirmación: “”Bienvenido Administrador”

FUENTE: [Elaboración Propia]

142 de 255

:Base de Datos


 Diagrama de clases. En los diagramas de clases, como se ilustra en la Figura Nº 78, muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Figura Nº 78 : Diagrama de clases: Ingresar a la herramienta de cobro de patentes.

Persona -apellidoMaterno: String -apellidoPaterno: String -ci: String -direccion: String -id: int -nombre: String

Contribuyente -id: int -persona: Persona -sitioMunicipales: SitioMunicipales[]

FUENTE: [Elaboración Propia]

 Diseño de interfaces. El diseño de la interfaz de la autenticación permite el acceso al cajero de la entidad financiera, en la Figura Nº 79, se muestra el diseño de la interfaz de autenticación. Figura Nº 79 : Diseño de la interfaz de autenticación.

FUENTE: [Elaboración Propia]

4. Modelo de implementación.  Diagrama de componentes. Un diagrama de componentes muestra la realización de un conjunto de interfaces, las cuales permiten implementar un componente utilizando componentes más pequeños, en la Figura Nº 80, se ilustra el diagrama de componentes de ingreso a la herramienta de cobro de patentes.

143 de 255


Figura Nº 80 : Diagrama de componentes: Ingresar a la herramienta de cobro de patentes.

FUENTE: [Elaboración Propia]

5. Modelo de pruebas. Para este modelo no se realizó ningún tipo de pruebas, ya que en esta etapa de inicio solo se refleja lo que corresponde a la información y según la metodología en dichas fases indica que no existe ninguna prueba.

3.5.1.2 Fase de elaboración. • Segunda iteración: Administración de cobro de patentes. A continuación se detallarán los requerimientos funcionales y no funcionales para la segunda iteración de la herramienta de cobro de patentes, así como la identificación de los actores y sus respectivos diagramas UML. • Análisis de requerimiento de la herramienta de cobro de patentes.  Requerimientos funcionales. •

Ingreso a la administración de la entidad financiera mediante un login y password del administrador de la entidad financiera.

Registro de contribuyentes para realizar alguna actividad comercial. 144 de 255


Gestionar los sitios municipales, crea sitios municipales modifica y eliminar, así como la asignación del sitio a otro contribuyente.

Generar datos para nueva gestión donde se ingresa datos para el cobro de la nueva gestión.

Generar reportes de los estados de los contribuyentes, así como de las entidades financieras

Gestionar las entidades financieras como asignación de número máximo de cajeros.

 Requerimientos no funcionales. •

La herramienta de cobro de patentes utilizará como gestor de base de datos MySQL.

La herramienta no debe demorar más de 5 segundos en mostrar los resultados de una búsqueda. Caso contrario se detendrá la búsqueda y se visualizará los resultados encontrados.

Utilizar arquitectura cliente servidor para estructurar el sistema.

1. Modelo de casos de uso.  Identificación de actores. Se denomina actor o actores a los usuarios que cumplen un determinado rol dentro del sistema. Para el desarrollo de la segunda iteración de la herramienta de cobro de patentes, se identificó el siguiente actor, ilustrado en la Figura Nº 81. Figura Nº 81 : Actores de la herramienta de cobro de patente: segunda iteración.

FUENTE: [Elaboración Propia]

145 de 255


 Descripción de actores. •

Administrador alcaldía: Es la persona encarga de la administración de cobro de patentes en la alcaldía, puede crear contribuyentes para que realice alguna actividad comercial, gestionar los sitios municipales, asignación de sitios municipales, así como reporte del estado de cuenta de los contribuyentes y reportes de las entidades financieras, también es encargado de gestionar las entidades financieras.

 Diagrama de casos de uso. En la Figura Nº 82, se muestra el diagrama de casos de uso administrar cobro de patentes, el cual lo realiza el administrador de la alcaldía. •

Caso de uso: Administrar cobro de patentes. Actor: Administrador Alcaldía. Figura Nº 82 : Caso de uso: Administrar cobro de patentes.

FUENTE: [Elaboración Propia]

146 de 255


Escenario de casos de uso: Administrar cobro de patentes. Tabla Nº 16: Escenario: Administrar cobro de patentes.

Nombre:

Administrar cobro de patentes.

Actor:

Administrador alcaldía.

Función:

Permitir el acceso a la administración de patentes al administrador de la alcaldía.

Descripción: El administrador de la alcaldía puede registrar contribuyentes, esto mediante trámites internos que se realizan en la Alcaldía de Cochabamba. Gestionar sitio municipal se refiere a que el administrador de la alcaldía puede verificar los sitios, si estos pertenecen algún contribuyente o se encuentran disponibles, en el caso de que se encuentre disponible puede asignar o transferir el sitio a otro contribuyente, así como también el administrador puede modificar y eliminar el sitio. Generar datos para nueva gestión se refiere a que el administrador de la alcaldía ingresa los nuevos datos para la nueva gestión, el sistema procesa los nuevos datos ya sea multas interés de la gestión anterior. Generar reporte de estados financieros del contribuyente se refiere a que se puede realizar la búsqueda del contribuyente y ver las gestiones que cancelo y las que no se pagaron. Generar reporte por entidad financiera incluye un detalle de los contribuyentes que realizaron el pago de la patente en dicha entidad financiera. El reporte se realiza por rango de fechas. Gestionar entidades financieras se refiere a que el administrador de la entidad financiera asigna la cantidad de cajeros necesarios a cada entidad financiera, así como habilitar e inhabilitar la entidad financiera. FUENTE: [Elaboración Propia]

147 de 255


2. Modelo de análisis  Diagrama de colaboración. Los diagramas de colaboración muestran cómo el control pasa de un objeto a otro a medida que se lleva a cabo el caso de uso, y los mensajes que se envían entre los objetos. A continuación se describe el diagrama de colaboración administrar cobro de patentes, ilustrado en la Figura Nº 83. •

Caso de uso: Administrar cobro de patentes. Actor: Administrador alcaldía.

Figura Nº 83 : Diagrama de colaboración: Administrar cobro de patentes.

FUENTE: [Elaboración Propia]

3. Modelo de diseño.  Diagrama secuencia. A continuación se presentan el diagrama de secuencia del caso de uso administrar cobro de patentes, con los objetos de diseño en una secuencia temporal como se muestra en la Figura Nº 84.

148 de 255


โ€ข

Administrar cobro de patentes Figura Nยบ 84 : Diagrama de secuencia: Administrar cobro de patentes.

FUENTE: [Elaboraciรณn Propia]

149 de 255


 Diagrama de clases. En los diagramas de clases, como se ilustra en la Figura Nº 85, muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Figura Nº 85 : Diagrama de clases: Administración de cobro de patentes. Usuario -Email: String -id: Int -login: String -password: String -persona: Persona

SitioMunicipal Persona -apellidoMaterno: -apellidoPaterno: -ci: String -direccion: String -id: int -nombre: String

String String

Contribuyente -id: int -persona: Persona -sitioMunicipales: SitioMunicipales[]

-codigoLic: String -descripcion: String -direccion: String -estado: String -fechaInicio: Date -pagos: Pagos[] -sindicato: String -superficie: int -tipo: String

Pago -cajero: Cajero -estado: String -fecha: Date -gestion: int -monto: Double -nroComprobante: int -patente: Patente -ufv: Ufv

FUENTE: [Elaboración Propia]

 Diseño de interfaces. El diseño de la interfaz de la administración de cobro de patente permite al administrador de la alcaldía poder visualizar reportes y demás funcionalidades como se muestra en la Figura Nº 86. Figura Nº 86 : Diseño de interfaz de la administración de cobro de patentes.

FUENTE: [Elaboración Propia]

150 de 255


4. Modelo de implementación  Diagrama de componentes. Un diagrama de componentes muestra la realización de un conjunto de interfaces, las cuales permiten implementar un componente utilizando componentes más pequeños, en la Figura Nº 87, se ilustra el diagrama de componentes de administrar cobro de patentes. Figura Nº 87 : Diagrama de componentes: Administrar cobro de patentes.

FUENTE: [Elaboración Propia]

 Implementación de la interfaz. En la Figura Nº 88, se observa la implementación de la interfaz del administrador de la alcaldía, en la que tiene varias funcionalidad entre ellas mencionamos: Administrar Entidades Financieras, Sitios Municipales, Reporte de Entidades Financieras, Reporte General de Entidades Financieras y Administrar Datos para la nueva Gestión de Cobro de Patentes.

151 de 255


Figura Nº 88 : Implementación de la interfaz del administrador de la alcaldía.

FUENTE: [Elaboración Propia]

5. Modelo de pruebas. Según la metodología UP en esta fase simplemente se describe las pruebas a utilizar. Estas son unitarias (en la siguiente fase) y funcionales en la fase de transición.

3.5.1.3 Fase de construcción. • Tercera iteración: Realizar cobro de patente. A continuación se detallarán los requerimientos funcionales y no funcionales para la tercera iteración de la herramienta de cobro de patentes, así como la identificación de los actores y sus respectivos diagramas UML.

152 de 255


• Análisis de requerimiento de la herramienta de cobro de patentes.  Requerimientos funcionales. •

Ingreso a la herramienta mediante un login y password.

Administración del cobro de patente supervisado por el administrador de la alcaldía.

Realizar el cobro de patentes con sus respectivas funcionalidades, administrado por el cajero de la entidad financiera.

Gestionar cajeros y sucursales supervisado por el administrador de la entidad financiera.

 Requerimientos no funcionales. •

La herramienta de cobro de patentes utilizará como gestor de base de datos MySQL.

La herramienta no debe demorar más de 5 segundos en mostrar los resultados de una búsqueda. Caso contrario se detendrá la búsqueda y se visualizará los resultados encontrados.

Utilizar arquitectura cliente servidor para estructurar el sistema.

1. Modelo de casos de uso.  Identificación de actores. Se denomina actor o actores a los usuarios que cumplen un determinado rol dentro del sistema. Para el desarrollo de la tercera Iteración de la herramienta de cobro de patentes, se identificó el siguiente actor, ilustrado en la Figura Nº 89. Figura Nº 89 : Actores de la herramienta de cobro de patente: tercera iteración.

FUENTE: [Elaboración Propia]

153 de 255


 Descripción de actores. •

Cajero entidad financiera: Es la persona cuya tarea es realizar el cobro de patentes de los contribuyentes mediante una interfaz de usuario, efectúa la búsqueda en la réplica de la base de datos donde verifica el estado de cuentas del contribuyente, esto se refiere a que puede ver las gestiones de la cual es deudor el contribuyente. También realiza un reporte al finalizar el día, denominado reporte de caja diario.

 Diagrama de casos de uso. En la Figura Nº 90, se muestra el diagrama de casos de uso realizar cobro de patentes, el cual lo realiza el cajero de la entidad financiera. •

Caso de uso: Realizar cobro de patente. Actor: Cajero entidad financiera. Figura Nº 90 : Caso de uso: Realizar cobro de patente.

FUENTE: [Elaboración Propia]

154 de 255


Escenario de casos de uso: Realizar cobro de patente.

Tabla Nº 17: Escenario: Realizar cobro de patente. Nombre:

Realizar cobro de patente.

Actor:

Cajero entidad financiera

Función:

Permitir el acceso a la interfaz de la herramienta de cobranza al cajero de la entidad financiera.

Descripción: El cajero de la entidad financiera tendrá el acceso a la interfaz de la herramienta para realizar la búsqueda del contribuyente que está cancelando su patente, mediante su código de licencia o nombre completo. Mostrar pagos pendientes verificara el sitio municipal y el detalle de este, así como las gestiones a la cual es deudor el contribuyente Procesar pago se refiere a que al cajero realiza el respectivo cobro de la patente el cual le lleva a la ventana del comprobante de pago, así también este puede cancelar la transacción. Cambiar número de comprobante según dosificación se refiere que el cajero puede ingresar la nueva numeración del comprobante, esto sucede cuando ya no exista dosificación, y el sistema realizará la numeración correlativamente según los cobros realizados. Emitir comprobante de pago al contribuyente de la gestión o gestiones que se canceló. Anular comprobante de pago se refiere a que el cajero puede anular un comprobante cuando se realizó una acción o cobro indebido. Generar reporte diario se refiere a que el cajero realiza su balance de caja finalizada la jornada de los contribuyentes que realizaron su pago en la respectiva caja. FUENTE: [Elaboración Propia]

155 de 255


2. Modelo de análisis.  Diagrama de colaboración. Los diagramas de colaboración muestran cómo el control pasa de un objeto a otro a medida que se lleva a cabo el caso de uso, y los mensajes que se envían entre los objetos. A continuación se describe el diagrama de colaboración realizar cobro de patentes, ilustrado en la Figura Nº 91. •

Caso de uso: Realizar cobro de patentes Actor: Cajero entidad financiera Figura Nº 91 : Diagrama de colaboración: Realizar cobro de patentes

FUENTE: [Elaboración Propia]

156 de 255


3. Modelo de diseño  Diagrama secuencia. A continuación se presentan el diagrama de secuencia del caso de uso realizar cobro de patentes, con los objetos de diseño en una secuencia temporal como se muestra en la Figura Nº 92. Figura Nº 92 : Diagrama de secuencia: Realizar cobro de patentes.

FUENTE: [Elaboración Propia]

157 de 255


 Diagrama de clases. En los diagramas de clases, como se ilustra en la Figura Nº 93, muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Figura Nº 93 : Diagrama de clases: Administración de cobro de patentes. Usuario -Email: String -id: Int -login: String -password: String -persona: Persona

SitioMunicipal Persona -apellidoMaterno: String -apellidoPaterno: String -ci: String -direccion: String -id: int -nombre: String

Contribuyente -id: int -persona: Persona -sitioMunicipales: SitioMunicipales[]

-codigoLic: String -descripcion: String -direccion: String -estado: String -fechaInicio: Date -pagos: Pagos[] -sindicato: String -superficie: int -tipo: String

Pago Cajero -id: int -persona: Persona

-cajero: Cajero -estado: String -fecha: Date -gestion: int -monto: Double -nroComprobante: int -patente: Patente -ufv: Ufv

Ufv -fecha: Date -monto: Double

EntidadFinanciera -id: int -nit: String -nombre: String

ImpuestoPatente

Patente -gestion: int -impuestosDefinidos: ImpuestoPatente []

FUENTE: [Elaboración Propia]

158 de 255

-costo: double -superficie: int


 Diseño de interfaces. Esta interfaz permite al cajero realizar el cobro del contribuyente mediante la búsqueda según criterio de: código de licencia o nombre, como se muestra en la Figura Nº 94. Figura Nº 94 : Diseño de la interfaz: menú principal.

FUENTE: [Elaboración Propia]

Mediante esta interfaz el cajero de la entidad financiera realiza la emisión del comprobante de pago, como se muestra en la Figura Nº 95. Figura Nº 95 : Diseño de la interfaz de proceso de pago y emisión de comprobante.

FUENTE: [Elaboración Propia]

159 de 255


4. Modelo de implementación  Diagrama de componentes. Un diagrama de componentes muestra la realización de un conjunto de interfaces, las cuales permiten implementar un componente utilizando componentes más pequeños, en la Figura Nº 96, se ilustra el diagrama de componentes de realizar cobro de patentes. Figura Nº 96 : Diagrama de componente: Realizar cobro de patentes

FUENTE: [Elaboración Propia]

 Implementación de la interfaz. En la Figura Nº 97, se observa la implementación de la interfaz del cajero de la entidad financiera, en la que tiene varias funcionalidades entre ellas mencionamos: Realizar cobro de patentes, cambiar el número de dosificación, anular comprobante de pago, Realizar reporte de caja diario.

160 de 255


Figura Nº 97 : Implementación de la interfaz de realizar cobro de patentes.

FUENTE: [Elaboración Propia]

5. Modelo de pruebas. Para la Tercera iteración se realizó la prueba funcional del caso de uso Realizar Cobro de Patentes, la cual se describe en la Tabla Nº 18. Tabla Nº 18: Prueba funcional: Realizar cobro de patentes (tercera iteración) Caso de prueba

Datos introducidos

Acción esperada

El cajero de la Entidad Financiera realiza la Realizar Cobro de Patente.

Muestra

en

Resultado

pantalla

el

detalle del sitio a la cual es Satisfactorio

búsqueda del

acreedor el contribuyente

contribuyente mediante su Código de Licencia, presiona “Buscar” para mostrar resultado.

Seguidamente se muestra las

gestiones

que

debe

según el sitio municipal del contribuyente

161 de 255

Satisfactorio


Caso de prueba

Datos introducidos

Acción esperada Efectúa

el

cobro

de

Resultado la

gestión y se registra la

Satisfactorio

transacción. Se Emite un comprobante de pago según a la gestión que

Satisfactorio

se cancelo Los datos de búsqueda tiene que

ser

mínimo

de

5

caracteres caso contrario se

Satisfactorio

muestra un mensaje de error FUENTE: [Elaboración Propia]

• Cuarta iteración: Realizar pagos e integración de la herramienta de cobro de patentes. A continuación se detallarán los requerimientos funcionales y no funcionales para la cuarta iteración de la herramienta de cobro de patentes, así como la identificación de los actores y sus respectivos diagramas UML. • Análisis de requerimiento de la herramienta de cobro de patentes.  Requerimientos funcionales. •

Crear Sucursales de la entidad financiera

Crea cajeros para las sucursales, tomando en cuenta el número de cajeros asignados por el administrador de la alcaldía.

Modifica sucursales y cajeros.

Habilita e inhabilita sucursales y cajeros.

Conexión con la réplica de base datos situado en la alcaldía.

162 de 255


 Requerimientos no funcionales. •

La herramienta de cobro de patentes utilizará como gestor de base de datos MySQL.

La herramienta no debe demorar más de 5 segundos en mostrar los resultados de una búsqueda. Caso contrario se detendrá la búsqueda y se visualizará los resultados encontrados.

Utilizar arquitectura cliente servidor para estructurar el sistema.

1. Modelo de casos de uso.  Identificación de actores. Se denomina actor o actores a los usuarios que cumplen un determinado rol dentro del sistema. Para la integración de la herramienta de cobro de patentes, se identificaron los siguientes actores, ilustrados en la Figura Nº 98. Figura Nº 98 : Actores de la herramienta de cobro de patente: cuarta iteración.

FUENTE: [Elaboración Propia]

 Descripción de actores. •

Administrador alcaldía: El administrador de la alcaldía es la persona encargada de administrar la herramienta de cobro de patentes en su totalidad, el cual realiza tareas tales como: -

Registrar contribuyentes.

-

Gestionar sitios municipales.

-

Transferir sitio municipal.

-

Generar pagos por gestión.

-

Generar reporte de estados financieros del contribuyente.

-

Generar reporte por entidad financiera.

-

Gestionar entidades financieras.

163 de 255


Administrador entidad financiera: Es la persona encargada administrar en su conjunto las sucursales cajeros y sobre todo los pagos que se efectuaron en la entidad financiera, realizando tareas tales como:

-

Crear Cajeros y sucursales.

-

Modificar, eliminar cajero y sucursales.

-

Realizar reporte por sucursales y cajeros.

-

Efectuar un reporte del monto recaudado en el día.

Cajero entidad financiera: Es la persona encargada de ingresar a la herramienta de cobro de patentes mediante un login y password para realizar los cobros correspondientes, el cual tiene tareas tales como: -

Buscar sitio municipal por código de licencia

-

Verificar estado de cuenta del contribuyente mostrando las gestiones que no fueron pagadas.

-

Realizar el cobro, con las opciones de cancelar transacción y anular comprobante.

-

Realiza el cambio del número de comprobante para el cambio de dosificación.

-

Realizar un reporte diario de caja mediante las funcionalidades de la herramienta.

Contribuyente: Es la persona encargada de ingresar a la página web, y tener conocimiento de su estado de cuentas de la patente, realiza tareas dentro de la página web tales como: -

Ingresa a la página web mediante el número de Cédula de Identidad (C.I.).

-

Se informa mediante la página web a cerca de las fechas límites de cancelación de la patente.

-

Verifica su estado de cuentas de acuerdo al número de sitios que dispone.

Puede efectuar la impresión del detalle de su estado de cuentas denominado (Proforma de Pago). 164 de 255


CambEm GenerMoARaC HCompr IAsigna nEfCompe<<E<<ICajbi<<GenecticlGeuiGtMAa<n<T Su C <<I n < << T I

 Diagrama de casos de uso.

<<CModirCr<eaPe<rrfEIa

En la Figura Nº 99, se muestra el diagrama de casos de uso general de la herramienta de cobro de patentes así como del módulo web. Figura Nº 99 : Diagrama de casos de uso general.

Modifi

FUENTE: [Elaboración Propia]

165 de 255


2. Modelo de análisis.  Diagrama de colaboración. Los diagramas de colaboración muestran cómo el control pasa de un objeto a otro a medida que se lleva a cabo el caso de uso, y los mensajes que se envían entre los objetos. A continuación se describe el diagrama de colaboración administrador cobro de patentes, ilustrado en la Figura Nº 100 y realizar cobro de patentes ilustrado en la Figura Nº 101. Figura Nº 100 : Diagrama de colaboración: Administrar cobro de patentes.

FUENTE: [Elaboración Propia]

Figura Nº 101 : Diagrama de colaboración: Realizar cobro de patentes

FUENTE: [Elaboración Propia]

166 de 255


3. Modelo de diseño.  Diagrama secuencia. A continuación se presentan el diagrama de secuencia del caso de uso administrador cobro de patentes, ilustrado en la Figura Nº 102 y realizar cobro de patentes ilustrado en la Figura 103., con los objetos de diseño en una secuencia temporal. Figura Nº 102 : Diagrama de secuencia: Administrar cobro de patentes.

FUENTE: [Elaboración Propia]

167 de 255


Figura N潞 103 : Diagrama de secuencia: Realizar cobro de patentes.

FUENTE: [Elaboraci贸n Propia]

168 de 255


 Diagrama de clases general. En los diagramas de clases, como se ilustra en la Figura Nº 104, muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Figura Nº 104 : Diagrama de clases general. Usuario -Email: String -id: Int -login: String -password: String -persona: Persona

SitioMunicipal Persona -apellidoMaterno: String -apellidoPaterno: String -ci: String -direccion: String -id: int -nombre: String

Contribuyente -id: int -persona: Persona -sitioMunicipales: SitioMunicipales[]

-codigoLic: String -descripcion: String -direccion: String -estado: String -fechaInicio: Date -pagos: Pagos[] -sindicato: String -superficie: int -tipo: String

Pago Cajero -id: int -persona: Persona

-cajero: Cajero -estado: String -fecha: Date -gestion: int -monto: Double -nroComprobante: int -patente: Patente -ufv: Ufv

Ufv -fecha: Date -monto: Double

EntidadFinanciera -id: int -nit: String -nombre: String

ImpuestoPatente

Patente -gestion: int -impuestosDefinidos: ImpuestoPatente []

FUENTE: [Elaboración Propia]

 Diseño de la base de datos. 169 de 255

-costo: double -superficie: int


A continuación se muestra en la Figura Nº 105, el diseño de la base de datos con sus respectivas relaciones entre tablas. Figura Nº 105 : Diseño de la base de datos.

FUENTE: [Elaboración Propia]

 Diseño de interfaces. 170 de 255


El diseño de la interfaz de la autenticación permite el acceso al cajero de la entidad financiera, en la Figura Nº 106, se muestra el diseño de la interfaz de autenticación. Figura Nº 106 : Diseño de la interfaz de autenticación.

FUENTE: [Elaboración Propia]

El diseño de la interfaz de la administración de cobro de patente permite al administrador de la alcaldía poder visualizar reportes y demás funcionalidades como se muestra en la Figura Nº 107. Figura Nº 107 : Diseño de interfaz de la administración de cobro de patentes.

FUENTE: [Elaboración Propia]

Esta interfaz permite al cajero realizar el cobro del contribuyente mediante la búsqueda según criterio de: código de licencia o nombre, como se muestra en la Figura Nº 108. Figura Nº 108 : Diseño de la interfaz: menú principal.

171 de 255


FUENTE: [Elaboración Propia]

Mediante esta interfaz el cajero de la entidad financiera realiza la emisión del comprobante de pago, como se muestra en la Figura Nº 109. Figura Nº 109 : Diseño de la interfaz de proceso de pago y emisión de comprobante.

FUENTE: [Elaboración Propia]

4. Modelo de implementación.

172 de 255


 Diagrama de componentes. Un diagrama de componentes muestra la realización de un conjunto de interfaces, las cuales permiten implementar un componente utilizando componentes más pequeños, en la Figura Nº 110, se ilustra el diagrama de componentes general de la herramienta de cobro de patentes y el módulo web. Figura Nº 110 : Diagrama de componente: Gestionar cajeros y sucursales.

FUENTE: [Elaboración Propia]

 Análisis del lenguaje de programación para la herramienta de cobro de patente. 173 de 255


Para la selección del lenguaje de programación, se muestra en la Tabla Nº 19 las características más relevantes para la identificación del lenguaje a utilizar en el presente trabajo. Tabla Nº 19: Selección del lenguaje de programación para la herramienta de cobro de patentes.

FUENTE: [Elaboración Propia]

Considerando las características y criterio de ponderación, se ha determinado que el lenguaje de programación C Sharp es el adecuado para el desarrollo del presente trabajo.  Implementación de la interfaz de la herramienta de cobro de patentes.

174 de 255


• Interfaz de autenticación la herramienta de cobro de patentes. Para la autenticación a la herramienta de cobro de patentes se tiene 3 usuarios, cajero de la entidad financiera, Administrador de la entidad financiera y Administrador de la Alcaldía. a) Cajero. En esta interfaz se muestra el acceso que tiene el cajero la entidad financiera a través de un Login y Password, en la Figura Nº 111, se ilustra la interfaz de autenticación para el ingreso a la herramienta de cobro de patentes, como ejemplo se tomó en cuenta el usuario N.LOPEZ el cual es un cajero de la entidad financiera. Figura Nº 111 : Autenticación de cajero a la herramienta de cobro de patentes.

FUENTE: [Elaboración Propia]

Ingreso de la UFV por el cajero de la entidad financiera. Una vez que se realizó la autenticación el cajero tiene que ingresar la UFV actual del día, como se observa en la Figura Nº 112. Figura Nº 112 : Ingreso de la UFV.

FUENTE: [Elaboración Propia]

b) Administrador entidad financiera.

175 de 255


En esta interfaz se muestra el acceso que tiene el administrador de la entidad financiera a través de un Login y Password, a diferencia del cajero se muestra como ejemplo a un usuario el cual es perteneciente al administrador de la entidad financiera, en la Figura Nº 113, se ilustra la autenticación del administrador de la entidad financiera para el ingreso a la herramienta de cobro de patentes. Figura Nº 113 : Autenticación del administrador de la entidad financiera a la herramienta de cobro de patentes.

FUENTE: [Elaboración Propia]

c) Administrador alcaldía. En esta interfaz se muestra el acceso que tiene el administrador de la alcaldía a través de un Login y Password, como se observa en la Figura Nº 114 se ilustra la autenticación del usuario ADMIN.ALCALDIA para el ingreso a la administración de cobro de patentes. Figura Nº 114 : Autenticación del administrador de la alcaldía a la herramienta de cobro de patentes.

FUENTE: [Elaboración Propia]

• Interfaces del usuario cajero. 176 de 255


a) Interfaz menú principal. Una vez que el cajero de la entidad financiera ingreso la UFV, se muestra la interfaz principal de la herramienta de cobro de patentes, en la cual se tiene los parámetro de búsqueda del contribuyente, ya sea mediante su código de licencia o bien su nombre completo, como ejemplo realizamos la búsqueda del contribuyente Rodrigo Gutiérrez Chávez en donde se visualiza los sitios municipales al que es acreedor, como se muestra en la Figura Nº 115, seleccionamos alguno de los sitios y aparece en la tabla de “Pagos Pendientes” las gestiones pendientes a cancelar, seleccionamos las gestiones que desea cancelar la contribuyente y oprimimos la opción “Pagar”, la cual nos lleva a la interfaz de proceso de pago y emisión de comprobante, la cual se detalla en el siguiente punto. Figura Nº 115 : Interfaz menú principal.

FUENTE: [Elaboración Propia]

b) Interfaz de proceso de pago y emisión de comprobante. 177 de 255


En esta interfaz como se muestra en la Figura Nº 116, se realiza el proceso de pago del contribuyente, mostrando en pantalla un comprobante con el detalle del contribuyente y las gestiones o gestión que está cancelando, concepto, monto, etc. Para posteriormente emitir el comprobante de pago. Figura Nº 116 : Interfaz de proceso de pago y emisión de comprobante.

FUENTE: [Elaboración Propia]

Seleccionando la opción de “Procesar Pago” se registran los datos en la réplica y posteriormente se actualiza estos mismos datos en la Base de Datos central (Alcaldía), el mismo detalle se puede observar en el ANEXO I.

178 de 255


c) Interfaz de reporte de caja diario. En la Figura Nº 117, se puede observar la interfaz del reporte del cajero, en donde se observa el detalle de los cobros que realizó durante el día, así como el detalle de los comprobantes anulados Figura Nº 117 : Interfaz de reporte diario de cajero

FUENTE: [Elaboración Propia]

• Interfaces del usuario administrador entidad financiera.

a) Interfaz menú principal administrador entidad financiera. 179 de 255


Una vez que el administrador de la entidad financiera se autentico se muestra una interfaz en la cual se describen las sucursales y los cajeros con las que cuenta la entidad financiera, como se ilustra en la Figura Nº 118. Figura Nº 118 : Interfaz de administrador de entidad financiera.

FUENTE: [Elaboración Propia]

b) Interfaz de reporte de entidad financiera por sucursales y rango de fechas. Dentro de la interfaz de administración de entidad financiera existe la opción “Reporte de Entidad Financiera” en la cual seleccionando la opción y se muestra un reporte de los pagos realizados en la entidad financiera, así como el detalle general de los cobros realizados en la entidad financiera, ilustrado en la Figura Nº 119.

Figura Nº 119 : Reporte de los pagos realizados en la entidad financiera.

180 de 255


FUENTE: [Elaboración Propia]

• Interfaces del usuario administrador de la alcaldía.

181 de 255


a) Interfaz menú principal administrador alcaldía. Una vez realizada la autenticación del administrador de la Alcaldía, se muestra la interfaz de administración de cobro de patentes en la cual se describen las entidades financieras y el administrador a cargo de la entidad bancaria, como se muestra en la Figura Nº 120, también se visualizan otras opciones tales como nuevo, modificar y eliminar dichas entidades financiera, entre otras funcionalidades las cuales son explicadas en los siguientes puntos. Figura Nº 120 : Interfaz del administrador de la alcaldía.

FUENTE: [Elaboración Propia]

b)

Interfaz sitios municipales.

182 de 255


Como se indicó en el párrafo anterior se observa en la Figura Nº 121 la interfaz de “Sitios Municipales”, en el cual ingresando el nombre del contribuyente o su código de licencia accedemos a visualizar los sitios correspondientes, una de las opciones para esta interfaz es de “Asignar Contribuyente” esto quiere decir que un sitio puede ser transferido a otro contribuyente tomando encuentra las deudas y demás parámetros al momento de realizar la asignación del sitio a un contribuyente, también se observa la opción de “Ver estado de cuentas”, la cual consiste básicamente en visualizar el detalle de cuentas del contribuyente. Figura Nº 121 : Interfaz de sitios municipales.

FUENTE: [Elaboración Propia]

c) Interfaz de reporte detallado de entidades financieras.

183 de 255


En esta interfaz el administrador de la Alcaldía puede visualizar los reportes detallada de las entidades financieras dentro de un rango de fechas, en la Figura Nº 122 se ilustra el detalle de reportes del Banco Unión. Figura Nº 122 : Reporte detallado de entidades financieras.

FUENTE: [Elaboración Propia]

d) Interfaz de reporte general de entidades financieras. 184 de 255


Mediante esta interfaz se visualiza los reportes por entidad financiera, describiendo el monto total que se recaudó en la entidad bancaria, en la Figura Nº 123 se observa el reporte general de las entidades financieras tales como: Banco de Crédito, Banco Sol, Banco Unión y Fondo Financiero Privado Fassil. Figura Nº 123 : Reporte general de entidades financieras.

FUENTE: [Elaboración Propia]

e) Interfaz de registro de contribuyentes. En esta interfaz se puede realizar el registro de un nuevo contribuyente, así también la modificación de sus datos principales del contribuyente, en la Figura Nº 124 se ilustra la interfaz de creación, modificación y eliminación del contribuyente. Figura Nº 124 : Interfaz de registro de contribuyentes. 185 de 255


FUENTE: [Elaboración Propia]

 Implementación de la seguridad del enlace en línea entre entidad financiera y Alcaldía. Como primer parámetro a tomar se realizó la conexión mediante el acceso a la base de datos de la Alcaldía. •

Connection Server = 192.168.3.10 (IP del servidor)

Database = cobranza_patentes (Base de datos)

User ID = root; Password = root (cuenta de acceso a la base de datos).

Security = true encrypt (Encriptación de datos) Port: 18566 SSH

1. Seguridad al módulo web mediante SSL y HTTPS.

186 de 255


Para realizar la seguridad al módulo web primeramente se realizaron configuraciones tales como activar ssl y https, descritas con más detalle en el ANEXO F. En la Figura Nº 125 se ilustra la seguridad de la página web con HTTPS. Figura Nº 125 : Activación SSL y HTTPS al módulo web.

FUENTE: [Elaboración Propia]

De igual manera se puede observar el detalle de la conexión, la activación satisfactoria de HTTPS, ingresando a las opciones de dato del certificado se puede observar los datos del certificado firmado, como se muestra en la figura Nº 126. Figura Nº 126 : Certificado SSL del módulo web.

FUENTE: [Elaboración Propia]

187 de 255


2. Medidas de seguridad de la intermediación financiera para el enlace en línea entre entidad financiera y Alcaldía. Para realizar la seguridad de la entidad financiera y empresa se aplicaron las medidas de seguridad bajo la ISO/IEC 17799/2005 “Gestión de seguridad de la información”, en la cual trata sobre “Transacciones en Línea”, mencionadas en el presente estándar, para tal efecto se consideraron los siguientes puntos los cuales de detallan en el ANEXO I. Así también se realizó un análisis sobre los aspectos de seguridad que indica la circular SB/466/2004, se determinó los siguientes puntos descritos en la circular a cerca de enlace en línea bajo la intermediación financiera los que se describen en el punto 3.4.1.2 y aplicados en la implementación de la seguridad de la siguiente forma: A) Las políticas, normas y procedimientos de seguridad informática.- Para el acceso a la herramienta de cobro de patentes se estableció diferentes roles de usuario tales como:  Cajero Entidad Financiera.  Administrador Entidad Financiera.  Administrador Alcaldía. •

La configuración del cifrado de contraseñas esta implementada en la herramienta de cobro de patentes. ANEXO I.

La conexión entre la entidad financiera y alcaldía deben encontrarse encriptada a nivel de base datos, para ver más detalles ver ANEXO I

El uso del firewall y las reglas deben ser considerados en ambas partes, tanto en la entidad financiera y Alcaldía.

La Alcaldía puede tener un firewall ya sea hardware o software, mediante el cuál pueda configurar reglas de entrada para la recepción de transacciones efectuadas en la entidad financiera. Las reglas de entrada que deben ser configuradas en el firewall del Alcaldía son las siguientes:  Permitir acceso a las IP entrantes de la entidad financiera hacia el servidor de la alcaldía.

188 de 255


 Permitir las solicitudes entrantes de la entidad financiera de tipo TCP en los puertos 3309, 3306, 1954 y de tipo UDP en el puerto 3300. Estos puertos permiten el acceso a la base de datos de la Alcaldía. •

El Administrador del Alcaldía tiene el acceso a una interfaz en la herramienta de cobro de patentes, en la cual puede realizar consultas hacia los logs de la base de datos (pistas de auditoria). En la Figura Nº 127, se observa la interfaz de logs de la herramienta de cobro de patentes. Figura Nº 127 : Interfaz de logs de la herramienta de cobro de patentes

FUENTE: [Elaboración Propia]

189 de 255


3. Políticas de seguridad en usuarios. Para tener acceso a la herramienta de cobro de patentes se estableció diferentes funcionalidades dependiendo al tipo de usuario, donde cada uno tiene diferentes opciones para el manejo de la herramienta así como privilegios diferentes. •

Administrador alcaldía: Encargado de manipular la herramienta de cobro de patentes. Tiene acceso a las funcionalidades de: -

Registrar Contribuyentes.

-

Gestionar Sitios Municipales. (Asignación de sitios a contribuyentes, Visualización de Estado Financieros de Contribuyente).

-

Gestionar Entidades Financieras (Asignación de un administrador por cada entidad financiera).

Generar Reporte de Entidades Financieras.

Administrador de entidad financiera: Encargado de la administración de la entidad financiera. Tiene acceso a las siguientes funcionalidades: -

Gestionar Sucursales y Cajeros (Creación de cajeros para las diferentes sucursales).

-

Reporte de pagos efectuados la entidad financiera por rango de fechas y por sucursal.

Cajero de entidad financiera: Encargado de registrar los pagos de cobro de patentes mediante la herramienta. Tiene acceso a las siguientes funciones: -

Búsqueda del contribuyente mediante su código de licencia o nombre completo.

-

Muestra sitios y pagos pendientes para posteriormente efectuar el pago.

-

Cambio de dosificación en caso de culminación o escases de comprobantes.

-

Emitir comprobante de pago según las gestiones canceladas.

-

Anulación del comprobante en caso de fallos personales o de terceros.

-

Reporte de caja diario efectuado por el cajero.

Según la Circular SB/466/2004 establece las políticas de usuarios, para lo cual se utilizó la siguiente política en la creación de contraseñas para el acceso a la herramienta de cobro de patentes.

190 de 255


 Tamaño mínimo de caracteres: 8  Establecimiento de al menos 1 caracteres alfa numérico (carácter especial y números).  Aplicación de letra mayúscula.  Contraseña debe ser diferente al login o nombre de usuario evitando secuencia de teclado (Ejemplo: asd, qwr, zxc, 123, etc).  Contraseña encriptada en la base datos. 5. Modelo de pruebas. Para la Tercera iteración se realizó las pruebas unitarias a la herramienta de cobro de patentes. Las pruebas unitarias consisten en aplicar determinadas pruebas a distintas acciones o métodos que se ejecutan en la herramienta, al ser orientado a objetos, las pruebas unitarias se aplican a cada clase. Para ello se realizó las pruebas unitarias a la herramienta de cobro de patentes. • Pruebas unitarias (herramienta de cobro de patentes) Se realizaron las pruebas unitarias a la herramienta de cobro de patentes, considerando principalmente las clases más importantes dentro la herramienta para lo cual en la Tabla Nº 20 se muestra la descripción de las pruebas realizadas y a continuación se muestra las clases depuradas por el framework NUnit. Tabla Nº 20: Pruebas unitarias Tipo de prueba

Clase

Descripción Extraer

Unitaria

PagoControl

todos

los

datos

Observaciones para

realizar el pago correspondiente

Ninguna.

del contribuyente Insertar los pagos efectuados, Unitaria

InsertNuevoPago

mediante los datos extraídos de la anterior clase

191 de 255

Datos

a

considerar de la Base de Datos


Tipo de prueba

Clase

Descripción

Observaciones

Describir que numero de pago está Unitaria

PagoById

siendo realizo y mediante que id de

Ninguna.

cajero se está cobrando

Unitaria

ProcesarPagos

Registrar los datos según el id del cajero

Ninguna.

FUENTE: [Elaboración propia]

Estas clases son sometidas a depuramiento mediante el framework NUnit, mencionado anteriormente, en la Figura Nº 128, se muestra que pasaron las unidades de prueba satisfactoriamente. Figura Nº 128 : Pruebas unitarias mediante Framework NUnit

FUENTE: [Elaboración Propia]

192 de 255


3.5.1.4 Fase de transición. • Quinta iteración: Realizar reportes y pruebas. A continuación se detallarán los requerimientos funcionales y no funcionales para la quinta iteración de la herramienta de cobro de patentes, así como la identificación de los actores y sus respectivos diagramas UML. • Análisis de requerimiento de la herramienta de cobro de patentes.  Requerimientos funcionales. •

Realizar reporte de la entidad financiera.

Reporte de contribuyentes que pagaron en la entidad financiera

Reporte por cajeros.

Reporte del monto que se recaudó en el día

Conexión con la réplica de base datos situado en la alcaldía.

 Requerimientos no funcionales. •

La herramienta de cobro de patentes utilizará como gestor de base de datos MySQL.

La herramienta no debe demorar más de 5 segundos en mostrar los resultados de una búsqueda. Caso contrario se detendrá la búsqueda y se visualizará los resultados encontrados.

Utilizar arquitectura cliente servidor para estructurar el sistema.

1. Modelo de casos de uso.  Identificación de actores. Se denomina actor o actores a los usuarios que cumplen un determinado rol dentro del sistema. Para el desarrollo de la quinta iteración de la herramienta de cobro de patentes, se identificó el siguiente actor, ilustrado en la Figura Nº 129.

193 de 255


Figura Nº 129 : Actores de la herramienta de cobro de patente: quinta iteración

FUENTE: [Elaboración Propia]

 Descripción de actores. •

Administrador entidad financiera: Es la persona encargada de realizar reportes de patentes, ya sea de los pagos realizados en las sucursales, reporte por cajeros, y tener un estimado de cuanto se recaudó durante el día.

 Diagrama de casos de uso. En la Figura Nº 130, se muestra el diagrama de casos de uso gestionar reporte de patentes Gestionar Cajeros y Sucursales, el cual lo realiza el administrador de la entidad financiera. Actor: Administrador entidad financiera, Administrador alcaldía. Figura Nº 130 : Caso de uso: Gestionar reporte de patentes.

FUENTE: [Elaboración Propia]

194 de 255


Escenario de casos de uso: Gestionar reporte de patentes.

Tabla Nº 21: Escenario: Gestionar reporte de patentes. Nombre:

Gestionar reporte de patentes.

Actor:

Administrador entidad financiera.

Función:

Administrador entidad financiera emite reportes de pagos realizados en el día.

Descripción: El Administrador de la Entidad Financiera realiza reportes de los contribuyentes que pagaron su impuesto en la entidad financiera, así como en las sucursales, también realiza un reporte por cada sucursal y por cada cajero, además realiza un reporte general del monto que se recaudó en la entidad financiera y sucursales. FUENTE: [Elaboración Propia]

Escenario de casos de uso: Gestionar cajero y sucursales. Tabla Nº 22: Escenario: Gestionar cajero y sucursales.

Nombre:

Gestionar cajero y sucursales.

Actor:

Administrador entidad financiera.

Función:

El administrador de la entidad financiera crea sucursales y distribuye cajeros a cada sucursal.

Descripción: El Administrador de la Entidad Financiera puede crear sucursales en las cuales distribuye los cajeros que fueron asignados por el administrador de la alcaldía a las distintas sucursales. Con las opciones de modificar y eliminar cajeros y sucursales, así como habilitar e inhabilitar. FUENTE: [Elaboración Propia]

195 de 255


2. Modelo de análisis.  Diagrama de colaboración. Los diagramas de colaboración muestran cómo el control pasa de un objeto a otro a medida que se lleva a cabo el caso de uso, y los mensajes que se envían entre los objetos. A continuación se describe el diagrama de colaboración gestionar reporte de patentes, ilustrado en la Figura Nº 131 y Gestionar Cajeros y Sucursales ilustrado en la Figura Nº 132 •

Caso de uso: Gestionar reporte de patentes. Actor: Administrador entidad financiera. Figura Nº 131 : Diagrama de colaboración: Gestionar reporte de patentes.

FUENTE: [Elaboración Propia]

Figura Nº 132 : Diagrama de colaboración: Gestionar cajeros y sucursales.

FUENTE: [Elaboración Propia]

196 de 255


3. Modelo de diseño.  Diagrama secuencia. A continuación se presentan el diagrama de secuencia del caso de uso gestionar reporte de patentes, con los objetos de diseño en una secuencia temporal como se muestra en la Figura Nº 133. Y el caso de Uso Gestionar Cajero y Sucursales ilustrado en la Figura Nº 134 •

Gestionar reporte de patentes. Figura Nº 133 : Diagrama de secuencia: Gestionar reporte de patentes. :IU Reporte Entidad Financiera

: IU Administracion Entidad Financiera

:IU Reporte Cajeros

:IU Reporte Sucursales

:Réplica BD

Ingresa a la herramienta mediante login y password Seleccionar la opción Gestionar Reportes

Administrador Entidad Financiera,

Conexión con la Réplica BD Mostrar Interfaz Seleccionar Sucursal Visualizar Detalle de la Sucursal ¿Imprimir Reporte?

FUENTE: [Elaboración Propia]

Figura Nº 134 : Diagrama de secuencia: Gestionar cajeros y sucursales. : IU Administracion Entidad Financiera

: IU Sursales Entidad Financiera

: IU Cajeros

: Réplica BD

: Cajero

Ingresar a la Herramienta mediante un login y password Administrador Entidad Financiera

Seleccionar Opción Sucursales Visualiza Sucursales Seleccionar Opción Nuevo/Modificar o Elminar

¿Realiza Cambios? Guardar Cambios en la Réplica de BD Enviar Mensaje: “Cambio Realizado”

Mostrar Cajeros Visualiza Cajeros de la Entidad Financiera

Seleccionar Opción Nuevo, Modificar o Eliminar

¿Realizar Cambios? Guardar Cambios en la Réplica de BD Enviar Mensaje: “Cambio Realizado”

FUENTE: [Elaboración Propia]

197 de 255

Habilitar Cajero Enviar Mensaje


 Diseño del enlace entre entidad financiera y alcaldía.

a) Cliente (entidad financiera). La herramienta es aquella la cual estará situada en la entidad financiera, donde el cajero de la entidad financiera permitirá enviar solicitudes o peticiones al servidor mediante una interfaz gráfica de usuario (Herramienta de Cobro de Patente). El cajero al ingresar a la herramienta de cobro de patentes en previa instancia se tiene que autenticar, mediante un login y password. En la Figura Nº 135 se observa al administrador de la entidad financiera así como las terminales (cajeros) conectados mediante un router, en cual distribuye la comunicación en toda el área de caja. Además se cuenta con un Firewall el cual está comprendido para la seguridad de la entidad financiera. Figura Nº 135 : Herramienta del lado del cliente (entidad financiera).

FIREWALL Entidad Financier FUENTE: [Elaboración Propia]

198 de 255


b) Canal de comunicaciones (enlace). Cuando el cajero de la entidad financiera realiza la consulta y el cobro de patente correspondiente, esta información viaja a través de una canal de comunicación hacia la réplica de base de datos para ello se establecen una conexión. En la cual los datos son enviados de forma encriptada, quiere decir que existe un canal de comunicaciones seguro entre la entidad financiera y alcaldía c) Servidor (alcaldía). Mencionando la parte del servidor se encuentra la Alcaldía, principalmente se encarga de responder a peticiones por parte del cliente (Entidad financiera), en la Figura Nº 136 se muestra la conexión del router hacia el firewall ya sea de tipo hardware o software, el cual permitirá el acceso a la entidad financiera. También se encuentra el administrador de la Alcaldía el cual está encargado de gestionar la herramienta de cobro de patentes Figura Nº 136 : Herramienta del lado del servidor (alcaldía).

FUENTE: [Elaboración Propia]

Base de datos: Se menciona que la réplica se encuentra implícitamente dentro de la seguridad de respaldo de información de la alcaldía según la circular SB/466/2004, es decir que la entidad financiera realiza consultas y transacciones mediante la réplica y está a la vez realiza una conexión con la base de datos central en donde actualizan los datos, transacciones en línea. 199 de 255


4. Modelo de Implementación.  Diagrama de componentes. Un diagrama de componentes muestra la realización de un conjunto de interfaces, las cuales permiten implementar un componente utilizando componentes más pequeños, en la Figura Nº 137, se ilustra el diagrama de componentes de gestionar reporte de patentes. Y en la Figura Nº 138 el diagrama de componentes de Gestionar Cajeros y Sucursales. Figura Nº 137 : Diagrama de componente: Gestionar reporte de patentes.

FUENTE: [Elaboración Propia]

Figura Nº 138 : Diagrama de Componente: Gestionar cajero y sucursales.

FUENTE: [Elaboración Propia]

200 de 255


5. Modelo de pruebas. Las pruebas de funcionalidades o de entrega se realizaron en base a la respuesta que se espera tener de cada caso de uso del sistema en funcionamiento. Se evalúa su funcionamiento viendo si cumple el objetivo principal de la herramienta de cobro de patentes En la Tabla Nº 23, se observa las pruebas realizadas según a cada caso de uso. Tabla Nº 23: Pruebas funcionales de la propuesta. Caso de

Datos

prueba

introducidos

Acción esperada

Resultado

Desplegar la página principal, habilitando la pestaña “Sitios Municipales” El

Página Web.

donde

se Satisfactorio

contribuyente observa el sitio o los sitios del

tiene Ingresar a la

en

que contribuyente.

autenticarse

Seleccionando un sitio municipal

mediante

su

Carnet

de

Identidad

(C.I.)

se observa en pantalla el detalle de las gestiones deudoras del

Satisfactorio

contribuyente

oprimir “Ingresar”. Si los datos introducidos son erróneos el sistema muestra

Satisfactorio

mensaje de error. Desplegar una ventana para El cajero de la Entidad

ingresar

los

datos Satisfactorio

correspondientes.

Ingresar a la Financiera herramienta

ingresa mediante

de cobro de Login patentes.

y

Desplegar la ventana principal del cobro de patentes.

Satisfactorio

Password, oprime “Ingresar” validarlos

para

Si los datos introducidos son erróneos el sistema devuelve un mensaje de error.

201 de 255

Satisfactorio


Caso de

Datos

prueba

introducidos

Acción esperada

Resultado

Administrar cuenta de usuario donde

puede

modificar

su Satisfactorio

contraseña

Registrar contribuyentes, existe una opción para el registro de un nuevo contribuyente.

Satisfactorio

Desplegar opción de búsqueda del sitio con las opciones de El

administrador modificar eliminar y asignar sitio de la alcaldía a un contribuyente. Administrar Cobro Patentes

ingresa

a

Satisfactorio

la

de herramienta mediante su login Generar reporte de los estados y password y financieros del contribuyente, oprime ingresar

mediante una búsqueda previa

Satisfactorio

por su código de licencia.

Realizar un reporte de cada Satisfactorio

entidad financiera. Asignar el número de cajeros a la entidad financiera ver el detalle

de

financiera, etc.

202 de 255

cada

entidad

Satisfactorio


Caso de

Datos

prueba

introducidos

Acción esperada

Resultado

Mostrar en pantalla el detalle del sitio a la cual es acreedor el

Satisfactorio

contribuyente El cajero de la

Mostrar las gestiones que debe según el sitio municipal del

Entidad Financiera realiza

Satisfactorio

contribuyente

la búsqueda del Efectuar el cobro de la gestión y Realizar Cobro Patente.

contribuyente de mediante Código

se registra la transacción. su de Emitir comprobante de pago

Licencia, presiona “Buscar” para

Satisfactorio

mostrar

según a la gestión que se

Satisfactorio

cancelo

resultado. Los datos de búsqueda tiene que ser mínimo de 5 caracteres caso contrario se muestra un mensaje

Satisfactorio

de error. Administrador de Modificar la

o

eliminar

las

entidad diferentes sucursales.

Satisfactorio

financiera ingresa Gestionar

al

módulo

Asignar cajeros a las diferentes y mediante su login de la entidad y password, y sucursales Sucursales presiona ingresar financiera. Cajeros

203 de 255

Satisfactorio


Caso de

Datos

prueba

introducidos El de

Gestionar Reporte Patente.

administrador la

entidad

financiera ingresa de con su login y

Acción esperada

Resultado

Aparece en pantalla el reporte por cajeros, y el monto total que se

recaudó

en

la

entidad

Satisfactorio

financiera.

password,

Si los datos introducidos son

selecciona

erróneos el sistema devuelve un

“Reporte Diario”

mensaje de error.

Satisfactorio

FUENTE: [Elaboración Propia]

3.6 PRUEBAS DE LA HERRAMIENTA DE COBRO DE PATENTES Y MÓDULO WEB. Las pruebas se realizaron en base a la teoría descrita en el marco teórico (pag.84), para ello se efectuaran las pruebas de carga o rendimiento, tanto a la herramienta de cobro de patentes como al módulo web.

3.6.1 Pruebas de carga o rendimiento. En este punto se llevaran a cabo las pruebas de carga para verificar si el sistema funciona cuando existe gran cantidad de carga de datos.

3.6.1.1 Prueba de carga al módulo web. Para realizar las pruebas de carga en el módulo web se utilizó la herramienta WebServer Stress, en la cual se pudo obtener el porcentaje de carga que existe al momento se realizar operación en diferentes terminales, en la Figura Nº 139, se puede observar un resumen la prueba de carga que se realizó al módulo web, con el total de usuarios tomado en cuenta, para más detalle ver ANEXO J.

204 de 255


Figura Nº 139 : Prueba de carga al módulo web.

FUENTE: [Elaboración Propia]

Para realizar la prueba de carga se priorizo tomar una cantidad mínima de usuario así como una cantidad limitada, en la cual se pueda observar hasta cuantos contribuyentes pueden acceder al módulo web, y este no colapse (VER ANEXO J). En la Tabla Nº 24 se describe un resumen de las observaciones que se pudo obtener sobre las diferentes pasadas al módulo web mediante las pruebas de carga. Tabla Nº 24: Observaciones de la prueba de carga al módulo web. Descripción

Cantidad de usuarios

Se ejecutaron las pruebas Primera Pasada:

Observaciones Se verificó que el ingreso de un

de carga al módulo web en Se usuarios al realizó la numero de 150 el cual accedieron diferentes carga de 150 módulo no presenta alguna cantidades de usuarios al sobrecarga inesperada, pero contribuyentes y consultaron módulo web. su estado de cuentas

205 de 255

vale mencionar que si se tuvo un 20% del consumo del procesador


Descripción

Cantidad de

Observaciones

usuarios Segunda

Se observó un gran consumo de

Pasada:

procesador

Se

realizó

carga

de

usuarios módulo web.

al

momento

de

la ejecutar la carga de 500 no obstante el 500 usuarios, al rendimiento de tiempos de acceso se mantuvieron estables. Con un consumo del procesador del 25%

FUENTE: [Elaboración Propia]

3.6.1.2 Prueba de carga a la herramienta de cobro de patentes. Para realizar las pruebas de carga a la herramienta de cobro de patentes se utilizó la herramienta ANTS Performance Profiler 8, en la cual se pudo obtener el porcentaje de carga con diferentes parámetros al momento se realizar operación correspondientes, en la Figura Nº 140, se puede observar la prueba de carga que se realizó a la herramienta de cobro de patentes, y para más detalle revisar el ANEXO J. Figura Nº 140 : Prueba de carga a la herramienta de cobro de patentes.

FUENTE: [Elaboración Propia]

206 de 255


En la Tabla Nº 25 se observa un resumen de la prueba realizada a los diferentes casos de uso de la herramienta de cobro de patentes, en donde se obtuvieron los siguientes resultados por cada caso de uso: Tabla Nº 25: Resultado prueba de carga a la herramienta de cobro de patentes. Caso de Uso

Prueba

Estado

Observaciones

Carga

Consumo medio

Administrar Cobro de Patentes.

Carga

Realizar Cobro de Patentes.

Carga

Carga

Ninguna

Carga

Ninguna

Ingresar a la herramienta de cobro de patentes.

Gestionar

Cajeros

y

Sucursales.

Gestionar Reporte de Patente

del Procesador

Ninguna

Consumo del procesador

FUENTE: [Elaboración Propia]

En la Tabla Nº 26 se puede apreciar las observaciones que se realizaron de la prueba de carga, tomando en cuenta la cantidad de usuarios ejecutados en la herramienta de cobro de patentes.

207 de 255


Tabla Nº 26: Observaciones de la prueba de carga a la herramienta de cobro de patentes. Descripción

Cantidad de usuarios

Observaciones

Se ejecutaron las Primera Pasada:

Se verificó que el ingreso de un

pruebas de carga a

numero de 120

Se realizó la carga de 120

usuarios a la

la herramienta de usuarios a la herramienta herramienta, presento un alto cobro de patentes, de cobro de patentes, para consumo del procesador con principalmente se el caso de uso Ingresar a la tiempos de respuesta pudieron

obtener herramienta resultados de 2

relativamente bajos.

casos de uso: el primero fue el caso Segunda Pasada:

Se observó un gran consumo de

de uso: Ingresar a

Se realizó la carga de 525 procesador al momento de la herramienta la usuarios a la herramienta ejecutar la carga de 525 cual fue realizada

de cobro de patentes, para usuarios, el pago se efectuó por parte de los el caso de uso Realizar relativamente bien, los tiempos cajeros

y

el

segundo

fue

al

caso

de

Cobro de Patentes.

en procesar los datos fueron altos, ya que se realizaron el

uso

registro

de

los

datos

Realizar Cobro de

correspondiente y este demoro al

Patentes.

momento operación.

FUENTE: [Elaboración Propia]

208 de 255

de

realizar

la


3.7 DEMOSTRACIÓN DE LA HIPÓTESIS. La hipótesis planteada para el presente trabajo menciona lo siguiente: “Herramienta de cobro de patentes mediante intermediación financiera aplicando enlace en línea entre entidades y un módulo web de estado de cuentas del contribuyente, permitirá extender puntos de cobranza, incrementar el número de patentes cancelados al municipio del cercado y mejorar el tiempo de obtención de la proforma de pago.” Para la demostración de la hipótesis es necesario analizar las variables independientes y dependientes las cuales se describen a continuación: Variable independiente. Herramienta de cobro de patentes considerando la intermediación financiera y la cual estará situada en la entidad financiera con la que se establecerá un enlace en línea a la empresa, será utilizada por el cajero mediante una interfaz donde podrá realizar el cobro correspondiente de la patente, además el contribuyente podrá realizar la obtención de la proforma de pago mediante la página web, facilitando al usuario pagar su impuesto en una entidad financiera y obtener su proforma de pago mediante web. Variable dependiente. 1. Extender puntos de cobranza. Involucra incrementar puntos de cobranza para la cancelación de la patente.

2. Incrementar el número de patentes cancelados. Involucra el aumento de patentes canceladas por el número de ventanillas puestas a disposición del contribuyente.

3. Obtención de la proforma de pago. Involucra el tiempo para la obtención del detalle de la patente denominado proforma de pago mediante la página web.

209 de 255


Tabla Nº 27: Operativización de variables. Variable

Dimensión

Indicador

Variable Independiente. Herramienta

de

cobro

de Cobro y actualización Herramienta

patentes

mediante de datos en línea.

implementada

intermediación

financiera

testeada.

y

aplicando enlace en línea entre entidades. Variable Dependiente.

Punto de cobranza con

Extender puntos de cobranza.

Puntos de cobranza.

dos ventanillas de caja actuales, con

comparado

el

puntos

número de

de

cobranza

propuesto. Incrementar

el

número

de Patentes cancelados.

patentes cancelados.

Número

de

patentes

canceladas actualmente

en

las

oficinas de Alcaldía de Cochabamba patentes

y

canceladas

con la implantación en los puntos de cobranza en Fassil. Obtención de la Proforma de Tiempo en el proceso Horas utilizadas para el Pago

de obtención de la proceso de obtención proforma de pago. FUENTE: [Elaboración Propia]

210 de 255

del detalle de la patente.


3.7.1 Demostración de las variables dependientes. Para la demostración de las variables dependientes mencionadas en la tabla anterior se determinaran los puntos de cobranza, número de patentes y tiempos estimados. Cabe señalar que para la última variable dependiente se asignaran tiempos promedios en cada una de las actividades.

3.7.1.1 Demostración de la primera variable dependiente. Para la demostración de la primera variable independiente se realizó un análisis de la cantidad de puntos de cobranza de patentes que existen con el uso del sistema actual y posteriormente considerando la cantidad de puntos de cobranza de patentes con el uso del sistema desarrollado mediante la intermediación financiera. Tabla Nº 28: Puntos de cobro de patentes. Actividad

Puntos de

Procedimiento

cobranza

El cobro de patentes se efectúa en las

instalaciones

del

CEMAC,

donde existen 2 únicas ventanillas de caja para que el contribuyente pueda cancelar este impuesto, por lo que se menciona que este proceso es centralizado, ya que Cobro de patentes con este cobro se realiza en un solo el sistema actual. punto de la ciudad de Cochabamba, y para tal efecto existen largas filas cuando se están por cumplir las fechas límites de cancelación de la patente.

211 de 255

1 punto de cobro con 2 ventanillas de caja


Actividad

Puntos de

Procedimiento

cobranza

El cobro de patentes puede ser efectuado a través de las diferentes entidades financieras dentro del territorio

de

la

Cochabamba

ciudad

mediante

de la

intermediación financiera. En la Cobro de patentes con sección 3.4.1.3 se seleccionó al el sistema desarrollado Fondo Financiero Privado Fassil mediante

la S.A. como la entidad financiera la

intermediación

cual realizara un acuerdo con la

financiera.

Alcaldía de Cochabamba, por lo

17 puntos de cobro, 1 caja por cada sucursal.

tanto es primordial obtener la información acerca de la cantidad de

sucursales

distribuidas

de

financiera.

(Los

disponibles esta

y

entidad

detalles

son

descritos en el ANEXO K). FUENTE: [Elaboración Propia]

A través del análisis efectuado en la tabla anterior, podemos mencionar que con la implantación del sistema aplicando la intermediación financiera entre entidades, se podrán extender el número de puntos para el cobro de patentes en las diferentes sucursales de la entidad financiera, permitiendo a los contribuyentes acceder a cancelar su impuesto de la patente, evitando que realicen a la vez largas filas cuando se están por cumplir las fechas límites de cancelación, y sin la necesidad de aproximarse a las instalaciones del CEMAC.

212 de 255


3.7.1.2 Demostración de la segunda variable dependiente. Para la demostración de la segunda variable dependiente se tomaron en cuenta los datos obtenidos de la unidad de recaudaciones de la alcaldía la cual se describe mediante una tabla en los siguientes párrafos, así como la simulación de la herramienta a través de la intermediación financiera y la información obtenida del Fondo Financiero Privado Fassil para la habilitación de los puntos de cobranza, teniendo un estimado de 17 ventanillas a disposición del contribuyente distribuidas en las diferentes sucursales de la entidad financiera (VER ANEXO K). Tabla Nº 29: Número de patentes cancelados. Pasos para el Actividad

cobro de patentes en el CEMAC

Número de patentes

Pasos para el

patentes con

con el

cobro de patentes

la

sistema

en Fassil.

implantación

actual

del sistema.

El contribuyente

El

accede a pagar

accede a pagar su

su patente en

patente

las

diferentes

ventanillas

caja (2 de de patentes del ventanillas actualmente), Gobierno Donde

provee

o

en

habilitadas

las

para

1000

efectuar el cobro (17

8500

patentes

puntos de Cobro, 1

Patentes

Municipal de sus datos como Cochabamba ser: Código de Licencia

contribuyente

sucursales

Cobro

Autónomo

Número de

ventanilla por cada punto).

su

provee

Donde sus

datos

nombre

como ser: Código de

completo

licencia o su nombre completo FUENTE: [Elaboración Propia].

213 de 255


Habiendo realizado el análisis del número de patentes cancelados en la tabla anterior, se puede apreciar que para incrementar el número de patentes, se disponga de más ventanillas a disposición del contribuyente, ya que actualmente solo existen 2 únicas ventanillas en las instalaciones del CEMAC, para lo cual acceden una cantidad de 500 contribuyentes en el tiempito límite de cancelación del impuesto (Ver Paginas 8-9), en la siguiente Tabla Nº 30 se especificara más a detalle el número de patentes cancelados de la gestión 2012 dentro el plazo de cancelación de los 180 días (6 meses). Tabla Nº 30: Patente por espacio ocupado de contribuyentes minoristas, artesanos, vivanderos y número de patentes cancelados actualmente.

FUENTE: [Elaboración Propia]

Habiendo simulado el sistema de cobro de patentes con la intermediación financiera durante el mes de octubre del 2013, se pudo constatar que se incrementó el número de patentes cancelados, según a los datos que se muestra la Tabla Nº 31, cabe mencionar que estos datos son estimados ya que con la implantación del sistema se tendrían diferentes números de patentes.

214 de 255


Tabla Nº 31: Patente por espacio ocupado de contribuyentes minoristas, artesanos, vivanderos y número de patentes cancelados con la implantación del sistema.

FUENTE: [Elaboración Propia]

Entonces como se elaborado una encuesta al Fondo Financiero Privado Fassil a cerca de los puntos de cobranza para la habilitación del cobro de patentes, esta sea de 17 ventanillas (VER ANEXO K), se concluye que se incrementaran el número de patentes cancelados al municipio del cercado, teniendo un estimado de 500 contribuyentes para la cancelación de este impuesto, donde se pudo obtener el siguiente resultado expuesto en la Tabla Nº 32. Tabla Nº 32: Análisis del número de patentes cancelados. Número de patentes con

Número de patentes con la

el sistema actual

implantación del sistema

Cobro de Patentes del

2 (Ventanillas) x 500

17 (Ventanillas) x 500

Gobierno Autónomo

Contribuyentes

contribuyentes

1000 Patentes.

8500 Patentes.

Actividad

Municipal de Cochabamba

FUENTE: [Elaboración Propia]

Se puede reflejar que extendiendo los puntos de cobranza con las ventanillas puestas a disposición del contribuyente en las diferentes sucursales de la entidad financiera se incremente el número de patentes cancelados al Gobierno Autónomo Municipal de Cochabamba. 215 de 255


3.7.1.3 Demostración de la tercera variable dependiente. Para la demostración de la tercera variable dependiente se consideró el uso de un tiempo promedio, para cada actividad sobre el proceso para la obtención de Proformas de Pago. Lo cual permitirá el análisis del tiempo que le toma al contribuyente obtener esta documentación. Información que se pudo obtener a través de una encuesta realizada a la Alcaldía (VER ANEXO B), así como la descripción del mismo expuestas en las Páginas 6,7 Este promedio de tiempo se ha conseguido por medio de la observación directa, haciendo uso de un reloj, para la medición del tiempo. Tabla Nº 33: Pasos a seguir para la obtención de la proforma de pago Actividad

Tiempo con el sistema

Tiempo con la implantación

actual (min.)

del módulo web. (min.)

Proceso de Obtención De Proforma de Pago El

Contribuyente

debe El contribuyente accede a la

Proceso para que recabar una ficha para ser página web de cobro de el contribuyente atendido en la plataforma de patentes en donde pueda acceder a Proformas de Pago primeramente se tiene que ventanilla

de

autenticar.

Proforma de Pago 25 min

2 min

Una vez que el contribuyente El contribuyente una vez que obtenga la ficha para ser se autentica en la página web atendido, se aproxima a una mediante el número de Cédula Proceso para que de las ventanillas en donde de Identidad, puede visualizar el contribuyente brinda sus datos como ser: su estado de cuentas de la e imprimir pueda obtener su Código de Licencia o nombre patente Proforma de Pago completo, y el funcionario de directamente mediante la hace entrega de la Proforma interfaz de usuario. de Pago impresa. 6 min FUENTE: [Elaboración Propia]

216 de 255

3 min


Una vez analizado el tiempo empleado en la obtención de la Proforma de Pago tanto con el actual proceso como con el uso del módulo web se concluye que el tiempo empleado es menor con la implantación del módulo web, donde puede observar en la Tabla Nº 34 el resultado estimado de todo el análisis sobre el proceso para la obtención de Proforma de Pago. Tabla Nº 34: Resumen de los tiempos para el proceso de obtención de la proforma de pago.

Actividad

Tiempo con el sistema Actual (min.)

Tiempo con la implantación del módulo web (min.)

25 + 6

2+3

(31 min)

(5 min)

Proceso para la obtención de la Proforma de Pago

FUENTE: [Elaboración Propia]

3.7.2 Demostración de variable independiente Para la demostración de la variable independiente, se realiza el análisis a través de una muestra de todos los beneficios que tiene el sistema propuesto tanto en la herramienta de cobro de patentes como el módulo web, teniendo en cuenta tanto el proceso actual que se lleva para realizar el cobro de patentes así como el proceso para realizar la obtención de las proformas de pago. Calificando como un beneficio con la palabra “Si” y rechazando el beneficio con la palabra “No”, tal como se muestra en la Tabla Nº 35.

217 de 255


Tabla N潞 35: Tabla comparativa de beneficios del sistema propuesto. Nro. Factor

Factores tomados como beneficio

Proceso con el

Proceso con el

sistema actual

sistema

(Antes)

(Ahora)

No

Si

Si

Si

No

Si

No

Si

No

Si

No

Si

Herramienta de Cobro de patentes Permite efectuar el pago de cobro de patentes en las distintas sucursales 1

de la entidad financiera con la cual la Alcald铆a tiene el acuerdo de la intermediaci贸n financiera. Permite la emisi贸n del comprobante

2

de pago cuando el contribuyente cancela la patente. Permite

3

reportes

efectuados

tanto

de

los

pagos

en

la

entidad

financiera como en sus sucursales o agencias. Permite el control de los diferentes funcionarios

4

cajeros ya

sea

en

reportes de caja diario como un reporte

general

de

los

pagos

realizados. Permite 5

el

seguimiento

de

los

diferentes usuarios que realizan las funcionalidades del sistema (Logs) Permiten administrar sus cuentas de

6

usuarios, referente al cambio de Login y Password.

218 de 255


Nro. Factor

Factores tomados como beneficio

Proceso con el

Proceso con el

sistema actual

sistema

(Antes)

(Ahora)

No

Si

No

Si

Si

Si

No

Si

2 (Si)

10 (Si)

Módulo Web Permite que la información acerca de 1

las fechas límites de cancelación de la patente esté siempre visibles para el contribuyente. Permite que el contribuyente pueda

2

acceder a verificar su estado de cuentas de la patente mediante una interfaz.

3

Permite Obtener la proforma de Pago. Permite imprimir el detalle de su

4

estado de cuentas sobre patentes, denominado

Proforma

de

Pago

mediante web. Total Beneficios

FUENTE: [Elaboración Propia]

Teniendo como resultado el análisis de las muestras reflejadas en la tabla anterior, se concluye que el total de beneficios con el proceso del sistema actual tiene la cantidad de 2, y con el proceso del sistema se tiene un total de 10. Para tal efecto estos resultados se tomaran en cuenta en el cálculo del T donde se verificara la aceptación o rechazo de la hipótesis, cálculo que se detalla en los siguientes apartados.

219 de 255


3.7.2.1 DefiniciĂłn de la hipĂłtesis. Para efectuar la demostraciĂłn de la hipĂłtesis se considera el anĂĄlisis de aceptaciĂłn y rechazo de la misma, haciendo referencia a un đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x203A;đ?&#x2018;&#x203A; que representa a una probabilidad, para esto tenemos que: â&#x20AC;˘

đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 = El proceso actual para la obtenciĂłn de proforma de pago y realizar el cobro de patentes del Gobierno AutĂłnomo Municipal de Cochabamba.

â&#x20AC;˘

đ?&#x2018;&#x192;đ?&#x2018;&#x192;2 = Herramienta de cobro de patentes mediante intermediaciĂłn financiera aplicando enlace en lĂ­nea entre entidades.

Donde los factores que influyen en la operativizaciĂłn son: ď&#x192;&#x2DC; HipĂłtesis nula (H0): Los factores de ĂŠxito de ambas muestras son iguales

Quiere Decir que:

đ??ťđ??ť0 : đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 = đ?&#x2018;&#x192;đ?&#x2018;&#x192;2

đ??ťđ??ť0 : đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 = đ?&#x2018;&#x192;đ?&#x2018;&#x192;2 : (El proceso actual para la obtenciĂłn de proforma de pago y realizar el cobro de patentes del Gobierno AutĂłnomo Municipal de Cochabamba es igual que la herramienta de cobro de patentes mediante intermediaciĂłn financiera aplicando enlace en lĂ­nea entre entidades). ď&#x192;&#x2DC; HipĂłtesis alternativa (H1): Los factores de ĂŠxito de ambas muestras son distintas.

Quiere Decir que:

đ??ťđ??ť1 : đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 <> đ?&#x2018;&#x192;đ?&#x2018;&#x192;2

đ??ťđ??ť1 : đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 <> đ?&#x2018;&#x192;đ?&#x2018;&#x192;2 : (El proceso actual para la obtenciĂłn de proforma de pago y

realizar el cobro de patentes del Gobierno AutĂłnomo Municipal de Cochabamba

es diferente que la herramienta de cobro de patentes mediante intermediaciĂłn financiera aplicando enlace en lĂ­nea entre entidades). Para lo cual se presentan dos casos: ď&#x192;ź Los factores de ĂŠxito de la muestra anterior es mayor a la posterior: đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 > đ?&#x2018;&#x192;đ?&#x2018;&#x192;2 ď&#x192;ź Los factores de ĂŠxito de la muestra anterior es menor a la posterior: đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 < đ?&#x2018;&#x192;đ?&#x2018;&#x192;2 220 de 255


Describiendo los dos casos:

ď&#x192;ź đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 > đ?&#x2018;&#x192;đ?&#x2018;&#x192;2 : (El proceso actual para la obtenciĂłn de proforma de pago y realizar el cobro de patentes del Gobierno AutĂłnomo Municipal de

Cochabamba tiene mayores beneficios que la herramienta de cobro de patentes mediante intermediaciĂłn financiera aplicando enlace en lĂ­nea entre entidades).

ď&#x192;ź đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 < đ?&#x2018;&#x192;đ?&#x2018;&#x192;2 : (El proceso actual para la obtenciĂłn de proforma de pago y realizar el cobro de patentes del Gobierno AutĂłnomo Municipal de

Cochabamba tiene menores beneficios que la herramienta de cobro de patentes mediante intermediaciĂłn financiera aplicando enlace en lĂ­nea entre entidades).

De ambas hipĂłtesis definidas anteriormente (HipĂłtesis Nula, HipĂłtesis Alternativa), se procederĂĄ al cĂĄlculo del estadĂ­stico T, para la demostraciĂłn de la hipĂłtesis del presenta trabajo.

3.7.2.2 Calculo del estadĂ­stico T. Mediante el siguiente cĂĄlculo del estadĂ­stico T permite conocer la aceptaciĂłn o rechazo de la hipĂłtesis, para posteriormente contrastar que el dato calculado se encuentra en un rango de aceptaciĂłn o rechazo. Las fĂłrmulas que nos ayudaran en la demostraciĂłn de la hipĂłtesis son las siguientes: â&#x20AC;˘ â&#x20AC;˘ â&#x20AC;˘

đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192; =

â&#x20AC;˘

đ?&#x2018;&#x203A;đ?&#x2018;&#x203A;

đ?&#x2018;&#x201D;đ?&#x2018;&#x201D;đ?&#x2018;&#x201D;đ?&#x2018;&#x201D; = đ?&#x2018;&#x203A;đ?&#x2018;&#x203A; â&#x2C6;&#x2019; 1 đ?&#x2018;Ąđ?&#x2018;Ą =

DĂłnde: â&#x20AC;˘

đ?&#x2018;&#x2039;đ?&#x2018;&#x2039;đ?&#x2018;&#x203A;đ?&#x2018;&#x203A;

đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x203A;đ?&#x2018;&#x203A; đ?&#x2018;&#x2039;đ?&#x2018;&#x2039;

đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 â&#x2C6;&#x2019; đ?&#x2018;&#x192;đ?&#x2018;&#x192;2

đ?&#x2018;&#x192;đ?&#x2018;&#x192; â&#x2C6;&#x2014;đ?&#x2018;&#x201E;đ?&#x2018;&#x201E; đ?&#x2018;&#x192;đ?&#x2018;&#x192; â&#x2C6;&#x2014;đ?&#x2018;&#x201E;đ?&#x2018;&#x201E; ďż˝ 1đ?&#x2018;&#x203A;đ?&#x2018;&#x203A; 1 + 2đ?&#x2018;&#x203A;đ?&#x2018;&#x203A; 2 1

2

= Probabilidad de ocurrencia de una de las dos probabilidades (đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 Ăł đ?&#x2018;&#x192;đ?&#x2018;&#x192;2 )

= NĂşmero de aciertos en la muestra de la probabilidad (â&#x20AC;&#x153;Siâ&#x20AC;? o â&#x20AC;&#x153;Noâ&#x20AC;?

â&#x20AC;Śâ&#x20AC;Śâ&#x20AC;Ś..obtenidos de la Tabla NÂş 35)

â&#x20AC;˘ â&#x20AC;˘

đ?&#x2018;&#x203A;đ?&#x2018;&#x203A;

đ?&#x2018;Ąđ?&#x2018;Ą

= NĂşmero de muestras ( Diez Beneficios obtenidos, Ver Tabla NÂş 35) = Valor estadĂ­stico para la aceptaciĂłn o rechazo de la hipĂłtesis. 221 de 255


â&#x20AC;˘ â&#x20AC;˘

đ?&#x2018;&#x201E;đ?&#x2018;&#x201E;đ?&#x2018;&#x203A;đ?&#x2018;&#x203A;

= Probabilidad de concurrencia de uno de los casos.

đ?&#x2018;&#x201E;đ?&#x2018;&#x201E;ďż˝ 2 = Grado de error (Se utiliza para los rangos de rechazo de hipĂłtesis, se â&#x20AC;Śâ&#x20AC;Śâ&#x20AC;Ś..obtiene de la tabla T-Student-Columna)

â&#x20AC;˘

đ?&#x2018;&#x201D;đ?&#x2018;&#x201D;đ?&#x2018;&#x201D;đ?&#x2018;&#x201D;: = Grado de libertad (Se utiliza para los rangos de rechazo de hipĂłtesis,

â&#x20AC;Śâ&#x20AC;Śâ&#x20AC;Ś..se obtiene de la tabla T-Student-Fila) â&#x20AC;˘

đ?&#x2018;&#x203A;đ?&#x2018;&#x203A;1 /đ?&#x2018;&#x203A;đ?&#x2018;&#x203A;2 = Numero de Beneficio obtenidos para los dos casos de probabilidades

Realizando los cĂĄlculos necesarios para đ?&#x2018;&#x203A;đ?&#x2018;&#x203A; = 10 y đ?&#x2018;&#x2039;đ?&#x2018;&#x2039;đ?&#x2018;&#x203A;đ?&#x2018;&#x203A; = 2 (Tabla Beneficios: 2 â&#x20AC;&#x153;Siâ&#x20AC;?) ď&#x192;&#x2DC; đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 =

2

10

= 0,20 ; Entonces el proceso actual para la obtenciĂłn de proforma

de pago y realizar el cobro de patentes del Gobierno AutĂłnomo Municipal de Cochabamba (đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 ) alcanza un 20% de los beneficios de la muestra.

ď&#x192;&#x2DC; đ?&#x2018;&#x192;đ?&#x2018;&#x192;2 =

10 10

=1

; Entonces la herramienta de cobro de patentes mediante

intermediaciĂłn financiera aplicando enlace en lĂ­nea entre entidades (đ?&#x2018;&#x192;đ?&#x2018;&#x192;2 )

alcanza un 100% de los beneficios de la muestra. ď&#x192;&#x2DC; đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 < đ?&#x2018;&#x192;đ?&#x2018;&#x192;2

; Por lo tanto đ?&#x2018;&#x192;đ?&#x2018;&#x192;2 es mejor que la variable đ?&#x2018;&#x192;đ?&#x2018;&#x192;1

Para el cĂĄlculo del T- Student de considera el valor đ?&#x153;śđ?&#x153;ś de acuerdo al nĂşmero de

muestras que se tiene. Para tal efecto se va considerar una muestra menor a 100, para el cĂĄlculo del grado de error el valor es de 0.05.

đ?&#x2018;&#x201E;đ?&#x2018;&#x201E;ďż˝ 2 = 0.05/2 = 0.025

Los grados de libertad se calculan a continuaciĂłn:

đ?&#x2018;&#x201D;đ?&#x2018;&#x201D;đ?&#x2018;&#x201D;đ?&#x2018;&#x201D; = đ?&#x2018;&#x203A;đ?&#x2018;&#x203A; â&#x2C6;&#x2019; 1 = 9

Para los rangos de rechazo de la hipĂłtesis, se obtiene los valores de la distribuciĂłn en la tabla de T -Student la intersecciĂłn del valor que corresponda al grado de error (columna) y el valor del grado de libertad (fila), VER ANEXO L. Donde los rangos obtenidos para este caso son: -2,262 y 2,262, es decir que cualquier valor dentro de este rango demostrarĂĄ que la hipĂłtesis es nula (H0) por lo que la hipĂłtesis alternativa (H1) se encuentra fuera de los rangos obtenidos.

đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 =

2

10

= 0,20 Por lo tanto: đ?&#x2018;&#x201E;đ?&#x2018;&#x201E;1 = 1 â&#x2C6;&#x2019; 222 de 255

2

10

= 0,80


DĂłnde:

đ?&#x2018;&#x192;đ?&#x2018;&#x192;2 =

10 10

= 1 Por lo tanto: đ?&#x2018;&#x201E;đ?&#x2018;&#x201E;2 = 1 â&#x2C6;&#x2019; 1 = 0

đ?&#x2018;&#x201E;đ?&#x2018;&#x201E;1 = Porcentaje de beneficios no alcanzados con el proceso actual para la obtenciĂłn

de proforma de pago y realizar el cobro de patentes del Gobierno AutĂłnomo Municipal de Cochabamba

đ?&#x2018;&#x201E;đ?&#x2018;&#x201E;2 = Porcentaje de beneficios no alcanzados con la herramienta de cobro de patentes mediante intermediaciĂłn financiera aplicando enlace en lĂ­nea entre entidades.

Sustituyendo los datos obtenidos tenemos: đ?&#x2018;Ąđ?&#x2018;Ą =

ďż˝

0.20â&#x2C6;&#x2019;1

0.20â&#x2C6;&#x2014;0.80 1â&#x2C6;&#x2014;0 + 10 10

= â&#x2C6;&#x2019;6,3245

Figura NÂş 141 : Campana de Gauss para la demostraciĂłn de la hipĂłtesis.

FUENTE: [ElaboraciĂłn Propia]

Una vez realizado el anĂĄlisis de las muestras, el cĂĄlculo de T-Student y la grĂĄfica de la campana de gauss, se demuestra que el dato obtenido del valor estadĂ­stico đ?&#x2018;Ąđ?&#x2018;Ą sea de

-6,3245, este se refiere que estĂĄ dentro el rango de la hipĂłtesis alternativa, quiere decir que đ?&#x2018;&#x192;đ?&#x2018;&#x192;1 < đ?&#x2018;&#x192;đ?&#x2018;&#x192;2 para lo cual la hipĂłtesis nula (H0) es rechazada y se acepta la alternativa (H1), entonces se concluye que â&#x20AC;&#x153;El proceso actual para la obtenciĂłn de proforma de

pago y realizar el cobro de patentes del Gobierno AutĂłnomo Municipal de Cochabamba tiene menores beneficios que la herramienta de cobro de patentes mediante intermediaciĂłn financiera aplicando enlace en lĂ­nea entre entidadesâ&#x20AC;?.

223 de 255


4

AN AL ISIS DE VIAB ILID AD.

4.1 VIABILIDAD TÉCNICA. La viabilidad técnica es un punto importante cuando se trata de la implementación e implantación de un proyecto. En la actualidad el Gobierno Autónomo Municipal de Cochabamba cuenta con un conjunto de licencias ya adquiridas para el desarrollo del software, por lo tanto se tomaran en cuenta algunos aspectos tales la disponibilidad tecnológica, recursos materiales y humanos disponibles para determinar la ejecución, funcionalidad y realización del presente trabajo. En lo que respecta a los aspectos humanos, se tomaran en cuenta el personal o usuarios los cuales manipularan el sistema de cobro de patentes así como el módulo web, para lo cual es primordial establecer en la viabilidad técnica. Principalmente se tienen las siguientes clasificaciones de usuarios finales, los cuales se mencionan a continuación: •

Administrador de la Alcaldía: Dentro de la herramienta de cobro de patentes se prioriza tener a un Administrador el cual esté capacitado para manipular el sistema de cobro de patentes, básicamente que cuente con conocimientos sobre base de datos y desarrollo sobre aplicaciones .NET

Contribuyente: Este usuario básicamente es necesario y de importancia que tenga conocimientos básicos de navegación por internet.

Administrador Entidad Financiera: Para entregar la herramienta a la entidad financiera, es de gran importancia tener una cuenta de usuario para acceder a la funcionalidad del sistema, además se disponga de un personal capacitado para utilizar la herramienta, básicamente que cuente con conocimientos sobre aplicaciones de escritorio.

Cajero: Así también se encuentra el usuario cajero el cual se prioriza que tenga conocimientos básicos en procesamiento de transacciones mediante sistemas informáticos.

En base de lo mencionado anteriormente podemos describir los requisitos de software y hardware que la institución tiene que tener para el funcionamiento del sistema.

224 de 255


4.1.1 Requerimientos del sistema. Para realizar un mejor énfasis al trabajo propuesto se describirán los requerimientos mínimos como recomendados a lo que respecta hardware y software enfocados tanto al servidor como al cliente.

4.1.1.1 Servidor. A continuación se detallaran los requerimientos mínimos y recomendados necesarios para el lado del servidor, en lo que respecta al funcionamiento de la herramienta de cobro de patentes que permitirá la implementación del enlace en línea entre entidades. Tabla Nº 36: Requerimientos mínimos y recomendados del Servidor. Componente

Característica

Disponibilidad

Requerimiento Hardware Mínimo: Procesador de doble núcleo

de

1.5

Ghz

de

frecuencia Procesador Recomendado: Procesador de doble núcleo de 3 Ghz o superior Actualmente

Mínimo: 2 GB de RAM Memoria RAM

Recomendado:

4

GB

o

requerido.

superior Espacio disco duro

en Mínimo: 8GB Recomendado: 20 GB Monitor

Pantalla

dispone

con

resolución

800x600 o superior

225 de 255

del

la

Alcaldía hardware


Componente

Característica

Disponibilidad

Requerimiento Software Sistema Operativo

Gestor de Base de Datos

Windows

Server

2008

o

superior MySQL

Actualmente Server dispone Herramienta requerido.

Community

5.6.12

y

la del

Alcaldía software

Workbench 5.2 La alcaldía cuenta con el requerimiento software, pero este puede ser adquirido mediante las siguientes direcciones:

Mínimo: Internet Explorer 8, 9 Chrome v.23, Firefox v.17

Explorador

http://windows.microsoft.c om/es-es/internet-

Recomendado: Chrome v.29

explorer/download-ie

Firefox v.23 •

http://www.google.com/int l/es-419/chrome/

http://www.mozilla.org/esES/firefox/new/

Disponible en: Microsoft Framework 4.5 http://www.microsoft.com/ Software Adicional Service

SSHd

2.4

(Canal Disponible en:

Seguro)

http://www.freesshd.com/

FUENTE: [Elaboración Propia]

226 de 255


4.1.1.2 Cliente. a) Cliente entidad financiera. En la Tabla Nº 37 se detallaran los requerimientos mínimos y recomendados necesarios para el lado del cliente de la entidad financiera, en lo que respecta al funcionamiento de la herramienta de cobro de patentes que permitirá la implementación del enlace en línea entre entidades. Tabla Nº 37: Requerimientos mínimos y recomendados para el cliente de entidad financiera. Componente

Características

Disponibilidad

Requerimiento Hardware Mínimo: Procesador de 1 núcleo de 800 Mhz de frecuencia Procesador Recomendado: Procesador de 1 núcleo de 1 GB o superior Memoria RAM

Mínimo: 512MB de RAM Las computadoras de los Recomendado: 1GB o usuarios cajeros de la entidad financiera superior Mínimo: 30 MB

cuentan con el hardware requerido.

Espacio en disco duro Recomendado: 100 MB Tarjeta de Red o Adaptador Soporte de 100 Mbps20 o de red inalámbrico.

superior Monitor con resolución

Pantalla

800x600 o superior

20

Mbps: En redes es la unidad que se usa para cuantificar un caudal de datos equivalente a 1000 kilobits por segundo

227 de 255


Componente

Características

Disponibilidad

Requerimiento Software

Windows Vista SP2 o

Sistema operativo

superior

Las computadoras de los usuarios cajero cuentan con el software requerido. Disponible en:

Software adicional

Microsoft Framework 4.5 http://www.microsoft.com/ FUENTE: [Elaboración Propia]

b) Cliente contribuyente. En la Tabla Nº 38 se detallaran los requerimientos mínimos y recomendados necesarios para el usuario contribuyente, en lo que respecta al funcionamiento del módulo web, el cual permitirá que el usuario pueda ver su estado de cuentas de su patente así como poder imprimir esta documentación. Tabla Nº 38: Requerimientos mínimos y recomendados del cliente contribuyente. Componente

Requerimientos mínimos.

Sistema Operativo

Multiplataforma, recomendado Windows XP o más reciente

Navegador Web.

Recomendado Google Chrome o Firefox 14.*, CSS 2.1 y lenguaje JavaScript.

Conexión a Internet

Conexión de banda ancha superior a 56 Kbps FUENTE: [Elaboración Propia]

4.1.2 Requerimientos del enlace en línea. Es fundamental especificar los requerimientos de enlace en línea que se efectuara desde la entidad financiera hacia el servidor de la Alcaldía de Cochabamba, para ello en la Tabla Nº 39, se muestran los requerimientos de hardware y conectividad.

228 de 255


Tabla Nº 39: Requerimientos para el enlace en línea Componente

Características

Disponibilidad

Enlace

Enlace que conecta la entidad Existe la disponibilidad para solicitar

Dedicado

financiera con el servidor de la el Alcaldía de Cochabamba

enlace

transmisión

dedicado de

para

datos

la ISP

(COMTECO, Entel, AXS)

Switch

Permite

Interconectar

el La Alcaldía no dispone actualmente

Servidor de la Alcaldía hacia del equipo para la propuesta pero la entidad financiera y esta se puede adquirir del mercado local, que pueda distribuir a las en las tiendas de componentes sucursales correspondientes

electrónicos de la calle Esteban Arce (Cochabamba).

FUENTE: [Elaboración Propia]

Los requerimientos mínimos en lo que respecta al hardware, se encuentran conforme a las necesidades requeridas por parte del software, cabe mencionar que la Alcaldía de Cochabamba cuenta con algunos de los requerimientos mínimos de software los cuales se mencionaron en la Tabla Nº 36, para el lado del Servidor, puesto que la institución trabaja actualmente sobre Bases de Datos MySQL-SQL Server entre otras, todas ellas cuentan con licencias para el trabajo de los diferentes sistemas entre este para la herramienta de cobro de patentes. En lo que respecta a los requerimientos del Cliente como se describe en la Tabla Nº 37, las maquinas clientes de los cajeros tienen que tener como mínimo estos requerimientos necesarios para el uso del sistema. Para el lado del cliente contribuyente, si accediera desde una maquina con internet tiene que tener básicamente los requerimientos descritos en la Tabla Nº 38. De esta manera se concluye que el presente trabajo aplicado para el enlace en línea entre el cliente (Entidad Financiera) y servidor (Alcaldía), para su funcionamiento y puesta en marcha es técnicamente viable, puesto que ambas partes cuentan con la tecnología requerida para la administración de la herramienta, así como para su desarrollo.

229 de 255


4.2 VIABILIDAD ECONÓMICA. Para llevar a cabo el análisis de la Viabilidad Económica se han identificado los costos por tecnología y los costos por mano de obra.

4.2.1 Costos por tecnología. Para determinar los costos de cada uno de los componentes tecnológicos, tanto de hardware como de software, se realizó consultas a sitios web oficiales de los proveedores,

tales

como:

www.mercadolibre.com,

www.att.gob.bo

y

www.microsoft.com, y se obtuvieron los siguientes resultados organizados tanto para el servidor como para el cliente, así como también para el enlace en línea, esto se refiere al canal de comunicación que se efectuara entre la Entidad Financiera y Alcaldía.

4.2.1.1 Servidor. En la Tabla Nº 40, se muestran los siguientes costos por tecnología para el lado del servidor, alguno se ha incluido al equipo dedicado Tabla Nº 40: Precio de los componentes para el servidor Componente

Precio Aproximado en $us.

Procesador 2,5 GHz Memoria de 2 GB Equipo

Disco Duro 40 GB 7200 rpm

dedicado para

el

696. Tarjeta de Red con soporte de 100 Mbps

Servidor Case Combo: Monitor resolución 1024x768, teclado, mouse. Service SSHd 2.4

230 de 255

0.00


Componente Navegador Web Internet Explorer

Precio Aproximado en $us. 0.00 0.00

Licencia de MySQL Bajo Licencia GNU 21 Total

696.

FUENTE: [Elaboración Propia]

4.2.1.2 Cliente. Para el caso del usuario cliente como se mencionó en la Viabilidad Técnica tomaremos en cuenta el cliente de entidad financiera y dentro del cliente contribuyente no estimaran los costos ya que no está contemplado para el desarrollo del presente trabajo, en la Tabla Nº 41, se ilustran los siguientes costos establecidos para el lado del cliente de la entidad financiera. Tabla Nº 41: Precio de los componentes para el cliente de entidad financiera. Componente

Precio Aproximado en $us

Windows 7, Procesador 1,5 GHz Memoria de 1 GB Equipo de los

Disco Duro 80 GB 7200 rpm

usuarios cajero

y

administrador de

entidad

financiera.

386.

Tarjeta de Red con soporte de 100 Mbps Case Combo: Monitor resolución 1024x768, teclado, mouse. Service Pack 2 o Superior y Microsoft

0.00

.NET Framework 4.0. Total

386

FUENTE: [Elaboración Propia]

21

Licencia GNU: Licencia para contenido libre la cual está disponible de forma completamente libre, pudiendo ser copiado, redistribuido, modificado e incluso vendido siempre y cuando el material se mantenga bajo los términos de esta misma licencia (GNU GFDL).

231 de 255


En la Tabla Nº 42, como se mencionó anteriormente no se estimaran los costos para el cliente contribuyente, para lo cual tenemos: Tabla Nº 42: Precio de componente para el cliente contribuyente. Componente

Precio aproximado en $us

Navegador Web

Incluido como componente en el S.O.

Total

0.00 FUENTE: [Elaboración Propia]

4.2.1.3 Canal de comunicación. Para efectuar el enlace entre la Entidad Financiera y Alcaldía es primordial estimar los costos de un canal de comunicaciones, para tal efecto tomaremos en cuenta tanto los precios que establecen la ATT (Autoridad de Fiscalización y Control Social de Telecomunicaciones y Transportes) y la empresa de telecomunicaciones COMTECO LTDA. En la Tabla Nº 43, se ilustran los precios estimados del enlace entre entidades tomando en cuenta una la línea dedica. Tabla Nº 43: Precio del canal de comunicación entre entidades. Cargo Fijo Componente (Aprox.) 680 (94.4 $) Enlace en línea punto a punto para

Tomado en cuenta solo

la transmisión de datos desde un

el Primer Mes

punto origen (Alcaldía) hacia un

Instalación

punto destino (Entidad financiera).

232 de 255


Cargo Fijo anual (Aprox.) Velocidad de

7800

Transferencia:

(1130 $)

64 kbps

Cargo Fijo Componente (Aprox.) Switch Switch

para

interconectar

Cisco

la

8

Bocas

Sf100-d 8

Puertos

Alcaldía con la Entidad Financiera

10/100mbps

285 $ R/

Sd208. Total

1509.4 $

FUENTE: [Elaboración Propia]

Identificados los costos de cada componente correspondiente tanto para el cliente como para el servidor incluyendo al canal de comunicaciones se presentan a continuación en la Tabla Nº 44, del costo total de los componentes tecnológicos. Tabla Nº 44: Lista de costos por tecnología. Tipo

Monto $us

Servidor

655

Cliente Entidad Financiera

386

Cliente Contribuyente

0.00

Canal de Comunicación

1509

TOTAL

2550

FUENTE: [Elaboración Propia]

233 de 255


4.2.2 Costos por mano de obra Para estimar el coste de un producto de software principalmente se procederĂĄ a la elaboraciĂłn del modelo COCOMO II (Constructive Cost Model, segunda version). Los factores de costo describen aspectos relacionados con la naturaleza del producto, hardware utilizado, personal involucrado, y caracterĂ­sticas propias del proyecto. BĂĄsicamente COCOMO II estĂĄ compuesto por tres modelos denominados: ComposiciĂłn de AplicaciĂłn, DiseĂąo Temprano y Post-Arquitectura, cada uno de ellos orientados a sectores que rigen el mercado actual de desarrollo de software, para ello lo describiremos a continuaciĂłn: ď&#x192;&#x2DC; El modelo composiciĂłn de aplicaciĂłn: Se emplea en los proyectos de software que se construyen a partir de software pre-empaquetados. En donde se emplean puntos objetos para estimar el tamaĂąo del software. ď&#x192;&#x2DC; El modelo diseĂąo temprano: Se utiliza en las primeras etapas del desarrollo en las cuales se evalĂşan las alternativas de hardware y software de un proyecto. En estas etapas se tiene poca informaciĂłn, lo que concuerda con el uso de Puntos FunciĂłn, para estimar tamaĂąo y el uso de un nĂşmero reducido de factores de costo. ď&#x192;&#x2DC; El modelo Post-Arquitectura: Se aplica en la etapa de desarrollo propiamente dicho, despuĂŠs que se define la arquitectura del sistema, y en la etapa de mantenimiento. Para tal caso tomaremos en cuenta el modo Post-Arquitectura, el cual utilizaremos para la estimaciĂłn econĂłmica del presente trabajo, puesto que este presenta un modelo de estimaciĂłn detallado y es aplicable cuando la arquitectura del proyecto estĂĄ completamente definido Siguiendo el modelo Post-Arquitectura se utilizaran las siguientes fĂłrmulas para el desarrollo de la estimaciĂłn del software (GĂłmez and LĂłpez and Migani, 1981): 14

â&#x2C6;&#x2018; đ??šđ??šđ??šđ??š] ď&#x192;&#x2DC; đ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ť = đ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??ś đ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ą Ă&#x2014; [0.65 + 0.01 Ă&#x2014;i=1

ď&#x192;&#x2DC; đ?&#x2018;Źđ?&#x2018;Źđ?&#x2018;Źđ?&#x2018;Źđ?&#x2018;Źđ?&#x2018;Źđ?&#x2018;´đ?&#x2018;´ = đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC;đ?&#x2018;&#x20AC; đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018; đ?&#x2018;&#x2122;đ?&#x2018;&#x2122;đ?&#x2018;&#x2122;đ?&#x2018;&#x2122;đ?&#x2018;&#x2122;đ?&#x2018;&#x2122; đ?&#x2018;Łđ?&#x2018;Łđ?&#x2018;Łđ?&#x2018;Łđ?&#x2018;Łđ?&#x2018;Łđ?&#x2018;Łđ?&#x2018;Łđ?&#x2018;Łđ?&#x2018;Łđ?&#x2018;Łđ?&#x2018;Łđ?&#x2018;Łđ?&#x2018;Ł đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019; đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019;đ?&#x2018;&#x2019; đ?&#x2018;&#x2122;đ?&#x2018;&#x2122;đ?&#x2018;&#x2122;đ?&#x2018;&#x2122;đ?&#x2018;&#x2122;đ?&#x2018;&#x2122; đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018; 17 đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;? đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018; đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?

ď&#x192;&#x2DC; đ?&#x2018;¨đ?&#x2018;¨ = 2.94

234 de 255

=

đ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??ś đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;

đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;? đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018; đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2018;đ?&#x2018;&#x2122;đ?&#x2018;&#x2122;đ?&#x2018;&#x2122;đ?&#x2018;&#x2122;đ?&#x2018;&#x2122;đ?&#x2018;&#x2122;


5

№Ѓў ­ЮЉЕ­ЮЉЕ = 1.01 + 0.01 ├Ќ РѕЉ ­ЮЉі­ЮЉі­ЮЉі­ЮЉі j=1

№Ѓў ­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉх­ЮЉх­ЮЉх­ЮЉх­ЮЉх­ЮЉх­ЮЉх­ЮЉх­ЮЉх­ЮЉх­ЮЉх­ЮЉх­ЮЉх­ЮЉх = ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ = ­Юљ┤­Юљ┤ ├Ќ (­ЮљЙ­ЮљЙ­ЮљЙ­ЮљЙ­ЮљЙ­ЮљЙ­ЮљЙ­ЮљЙ­ЮљЙ­ЮљЙ)­Юљх­Юљх

№Ѓў ­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ = ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ = №Ѓў ­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ,­ЮЉђ­ЮЉђ­ЮЉђ­ЮЉђ­ЮЉђ­ЮЉђ­ЮЉђ­ЮЉђ­ЮЉђ­ЮЉђ­ЮЉђ­ЮЉђ = ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ ­ЮЉђ­ЮЉђ├│­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ =

­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє

­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ

­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉџ­ЮЉџ├│­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ

­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ

№Ѓў ­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ,­ЮЉђ­ЮЉђ├│­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ = ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ ­ЮЉђ­ЮЉђ├│­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ = ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ­ЮЉЂ,­ЮЉђ­ЮЉђ├│­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ ├Ќ ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮЉђ­ЮЉђ рхЁ №Ѓў ­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ = ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ = РѕЉ ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ,­ЮЉђ­ЮЉђ├│­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉќ­ЮЉќ i= 1

№Ѓў ­ЮЉ╗­ЮЉ╗­ЮЉ╗­ЮЉ╗­ЮЉ╗­ЮЉ╗­ЮЉ╗­ЮЉ╗ = ­ЮЉЄ­ЮЉЄ­ЮЉЄ­ЮЉЄ­ЮЉЄ­ЮЉЄ­ЮЉЄ­ЮЉЄ ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ ­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи­Юљи ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ = 3.0 ├Ќ ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ(0.33+0.2├Ќ(­Юљх­ЮљхРѕњ1.01)) №Ѓў ­ЮЉф­ЮЉф­Юњљ­Юњљ­Юњћ­Юњћ­Юњћ­Юњћ­Юњћ­Юњћ­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг,­ЮЉ┤­ЮЉ┤­ЮЉ┤­ЮЉ┤­ЮЉ┤­ЮЉ┤ = ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ. = ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ Рѕњ ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ ├Ќ ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ,­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ

рхЁ №Ѓў ­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг = ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ = РѕЉ ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ,­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉю­ЮЉю­ЮЉќ­ЮЉќ

№Ѓў ­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮЉф­ЮњЉ­ЮњЉ­ЮњЉ­ЮњЉ­ЮњЉ­ЮњЉ ­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі­Юњі

i= 1

(­Юњј­Юњј­Юњј­Юњј­Юњј­Юњј­Юњј­Юњј­Юњј­Юњј $­Юњќ­Юњќ­Юњќ­Юњќ)

= ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ­ЮЉќ =

№Ѓў ­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи = ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ­ЮЉџ = ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ

­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљХ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ,­ЮЉђ­ЮЉђ├│­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ ­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉђ­ЮЉђ├│­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ

­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉђ­ЮЉђ├│­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉю­ЮЉю

­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ­ЮљИ,­ЮЉђ­ЮЉђ├│­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ

№Ѓў ­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉи­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг­ЮЉг = ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ­ЮЉЉ ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ­ЮЉЮ = ­ЮЉЃ­ЮЉЃ­ЮЉЃ­ЮЉЃ

­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє­ЮЉє

­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ­ЮЉњ

Mencionadas las formulas del modelo Post-Arquitectura se identificaran los m├│dulos que presenta el sistema de cobro de patentes ilustrados en la Tabla N┬║ 45. Tabla N┬║ 45: M├│dulos del sistema. N├║mero de modulo

1

2

Nombre del m├│dulo Herramienta de cobro de patentes M├│dulo web de obtenci├│n de proformas de pago FUENTE: [Elaboraci├│n Propia]

235 de 255

Siglas del m├│dulo

(HCP)

(MWOPP)


4.2.2.1 Módulo 1: Herramienta de cobro de patentes. Para obtener la cantidad de líneas de código LCD se utilizó las métricas orientadas a función (UFP) para este módulo, donde posteriormente se determinaran los niveles de complejidad de cada uno de los parámetros mencionados en la Tabla Nº 46. Tabla Nº 46: Ponderación de parámetros de medición – LDC. Factores de ponderación Parámetros de medición

Cuenta

Total Simple

Medio

Complejo

95

3

4

6

380

72

4

5

7

360

42

3

4

6

126

Número de Archivos Lógicos

12

7

10

15

120

Número de Interfaces Externas

33

5

7

10

231

Número

de

Entradas

de

Usuario Número de Salidas de Usuario Número de Peticiones

de

Usuario

Total Cuenta (UFP): 1217 FUENTE: [Elaboración Propia]

Posteriormente se calcula el factor de ajuste asignando un valor del 1 al 5 a cada uno de los factores, los cuales son descritos en la Tabla Nº 47, para lo cual tenemos que: 0 = No presente o no influencia 1 = Influencia insignificante o incidental. 2 = Influencia moderada. 3 = Influencia promedio o medio 4 = Influencia significante. 5 = Influencia Esencial o Fuerte.

236 de 255


Tabla NÂş 47: Valores de factores de ajuste â&#x20AC;&#x201C;LDC. Valor

Valor

Factor de ajuste

Factor de ajuste (1-5)

(1-5)

ComunicaciĂłn de Datos

4

ActualizaciĂłn en LĂ­nea

5

Proceso Distribuido

3

Liga de Proceso Interno Compleja

4

Objetivo de Rendimiento

4

Reusabilidad de CĂłdigo

4

ConfiguraciĂłn de ExplotaciĂłn Compartida

3

ConversiĂłn

de

InstalaciĂłn

Completada

0

Tasas de Transacciones

5

Facilidad de OperaciĂłn

4

Entradas de Datos de LĂ­nea

4

Instalaciones MĂşltiples

2

Eficiencia con el Usuario Final

4

Facilidad de Cambios

5 14

ďż˝ đ??šđ??šđ??šđ??š

51

đ?&#x2018;&#x2013;đ?&#x2018;&#x2013;=1

FUENTE: [ElaboraciĂłn Propia]

Utilizando la fĂłrmula del factor de complejidad tĂŠcnica (TFC) se tiene que la cantidad de lĂ­neas de cĂłdigo (LDC).

14

đ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ť = đ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??ś đ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ą Ă&#x2014; ďż˝0.65 + 0.01 Ă&#x2014; ďż˝ đ??šđ??šđ??šđ??š ďż˝ đ?&#x2018;&#x2013;đ?&#x2018;&#x2013;=1

đ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ť = 1217 Ă&#x2014; [0.65 + 0.01 Ă&#x2014; 51] = đ?&#x;?đ?&#x;?đ?&#x;?đ?&#x;?đ?&#x;?đ?&#x;?đ?&#x;?đ?&#x;?, đ?&#x;&#x2013;đ?&#x;&#x2013; đ?&#x2018;łđ?&#x2018;łđ?&#x2018;łđ?&#x2018;łđ?&#x2018;łđ?&#x2018;ł

237 de 255


Tabla Nº 48: Factores de costo en COCOMO II MUY

FACTORES DE COSTO

COMPUTADOR PROYECTO

ATRIBUTOS DEL

ATRIBUTOS DEL PERSONAL ATRIBUTOS DEL

ATRIBUTOS DEL PRODUCTO

Fiabilidad requerida del software Tamaño de la base de datos Documentación acorde las diferentes etapas del ciclo de vida Complejidad del producto Requerimientos de usabilidad Restricciones del tiempo de ejecución Restricciones del almacenamiento principal Volatilidad de la máquina virtual Capacidad del analista Experiencia en aplicaciones Capacidad de los programadores Experiencia en sistema operativo utilizado Experiencia con el lenguaje de programación Continuidad de personal Utilización de herramientas de software Limitaciones de planificación del desarrollo del proyecto Desarrollo multisitio

BAJO

BAJO

MEDIO

ALTO

MUY

EXTRA

ALTO

ALTO

RELY

0.82

0.92

1

1.10

1.26

-

DATA

-

0.90

1

1.14

1.28

-

DOCU

0.81

0.91

1

1.11

1.23

-

CPLX

0.73

0.87

1

1.17

1.34

1.74

RUSE

-

0.95

1

1.07

1.15

1.24

TIME

-

-

1

1.11

1.29

1.63

STOR

-

-

1

1.05

1.17

1.46

PVOL

-

0.87

1

1.15

1.3

-

ACAP

1.42

1.19

1

0.85

0.71

-

AEXP

1.22

1.10

1

0.88

0.81

-

PCAP

1.34

1.15

1

0.88

0.76

-

PEXP

1.19

1.09

1

0.91

0.85

-

LTEX

1.20

1.09

1

0.91

0.84

-

PCON

1.29

1.12

1

0.90

0.81

-

TOOL

1.17

1.09

1

0.90

0.78

-

SCED

1.43

1.14

1

1

1

-

SITE

1.22

1.09

1

0.93

0.86

0.80

Nota: Los valores marcados con fondo azul, son considerados seleccionados para la estimación.

FUENTE: [Silvina Migani]

𝑬𝑬𝑬𝑬𝑬𝑬𝟏𝟏 = 1.10 X 1 X 1.11 X 1 X 1 X 1 X 1 X 1 X 1 X 1.10 X 1.15 X 1 X 1 X 1 X 1.09 X 1 X 1.09 𝑬𝑬𝑬𝑬𝑬𝑬𝟏𝟏 = 1.835097677 [Conductores de Costo de Desarrollo] 238 de 255


4.2.2.2 Módulo 2: Módulo web de obtención de proformas de pago. Para obtener la cantidad de líneas de código LCD se utilizó las métricas orientadas a función (UFP) para este módulo, donde posteriormente se determinaran los niveles de complejidad de cada uno de los parámetros mencionados en la Tabla Nº 49. Tabla Nº 49: Ponderación de parámetros de medición – LDC. Factores de Ponderación Parámetros de Medición

Cuenta

Total Simple

Medio

Complejo

4

3

4

6

16

15

4

5

7

105

12

3

4

6

48

Número de Archivos Lógicos

6

7

10

15

60

Número de Interfaces Externas

13

5

7

10

91

Número

de

Entradas

de

Usuario Número de Salidas de Usuario Número de Peticiones

de

Usuario

Total Cuenta (UFP):

320

FUENTE: [Elaboración Propia]

Posteriormente se calcula el factor de ajuste asignando un valor del 1 al 5 a cada uno de los factores, los cuales son descritos en la Tabla Nº 50, para lo cual tenemos que: 0 = No presente o no influencia 1 = Influencia insignificante o incidental. 2 = Influencia moderada. 3 = Influencia promedio o medio 4 = Influencia significante. 5 = Influencia Esencial o Fuerte.

239 de 255


Tabla NÂş 50: Valores de factores de ajuste â&#x20AC;&#x201C;LDC. Valor

Valor

Factor de ajuste

Factor de ajuste (1-5)

ComunicaciĂłn de Datos

4

Proceso Distribuido

0

Objetivo de Rendimiento

3

ConfiguraciĂłn

de

ExplotaciĂłn Compartida Tasas de Transacciones Entradas de Datos de LĂ­nea Eficiencia con el Usuario Final

2

(1-5) ActualizaciĂłn en LĂ­nea

5

Liga de Proceso Interno Compleja Reusabilidad de CĂłdigo ConversiĂłn de InstalaciĂłn Completada

4 3 3

4

Facilidad de OperaciĂłn

4

4

Instalaciones MĂşltiples

2

5

Facilidad de Cambios

3 14

ďż˝ đ??šđ??šđ??šđ??š

46

đ?&#x2018;&#x2013;đ?&#x2018;&#x2013;=1

FUENTE: [ElaboraciĂłn Propia]

Utilizando la fĂłrmula del factor de complejidad tĂŠcnica (TFC) se tiene que la cantidad de lĂ­neas de cĂłdigo (LDC) 14

đ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ť = đ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??śđ??ś đ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ąđ?&#x2018;Ą Ă&#x2014; ďż˝0.65 + 0.01 Ă&#x2014; ďż˝ đ??šđ??šđ??šđ??š ďż˝ đ?&#x2018;&#x2013;đ?&#x2018;&#x2013;=1

đ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ťđ?&#x2018;ť = 320 Ă&#x2014; [0.65 + 0.01 Ă&#x2014; 46] = đ?&#x;&#x2018;đ?&#x;&#x2018;đ?&#x;&#x2018;đ?&#x;&#x2018;đ?&#x;&#x2018;đ?&#x;&#x2018;, đ?&#x;?đ?&#x;? đ?&#x2018;łđ?&#x2018;łđ?&#x2018;łđ?&#x2018;łđ?&#x2018;łđ?&#x2018;ł En la Tabla NÂş 51 se pueden observar los factores de costo para realizar el cĂĄlculo de conductores de costo de desarrollo (EAF), analizando los valores de complejidad y puntualizando este para cada uno de los factores de costo.

240 de 255


Tabla Nº 51: Factores de costo en COCOMO II MUY

FACTORES DE COSTO

COMPUTADOR PROYECTO

ATRIBUTOS DEL

ATRIBUTOS DEL PERSONAL ATRIBUTOS DEL

ATRIBUTOS DEL PRODUCTO

Fiabilidad requerida del software Tamaño de la base de datos Documentación acorde las diferentes etapas del ciclo de vida Complejidad del producto Requerimientos de usabilidad Restricciones del tiempo de ejecución Restricciones del almacenamiento principal Volatilidad de la máquina virtual Capacidad del analista Experiencia en aplicaciones Capacidad de los programadores Experiencia en sistema operativo utilizado Experiencia con el lenguaje de programación Continuidad de personal Utilización de herramientas de software Limitaciones de planificación del desarrollo del proyecto Desarrollo multisitio

BAJO

BAJO

MEDIO

ALTO

MUY

EXTRA

ALTO

ALTO

RELY

0.82

0.92

1

1.10

1.26

-

DATA

-

0.90

1

1.14

1.28

-

DOCU

0.81

0.91

1

1.11

1.23

-

CPLX

0.73

0.87

1

1.17

1.34

1.74

RUSE

-

0.95

1

1.07

1.15

1.24

TIME

-

-

1

1.11

1.29

1.63

STOR

-

-

1

1.05

1.17

1.46

PVOL

-

0.87

1

1.15

1.3

-

ACAP

1.42

1.19

1

0.85

0.71

-

AEXP

1.22

1.10

1

0.88

0.81

-

PCAP

1.34

1.15

1

0.88

0.76

-

PEXP

1.19

1.09

1

0.91

0.85

-

LTEX

1.20

1.09

1

0.91

0.84

-

PCON

1.29

1.12

1

0.90

0.81

-

TOOL

1.17

1.09

1

0.90

0.78

-

SCED

1.43

1.14

1

1

1

-

SITE

1.22

1.09

1

0.93

0.86

0.80

Nota: Los valores marcados con fondo azul, son considerados seleccionados para la estimación.

FUENTE: [Silvina Migani]

𝑬𝑬𝑬𝑬𝑬𝑬𝟐𝟐 = 1.10 X 1 X 1.11 X 1 X 1 X 1 X 1 X 0.87 X 1 X 1.10 X 1.15 X 1 X 1 X 1 X 1.09 X 1 X 1.09 𝑬𝑬𝑬𝑬𝑬𝑬𝟐𝟐 = 1.596534979 [Conductores de Costo de Desarrollo] 241 de 255


Realizando el cĂĄlculo para el factor exponencial de escala â&#x20AC;&#x153;Bâ&#x20AC;?, se tienen los siguientes datos que se muestran en la Tabla NÂş 52. Tabla NÂş 52: Factor de escala. Muy

Factores de Escala đ?&#x2018;žđ?&#x2018;žđ?&#x2019;&#x2039;đ?&#x2019;&#x2039; Procedencia Flexibilidad en el desarrollo

Bajo

Bajo

Normal

Alto

Muy Alto

Extra

PREC

6.20

4.96

3.72

2.48

1.24

0.00

FLEX

5.20

4.05

3.04

2.03

1.01

0.00

RESL

7.07

5.65

4.24

2.83

1.41

0.00

TEAM

5.48

4.38

3.29

2.19

1.10

0.00

PMAT

7.80

6.24

4.68

3.12

1.15

0.00

Arquitectura / ResoluciĂłn de Riesgo CohesiĂłn de Equipo Madurez del Proceso

FUENTE: [Bohem COCOMO II]

Seguidamente se efectuara el cĂĄlculo del costo del proyecto utilizando los valores obtenidos anteriormente, aplicando las formulas mencionadas en la PĂĄgina 234-235. El primer cĂĄlculo es el esfuerzo nominal requerido para desarrollar el sistema y se calcula de la siguiente forma:

DĂłnde:

đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; = đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸ đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; đ?&#x2018; = đ??´đ??´ Ă&#x2014; (đ??žđ??žđ??žđ??žđ??žđ??žđ??žđ??žđ??žđ??ž)đ??ľđ??ľ

5

đ??žđ??žđ??žđ??žđ??žđ??žđ??žđ??žđ??žđ??ž =

đ??´đ??´ = 2.94

1411.8 + 355.2 = 1.767 1000

đ??ľđ??ľ = 1.01 + 0.01 Ă&#x2014; ďż˝ đ?&#x2018;&#x160;đ?&#x2018;&#x160;đ?&#x2018;&#x160;đ?&#x2018;&#x160; = 1.01 + 0.01 â&#x2C6;&#x2014; (3.72 + 2.03 + 2.83 + 3.29 + 3.12) = 1.16 đ?&#x2018;&#x2014;đ?&#x2018;&#x2014;=1

242 de 255


Entonces: 𝑃𝑃𝑃𝑃𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 = 2.94 ∗ (1.767)1.16 = 5.679180659 �

El cálculo de la productividad se muestra a continuación:

𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 � 𝑚𝑚𝑚𝑚𝑚𝑚

𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 = 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 𝑑𝑑𝑒𝑒𝑒𝑒 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 = 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 =

𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝑃𝑃𝑃𝑃𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁

1767 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 = 311.1364308 � 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝� 5.679180659 𝑚𝑚𝑚𝑚𝑚𝑚

Lo siguiente es calcular el esfuerzo nominal por módulos, según la siguiente fórmula: 𝑃𝑃𝑃𝑃𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 ,𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛 𝑝𝑝𝑝𝑝𝑝𝑝 𝑚𝑚ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 =

Módulo 1: Herramienta de Cobro de Patentes (HCP)

𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁

𝑃𝑃𝑃𝑃𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 ,𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 =

1411.8 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 = 4.537559283 ≅ 5 � � 311.1364308 𝑚𝑚𝑚𝑚𝑚𝑚

𝑃𝑃𝑃𝑃𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 ,𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 =

355.2 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 = 1.141621375 ≅ 1 � � 311.1364308 𝑚𝑚𝑚𝑚𝑚𝑚

Módulo 2: Módulo Web de Obtención de Proformas de Pago. (MWOPP)

Consecutivamente se realiza el esfuerzo estimado por cada módulo, mediante la siguiente fórmula: 𝑃𝑃𝑃𝑃𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 ,𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 𝑝𝑝𝑝𝑝𝑝𝑝 𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚 = 𝑃𝑃𝑃𝑃𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 ,𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 ∗ 𝐸𝐸𝐸𝐸𝐹𝐹𝑀𝑀

Módulo 1: Herramienta de Cobro de Patentes (HCP)

𝑃𝑃𝑃𝑃𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 ,𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 4.537559283 × 1.83 = 8.303733488 �

𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 � 𝑚𝑚𝑚𝑚𝑚𝑚

Módulo 2: Módulo Web de Obtención de Proformas de Pago. (MWOPP) 𝑃𝑃𝑃𝑃𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 ,𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 1.141621375 × 1.60 = 1.8265942 �

𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 � 𝑚𝑚𝑚𝑚𝑚𝑚

El siguiente cálculo es para hallar el esfuerzo estimado del proyecto: 𝑎𝑎

𝑃𝑃𝑃𝑃𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 = 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 = � 𝑃𝑃𝑃𝑃𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸,𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑖𝑖 𝑖𝑖=1

243 de 255


𝑃𝑃𝑃𝑃𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 = 8.303733488 + 1.8265942 = 10.13032769 �

𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 � 𝑚𝑚𝑚𝑚𝑚𝑚

Así mismo es necesario calcular el tiempo de desarrollo del proyecto:

𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 = 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝑑𝑑𝑑𝑑 𝑑𝑑𝑑𝑑𝑑𝑑. 𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 𝑑𝑑𝑑𝑑𝑑𝑑 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 = 3.0𝑥𝑥𝑃𝑃𝑃𝑃𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 (0.33+0.2∗(𝐵𝐵−1.01)) 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 = 3.0 × 10.13032769(0.33+0.2∗(1.16−1.01)) = 6.904714288[𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚]

A continuación se va a determinar el costo mes - persona, considerando que el salario mínimo en Bolivia es de 1200 Bs = 173,6616 $us. El cálculo se muestra a continuación: 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸,𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝑚𝑚𝑚𝑚𝑚𝑚 − 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 ∗ 𝑃𝑃𝑃𝑃𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸,𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 ( 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 𝑝𝑝𝑝𝑝𝑝𝑝 𝑚𝑚ó𝑑𝑑𝑢𝑢𝑙𝑙𝑙𝑙)

Módulo 1: Herramienta de Cobro de Patentes (HCP)

𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸,𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 173,6616 × 8.303733488 = 1442.039643[$𝑢𝑢𝑢𝑢]

Módulo 2: Módulo Web de Obtención de Proformas de Pago. (MWOPP) 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸,𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 173,6616 × 1.8265942 = 317.2092713[$𝑢𝑢𝑢𝑢]

Ahora se obtiene el costo estimado del proyecto, mediante la siguiente formula: 𝑎𝑎

𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 𝑑𝑑𝑑𝑑𝑑𝑑 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 = � 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸,𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑖𝑖 𝑖𝑖=1

𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝑎𝑎𝑎𝑎𝑎𝑎 = 1442.039643 + 317.2092713 = 𝟏𝟏𝟏𝟏𝟏𝟏𝟏𝟏. 𝟐𝟐𝟐𝟐𝟐𝟐𝟐𝟐𝟐𝟐𝟐𝟐[$𝒖𝒖𝒖𝒖]

Lo siguiente es obtener el costo estimado por módulo considerando las líneas de código que se obtuvieron anteriormente: 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑃𝑃𝑃𝑃𝑃𝑃 𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖ó𝑛𝑛 (𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚 $𝑢𝑢𝑢𝑢) = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝑝𝑝𝑝𝑝𝑝𝑝 𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖ó𝑛𝑛 =

Módulo 1: Herramienta de Cobro de Patentes (HCP)

𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸,𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑

𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑃𝑃𝑃𝑃𝑃𝑃 𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖ó𝑛𝑛 (𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚 $𝑢𝑢𝑢𝑢) =

1442.039643 𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚 𝑆𝑆𝑆𝑆𝑆𝑆 = 1.021419212 � � 1411.8 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆

𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑃𝑃𝑃𝑃𝑃𝑃 𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖ó𝑛𝑛 (𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚 $𝑢𝑢𝑢𝑢) =

317.2092713 𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚 𝑆𝑆𝑆𝑆𝑆𝑆 = 0.8930441197 � � 355.2 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆

Módulo 2: Módulo Web de Obtención de Proformas de Pago. (MWOPP)

244 de 255


Se debe obtener la productividad de cada módulo: 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 = 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 𝑝𝑝𝑝𝑝𝑝𝑝 𝑚𝑚ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 =

Módulo 1: Herramienta de Cobro de Patentes (HCP) 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 =

𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 𝑃𝑃𝑃𝑃 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸,𝑀𝑀ó𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑

1411.8 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 = 170.0199076 � 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝� 8.303733488 𝑚𝑚𝑚𝑚𝑚𝑚

Módulo 2: Módulo Web de Obtención de Proformas de Pago. (MWOPP) 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 =

355.2 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 = 194.4602693 � 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝� 1.8265942 𝑚𝑚𝑚𝑚𝑚𝑚

Así mismo se obtiene la productividad del proyecto:

𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 = 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 𝑑𝑑𝑑𝑑𝑑𝑑 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 = 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 =

𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝑃𝑃𝑃𝑃 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸

1767 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 = 174.4267366 � 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝� 10.13032769 𝑚𝑚𝑚𝑚𝑚𝑚

Una vez que se ha realizado todos los cálculos de COCOMO II, se obtiene una tabla final donde se muestran los resultados obtenidos para cada módulo como también para el proyecto en su totalidad: Tabla Nº 53: Tabla final de COCOMO II

21

𝑷𝑷𝑷𝑷𝑵𝑵𝑵𝑵𝑵𝑵 𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑 � � 𝒎𝒎𝒆𝒆𝒔𝒔

22

𝑷𝑷𝑷𝑷𝑬𝑬𝑬𝑬𝑬𝑬 𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑 � � 𝒎𝒎𝒎𝒎𝒎𝒎

23

Costo 𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑 � � 𝒎𝒎𝒎𝒎𝒎𝒎 [$𝒖𝒖𝒖𝒖]

Costo estim. [$𝒖𝒖𝒖𝒖]

25

Costo Instruc. 𝑴𝑴𝑴𝑴𝑴𝑴𝑴𝑴𝑴𝑴 � � $𝒖𝒖𝒖𝒖

26

Productividad 𝑺𝑺𝑺𝑺𝑺𝑺𝑺𝑺 � 𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑� 𝒎𝒎𝒎𝒎𝒎𝒎

1411.8

1.835

4.537

8.303

173.662

1442.039

1.021

170.019

MWOPP

355.2

1.596

1.142

1.826

173.662

317.209

0.893

194.460

28

1767

31

10.130

32

1759.248

Nro. de Mod.

Nombre del módulo

Líneas de código

EAF

1

2

3

1

HCP

2 𝑺𝑺𝑺𝑺𝑺𝑺𝑺𝑺𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷 𝑷𝑷𝑷𝑷𝑵𝑵𝑵𝑵𝑵𝑵 𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑 � � 𝒎𝒎𝒎𝒎𝒎𝒎

𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑵𝑵𝑵𝑵𝑵𝑵 𝑺𝑺𝑺𝑺𝑺𝑺𝑺𝑺 � 𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑� 𝒎𝒎𝒎𝒎𝒎𝒎

29

5.679

30

311.134

𝑃𝑃𝑃𝑃𝐸𝐸𝐸𝐸𝐸𝐸 𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑 � � 𝒎𝒎𝒎𝒎𝒎𝒎 𝑻𝑻𝑻𝑻𝑻𝑻𝑻𝑻 [𝒎𝒎𝒎𝒎𝒎𝒎]

34

6.904

24

Costo estim. [$𝒖𝒖𝒖𝒖]

FUENTE: [Elaboración Propia]

245 de 255

27

33

174.426

Product. estim. 𝑺𝑺𝑺𝑺𝑺𝑺𝑺𝑺 � 𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑� 𝒎𝒎𝒎𝒎𝒎𝒎


Uno de los cĂĄlculos mĂĄs importantes es la cantidad de personal promedio para el desarrollo del presente proyecto, el cual se obtiene mediante la siguiente formula:

đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192; =

đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192; =

đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ?&#x2018;&#x192;đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸đ??¸ đ?&#x2018;&#x2021;đ?&#x2018;&#x2021;đ?&#x2018;&#x2021;đ?&#x2018;&#x2021;đ?&#x2018;&#x2021;đ?&#x2018;&#x2021;đ?&#x2018;&#x2021;đ?&#x2018;&#x2021;

10.13032769 = 1.467161025 [đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?đ?&#x2018;?] 6.904714288

Interpretando los valores obtenidos en la tabla se concluye que: â&#x20AC;˘

En el proyecto existen: 1767 lĂ­neas de cĂłdigo funcionales.

â&#x20AC;˘

Existe un esfuerzo estimado de 10 personas por mes

â&#x20AC;˘

El tiempo de desarrollo del es de 7 meses.

â&#x20AC;˘

Se requiere de 1 programador para el desarrollo del proyecto.

â&#x20AC;˘

El costo total del proyecto es: 1759$us. Tabla NÂş 54: Tabla final de viabilidad econĂłmica. ConsideraciĂłn

Monto ($us)

Costo por tecnologĂ­a (Hardware-Software)

2550

Costo por mano de obra (COCOMO II)

1759

Total

4309

FUENTE: [ElaboraciĂłn Propia]

Habiendo realizado los resultados de los cĂĄlculos efectuados del sistema mediante COCOMO II, asĂ­ como la estimaciĂłn de equipamiento tecnolĂłgico para el funcionamiento del sistema se determina que el costo del proyecto es 4309 $us. (DĂłlares Americanos) estimados. Este precio es aceptable considerando el esfuerzo y la magnitud del proyecto, por lo tanto se considera que el trabajo de grado es viable econĂłmicamente.

246 de 255


4.3 VIABILIDAD OPERATIVA. Dentro del análisis de viabilidad operativa para el presente trabajo se identificaran los beneficios y la manera de gestionar tanto la herramienta de cobro de patentes como el modulo web para el usuario final. La herramienta de cobro de patentes mediante la intermediación financiera aplicando enlace en línea entre entidades permitirá que el proceso centralizado pueda ser distribuido, quiere decir que los contribuyente podrán acceder a cancelar su patente en cualquier entidad financiera con la que este asociada la Alcaldía. Así también el módulo web para la obtención de la proforma de pago, donde el contribuyente podrá acceder a la página web, verificar su estado de cuentas y poder imprimir su proforma de pago. 1. Herramienta de cobro de patentes. Principalmente intervienen tres usuarios los cuales estarán encargados de manejar la herramienta. a. Administración de sistemas: Para la entidad financiera un administrador especializado en el área de sistemas informáticos con conocimientos de redes, seguridad y capacitación para la herramienta de cobro de patentes. Administrador de entidad financiera: Gestiona la herramienta de cobro de patentes correspondiente a la entidad financiera, este usuario está encargado de efectuar reportes de cobros efectuados en las agencias o sucursales pertenecientes a la entidad bancaria, como también administra a los usuarios cajeros habilitando o inhabilitándolos. b. Administración de sistemas: Para el lado de la Alcaldía un administrador especializado en sistemas informáticos y tecnologías de información relacionadas con conocimientos sobre MySQL, servidor apache, redes y seguridad. Administrador de la alcaldía: Gestiona la herramienta de cobro de patentes en general ya que puede crear y habilitar entidades financieras, visualizar los estados económicos por entidades financieras, gestionar todo referente al cobro de patentes, tales funciones como el de extraer detalles generales por cada contribuyente a cerca del impuesto y realizar los respectivos descuentos a partir de la fecha límite de cancelación. 247 de 255


c. Usuario final de la herramienta de cobro de patentes: Funcionario seleccionado y capacitado en procesamiento de transacciones mediante sistemas informáticos pertenecientes a la entidad financiera. Usuario cajero: Encargado de Efectuar los pagos del impuesto de la patente, como otorgar la proforma de pago al contribuyente, entre otras funcionalidades el usuario cajero puede anular comprobantes de pago ya sea por pagos mal efectuados, cambiar su contraseña de ingreso a la herramienta así como realizar el balance de caja diario al final de día, un reporte importante para verificar la concordancia de cobros realizados en la entidad financiera durante la jornada Esta herramienta fue desarrollada de manera que el usuario final pueda manejar y entender las funcionalidades para efectuar el cobro de patentes, como también sea intuitivos para su respectivo uso. 2. Módulo web de obtención de proforma de pago. Básicamente está dirigida a un solo usuario: a. Usuario final del módulo web: Persona que tenga experiencia en el manejo básico de navegación por internet. Contribuyente: Persona encargada de visualizar su estado de cuentas denominado proforma de pago. Principalmente el contribuyente accede a la página web y se autentica ingresando el número de Cédula de Identidad, donde podrá verificar el detalle de patente e imprimir este documento. El modulo web de obtención de proforma de pago fue desarrollada de manera que el usuario contribuyente tenga acceso de manera eficiente a verificar su estado de cuentas mediante la página web, teniendo una interfaz amigable e intuitiva para su uso. Teniendo en cuenta los beneficios que brinda tanto la herramienta de cobro de patentes como el modulo web para la obtención de proformas de pago. Se puede concluir que el sistema brinda al usuario final la facilidad de cancelar sus impuestos en una entidad financiera, como también obtener el detalle de su patente mediante la página web, por lo cual se concluye que la propuesta es operativamente viable.

248 de 255


5

CONCLU SION ES Y REC OMEND AC ION ES.

5.1 CONCLUSIONES. En el presente trabajo de grado fueron efectuados el análisis, la evaluación y aplicación tanto a la herramienta de cobro de patentes como al módulo web, para lo cual se puede mencionar que se alcanzaron los objetivos generales y específicos, obteniendo las siguientes conclusiones:  Mediante métodos de recolección de datos como entrevistas/encuestas y con el asesoramiento de un funcionario del área de sistemas se logró recabar información acerca del proceso actual de cobro de patentes y la obtención de proformas de pago del Gobierno Autónomo Municipal de Cochabamba, para lograr entender el proceso y obtener la información oportuna se tuvo que estar de forma presencial en la Alcaldía, y como resultado se consiguió la estructura básica de la base datos, las normativas y formulas empleadas como también se pudo obtener una parte del código empleado para el cobro de patentes. En base a esta información se logró analizar, modelar y aplicar al desarrollo de la herramienta de cobro de patentes y módulo web de obtención de proformas de pago.  Mediante un análisis de comparación y valoración se seleccionó a la metodología UP (Proceso unificado), la cual permitió el desarrollo del sistema a través una serie de diagramas de modelamiento, permitiendo así tener en cada ciclo la retroalimentación e iteraciones correspondientes a la herramienta de cobro de patentes y módulo web.  Para lograr obtener información acerca del proceso para la obtención de proformas de pago de la Alcaldía, se tuvo que aproximar a las instalaciones del CEMAC y presenciar cómo se accede a ventanilla de proformas especiales para recabar información acerca de patentes. En base a la información obtenida se pudo modelar el proceso alternativo y seleccionando el gestor de base de datos MySQL, utilizando como plataforma de desarrollo al lenguaje de programación PHP y aplicando la metodología (UP) se desarrolló una página web en donde el contribuyente puede ingresar de manera eficiente para visualizar el estado de cuentas de la patente e imprimir este documento el cual es denominado “Proforma de Pago”, con el cual le permitirá cancelar su impuesto. 249 de 255


Mediante la revisión de normativas y circulares que otorga la ASFI (Autoridad de Supervisión del Sistema Financiero) a través de su página web se pudo obtener los requerimientos de seguridad en lo que respecta a la intermediación financiera, también se logró recabar información de varios jefes de sistemas de diferentes entidades bancarias mediante encuestas y entrevistas personales sobre los requerimientos técnicos del enlace en línea. Con esta información obtenida se logró diseñar la conexión entre entidades, teniendo en cuenta la arquitectura.

 Para recabar información sobre el proceso actual de cobro de patentes de la Alcaldía de Cochabamba fue necesario aproximase a la unidad de recaudaciones ubicada en el CEMAC para presenciar el procedimiento que el contribuyente tiene que realizar para cancelar su impuesto de la patente, y también se pudo obtener el formato base del comprobante de pago el cual se le otorga al cliente cuando cancela el impuesto. Mediante la información obtenida se realizó el análisis, modelado, selección del gestor de base de datos MySQL y utilizando la plataforma Microsoft Visual Studio 2010 se desarrolló de la herramienta de cobro de patentes la cual se ubicó en una entidad financiera donde el contribuyente puede cancelar su patente de manera directa y eficiente. Logrando obtener así un incremento de 8500 contribuyentes atendidos en las entidades financieras por la disposición de 17 ventanillas.  Aplicada las pruebas finales de caja negra, caja blanca y carga tanto a la herramienta de cobro de patentes como al módulo web de obtención de proformas de pago, se logró tener un sistema que cumple con los criterios de calidad originando su buen funcionamiento, y asi teniendo un sistema comprensible y fácil de usar. Finalmente como conclusión general se lograron cumplir con los objetivos establecidos, los cuales permitieron el desarrollo de la herramienta de cobro de patentes y el módulo web para la obtención de proformas de pago, consiguiendo reducir largas filas de contribuyentes e incrementando los puntos de cobro de patentes, así también disminuyendo el tiempo en la obtención de proformas de pago mediante la página web, con lo cual se da solución al problema actual de la Alcaldía de Cochabamba. 250 de 255


5.2 RECOMENDACIONES. A continuación se presentarán algunas recomendaciones en lo que respecta al presente trabajo así como posibles mejoras:

5.2.1 Recomendación para la herramienta de cobro de patentes.  Para que la herramienta pueda ser integrada a otros sistemas con los que trabaja actualmente la Alcaldía, se recomienda tener en cuenta el gestor de base de datos y la arquitectura que se empleó en la herramienta.  Se recomienda una capacitación previa para los tres tipos de usuarios que utilizaran la herramienta, explicar que función cumple cada uno de ellos, la participación correcta a la hora de interactuar con los datos que deben ser introducidos a la herramienta.  Se recomienda cambiar las contraseñas de las credenciales de los usuarios de Caja, Administradores de Entidades Financieras y Administrador de la Alcaldía periódicamente de manera que aumenten la seguridad de acceso a la herramienta de cobro de patentes.  Se recomienda tener un seguimiento del sistema (Logs) con criterios de búsqueda específico, de manera que se pueda obtener la información requerida según las necesidades existentes.  Considerando las funcionalidades que brinda la herramienta de cobro de patentes se recomienda agregar nuevos opciones tales como: administrar login o nombre de los usuarios, realizar reportes estadísticos para visualizar los cobros efectuados dentro de la entidad financiera y que el usuario cajero tenga la opción de cambiar la UFV que ingresa diariamente.  Se recomienda mejorar las funcionalidades del administrador de entidad financiera para que pueda realizar otros tipos de reportes, gestionar cajeros y sucursales de forma minuciosa, etc.

251 de 255


5.2.2 Recomendaciones para el módulo web de obtención de proformas de pago.  Se recomienda agregar un módulo el cual permita gestionar las cuentas de acceso de los contribuyentes, está refriéndose a recuperar su contraseña mediante correo electrónico asociado a su cuenta de usuario, ya que actualmente solo ingresa por el número de cédula de identidad (C.I.)  Se recomienda aplicar el modulo web generando otro tipo de formulación para otros sistemas que trabajan con actividades económicas dentro de la Alcaldía, tomando en cuenta la metodología y los usuarios que ingresen a la página web.  Se recomienda mejorar la interfaz de inicio de la página web, a través de anuncios publicitarios dinámicos, noticias de patentes actualizadas y la ubicación de las entidades financieras que están asociadas a la Alcaldía.

252 de 255


BIBLIOGRAFÍA.  ASFI

(7

de

septiembre

de

2013).

Circulares

ASFI

[En

línea]

“https://www.asfi.gob.bo/Normativa/Circulares”  Barrantes R. (2000). “Investigación: Un Camino Al Conocimiento. Un Enfoque Cuantitativo Y Cualitativo”; 2da Edición. San José Costa Rica. EUNED.  Blake R. (2009). “Sistemas Electrónicos”, 2da Edición.  Booch G., Rumbaugh J., (2006). “El Lenguaje Unificado de Modelado: Guía de Usuario”; Segunda Edición, Pearson Addison Wesley. Madrid (España).  Booch G., Rumbaugh J., (2006). “El lenguaje unificado de modelado: UML 2.0”, 2da edición, Madrid – España, Pearson Education.  Canós J. (2005) “Metodologías Ágiles en el Desarrollo de Software”. Universidad Politécnica de Valencia.  Circular

ASFI

150

(2012).

“Reglamento

para

constitución,

adecuación,

funcionamiento, disolución y clausura de las empresas remesadoras”  Elmasri R., Navathe S., (2004). “Sistemas de Bases de Datos: conceptos fundamentales”, 2da edición, México DF, Addison Wesley.  Fassil S.A. (2013). “Sistema de Recepción de Pagos”.  Ferguson J., Patterson B., (2003). “La Biblia de C Sharp”, 2da edición, Madrid – España, Anaya Multimedia.  Gómez A., López M., (2000). “Un Modelo de Estimación de Proyectos de Software COCOMO II”.  Gutiérrez J. (2011). “Productos y servicios en Banca”, 1era Edición.  Jacobson I., Booch G., (2006) “El Proceso Unificado de Desarrollo de Software”; 1era edición español, España, Pearson Education.

253 de 255


 Kuainasi

(20

de

mayo

de

2013)

Modelado

de

Negocios

[En

línea]

“http://kuainasi.ciens.ucv.ve/ideas07/documentos/conferencias/conferenciajonasm ontilva.pdf”  Ley Nº 1488. Ley de bancos y entidades financieras (1993). “Capítulo 1: Artículo 3. Bolivia”  Macedonio

J.

(1769).

Archivo

histórico

del

municipio;

ISO/IEC

17799/2005

“Municipio

cabildo/ayuntamiento”.  Mmujica

(7

de

septiembre

de

2013).

[En

línea]

“https://mmujica.files.wordpress.com/2007/07/iso-17799-2005-castellano.pdf”  Nexun.org.

(1

de

mayo

de

2013)

Servidor

IIS

[En

línea].

”http://documentacion.nexun.org/mediawiki/index.php/5._Introducción_a_IIS._Versi ones_disponibles._Métodos_y_características_principales._Opciones_de_instalaci ón”  Ordenanza Municipal 4369 (2012). “Consejo Municipal de la provincia del cercado del departamento de Cochabamba”.  Orfali R. (2002). “Cliente/Servidor y objetos”, 3ra edición, México DF, Editorial Mexicana.  Pando Y. (2009), “SQL Server 2008”, MACRO, Lima- Perú. 1era edición.  Pavón J. (2007). “Creación de un portal con PHP y MySQL”, 3era edición, Madrid – España, Alfaomega Grupo Editor.  Peter R. (2004). “Sistemas de bases de datos, Diseño implementación y administración”, 5ta. Ed, Thomson.  Pressman R. (2012). “Ingeniería del Software: Un enfoque Práctico”; Séptima edición; publicado por Mc-GrawHill

254 de 255


 Seguridad informática (7 de septiembre de 2013). Normas de las Políticas de Seguridad

Informática

[En

línea].”http://seguridadinformaticaufps.wikispaces.com/Normas,+estandares,+Leye s+y+demas+de+las+politicas+de+seguridad.+1150204-159-250-214”  Silberschatz A. (2002). “Fundamentos de Bases de Datos”, 4ta edición, editorial Mc Graw Hill.  Somerville I. (2005). “Ingeniería del Software”; Séptima Edición, Editorial Pearson Educación, Madrid.

255 de 255


AN EXOS


ANEXO A


Ejemplo: Calculo del patente de la gesti贸n 2012

Calculo: Tabla de Patente Municipal seg煤n Gesti贸n 2012

1. De acuerdo superficie que ocupa el contribuyente es de 1.00 (M2). Por consiguiente seg煤n a la tabla de patente municipal. El contribuyente tiene:


Impuesto Determinado = 55Bs.

Ufv Vencida = Es el ultimo cálculo de la ufv por cada gestión, ya que las ufv’s se actualizan por día de acuerdo a ordenanza municipal. Para la gestión 2012 el último cálculo de la ufv. Es de= 1.79577

Teniendo el impuesto determinado y la ufv vencida tenemos la columna de Impuesto Determinado en Ufvs.


55 ÷ 1.79577 = 30.63

En la columna de descuento de Ufvs se aprecia cuando el contribuyente tiene algún descuento según la Ufv en este caso es “0”.

El interés de Ufvs se calcula cada gestión en este caso es “0”

La multa del Incumplimiento de Deberes Formales (IDF) por Ufvs es de “50”


La columna de descuento aplicado es una opción para que el contribuyente pueda tener una rebaja de hasta el 80% de su patente, en este caso el contribuyente no tiene ningún tipo de descuento, por lo tanto es “0”.

Para el cálculo de la deuda tributaria Ufvs se tiene la siguiente operación: Impuesto Determinado en Ufvs + Descuento Ufvs + Interes Ufvs + Multa IDF Ufvs - Dscto (%) Aplicado.

30.63 + 0 + 0 + 50 – 0 = 81


Finalmente para calcular el total del patente se realiza lo siguiente: Deuda tributaria Ufvs * Ufv actual

81*1.81432 = 146.95 =147


ANEXO B


ANEXO C GOBIERNO AUTONOMO MUNICIPAL DE COCHABAMBA

Organigrama del Gobierno Aut贸nomo Municipal de Cochabamba 2013


UNIDAD DE SISTEMAS. Es una unidad institucional del Municipio del Cercado, dependiendo de la oficialía mayor administrativa y financiera, la función principal que cumple esta unidad es del funcionamiento, administración y seguridad de los sistemas con los que cuenta actualmente la Alcaldía del Cochabamba, entre estos sistemas se encuentran: •

Sistemas de valores.- Este sistema está encargado de administrar los depósitos de las cajas 22 puestas a disposición del contribuyente en las diferentes comunas, entre estos depósitos se pueden mencionar: venta de timbres23, folders, planillas de llenado para el pago de valores, etc. Este sistema está desarrollado en un lenguaje de programación Visual Basic con la versión 6.0, sustentado con un gestor de base de datos SQL 2005.

Sistemas de ingresos.- Sistema utilizado por la unidad de recaudación, este sistema es encargado de verificar las recaudaciones y mostrar un detalle de los ingresos diarios. Este sistema está desarrollado en un entorno de programación Visual .net, con una base de datos Oracle.

Sistemas de bienes.- Este sistema está encargado de inventariar equipos computacionales (laptops, computadoras de escritorio, impresoras), material administrativo (sillas, mesas, escritorios) y material de escritorio que son adquiridas por la alcaldía de Cochabamba. Este sistema está desarrollado en un entorno de programación ASP.net, con una base de datos Oracle.

Sistemas de correspondencia.- Sistema encargado de administración de documentación que se envía a nivel local e interdepartamental mediante una hoja de ruta. Una hoja de ruta es un plan que establece a grandes rasgos la secuencia de pasos para alcanzar un objetivo. Se especifican tiempo y recursos necesarios.

22 23

Cajas: Ventanillas puestas a disposición del contribuyente para la cancelación de algún servicio. Timbres: Documento propio de aceptación de valores.


Puede entenderse como un plan de acción a largo o mediano plazo que acerca los objetivos estratégicos a objetivos más tangibles y alcanzables. Este sistema está desarrollado en un entorno de programación ASP.net, con una base de datos Oracle. •

Sistema de proyectos.- Sistema encargado de la administración del detalle de proyectos como ser obras públicas (Infraestructura y mejoramiento de barrios, alumbrado público, planta de asfalto, señalización y semaforización) y la gestión de obras contratadas (control de obras). Este sistema está desarrollado en un entorno de programación ASP.net, con una base de datos Oracle.

Sistemas de sitios y mercados.- Sistema encargado de la administración de cobro de patentes por cada contribuyente, este sistema se encuentra en las instalaciones del CEMAC dentro del área de actividades económicas. básicamente este sistema utiliza formulas establecidas por el código tributario, para el cálculo de la patente, así como también se basa en los montos especificados en la ordenanza municipal. Este sistema está desarrollado en un lenguaje de programación Visual Basic. 6.0, con un sistema de gestión de base de datos Microsoft Access.

CONEXIÓN DE LAS DIFERENTES COMUNAS Y CEMAC AL SERVIDOR CENTRAL DEL GOBIERNO AUTONOMO MUNICIPAL DE COCHABAMBA (GAMC). El gobierno autónomo municipal de Cochabamba está dividido en sub alcaldías las cuales son:  Comuna Tunari.  Comuna Molle.  Comuna Alejo Calatayud.  Comuna Adela Zamudio.  Comuna Itocta.  Comuna Valle hermoso.


Estas sub alcaldías se encuentra conectadas mediante una red privada Intranet al servidor que está ubicado en las instalaciones de la plaza 14 de septiembre, dentro del edificio de la alcaldía de Cochabamba. El centro municipal de atención al contribuyente CEMAC es otro de los edificios que se encuentran conectados al servidor central. Esta conexión intranet permite que puedan compartir recursos, almacenar información de los diferentes sistemas que se encuentran en las comunas, actualmente la alcaldía cuenta con un servidor Windows Server 2003 de 64 bits, en la figura Nº 4 se observa la conexión de las comunas al servidor central de la alcaldía. Conexión al servidor.

COMUNATUNARI

SERVIDOR FIREWALL INTERNET


ANEXO D Cuadro Nยบ 1


CUADRO Nยบ: 2


Ejemplo: Patente de funcionamiento permanente. PF = PM * (ZS/100) Donde: PF = Patente de funcionamiento. PM = Patente Mรกxima. ZS = Zona- Superficie. Teniendo un PM = Avicolas = 5941 bs obtenidos del cuadro 1, y un ZS = No zonificado (1 a 35 M2) = 3,75 Obtenemos la patente de funcionamiento: PF = 5941 * (3,75/100) PF = 222,79 Bs.


CUADRO Nยบ: 3

Ejemplo: Teniendo un PM = Avicolas = 5941 bs obtenidos del cuadro 1, y una Zona C (0 a 2 M2) = 0.36. Obtenemos de la tabla expresada en bolivianos el espacio de 0 a 2 M2 un total a cobrar de 21 bs. Pfe = pm* (zs/100) 21 = 5941 * ( zs/100) 21/5941 = zs/100 21/5941*100=zs Zs = 0.35347


CUADRO Nยบ: 3.1

Ejemplo: Teniendo un PM = Avicolas = 5941 bs obtenidos del cuadro 1, y una Zona C (0 a 2 M2) = 0.50. Obtenemos de la tabla expresada en bolivianos el espacio de 0 a 2 M2 un total a cobrar de 30 bs. PFET = pm* (zs/100) 30 = 5941 * ( zs/100) 30/5941 = zs/100 30/5941*100=zs Zs =0.50496


CUADRO Nยบ: 4

CUADRO Nยบ: 5


CUADRO Nยบ: 6

CUADRO Nยบ 7:


CUADRO Nยบ: 8

CUADRO Nยบ: 9


CUADRO Nยบ: 10

CUADRO Nยบ: 11


ANEXO E PARTE NORMATIVA DE LA ORDENANZA MUNICIPAL DE PATENTES


PARTE ARANCELARIA DE LA ORDENANZA MUNICIPAL DE PATENTES


ANEXO F CONFIGURACIÓN ARCHIVOS DE PHP Y APACHE PARA LA SEGURIDAD DEL MÓDULO WEB. Para realizar la seguridad en la página web primeramente se deben configurar la conectividad entre PHP y Apache para ello se realizará lo siguiente: •

Dentro de nuestra carpeta de PHP existe un archivo denominado php.ini como se muestra en la figura Nº 1, en el cual se tiene que realizar las configuraciones correspondientes. Configuración del archivo php.ini

FUENTE: [Elaboración propia]

La configuración a realizar dentro del archivos es la siguiente como se muestra en la figura Nº 2, se edita el “;” de la extensión php_mysql.dll Habilitación de conexión de PHP con Apache.

FUENTE: [Elaboración propia]


Finalmente se guarda el archivo con los cambios realizados, copiamos el mismo archivo a “C:/Windows/system32” para decirle a Apache que tenemos el PHP.

El siguiente paso a realizar es abrir un navegador y verificar que PHP está corriendo en Apache, en la figura Nº 3 se puede ilustrar que se ejecuta con éxito PHP en Apache. PHP en Apache.

FUENTE: [Elaboración propia]


1 Seguridad al módulo web. 1.1 Creación de certificado de seguridad. Una vez realizada la configuración entre PHP y Apache, el punto a considerar para la seguridad de la página web es crear un certificado con una llave privada, para ello el apache tiene un comando en su carpeta raíz: bin/openssl 24.exe en la cual se realiza la siguiente configuración como se muestra en la figura Nº 4. Creación del certificado.

FUENTE: [Elaboración propia].

Para verificar que se creó con satisfacción el certificado y la llave privada nos dirigimos a la carpeta raíz del apache, y se puede observar que se crearon tanto el certificado como la llave privada, ilustrados en la figura Nº 5.

24

Openssl: Herramientas para la administración relacionadas con la criptografía, que suministran funciones criptográficas a otros paquetes como OpenSSH y navegadores web (para acceso seguro a sitios HTTPS). Estas herramientas ayudan al sistema a implementar el Secure Sockets Layer (SSL), así como otros protocolos relacionados con la seguridad, como el Transport Layer Security (TLS)


Certificado y Llave privada.

FUENTE: [Elaboración propia]

1.2 Habilitación de la seguridad SSL en Apache Se deben realizar algunos cambios en los archivos de configuración de apache, en este caso se realizara la configuración en el archivo denominado “httpd-ssl.conf”, en los cuales se debe especificar el puerto 443 para conexiones seguras, así como el utilizar el certificado que se creó anteriormente. Como se muestra en la figura Nº 6. Finalmente reiniciamos el servicio de apache e ingresando a la página web se puede observar la activación de HTTPS Habilitación de SSL en Apache.

FUENTE: [Elaboración propia]


Superintendencia de Bancos y Entidades Financieras ANEXO G

Señores Presente

REF: REQUISITOS MÍNIMOS DE SEGURIDAD INFORMATICA PARA LA ADMINISTRACION DE SISTEMAS DE INFORMACIÓN Y TECNOLOGÍAS RELACIONADAS

Señores : Para su aplicación y estricto cumplimiento, se adjunta a la presente copia fotostática de la Resolución que aprueba y pone en vigencia las modificaciones a la regulación prudencial referida que contienen los Requisitos mínimos de Seguridad informática para la administración de sistemas de información y tecnologías relacionadas, la que será incorporada en la Recopilación de Normas para Bancos y Entidades Financieras, en el Titulo X, Capitulo XII. Atentament e.

Adj. Lo indicado YDR/SQB La Paz : P l a z a I s a b e l l a C a t o l i c a NO25 0 7 Santa Cruz

A v . l r a l a N 9 8 5 . 01. 2 0 1

Telefono: (591-2) 2 4 3 1 9 1 9

Telelono: (591-3) 3336288

F a x (591-2) 2430028 Telelax: ( 5 91 - 3 ) 3 3 36 2 8 9

e-mail: sbef@sbef.gov.bo www.sbef,gov.bo

. PO B OX . PO

N' 4 4 7

BOX N '

1359


RESOLUCION SB N° La Paz,

/2003

VISTOS: Las modificaciones propuestas a los REQUISITOS MINIMOS DE SEGURIDAD INFORMATICA PARA LA ADMINISTRACIÓN DE SISTEMAS DE INFORMACIÓN Y TECNOLOGÍAS RELACIONADAS, la carta SE-249103 de 31 de julio de 2003, los informes IEN/D-45903 e IEN/D-45908 de 7 y 8 de agosto de 2003, emitidos por la Intendencia de Estudios y Normas y demás documentación que ver convino y se tuvo presente. CONSIDERANDO: Que mediante Resolución SB N° 066/2003 de 4 de julio de 2003, la Superintendencia de Bancos y Entidades Financieras, aprobó y puso en vigencia la regulación prudencial referida a los Requisitos mínimos de seguridad informática para la administración de sistemas de información y tecnologías relacionadas en entidades financieras, para su aplicación y estricto cumplimiento por parte de las entidades de intermediación financiera, habiéndose incorporado el mismo en el Titulo X Capitulo XII de la Recopilación de Normas para Bancos y Entidades Financieras. Que, las entidades de intermediación financiera a través de su organización gremial, han puesto en conocimiento de este Organismo Supervisor sus preocupaciones para una inmediata adecuación al documento emitido. en virtud a que la elaboración del cronograma representa un trabajo delicado y complejo para lo cual se requiere de tiempo adicional, así como también la necesidad de efectuar algunas precisiones al documento. Que la Superintendencia de Bancos y Entidades Financieras, analizó desde el punto de vista técnico y legal los argumentos expuestos, concluyendo que no existe objeción para aceptarlos en virtud a que no contravienen disposiciones en vigencia y facilitan la aplicación y cumplimiento de los requisitos. lo cual amerita la modificación de los mismos a efectos de incorporar las sugerencias.

l a Paz : P l a z a l r a b e l La C a t o l i c a N1 1S 0 7

ielerono: (591-2) 2431919

.

Fax: ( 5 9 1 - 2 ) 2 4 3 0 0 1 8

PO B OX N V 4 7 S a n t a Cruz : A v . I r a i a N"55,

0f. 201

Telefona: (591-3) 3 3 3 6 2 8 8 PO B O X N V 3 5 9

e-mail: sbef@sbef.gov.bo www.sbef.gov.bo

.

Telef ax. 1591.3)

3336189


POR TANTO: El Superintendente de Bancos y Entidades Financieras, con la facultad que le confiere la Ley N° 1488 de 14 de abril de 1993, modificada por la Ley N" 2297 de 20 de diciembre de 2001 y demás disposiciones complementarias, RESUELVE: Aprobar y poner en vigencia las modificaciones a los REQUISITOS MINIMOS DE SEGURIDAD INFORMATICA PARA LA ADMINISTRACIÓN DE SISTEMAS DE INFORMACIÓN Y TECNOLOGÍASRELACIONADAS, de acuerdo al texto contenido en Anexo que forma parte de la presente Resolución y que será incorporado en la Recopilación de Normas para Bancos y Entidades Financieras. Regístrese, comuniquese archívese.

y

Ferna ndo Calvo Superi ntende nte de Banco sy Entida des Financi eras

.

L a P a i : P l a t a I s a b e l L a C a t ~ l i t aN 0 2 5 0 7

. S a n t a Cruz

Av. l ral a N' 58 5. 01. 2 0 1

.

lelelono: (591-2) 2431919

PO BOX N o 4 4 7 Telelono: (591-3) 3336288

.

PO B O X N o 1 3 5 9

e-mail: sbef@sbef.gov.bo www.sbef.gov.bo

.

i a x (391.2)

2430028

Telefax: ( 591-3) 3 33 6 2 8 9


SECCIÓN 2: REQUISITOS MÍNIMOS DE SEGURIDAD INFORMÁTICA Artículo 1° Responsable de la Seguridad Informática.- El Directorio u Órgano Equivalente, aprobará para uso obligatorio de la entidad financiera y de prestación de servicios auxiliares financieros, la Estrategia, Políticas y Normas de Seguridad Informática, considerando como mínimo las disposiciones establecidas en el presente capítulo. Es responsabilidad del Directorio u Órgano Equivalente, Gerencia General, y demás administradores responsables, tener formalizados por escrito, actualizados e implementados las políticas, normas y procedimientos, a ser aplicados en la administración y control de los sistemas de información y su tecnología que la soporta. La estrategia, las políticas, normas y procedimientos podrán ser solicitadas para su revisión, cuando la SBEF así lo requiera. Artículo 2° - Características y criterios de la información.- Los datos que administren las entidades financieras y las empresas de servicios auxiliares financieros deben contener un alto grado de seguridad para cumplir con los objetivos de control y criterios básicos de información definidas por la SBEF. Los criterios básicos se describen a continuación: •

Confiabilidad: Proveer información apropiada y confiable para el uso de las entidades financieras y empresas de servicios auxiliares financieros tanto interna como externamente.

Confidencialidad: Protección de información sensible para que no se divulgue sin autorización.

Integridad: Se refiere a la exactitud y suficiencia de la información, así como su validez de acuerdo con los valores y expectativas de la actividad de la entidad financiera.

Disponibilidad: Oportunidad de la información, cuando sea requerida.

Efectividad: Adecuada información para desarrollar las actividades de las entidades financieras y empresas de servicios auxiliares financieros.

Eficiencia: Proveer información suficiente a través del uso de los recursos de la mejor manera posible.

Cumplimiento: Debida atención a las leyes, regulaciones y acuerdos contractuales que la entidad financiera y empresas de servicios auxiliares financieros deben realizar.

Artículo 3° - Políticas, normas y procedimientos.- El área de Tecnologías de la Información de la entidad financiera o empresa de servicios auxiliares financieros, para asegurar la continuidad operativa de esta, deberá tener formalizado por escrito, implementadas y actualizadas, las políticas, normas y procedimientos de seguridad informática para las áreas fundamentales de la función informática, a saber: a) Gestión: Dirección, planificación, control y supervisión. b) Operación: Procesos y tareas propias del área informática.


c)

Administración de usuarios.

a) Gestión: La gestión o administración directiva, deberá contener a lo menos, las políticas, normas y procedimientos respecto a: i.

Plan informático.

ii.

Comité de informática.

iii. Comité operativo del área. iv. Desarrollo y mantenimiento de sistemas. v.

Administración de contratos externos.

b) Operaciones: El área de operaciones deberá contener a lo menos, las políticas, normas y procedimientos de: i.

Seguridad física de sala de servidores y el entorno que la rodea.

ii. Respaldos y recuperación de información. iii. Registro de caídas de los sistemas o no disponibilidad de servicios que afecten la atención normal al público. iv. Administración de cintoteca interna y externa. v. Control y políticas de administración de antivirus. vi. Administración de licencias de software y programas. vii. Traspaso de aplicaciones al ambiente de explotación. viii. Inventario de hardware y software. ix. Seguridad de redes. −

Características, topología y diagrama de la red

Seguridad física de sites de comunicaciones

Seguridad y respaldo de enlaces.

Equipos de seguridad y telecomunicaciones.

Seguridad de acceso Internet/Intranet.


c) Administración de Usuarios: El área de administración de usuarios deberá contener a lo menos, las políticas, normas y procedimientos para: i.

Administración de privilegios de acceso a sistemas.

ii.

Administración y rotación de password.

iii. Asignación y responsabilidad de hardware y software. iv. Administración de estación de trabajo ó PC. v.

Uso de comunicaciones electrónicas.

vi. Administración y control de usuarios Intranet/Internet. Artículo 4° Plan de Contingencias Tecnológicas.- Las entidades financieras y las empresas de servicios auxiliares financieros deberán tener formalizado por escrito, actualizado, implementado y aprobado por el Directorio u Órgano Equivalente, un Plan de Contingencias Tecnológicas. El plan debe incluir al menos: • Objetivo del plan de contingencias tecnológicas. • Metodología del plan de contingencias tecnológicas. • Procedimientos de recuperación de operaciones criticas. • Descripción de responsabilidades e identificación de personal clave. • Medidas de prevención. • Recursos mínimos necesarios para la recuperación. • Convenios realizados para la recuperación. Artículo 5° Pruebas del Plan de Contingencias Tecnológicas.- Las entidades financieras y empresas de servicios auxiliares financieros, deberán efectuar al menos 1 prueba al año del Plan de Contingencias Tecnológicas, debiendo ser el resultado de esta exitoso en toda su dimensión, caso contrario la entidad de intermediación financiera o empresa auxiliar de servicios financieros deberá realizar las pruebas que sean necesarias hasta cumplir con los objetivos del plan de contingencia. Esta prueba se realizará de acuerdo al cronograma que la entidad financiera presente a la SBEF una vez que el Plan esté implementado formalmente. En estas pruebas debe participar el auditor interno. El resultado de éstas deberá estar disponible para las inspecciones efectuadas por la SBEF. SECCIÓN 3: CONTRATO CON PROVEEDORES DE TECNOLOGÍAS DE LA INFORMACIÓN Todos los contratos con proveedores externos son importantes, deben encontrarse formalizados de manera que permitan a las entidades financieras y empresas de servicios auxiliares financieros operar en todas sus áreas de negocio, así como en procesos del tipo Banca Electrónica ó Internet (hospedaje del sitio WEB o WAP) y otros como mantenimiento


de equipos, soporte de sistemas operativos, externalización de especialistas informáticos, aseo y limpieza. Artículo 1° Contratación de Proveedores Externos de Tecnologías.- Las entidades financieras y empresas de servicios auxiliares financieros al contratar los servicios de proveedores externos de tecnologías de: 1.

Procesamiento de datos o ejecución de sistemas en lugar externo. Para la contratación de empresas encargadas del procesamiento de datos o ejecución de sistemas en lugar externo, la entidad financiera o empresa de servicios auxiliares financieros debe considerar al menos los siguientes aspectos: 1.1. Que es deber del Directorio u Órgano Equivalente, Gerencia General, y demás administradores responsables de la entidad de intermediación financiera o empresa de servicios auxiliares financieros solicitante, asegurarse que la empresa proveedora cuente con la necesaria solidez financiera, una organización y personal adecuados, con conocimiento y experiencia en el procesamiento de datos, servicios bancarios, telecomunicaciones, como asimismo de que sus sistemas de control interno y procedimientos de seguridad informática, respondan a las características del servicio que se desea contratar. 1.2. Que la infraestructura tecnológica y los sistemas que se utilizarán para la comunicación, almacenamiento y procesamiento de datos, ofrecen suficiente seguridad para resguardar permanentemente la continuidad operacional y la confidencialidad, integridad, exactitud y calidad de la información y los datos. Asimismo, verificar que las condiciones garantizan la obtención oportuna de cualquier dato o información que necesite, sea para sus propios fines o para cumplir con los requerimientos de las autoridades competentes, como es el caso de la información que en cualquier momento puede solicitarle la SBEF. 1.3. Que es responsabilidad del Directorio u Órgano Equivalente y el Gerente General de la entidad financiera o empresa de servicios auxiliares financieros, la suscripción del contrato con la empresa proveedora, el que entre otras cosas deberá especificar: a.

La naturaleza y especificaciones del servicio de procesamiento contratado.

b. La responsabilidad que asume la empresa proveedora, para mantener políticas, normas y procedimientos que garanticen la seguridad informática, el secreto bancario y la confidencialidad de la información, en conformidad con la legislación boliviana asimismo, para prever pérdidas atrasos o deterioros de la misma. c.

La responsabilidad que asume la empresa proveedora de tecnologías en caso de ser vulnerados sus sistemas, por atentados computacionales internos o externos.

d. La facultad de la entidad financiera o de la empresa de servicios auxiliares financieros, para practicar evaluaciones periódicas en la empresa proveedora del servicio, directamente o mediante auditorias independientes.


2.

Desarrollo y mantenimiento de programas, sistemas o aplicaciones. Para la contratación de empresas encargadas del desarrollo y mantenimiento de programas, sistemas o aplicaciones, la entidad financiera o empresa de servicios auxiliares financieros debe considerar al menos los siguientes aspectos: 2.1. Que es deber de la entidad financiera o empresa de servicios auxiliares financieros, asegurarse que la empresa contratada cuente con la necesaria solidez financiera, organización y personal adecuado, con conocimiento y experiencia en el desarrollo de sistemas y/o en servicios de intermediación financiera, asimismo de que sus sistemas de control interno y procedimientos de seguridad informática, responden a las características del servicio que se desea contratar. 2.2. Que la infraestructura tecnológica, sistemas operativos y las herramientas de desarrollo, referidos a licencias de software, que se utilizarán estén debidamente licenciados por el fabricante o representante de software.

Artículo 2° - Relación Contractual con el Proveedor Externo de Tecnologías.- El contrato con el proveedor externo de tecnologías deberá contener como mínimo las siguientes cláusulas1: 1.

Programas Fuente.- Al término del proyecto, el cliente debe asegurarse el acceso oportuno a los programas fuentes.

2.

Propiedad intelectual.- Se debe aclarar a quien pertenecerá la propiedad intelectual en el caso de desarrollo de programas, sistemas o aplicaciones.

3.

Plataforma de Desarrollo.- Se deberá indicar en detalle la plataforma de desarrollo que utilizará el proveedor, servidor, sistemas operativos y las herramientas de desarrollo, tal como lenguaje de programación y motor de base de datos.

4.

Formalización de Recursos Humanos.- El proveedor deberá tener el contrato del

personal que participa en el proyecto, actualizado y con cláusulas de confidencialidad para el manejo de la información. Adicionalmente, deberá enviar al cliente (entidad financiera o empresa de servicios auxiliares financieros) el currículo de todos los participantes en el proyecto, indicando al menos antecedentes profesionales y personales.

Cronograma y plan de trabajo.- Se debe indicar los tiempos de desarrollo por cada etapa en forma detallada, incluyendo las pruebas de programas. 6.

Atrasos y Riesgos.- Con la finalidad de proteger a la entidad financiera o empresa de servicios auxiliares financieros, junto a las cláusulas normales de condiciones de pago se deben establecer multas por atrasos en la entrega. Al mismo tiempo, indemnización por daños y perjuicios, en caso de fraudes o atentados cibernéticos.

7.

Acceso remoto.- En caso de que el proveedor sea autorizado a ingresar en forma remota a los servidores del cliente, deberá regirse y cumplir las normas, políticas y procedimientos


de la entidad financiera o empresa de servicios auxiliares financieros en lo referido a la seguridad de información. Artículo 3° - Seguridad Informática del Proveedor.- Adicionalmente, el proveedor deberá tener formalizados las políticas, normas y procedimientos de seguridad informática, tales como: •

Desarrollo de sistemas de información y programas.

Mantenimiento de sistemas y programas.

Seguridad física sala de servidores.

Respaldos y recuperación de información.

Respaldo y recuperación de bases de datos.

Administración de cintoteca interna y externa.

Control y políticas de administración de antivirus.

Administración de licencias de software y programas.

• Traspaso de aplicaciones al ambiente de explotación (producción). •

Administración y control de equipos de seguridad.

Plan de contingencias tecnológicas.

Será de responsabilidad de la entidad financiera o de la empresa de servicios auxiliares, verificar la seguridad informática del proveedor a través de una metodología que cumpla con este objetivo. Asimismo, la entidad financiera o la empresa de servicios auxiliares deberá mantener los documentos y antecedentes de los contratos suscritos con empresas proveedoras de servicios de tecnología de información a disposición de la SBEF. SECCIÓN 4: TRANSFERENCIAS Y TRANSACCIONES ELECTRÓNICAS1 Artículo 1° - Requisitos de los sistemas de transferencia y transacción electrónica.Para habilitar un sistema de transferencia electrónica de información o transacción electrónica de fondos del tipo Banca Electrónica, las entidades financieras o empresas de servicios auxiliares financieros, deben adquirir e implementar elementos de hardware y software necesarios para la protección y control de su plataforma tecnológica, adicionalmente y en forma complementaria, deberán considerar el cumplimiento de los siguientes requisitos mínimos: a) Seguridad del Sistema, el sistema debe proveer un perfil de seguridad que garantice que las operaciones, sólo puedan ser realizadas por personas debidamente autorizadas para


ello, debiendo resguardar, además, la privacidad o confidencialidad de la información transmitida o procesada por ese medio. Los procedimientos deberán asegurarse que tanto el originador como el destinatario, en su caso, conozcan la autoría de las transacciones o mensajes y la conformidad de su recepción, debiendo utilizarse las políticas, normas y procedimientos indicados en la Sección 2 y en el Artículo 3° de la presente Sección, que permitan asegurar su autenticidad e integridad. b) Canal de Comunicación, la entidad financiera o empresa de servicios auxiliares financieros, debe mantener permanentemente abierto y disponible un canal de comunicación que permita al usuario realizar consultas y solicitar el bloqueo de cualquier operación que intente efectuarse utilizando sus medios de acceso o claves de autenticación. Cada sistema que opere en línea y en tiempo real, debe permitir dicho bloqueo también en tiempo real. c) Difusión de Políticas de Seguridad, la entidad financiera o empresa de servicios auxiliares financieros, deberá difundir sus políticas de seguridad, relativas al tema de transferencias electrónicas al interior de la entidad. d) Certificación, La existencia de las páginas Web utilizadas por las entidades financieras o empresas de servicios auxiliares financieros, deberá estar avalada por una certificadora nacional o internacional. En el caso de la certificadora nacional deberán estar respaldada por una certificadora internacional. e) Continuidad Operativa, se refiere a procesos alternativos que puedan asegurar la continuidad de todos los procesos definidos como críticos relacionados con los servicios de transferencia electrónica de fondos. Es decir, las instalaciones y configuraciones de los equipos, sistemas y de las redes deben garantizar la continuidad de las operaciones frente a eventos fortuitos o deliberados, debiendo considerarse lo previsto en la Sección 2, Artículos 4° y 5°. f) Disponibilidad de la Información (Informes), los sistemas de transacción electrónica de fondos deberán generar la información necesaria para que el cliente pueda conciliar los movimientos de dinero efectuados, tanto por terminales como por usuario habilitado, incluyendo, cuando corresponda, totales de las operaciones realizadas en un determinado período. g) Registro de pistas de control, los sistemas utilizados, además de permitir el registro y seguimiento íntegro de las operaciones realizadas, deberán generar archivos que permitan respaldar los antecedentes de cada operación electrónica, necesarios para efectuar cualquier seguimiento, examen o certificación posterior, tales como, fechas y horas en que se realizaron, contenido de los mensajes, identificación de los operadores, emisores y receptores, cuentas y montos involucrados, terminales desde los cuales realizó sus operaciones. h) Acuerdos privados, en las transferencias electrónicas de información y transacciones electrónicas de fondos entre entidades de intermediación financiera, empresas de servicios auxiliares financieros, BCB, SBEF, usuarios y todas las


relacionadas con la actividad de intermediación financiera, pueden celebrarse acuerdos privados que estén debidamente firmados y protocolizados entre las partes interesadas y que consideren las medidas de seguridad que se indican en la Sección 2. Artículo 2° - Contrato formal.- Deberá celebrarse un contrato entre la entidad financiera o empresa de servicios auxiliares financieros, y el cliente o usuario, en el cual queden claramente establecidos los derechos y responsabilidades de cada una de las partes que intervienen en este tipo de operaciones electrónicas. Este contrato deberá contener de manera enunciativa y no limitativa, los siguientes puntos: a) El usuario o cliente, será responsable exclusivo del uso y confidencialidad del Password, Clave de acceso ó PIN, que utilizará en sus operaciones. Se indicará, el bloqueo automático de su clave después de tres intentos fallidos y el procedimiento para desbloqueo. b) Debe detallarse el tipo de operaciones que puede efectuar el cliente. c)

Debe quedar establecido el horario y consideraciones de cierre diario de cada entidad financiera o empresa financiera de servicios auxiliares, junto al procedimiento alternativo en caso de no-disponibilidad del servicio.

d) Hacer conocer al usuario o cliente las medidas de seguridad que ha tomado la entidad financiera o empresa de servicios auxiliares financieros para la transferencia electrónica de información y transacción electrónica de fondos. e)

Los sistemas que permitan ejecutar transacciones de fondos, además de reconocer la validez de la operación que el usuario realice, deben controlar que los importes girados no superen el saldo disponible o el límite que se haya fijado para el efecto, salvo la existencia previa de contratos de anticipo o adelanto en cuenta, debiendo cumplir para tal efecto con las formalidades del Código de Comercio y reglamentación vigente.

Artículo 3° - Encriptación de mensajes y archivos.- Para que una entidad financiera o empresa de servicios auxiliares financieros, efectúe transferencias electrónicas de información y transacciones electrónicas de fondos, deberá tener implementado un sistema de encriptación que garantice como mínimo que las operaciones realizadas por sus usuarios internos o externos sean realizadas en un ambiente seguro y no puedan ser observadas por usuarios no autorizados. Artículo 4° Transferencia como documento.- La generación de documentos electrónicos que constituyen documentación de carácter oficial, para el cumplimiento de disposiciones legales de la SBEF deberá cumplir con los requisitos mínimos descritos en el presente Capítulo. Artículo 5° - Operaciones interbancarias.- Las transacciones electrónicas de fondos interbancarias estarán regidas por el reglamento del sistema de pagos de alto valor, del Banco Central de Bolivia, mientras que, las transferencias electrónicas de información de estas operaciones estarán regidas por el Reglamento de Operaciones Interbancarias contenido en el Título IX, Capítulo IV de la Recopilación de Normas para Bancos y Entidades Financieras.


En caso de utilizarse otros medios para realizar las operaciones interbancarias, las entidades de intermediación financiera y empresas de servicios auxiliares financieros deberán regirse con el acuerdo privado descrito en inciso h), Artículo 1º de la presente Sección. Artículo 6° - Sanciones.- Las entidades financieras y empresas de servicios auxiliares financieras, que están bajo el ámbito de aplicación de la presente norma y que incumplan con lo descrito en el Artículo 2º de la Sección 2 y Artículo 4º de la presente Sección, estarán sujetas al régimen de sanciones del Título XIII, Capítulo I, Sección 1 de la Recopilación de Normas para Bancos y Entidades Financieras. SECCIÓN 5: DISPOSICIONES TRANSITORIAS1 Artículo 1° - Adecuación y Cronograma.- Las entidades financieras y empresas de servicios auxiliares financieros, deberán cumplir con todos los requisitos mínimos que se requieren en este capítulo hasta el 30 de junio de 2004. Adicionalmente deberán enviar su cronograma para el cumplimiento y adecuación a la presente hasta el 30 de septiembre de 2003


Superintendencia de Bancos y Entidades Financieras BOLIVIA

REF: REQUISITOS MINIMOS DE SEGURIDAD INFORMATICA

SEÑORES: Para su aplicación y estricto cumplimiento, se adjunta a la presente copia fotostática de la Resolución que aprueba y pone en vigencia las modificaciones a los Requisitos mínimos de Seguridad Informática para la administración de Sistemas De Información Y Tecnologías Relacionadas en entidades financieras, el que se encuentra contenido en el Título X, Capítulo 12 de la Recopilación de Normas para Bancos y Entidades Financieras.

ATENTAMENTE:


ANEXO H COMANDO EN JEFE DE LAS FF.AA. DE LA NACIÓN ESCUELA MILITAR DE INGENIERIA “MCAL. ANTONIO JOSE DE SUCRE” BOLIVIA

ENCUESTA PARA OBTENER INFORMACION SOBRE LOS REQUERIMIENTOS QUE SE REALIZAN ENTRE LA ENTIDAD FINANCIERA Y LA EMPRESA

Marque con una X:

FEMENINO MASCULINO

Entidad Financiera

:

Universo

:

Jefe de departamento de unidad de sistemas.

Objetivo

:

Obtener los requerimientos técnicos y administrativos sobre la intermediación financiera.

Fecha de aplicación

:

Junio de 2013.

PREGUNTAS: 1.- ¿Qué denominación tiene la entidad financiera para referirse a la Intermediación Financiera? ¿En qué consiste este servicio? 2.- ¿Qué requerimientos legales tiene la entidad financiera para otorgar este servicio a las instituciones públicas? 3.- ¿Qué requerimientos técnicos tiene la entidad financiera para otorgar este servicio a las instituciones? 4.- ¿Existe algún tipo de requerimiento económico para otorgar este servicio a las instituciones?


5.- Una vez realizado el acuerdo entre la institución y la entidad financiera, ¿Cuál es el costo por el servicio adquirido? 6.- ¿Existe algún tipo o normativa de seguridad entre el enlace de institución y entidad financiera? 7.- ¿Qué tipos de comprobantes existen para respaldar los pagos realizados en la entidad financiera? ¿Y qué formato utilizan para este comprobante? 8.- ¿Qué tipos de reportes se entrega a la institución respecto a los cobros realizados en la entidad financiera? ¿Cuál es el proceso para efectuar estos reportes? 9.- ¿Cómo se realiza el abono de los cobros realizados en la entidad financiera a la institución? 10.- ¿La Autoridad de Supervisión del Sistema Financiero (ASFI) se atribuye algún requerimiento para el enlace entre Entidad Financiera e Institución?


ANEXO I REGISTRO DE TRANSACCIONES EN LA REPLICA Y BASE DE DATOS CENTRAL DE LA ALCALDÍA 2. Registro de datos en la réplica de la base de datos. Los datos se registran en la réplica de la base de datos como se muestra en la figura Nº 1, en la que se observa que se realizó la cancelación de las gestiones. Registro de datos en la réplica de la base de datos.

FUENTE: [Elaboración propia] 3. Registro de datos en la base de datos central (G.A.M.C). Una vez realizado en registro de los datos del contribuyente en la réplica, esta realiza una conexión en tiempo real con la base de datos central (Alcaldía), en la cual se registraron los datos. Como se observa en la Figura Nº 2. Registro de datos en la base de datos central.

FUENTE: [Elaboración propia]


MEDIDAS DE SEGURIDAD DEL ENLACE EN LÍNEA ENTRE LA ENTIDAD FINANCIERA Y ALCALDÍA Para la ejecución de la seguridad empleada entre el enlace en línea entre la entidad financiera y alcaldía, se aplicó los puntos que establece el ASFI en la circular SB/466/2004 sobre la intermediación financiera, correspondiente a la parte de seguridad, así como también se consideró la ISO/IEC 17799/2005, en la cual describe claramente los puntos más relevantes sobre las “Transacciones en Línea” mencionados en el punto 10.9.2 del respectivo estándar de seguridad. A continuación mencionaremos el alcance del presente estándar, así como también la guía de implementación para las transacciones en línea. ISO/IEC 17799/2005: Alcance: Estándar internacional que establece directrices y principios generales para la iniciación, la realización, el mantenimiento, y la mejora en la gestión de seguridad de la información. Guía de implementación: Las consideraciones de seguridad para las transacciones en línea deben incluir lo siguiente: a) El empleo de firmas electrónicas por cada una de las partes involucradas en la transacción. b) Todos los aspectos de la transacción, deben considerar: 1) Las credenciales de usuario de todas las partes son válidas y verificadas. 2) Las transacciones permanece confidencial. 3) La privacidad asociada con todas las partes involucradas es conservada c) El camino de comunicaciones entre las partes involucradas es encriptado.


d) Los protocolos que solían comunicarse entre todas las partes involucradas es seguro. e) Asegurando que el almacenaje de los detalles de transacción son localizados fuera de cualquier ambiente público accesible. f) Donde la confianza en una autoridad es usada (p.ej. para los propósitos de emisión y mantenimiento de firmas digitales y/o firmas digitales y/o certificados digitales) la seguridad es integrada e incluida a lo largo de todo el proceso de gestión de certificados/firmas de principio a fin. En los puntos incisos descritos anteriormente, indica varios aspectos que fueron aplicados en el enlace en línea entre la entidad financiera y alcaldía, de los cuales se consideraron fundamentalmente para el presente trabajo fueron las siguientes: 1. Aspecto de las transacciones (Descritas en el inciso “b”).  Credenciales de usuarios para el acceso a la herramienta de cobro de patentes. Para la autenticación de acceso a la herramienta de cobro de patentes se aplicó el algoritmo de encriptación MD5, para el cifrado de contraseñas en la base de datos. A continuación se muestra una captura de pantalla (Figura Nº 3) del cifrado en la base datos sobre los respectivos usuarios. Encriptación de contraseñas en la base de datos.

FUENTE: [Elaboración propia]


2. El camino de comunicación entre las partes involucradas es encriptado. (Descritas en el inciso “c”).  Configuración del canal seguro de datos SSH para el enlace entre entidad financiera y alcaldía. Paso Nº 1: Para realizar la seguridad entre la entidad financiera y alcaldía se priorizo tener un canal de comunicaciones seguro, para tal efecto el SSH (Secure Shell) es el adecuado para realizar este tipo de conexiones seguras. Como primer paso creamos en el lado del servidor (Alcaldía) se procedió a crear un servidor SSH, esto mediante la herramienta FreeSSHD, y se realizó la siguiente configuración. a) Instalación de FreSSHd. Ejecutamos la herramienta, aparecerá aspectos de ubicación e información de la instalación hasta llegar a este punto, donde presionaremos si, esto nos generara las claves para SSH.


b) Configuración de la herramienta FreeSSHd. Abrimos la herramienta y vemos que está basado en pestañas, por defecto se nos abre la pestaña server status, presionamos la opción “SSH server is running”, la cual nos tiene q aparecer marcada con verde como se muestra en la figura.

Ahora vamos a la pestaña SSH y vemos varias opciones, como: •

Listen address: Si tenemos varias interfaces de red podemos escoger por cuál de ellas escuchara nuestro servidor SSH o también podemos dejarlo por defecto que escuche en cualquiera.

Port: Es el puerto en el que "escuchara" nuestro servidor, por defecto el puerto para los servidores de SSH es el 22, pero se recomienda utilizar el puerto 443. El puerto 443 es el puerto usado por SSL, con lo cual es muy raro que este puerto este bloqueado, dado que es el que se utiliza para navegar por páginas seguras lo cual nos puede evitar posibles problemas cuando queramos conectar a nuestro SSH desde el servidor MySQL o los clientes.

Max Number of connections: Número máximo de conexiones, 0 igual a ilimitadas.

idle Timeout: Tiempo para cerrar una sesión inactiva, 0 igual a ilimitado.


PestaĂąa Tunneling: Seleccionamos las 2 opciones, la cual nos permitirĂĄ luego crear la pasarela entre el servidor MySQL y los clientes.


Paso Nº 2: Una vez realizada la configuración en del servidor SSH mediante la herramienta descrita anteriormente, en el lado del cliente SSH (Replica BD Alcaldía) se ejecuta el siguiente comando mediante la herramienta “Plink” abriendo una consola MsDos

-v = Vervose mode, es decir, que nos muestre toda la información posible sobre lo que está ocurriendo. -ssh = Usar el protocolo SSH. -2 = Utilizamos la versión 2 del protocolo SSH, es decir SSH2. Necesario para poder usar la opción -N siguiente. -P = Puerto en el que escucha el servidor SSH. Recuerda lo dejamos en el 443. -N = (Solo con SSH2) Indicamos a SSH que no se ejecutaran comandos en el servidor, solo el túnel. -R 18566:localhost:3309 = Forward remote port to local address, es decir, lo que conseguimos es mapear un puerto remoto 18566 registrándolo en el servidor SSH a una dirección local (localhost en el puerto 3309). -L 18566:localhost:18566 = Mapeamos el puerto 18566 localmente hacia sí mismo. Si todo funciona correctamente se verá lo siguiente:


Realizado la configuración del canal SSH mediante la herramienta FreeSSHd, se concluye que la encriptación de datos ya es segura en ambas partes, referente al enlace en línea entre entidad financiera y alcaldía. En la siguiente figura se puede constatar que tanto entidad financiera como alcaldía se encuentran bajo una sesión SSH.

Paso Nº 3: Realizada la configuración del Plink y comunicación mediante el canal SSH, verificamos si el cliente SSH tiene acceso al Servidor SSH ejecutando la siguiente línea de código en nuestra consola


Si todo funciona bien tendremos lo siguiente:

3. Los protocolos que solían comunicarse entre todas las partes involucradas es seguro (Descritas en el inciso “d”). Una vez realizada la comunicación segura mediante un canal seguro SSH, se utilizó en lo que respecta el protocolo SSL (443) mediante TCP/IP entre ambas partes (Entidad Financiera-Empresa). Descrito en el punto 2 dentro de la configuración del canal SSH en el paso Nº 2, se puede observar que se utiliza el protocolo 443 perteneciente a SSL. Para realizar énfasis a lo que respecta el enlace en línea tendremos los siguientes elementos: 3.1. Cliente (Entidad Financiera). La herramienta situada cliente es aquel el cual estará situado en la entidad financiera, donde el cajero de la entidad financiera permitirá enviar solicitudes o peticiones al servidor mediante una interfaz gráfica de usuario (Herramienta de Cobro de Patente).


3.2. Canal de Comunicaciones (Enlace). Cuando el cajero de la entidad financiera realiza la consulta y el cobro de patente correspondiente, esta información viaja a través de una canal de comunicación hacia la réplica de base de datos para ello se establecen una conexión. Código de conexión entre replica y entidad financiera: <?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections> </configSections> <connectionStrings> <add name="Modelo.Properties.Settings.cobranza_patentesConnectionString" connectionString="server=localhost;Port=18566;User Id=root;password=root;Persist Security Info=True;database=cobranza_replica" providerName="MySql.Data.MySqlClient" /> </connectionStrings> </configuration> 3.3. Servidor (Alcaldía). •

Replica: Mediante la réplica de la base de datos, el cajero realiza consultas, el administrador de la entidad financiera realiza los reportes correspondientes haciendo consultas a la réplica, el cual tiene ciertos privilegios para realizar la consulta. A su vez la réplica se sincroniza en tiempo real con la base de datos central, para lo cual se utilizó el siguiente comando en MySQL: CREATE TABLE contribuyente ( id INTEGER NOT NULL AUTO_INCREMENT, nombre VARCHAR(50), apellidoPaterno VARCHAR(50), apellidoMaterno VARCHAR(50), ci VARCHAR(50),


direccion VARCHAR(200), password VARCHAR(50), PRIMARY KEY (id) )

ENGINE=FEDERATED

DEFAULT

CHARSET=utf8

CONNECTION='mysql://root:root@localhost:18566/cobranza_patentes/con tribuyente'; Como se observa se realiza una conexión con la base de datos central, la cual lleva como ip: 192.168.3.10, mediante un acceso por el puerto que definimos anteriormente (18566). •

Base de datos: Todas los registros de la réplica de base de datos se muestran en la base de datos, tales como los cobros realizados en la entidad financiera.


ANEXO J PRUEBAS DE LA HERRAMIENTA DE COBRO DE PATENTES Y MÓDULO WEB Pruebas de Carga. 1. Módulo Web. Caso de

Descripción

Uso

Pre-

Tiempo

Respuesta

Requisitos

Esperado

Esperada

Prueba 1:

Al

Ingresan a la página web 50 contribuyentes

al

mismo

Google Chrome

momento

ingresar 1 seg.

Fecha

de 50

contribuyentes a la

tiempo mediante su C.I. y

página

contraseña, desde diferentes

diferentes maquinas

maquinas

se recibieron un total

realizan

con las

internet,

y

operaciones

Mozilla Firefox

1,2 seg.

correspondientes

en

Google

Ingresan a la página web 100

de 223,02 Bytes y

al

Chrome

Al 4 seg.

mismo

momento

ingresar

de 100

contribuyentes a la

tiempo mediante su C.I. y

página

Ingresar a

contraseña, desde diferentes

diferentes maquinas

la Página

maquinas

se recibieron un total

Web

realizan

con las

internet,

y

operaciones

Mozilla Firefox

4.08 seg.

correspondientes

web

en

Google

Ingresan a la página web 500

de 512,14 Bytes y

al

Chrome

6 seg

Al

momento

ingresar

mismo

de 500

contribuyentes a la

tiempo mediante su C.I. y

página

contraseña, desde diferentes

diferentes maquinas

maquinas

se recibieron un total

realizan

con las

correspondientes

01-08-13

3212 Kbits/s

Prueba 3:

contribuyentes

25-08-13

1254,63 Kbits/s

Prueba 2:

contribuyentes

web

internet,

y

operaciones

Mozilla Firefox

6.02 seg

web

en

de 1042,47 Kilobytes y 8452 Kbits/s

01-08-13


Peticiones Abiertas y Datos Transferidos. En la siguiente imagen se ilustra el resultado de las tres pruebas, con el nĂşmero de contribuyentes (50, 100, 500)

Datos Transferidos-Memoria del Sistema y Carga del CPU En la siguiente imagen se ilustra el resultado de las tres pruebas, con el nĂşmero de contribuyentes (50, 100, 500)


Vistas de los Resultados en Tercera Dimensiรณn Cantidad de Usuarios: 50 Para visualiza a detalle tenemos en la siguiente imagen un resumen de los 50 usuarios que ingresaron a la pรกgina web

Cantidad de Usuarios: 100 Para visualiza a detalle tenemos en la siguiente imagen un resumen de los 100 usuarios que ingresaron a la pรกgina web


Cantidad de Usuarios: 500 Para visualiza a detalle tenemos en la siguiente imagen un resumen de los 500 usuarios que ingresaron a la página web

Para la ejecución de la prueba de carga al módulo web se realizó la prueba en 2 sistemas operativos los cuales mencionamos a continuación:

Sistema Operativo

Características

Windows 7 Service

• Procesador 2 Ghz Core i7

Pack 1

de 64 bits

Número de Usuarios

10:

Se

ejecutaron

las

principales

funciones con normalidad.

• Memoria Ram 4GB • Disco Duro: 500GB

40: Se observó un gran consumo de recursos pero la ejecución no tuvo alteraciones

150: Este fue el número de usuarios máximos que ingresaron a la página web y se observó que existe un gran consumo del procesador y de otros recursos del computador.


Sistema Operativo

Windows XP Service Pack 3

Características

• Procesador

2.66 Ghz

Pentium(R) de 32 bits • Memoria Ram:

Número de Usuarios

10:

Se

ejecutaron

funciones

con

las

principales

normalidad

y

con

normalidad

1 GB • Disco Duro: 80 GB

40: Se observó un gran consumo de recursos del procesador y tiempos críticos de respuesta.

150: Se realizó el acceso al módulo con tiempos críticos de respuesta y la observación que no se pudo completar la sesión de la página web de los 150 usuarios


2. Herramienta de Cobro de Patentes.

Caso de Uso

Tiempo

Descripción Prueba 1:

Al

la

de cobro de patentes por

al mismo tiempo así como

entidad

2 seg.

el administrador

de

la

de

la

entidad

financiera

al

recibieron un total de 800

mismo tiempo. Ingresar a la

Patentes

a

herramienta los 3 cajeros

administrador

de Cobro De

ingresar

Fecha

Ingresan a la herramienta

un parte 3 cajeros y el

Herramienta

Respuesta Esperada

Esperado

financiera

26-08-13

se

Kb

Prueba 2: Ingresan a la herramienta

Al

de cobro de patentes por

herramienta

un parte 120 cajeros y el

cajeros al mismo tiempo

administrador

así como el administrador

entidad

de

la

financiera

al

4,5 seg.

a los

la 120

de la entidad financiera se pudo

mismo tiempo.

ingresar

observar

01-09-13

la

respuesta critica de la herramienta recibieron así un total de 8.4 MB Prueba 1:

Al

Ingresa a la herramienta administrador alcaldía

de

y

la

realiza

ingresar

administrador 1 seg.

el de

la

alcaldía a la herramienta se recibió un total de 754

operaciones de reportes y

Kb

consultas Administrar

Prueba 2:

Cobro de

Ingresa a la herramienta el

administrador

Patentes.

administrador

la

alcaldía a la herramienta

alcaldía en 35 diferentes

se recibió un total de 3,44

máquinas

Al

de

y

realiza

operaciones de reportes y consultas

26-08-13

3 seg.

MB

ingresar

el de

la

31-08-13


Caso de Uso

Tiempo

Descripción Prueba 1:

Al

Para este caso de uso ingresaron

a

tiempo

máquinas

diferentes

en

cajeros 4,2 seg

y

Realizar Cobro de Patentes

Prueba 2:

Al

cajeros

máquinas

diferentes

la

y

a los

la 525

los

cuales

6 seg

correspondientes

el

y

tiempo de respuesta de la

realizaron las operaciones

herramienta fue muy baja

y

y el sistema salió de la

transacciones

a

Al

40

administradores

de

financieras

entidades 3 seg

40 de

financieras

y

realizar las operaciones de gestionar cajeros y

27-08-13

un total de 2,5 MB y un

acciones

consumo

correspondientes

regular

del

procesador

Sucursales

Al

Prueba 2:

60

administrador

de financieras

cada uno en máquinas diferentes y realizaron las

ingresar

herramienta

la

herramienta

entidades

los

la

sucursales se registraron

diferentes y realizaron las

a

a

administradores

cada uno en máquinas

Ingresaron

ingresar

herramienta

la

herramienta

entidades

01-09-13

depuración.

Prueba 1: Ingresaron

27-08-13

realizaron las operaciones

correspondientes

Cajero y

el

fue

ingresar

ingresaron

en

cuales

correspondientes

herramienta

tiempo

los

realizaron las operaciones

Para este caso de uso

mismo

450

relativamente bajo

correspondientes

a

los

la

herramienta

transacciones

herramienta 525 cajeros al

Gestionar

y

a

Fecha

tiempo de respuesta de la

realizaron las operaciones y

ingresar

herramienta

la

herramienta 450 cajeros al mismo

Respuesta Esperada

Esperado

a los

administradores 3 seg

entidades

financieras

la 60 de y

realizar las operaciones de gestionar cajeros y sucursales se registraron un total de 4,5 MB y un

31-08-13


acciones

consumo

correspondientes

procesado,

alto

del

pero

no

perjudicial para realizar las operaciones

dentro

la

herramienta. Prueba 1: Ingresaron

a

herramienta

1,2 seg.

cada uno en mรกquinas

Reporte de Patente.

Prueba 2:

entidades

de

financieras

y

realizar las operaciones

Al

la

herramienta

35

administrador

de

entidades

4

28-08-13

de

total de 0,5 MB

correspondientes

a

los

reporte se registraron un

acciones

Ingresaron

la

correspondientes

diferentes y realizaron las Gestionar

a

administradores

de financieras

ingresar

herramienta

4

administrador entidades

Al

la

financieras

cada uno en mรกquinas diferentes y realizaron las acciones correspondientes

ingresar

herramienta

a los

administradores 2,6 seg.

entidades

financieras

la 35 de y

realizar las operaciones correspondientes

31-08-13

de

reporte se registraron un total de 2,1 MB

Cantidad de Usuarios: 120 Para visualiza a detalle tenemos en la siguiente imagen un resumen de los 100 usuarios que ingresaron a la pรกgina web


Cantidad de Usuarios: 525 Para visualiza a detalle tenemos en la siguiente imagen un resumen de los 500 usuarios que ingresaron a la página web

Para la ejecución de la prueba de carga al módulo web se realizó la prueba en 2 sistemas operativos los cuales mencionamos a continuación: Sistema Operativo

Características

Número de Usuarios

Windows 7 Service Pack 1

• Procesador 2 Ghz Core i7 de 64 bits • Memoria Ram 4GB • Disco Duro: 500GB

120: Ingresaron los respectivos cajeros a la herramienta sin ningún tipo de interrupción o depuración fallida

525: Con esta Cifra de cajeros que ingresaron y realizaron las operaciones correspondientes el sistema se encontró muy lento y se salió de la depuración.

Windows XP Service Pack 3

• Procesador 2.66 Ghz Pentium(R) de 32 bits • Memoria Ram: 1 GB • Disco Duro: 80 GB

120: Para el presente S.O. ingresaron los 120 cajeros pero con un tiempo de respuesta bajo por parte de la herramienta.

525: Efectuando el ingreso y las operaciones correspondientes con el numero de 525 cajeros el S.O. no soporto la cantidad de usuarios y se salió de la depuración.


ANEXO K COMANDO EN JEFE DE LAS FF.AA. DE LA NACIÓN ESCUELA MILITAR DE INGENIERIA “MCAL. ANTONIO JOSE DE SUCRE” BOLIVIA

ENCUESTA PARA OBTENER INFORMACION SOBRE LOS PUNTOS DE COBRANZA PARA EL TRABAJO PROPUESTO Y EL NÚMERO DE SUCURSALES, DEL FONDO FINANCIERO PRIVADO FASSIL.

Marque con una X:

FEMENINO MASCULINO

Entidad Financiera

:

Fondo Financiero Privado FASSIL.

Universo

:

Jefe de departamento de unidad de sistemas.

Objetivo

:

Obtener información sobre el número de sucursales y/o agencias de la entidad financiera en la Ciudad de Cochabamba, así como el número estimado de puntos destinados para el cobro de patentes.

Fecha de aplicación

:

Octubre de 2013.

PREGUNTAS: 1.-¿Cuántas agencias o sucursales existe actualmente dentro del territorio de la Ciudad de Cochabamba? 2.-¿Cuántas de estas agencias o sucursales están habilitadas dentro del territorio urbano y cuantas en las provincias? 3.- Del número de sucursales que existe en el la ciudad de Cochabamba, ¿cuántas de estas se estima habilitar para el cobro de patentes?


ANEXO L Valores Cr铆ticos de la Distribuci贸n T-Student.


ANEXO M

Trabajo de grado  
Read more
Read more
Similar to
Popular now
Just for you