Borrador final by Daniel Bozo

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

TRABAJO DE GRADO

DESARROLLO DE UN SISTEMA DE INSCRIPCIÓN CON MÓDULO DE FACTURACIÓN MEDIANTE INTERMEDIACIÓN FINANCIERA APLICANDO ENLACE EN LÍNEA. CASO DE ESTUDIO: INSTITUTO ING DATA COMP.

DANNY DANIEL TERCEROS BOZO

COCHABAMBA, 2013

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

TRABAJO DE GRADO

DESARROLLO DE UN SISTEMA DE INSCRIPCIÓN CON MÓDULO DE FACTURACIÓN MEDIANTE INTERMEDIACIÓN FINANCIERA APLICANDO ENLACE EN LÍNEA. CASO DE ESTUDIO: INSTITUTO ING DATA COMP.

DANNY DANIEL TERCEROS BOZO

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

TUTOR: LIC. LENNY SANABRIA C. P.h.D.

COCHABAMBA, 2013.

RESUMEN EJECUTIVO Título:

Desarrollo de un sistema de inscripción con módulo de facturación

mediante

intermediación

financiera

aplicando enlace en línea. Caso de estudio: Instituto Ing Data Comp Autor:

Danny Daniel Terceros Bozo

Unidad Académica:

Escuela Militar de Ingeniería Cochabamba

Carrera:

Ingeniería en Sistemas.

El presente trabajo ha sido desarrollado para solucionar la perdida de información, tiempo excesivo en el proceso de inscripción y facturación y largas filas de estudiantes que no siempre son atendidos en el instituto Ing Data Comp por lo se ha visto la necesidad de desarrollar un sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea. De esta manera el trabajo de grado se ha desarrollado en cinco capítulos: En el primer capítulo se describen las generalidades del trabajo, el problema identificado a través un análisis a la situación actual del instituto respecto al proceso de inscripción, facturación y la solución a este problema planteado en un objetivo general el cual implica el desarrollo del sistema propuesto. En el segundo capítulo se describe la teoría para fundamentar el desarrollo el trabajo de grado involucrando técnicas de recopilación de información, intermediación financiera, sistemas de facturación, metodologías y herramientas de desarrollo de software. De manera que son base para la construcción del sistema. En el tercer capítulo se ha desarrollado el sistema dividido en un módulo de inscripción y un módulo de facturación a través de la metodología seleccionada y la aplicación de la teoría obtenida. Así mismo se ha demostrado que el sistema desarrollado incrementa puntos de cobro de matrículas y mensualidades, obtiene

información consistente respecto a la verificación de los cobros y disminuye el tiempo en el proceso de inscripción y facturación de manera que soluciona la problemática existente en el instituto. En el cuarto capítulo se demuestra la viabilidad técnica, económica, operativa y social del sistema desarrollado determinado los requerimientos de hardware y software, el costo y disponibilidad de equipos necesarios para el correcto funcionamiento del sistema propuesto y los beneficios que el sistema proporciona al instituto. Por último en el quinto capítulo se muestran los resultados del desarrollo de trabajo expresados en conclusiones específicas. Así mismo se describen recomendaciones que indican las implicaciones de estudio en investigaciones posteriores o con el fin de complementar el trabajo planteado. Palabras claves: Sistemas de facturación, Sistemas de inscripción, Intermediación financiera.

ÍNDICE DE CONTENIDO TÍTULO

Pág.

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

1.1

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

1.2

ANTECEDENTES. ..................................................................................... 5

1.3

PLANTEAMIENTO DEL PROBLEMA. ...................................................... 8

1.3.1.1

Identificación del problema. ........................................................................ 8

1.3.1.2

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

1.3.1.3

Identificación de las causas. ...................................................................... 9

1.3.2

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

1.3.3

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

1.4

OBJETIVOS Y ACCIONES. .................................................................... 10

1.4.1

Objetivo general. ...................................................................................... 10

1.4.2

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

1.5

JUSTIFICACIÓN. ..................................................................................... 13

1.5.1

Justificación Técnica. ............................................................................... 13

1.5.2

Justificación Económica ........................................................................... 14

1.5.3

Justificación Social ................................................................................... 14

1.6

ALCANCE. ............................................................................................... 14

1.6.1

Alcance temático. ..................................................................................... 14

1.6.2

Alcance temporal...................................................................................... 14

1.6.3

Alcance institucional. ................................................................................ 14

1.7

HIPOTESIS. ............................................................................................. 15

1.7.1

Análisis de variables................................................................................. 15

1.7.2

Definición conceptual. .............................................................................. 15

1.7.3

Operativización de variables. ................................................................... 16 ii

1.8

MATRIZ DE CONSISTENCIA. ................................................................. 18

MARCO TEORICO .................................................................................. 19

2.1

MÉTODOS Y TECNICAS DE RECOLECCIÓN DE DATOS .................... 19

2.1.1

Observación ............................................................................................. 19

2.1.2

Entrevistas ............................................................................................... 20

2.1.3

Cuestionarios ........................................................................................... 21

2.2

INTERMEDIACIÓN FINANCIERA ........................................................... 22

2.2.1

Generalidades .......................................................................................... 22

2.2.1.1

Servicios de remesa ................................................................................. 23

2.2.2

Entidades de intermediación financiera .................................................... 23

2.2.3

Empresa ................................................................................................... 26

2.2.3.1

Institución educativa ................................................................................. 26

2.2.3.2

Procedimientos de habilitación de estudiantes a carreras y cursos ......... 27

2.2.4

Arquitectura del enlace en línea ............................................................... 28

2.2.4.1

Cliente ...................................................................................................... 30

2.2.4.2

Servidor .................................................................................................... 31

2.2.4.3

Canal de comunicación ............................................................................ 35

2.2.5

Seguridad en la intermediación financiera ............................................... 39

2.2.5.1

Protocolos de seguridad ........................................................................... 39

2.2.5.2

Filtros de red ............................................................................................ 41

2.2.5.3

Normativas de seguridad ......................................................................... 41

2.3

SISTEMAS DE FACTURACIÓN .............................................................. 42

2.3.1

Facturación .............................................................................................. 42

2.3.2

Modalidades de facturación ..................................................................... 44

2.3.2.1

Facturación electrónica ............................................................................ 44

2.3.2.2

Facturación en línea ................................................................................. 45 iii

2.3.2.3

Facturación computarizada ...................................................................... 45

2.3.3

Aspectos técnicos de la factura ................................................................ 46

2.4

INGENIERÍA DE SOFTWARE ................................................................. 48

2.4.1

Modelos de desarrollo de software........................................................... 49

2.4.1.1

Modelo Incremental .................................................................................. 49

2.4.1.2

Modelo espiral .......................................................................................... 51

2.4.1.3

Modelo DRA ............................................................................................. 52

2.4.2

Metodologías de desarrollo de software ................................................... 53

2.4.2.1

Proceso unificado ..................................................................................... 53

2.4.2.2

Programación extrema (XP) ..................................................................... 60

2.4.2.3

Scrum ....................................................................................................... 64

2.4.3

Lenguajes de modelado de software........................................................ 67

2.4.3.1

UML.......................................................................................................... 67

2.4.4

Pruebas de software ................................................................................ 72

2.4.4.1

Pruebas unitarias ..................................................................................... 73

2.4.4.2

Pruebas funcionales ................................................................................. 75

2.4.4.3

Pruebas de carga ..................................................................................... 76

2.5

HERRAMIENTAS DE DESARROLLO DE SOFTWARE ......................... 77

2.5.1

Gestión de la configuración ...................................................................... 77

2.5.2

Arquitecturas de desarrollo de software ................................................... 78

2.5.2.1

Arquitectura cliente/servidor ..................................................................... 78

2.5.2.2

Arquitectura de n-capas ........................................................................... 79

2.5.3

Lenguajes de programación ..................................................................... 84

2.5.3.1

C Sharp .................................................................................................... 84

2.5.3.2

Java.......................................................................................................... 85

2.5.3.3

PHP .......................................................................................................... 86 iv

2.5.4

Sistemas gestores de base de datos ....................................................... 86

2.5.4.1

Sql server ................................................................................................. 87

2.5.4.2

MySql ....................................................................................................... 88

2.5.4.3

PostgreSql ................................................................................................ 88

2.5.4.4

Replicación de base de datos .................................................................. 89

MARCO PRÁCTICO ................................................................................ 92

3.1

DETERMINACIÓN DEL PROCESO ACTUAL DE INSCRIPCIÓN Y

FACTURACIÓN ........................................................................................................ 92 3.1.1

Resultado de entrevista respecto al proceso actual de inscripción y

facturación................................................................................................................. 92 3.1.2

Modelo de negocio actual ........................................................................ 93

3.1.2.1

Modelo de negocio en tres niveles ........................................................... 93

3.1.2.2

Modelado de negocio actual .................................................................... 94

3.1.2.3

Deficiencias en el proceso actual de inscripción y facturación ................. 95

3.1.3

Modelo de negocio alternativo ................................................................. 95

3.1.3.1

Modelo de negocio en tres niveles ........................................................... 95

3.1.3.2

Modelado de negocio alternativo.............................................................. 96

3.2

REQUERIMIENTOS EN ENTIDADES FINANCIERAS RESPECTO A LA

INTERMEDIACIÓN

FINANCIERA

REQUERIMIENTOS

ENTIDADES

REGULADORAS RESPECTO A LA FACTURACIÓN MEDIANTE SISTEMAS INFORMÁTICOS ...................................................................................................... 97 3.2.1

Aspectos de técnicos en la intermediación financiera según la circular

SB/466/2004 ............................................................................................................. 97 3.2.2

Aspectos de seguridad en la intermediación financiera según la circular

SB/466/2004 ............................................................................................................. 98 3.2.3

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

3.2.4

Requerimientos de solicitud de intermediación financiera para cobro de

servicios (Fondo Financiero Privado Fassil) ........................................................... 100 3.2.4.1

Sistema de recepción de pagos ............................................................. 101

3.2.5

Requerimientos para la emisión de factura ............................................ 101

3.2.5.1

Formato de la factura ............................................................................. 101

3.2.5.2

Dosificación ............................................................................................ 103

3.2.5.3

Registro de AutoImpresor ...................................................................... 103

3.2.5.4

Facturación por terceros ........................................................................ 104

3.2.5.5

Prototipo de factura ................................................................................ 104

3.3

DESARROLLO DEL MODULO DE INSCRIPCIÓN ............................... 105

3.3.1

Identificación y selección de metodología de desarrollo ........................ 105

3.3.2

Análisis de selección del modelo de desarrollo ...................................... 107

3.3.3

Análisis de selección del lenguaje de programación .............................. 108

3.3.4

Aplicar las etapas de la metodología elegida al módulo de inscripción .. 110

3.3.4.1

Identificación de fases y flujo de trabajo de UP ...................................... 110

3.3.4.2

Fase de inicio ......................................................................................... 111

3.3.4.3

Fase de elaboración ............................................................................... 116

3.3.4.4

Fase de construcción ............................................................................. 123

3.3.4.5

Fase de transición .................................................................................. 142

3.3.5

Identificación y selección de servidor de aplicaciones y servidor de base

de datos 145 3.3.5.1

Análisis de selección de servidor de aplicaciones .................................. 145

3.3.5.2

Análisis de selección de servidor de base de datos ............................... 146

3.4

DESARROLLO DEL MÓDULO DE FACTURACIÓN CON ENLACE EN

LÍNEA APLICANDO INTERMEDIACIÓN FINANCIERA ........................................ 148 3.4.1

Aplicar las etapas de la metodología elegida al módulo de facturación . 148

3.4.1.1

Fase de inicio ......................................................................................... 148

3.4.1.2

Fase de elaboración ............................................................................... 152

3.4.1.3

Fase de construcción ............................................................................. 161

3.4.1.4

Fase de transición .................................................................................. 186

3.4.2

Diseño del enlace en línea ..................................................................... 189

3.4.2.1

Cliente .................................................................................................... 189

3.4.2.2

Servidor .................................................................................................. 189

3.4.2.3

Canal de comunicación .......................................................................... 189

3.4.2.4

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

3.4.2.5

Esquema conexión entre entidad financiera e instituto .......................... 191

3.5

PRUEBAS FINALES DEL SISTEMA DE INSCRIPCIÓN Y EL MÓDULO

DE FACTURACIÓN. ............................................................................................... 193 3.5.1

Pruebas de carga y concurrencia ........................................................... 193

3.5.1.1

Aplicación de pruebas de carga y concurrencia al sistema de inscripción ... ............................................................................................................... 193

3.5.1.2

Aplicación de pruebas de carga y concurrencia al módulo de facturación ... ............................................................................................................... 194

3.6

DEMOSTRACIÓN DE LA HIPOTESIS .................................................. 195

3.6.1

Demostración de la primera variable dependiente: Filas de estudiantes

incrementando puntos de cobro de matrículas y mensualidades............................ 197 3.6.2

Demostración

segunda

variable

dependiente:

Información

consistente respecto a la verificación del cobro de los mismos .............................. 198 3.6.2.1

Integridad en la base de datos ............................................................... 198

3.6.2.2

Funciones hash ...................................................................................... 200

3.6.2.3

Certificados ............................................................................................ 200

3.6.2.4

Comparación de la integridad de la información .................................... 201

vii

3.6.3

Demostración de la tercera variable dependiente: Tiempo en el proceso

inscripción y facturación en el instituto Ing Data Comp ........................................... 202 3.6.4

Demostración de la variable independiente: El sistema de inscripción con

módulo de facturación mediante intermediación financiera aplicando enlace en línea . ............................................................................................................... 204 3.6.5

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

3.6.6

Cálculo del estadístico T ........................................................................ 207

ANÁLISIS DE VIABILIDAD ................................................................... 211

4.1

Viabilidad técnica ................................................................................. 211

4.1.1

Requerimientos del sistema ................................................................... 211

4.1.1.1

Licencias de software ............................................................................. 215

4.1.2

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

4.1.3

Requerimientos de personal .................................................................. 216

4.2

Viabilidad económica........................................................................... 217

4.2.1

Costos por componente tecnológico ...................................................... 217

4.2.2

Costos por mano de obra ....................................................................... 220

4.3

Viabilidad operativa ............................................................................. 235

CONCLUSIONES Y RECOMENDACIONES ......................................... 238

5.1

Conclusiones ........................................................................................ 238

5.2

Recomendaciones................................................................................ 240

5.2.1

Recomendaciones para el sistema de inscripción:................................. 240

5.2.2

Recomendación para el módulo de facturación ..................................... 241

BIBLIOGRAFÍA ...................................................................................................... 243 ANEXOS ............................................................................................................... 244

viii

ÍNDICE DE TABLAS Tabla Nº 1:

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

Tabla Nº 2:

Operativización de variables. ........................................................... 16

Tabla Nº 3:

Vistas y diagramas UML .................................................................. 69

Tabla Nº 4:

Selección de entidad financiera ....................................................... 99

Tabla Nº 5:

Selección de metodología de desarrollo ........................................ 106

Tabla Nº 6:

Selección de modelo de desarrollo ................................................ 107

Tabla Nº 7:

Selección de lenguaje de programación ........................................ 108

Tabla Nº 8:

Escenario: Crear cuenta usuario .................................................... 112

Tabla Nº 9:

Escenario: Crear carrera/curso ...................................................... 118

Tabla Nº 10:

Escenario: Realizar inscripción ...................................................... 125

Tabla Nº 11:

Pruebas funcionales: Sistema de inscripción ................................. 142

Tabla Nº 12:

Selección de servidor de aplicaciones ........................................... 145

Tabla Nº 13:

Selección de gestor de base de datos ........................................... 146

Tabla Nº 14:

Escenario: Crear entidad financiera ............................................... 149

Tabla Nº 15:

Escenario: Crear credencial de usuario ......................................... 154

Tabla Nº 16:

Escenario: Registrar datos de dosificación .................................... 155

Tabla Nº 17:

Escenario: Registrar pago.............................................................. 163

Tabla Nº 18:

Pruebas funcionales: Módulo de facturación ................................ 186

Tabla Nº 19:

Resultados de prueba de carga: Sistema de inscripción ............... 193

Tabla Nº 20:

Resultados de prueba de carga: Módulo de facturación ................ 194

Tabla Nº 21:

Operativización de variables de la hipótesis .................................. 196

Tabla Nº 22:

Puntos de cobro de matrículas y mensualidades........................... 197

Tabla Nº 23:

Integridad de la información sin el sistema y con el sistema.......... 201

Tabla Nº 24:

Tiempos invertidos en el proceso de inscripción y facturación ...... 202 ix

Tabla Nº 25:

Beneficios del sistema de propuesto ............................................. 205

Tabla Nº 26:

Requerimientos funcionales: Equipo servidor ................................ 211

Tabla Nº 27:

Requerimientos

inscripción

....................................................................................................... 213

Tabla Nº 28:

Requerimientos

facturación

....................................................................................................... 214

Tabla Nº 29:

Requerimientos no funcionales: Equipo servidor ........................... 215

Tabla Nº 30:

Requerimientos funcionales: Enlace en línea ................................ 216

Tabla Nº 31:

Requerimientos de personal .......................................................... 216

Tabla Nº 32:

Precio de componentes: Equipo servidor ...................................... 217

Tabla Nº 33:

Precio de componentes: Equipo cliente del sistema de inscripción .....

funcionales:

Equipo

cliente

del

sistema

módulo

....................................................................................................... 218 Tabla Nº 34:

Precio de componentes: Equipo cliente del módulo de facturación ..... ....................................................................................................... 219

Tabla Nº 35:

Precio de enlace en línea............................................................... 219

Tabla Nº 36:

Lista de costos por componente tecnológico ................................. 220

Tabla Nº 37:

Módulos del sistema propuesto ..................................................... 222

Tabla Nº 38:

Puntos Función no Ajustados: Módulo de inscripción .................... 223

Tabla Nº 39:

Valores de factores de ajuste - LDC .............................................. 223

Tabla Nº 40:

Factores de costo en COCOMO II: Módulo de inscripción ............ 225

Tabla Nº 41:

Puntos Función no Ajustados: Módulo de facturación ................... 226

Tabla Nº 42:

Valores de factores de ajuste - LDC .............................................. 227

Tabla Nº 43:

Factores de costo en COCOMO II: Módulo de facturación ............ 228

Tabla Nº 44:

Factores de escala ......................................................................... 230

Tabla Nº 45:

Tabla Final de COCOMO II ............................................................ 234 x

Tabla N潞 46:

Tabla final de viabilidad econ贸mica ............................................... 235

ÍNDICE DE FIGURAS Figura Nº 1:

Arquitectura cliente servidor............................................................... 3

Figura Nº 2:

Matriz de consistencia. .................................................................... 18

Figura Nº 3:

Entidades de intermediación financiera ........................................... 25

Figura Nº 4:

Envío de solicitudes del cliente al servidor ...................................... 30

Figura Nº 5:

Componentes de cliente .................................................................. 31

Figura Nº 6:

Componentes del servidor ............................................................... 32

Figura Nº 7:

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

Figura Nº 8:

Cliente/servidor con servidor de aplicaciones .................................. 33

Figura Nº 9:

Arquitecturas cliente/servidor: comparación entre de dos y tres

capas

......................................................................................................... 34

Figura Nº 10:

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

Figura Nº 11:

Infraestructura del software cliente/servidor..................................... 36

Figura Nº 12:

Componentes del middleware de base de datos ............................. 37

Figura Nº 13:

Interacción entre los componentes middleware cliente/servidor ...... 38

Figura Nº 14:

S-HTTP sobre SSL .......................................................................... 40

Figura Nº 15:

Firewalls: La patrulla fronteriza de la red. ........................................ 41

Figura Nº 16:

El modelo incremental ..................................................................... 50

Figura Nº 17:

Modelo en espiral típico ................................................................... 51

Figura Nº 18:

Modelo DRA..................................................................................... 53

Figura Nº 19:

Ciclo de vida del proceso unificado. ................................................. 54

Figura Nº 20:

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

Figura Nº 21:

El proceso unificado ......................................................................... 55

Figura Nº 22:

Modelo del proceso unificado. ......................................................... 59

Figura Nº 23:

Los cinco flujos de trabajo................................................................ 60 xii

Figura Nº 24:

El proceso de la programación extrema .......................................... 62

Figura Nº 25:

El proceso de desarrollo de software en Scrum............................... 64

Figura Nº 26:

Fases de pruebas ............................................................................ 72

Figura Nº 27:

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

Figura Nº 28:

Pruebas unitarias ............................................................................. 74

Figura Nº 29:

Pruebas de caja negra. .................................................................... 75

Figura Nº 30:

Arquitectura de un sistema de biblioteca de películas y fotografías . 79

Figura Nº 31:

Diagrama básico de la división según n-capas. ............................... 80

Figura Nº 32:

Diagrama de 2 niveles ..................................................................... 81

Figura Nº 33:

Modelo de 2 niveles, con una capa de dominio de aplicación ......... 82

Figura Nº 34:

Esquema de 3 niveles y n-capas ..................................................... 83

Figura Nº 35:

Replicación de datos ........................................................................ 89

Figura Nº 36:

Modelado de negocio actual en tres niveles .................................... 93

Figura Nº 37:

Modelado de negocio actual ............................................................ 94

Figura Nº 38:

Modelado de negocio alternativo en tres niveles ............................. 95

Figura Nº 39:

Modelado de negocio alternativo ..................................................... 96

Figura Nº 40:

Prototipo de factura instituto Ing Data Comp ................................. 105

Figura Nº 41:

Flujo de trabajo de UP ................................................................... 110

Figura Nº 42:

Diagrama de caso de uso: Crear cuenta usuario ........................... 112

Figura Nº 43:

Diagrama de colaboración: Crear cuenta de usuario ..................... 113

Figura Nº 44:

Diagrama de secuencia: Crear cuenta de usuario ......................... 114

Figura Nº 45:

Diagrama de clases: Cuenta de usuario ........................................ 114

Figura Nº 46:

Diseño de interfaz: Crear cuenta de usuario .................................. 115

Figura Nº 47:

Diseño de interfaz: Gestionar cuenta de usuario ........................... 115

Figura Nº 48:

Diagrama componentes: Cuenta de usuario .................................. 116 xiii

Figura Nº 49:

Diagrama de caso de uso: Crear carrera/curso ............................. 117

Figura Nº 50:

Diagrama de colaboración: Crear carrera/curso ............................ 119

Figura Nº 51:

Diagrama de secuencia: Crear carrera/curso ................................ 120

Figura Nº 52:

Diagrama de clases: carrera/curso ................................................ 121

Figura Nº 53:

Diseño de interfaz: Gestionar carrera/curso................................... 122

Figura Nº 54:

Diagrama componentes: Carrera/curso ......................................... 123

Figura Nº 55:

Diagrama de caso de uso: Realizar inscripción ............................. 125

Figura Nº 56:

Diagrama de caso de uso general: Sistema de inscripción ........... 126

Figura Nº 57:

Diagrama de colaboración: Realizar inscripción ............................ 127

Figura Nº 58:

Diagrama de secuencia: Realizar inscripción ................................ 128

Figura Nº 59:

Diagrama de clases del sistema de inscripción ............................. 129

Figura Nº 60:

Diagrama de base de datos del sistema de inscripción ................. 130

Figura Nº 61:

Diseño de interfaz: Interfaz principal del sistema de inscripción .... 131

Figura Nº 62:

Diseño de interfaz: Iniciar sesión ................................................... 131

Figura Nº 63:

Diseño de interfaz: Efectuar inscripción ......................................... 132

Figura Nº 64:

Diagrama componentes: Sistema de inscripción ........................... 133

Figura Nº 65:

Interfaz principal del sistema.......................................................... 134

Figura Nº 66:

Interfaz de inicio de sesión............................................................. 134

Figura Nº 67:

Interfaz de gestión de cuentas de usuario ..................................... 135

Figura Nº 68:

Interfaz de creación de carrera/curso ............................................ 136

Figura Nº 69:

Interfaz: Registrar plan académico ................................................ 137

Figura Nº 70:

Interfaz: Gestionar carrera/curso ................................................... 137

Figura Nº 71:

Interfaz de registro de datos de estudiante .................................... 139

Figura Nº 72:

Gestionar inscripción ..................................................................... 140

Figura Nº 73:

Pruebas unitarias: Sistema de inscripción ..................................... 141 xiv

Figura Nยบ 74:

Diagrama de caso de uso: Crear entidad financiera ...................... 149

Figura Nยบ 75:

Diagrama de colaboraciรณn: Crear entidad financiera ..................... 150

Figura Nยบ 76:

Diagrama de secuencia: Crear entidad financiera ......................... 150

Figura Nยบ 77:

Diagrama de clases: Entidad financiera ......................................... 151

Figura Nยบ 78:

Diseรฑo de interfaz: Crear entidad financiera y agencia .................. 151

Figura Nยบ 79:

Diagrama componentes: Entidad financiera .................................. 152

Figura Nยบ 80:

Diagrama de caso de uso: Crear credencial de usuario ................ 153

Figura Nยบ 81:

Diagrama de caso de uso: Registrar datos de dosificaciรณn ........... 154

Figura Nยบ 82:

Diagrama de colaboraciรณn: Crear credencial de usuario .............. 155

Figura Nยบ 83:

Diagrama de colaboraciรณn: Registrar datos de dosificaciรณn .......... 156

Figura Nยบ 84:

Diagrama de secuencia: Crear credencial de usuario ................... 156

Figura Nยบ 85:

Diagrama de secuencia: Registrar datos de dosificaciรณn .............. 157

Figura Nยบ 86:

Diagrama de clases: Entidad financiera, credencial de usuario y

datos de dosificaciรณn ................................................................................................ 158 Figura Nยบ 87:

Diseรฑo de interfaz: Crear credencial de usuario ............................ 159

Figura Nยบ 88:

Diseรฑo de interfaz: Registrar datos de dosificaciรณn ....................... 159

Figura Nยบ 89:

Diagrama componentes: Entidad financiera, credencial de usuario y

datos de dosificaciรณn ................................................................................................ 160 Figura Nยบ 90:

Diagrama de caso de uso: Registrar pago ..................................... 163

Figura Nยบ 91:

Diagrama de casos de uso general: Sistema de facturaciรณn ......... 164

Figura Nยบ 92:

Diagrama de colaboraciรณn: Ingresar al sistema ............................. 165

Figura Nยบ 93:

Diagrama de colaboraciรณn: Registrar pago .................................... 165

Figura Nยบ 94:

Diagrama de secuencia: Ingresar al sistema ................................. 166

Figura Nยบ 95:

Diagrama de secuencia: Registrar pago ........................................ 167

Figura Nยบ 96:

Diagrama de clases del sistema de inscripciรณn y facturaciรณn ........ 168 xv

Figura Nº 97:

Diagrama de base de datos: Sistema de inscripción y facturación 169

Figura Nº 98:

Diseño de interfaz: Crear entidad financiera y agencia .................. 170

Figura Nº 99:

Diseño de interfaz: Registrar pago (Paso I) ................................... 170

Figura Nº 100: Diseño de interfaz: Registrar pago (Paso II) .................................. 171 Figura Nº 101: Diseño de interfaz: Reporte de pagos ............................................ 171 Figura Nº 102: Diagrama componentes: Sistema de inscripción y facturación ...... 172 Figura Nº 103: Secuencia de acceso al módulo de facturación ............................. 173 Figura Nº 104: Acceso al sistema de facturación................................................... 173 Figura Nº 105: Consulta de inscripción .................................................................. 174 Figura Nº 106: Registro de pago: Paso I ............................................................... 174 Figura Nº 107: Registro de pago: Paso II .............................................................. 175 Figura Nº 108: Visualización de factura ................................................................. 176 Figura Nº 109: Interfaz de generación de reporte de pagos .................................. 177 Figura Nº 110: Reporte general de pagos: Funcionarios de caja........................... 177 Figura Nº 111: Reporte detalle de pagos: Funcionarios de caja ............................ 178 Figura Nº 112: Reporte mensual de pagos ............................................................ 179 Figura Nº 113: Reporte de deudas de estudiantes ................................................ 180 Figura Nº 114: Habilitación de SSL y Https al sistema de inscripción .................... 181 Figura Nº 115: Interfaz de logs de la base de datos .............................................. 183 Figura Nº 116: Pruebas unitarias: Módulo de facturación ...................................... 185 Figura Nº 117: Diagrama de despliegue: Arquitectura del enlace en línea ............ 191 Figura Nº 118: Esquema de diseño de enlace en línea para la intermediación financiera

....................................................................................................... 192

Figura Nº 119: Integridad en la base de datos ....................................................... 199 Figura Nº 120: Campana de Gauss para la demostración de la Hipótesis ............ 209 xvi

ÍNDICE DE ANEXOS ANEXO A: Circular SB/466/2004: Requisitos mínimos de seguridad informática ANEXO B: Sección 10.9.2 del estándar NB-ISO/IEC 17799: Gestión de seguridad de la información ANEXO C: Carreras y cursos disponibles Ing. Data Comp ANEXO D: Formulario de datos del estudiante ANEXO E: Registro de alumnos inscritos Ing Data Comp ANEXO F: Registro de pagos Ing Data Comp. ANEXO G: Factura de talonario del instituto Ing Data Comp ANEXO H: Tarjeta de pago de mensualidades ANEXO I: Generación del código de control ANEXO J: Cuestionarios de recolección de datos ANEXO K: Pruebas del sistema ANEXO L: Aplicación de medidas de seguridad ANEXO M: Cuestionarios para la demostración de las variables de la hipótesis ANEXO N: Valores críticos de la distribución T-Student ANEXO O: Cuestionarios de viabilidad operativa

xvii

1 GENERALIDADES 1.1 INTRODUCCIÓN. Los sistemas informáticos a lo largo de la última década han facilitado en gran manera la forma de organizar, administrar y distribuir la información en una organización o entidad. Las instituciones financieras son un tipo de organización que requiere de estas tecnologías de información para gestionar sus procesos, transacciones e información interna. Por este motivo estas instituciones hacen uso de sistemas informáticos para ofrecer a sus usuarios acceso a servicios financieros1, los cuales se refieren a ofrecer medios de pago (tarjetas, cheques, transferencias) para garantizar la satisfacción de las partes. Las entidades financieras también actúan como empresas remesadoras2, brindando otro tipo de servicios, como el pago de servicios domiciliaros, educativos y otros, tales como: 

Pago de servicios básicos (Luz, Agua, Telefonía).



Pago de servicios educativos (Mensualidades y matriculas de colegios, institutos, universidades).



Otros servicios de pago (Cable, Cine, Comunicación inalámbrica, etc) (Pita, 2011)

La adquisición de este tipo de servicios da lugar a la intermediación financiera 3; la cual da facultad a las entidades financieras a realizar operaciones económicas a nombre de la institución interesada mediante un contrato expreso. La intermediación financiera junto con el uso de sistemas informáticos facilitan el proceso de algunas funciones determinadas, tales como pago de matrículas, mensualidades, facturación y otros en el caso de una institución del área educativa.

Servicios financieros: Son todos aquellos ofrecimientos formales que ofrecen las organizaciones para el manejo del dinero 2 Empresa remesadora: Persona jurídica autorizada a realizar de forma habitual el servicio de remesas, debiendo suscribir contratos para efectuar tal servicio. 3 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.

1 de 243

El cobro de estos servicios educativos facilita el proceso de inscripción y pago de mensualidades a cualquier estudiante. Cuando se realizan este tipo de pagos en una institución financiera, esta proporciona un “voucher” (recibo o constancia de pago) para respaldar la transacción efectuada. (Ley Nº 1488, 1993) Ante toda actividad económica que se da en las instituciones financieras, existen otro tipo de empresas fiscalizadoras y reguladoras que controlan las tributaciones al estado, es decir los impuestos de comercialización y/o funcionamiento de las entidades lucrativas, para tal efecto es preciso la emisión de una factura; que es un documento autorizado por la Administración Tributaria, cuya emisión acredita la prestación de servicios gravados por el IVA. Este proceso de facturación4, puede ser efectuado mediante un sistema informático o de forma manual (usando talonarios impresos), dando resultado a la emisión de la factura. (Ley Nº 843, 2004) El pago de los servicios educativos también puede ser facturado en los predios de las entidades bancarias cuando existen convenios entre estos y las empresas o instituciones interesadas, este proceso es efectuado mediante la utilización de sistemas de facturación, que permiten la emisión impresa de facturas y facilitan la administración tributaria. El uso de cualquier servicio financiero, reduce el tiempo en el proceso de pago y otorga alta disponibilidad en cuanto a formas de pago de los mismos. Normalmente toda entidad financiera brinda estos servicios, categorizados en modalidades las cuales se describen a continuación: 

Modalidad de débito automático: Consiste en que la entidad efectúa el cobro de una cuenta indicada por el cliente, para pagar uno o varios servicios de manera periódica, su conveniencia reside en pagar a tiempo, sin necesidad de estar atentos a la fecha de pago. (Pita, 2011)



Modalidad de pago en ventanilla: La persona proporciona el apellido y nombre ó el código otorgado por la entidad al funcionario de caja, una vez identificada realiza el pago de servicios de manera presencial en ventanilla, a

Facturación: Acto a través el cual el sujeto responsable extiende la factura, nota fiscal o documento equivalente al comprador, cumpliendo con las formalidades establecidas por la administración tributaria.

2 de 243

continuación se emite la factura correspondiente que es entregada al cliente. (Pita, 2011) Toda modalidad requiere los datos de identificación que deben ser otorgados por la institución o la persona interesada para que pueda efectuar el pago de servicios mediante

entidad financiera,

acuerdo a

las modalidades descritas

anteriormente. Estas modalidades son efectuadas mediante un enlace en línea que permite él envió de información de operaciones económicas entre la entidad que tiene un programa cliente5 y la empresa que tiene un servidor6, mediante un canal de comunicación.7 Este enlace está orientado técnicamente al uso de la arquitectura cliente-servidor; es un modelo de aplicación distribuida8 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). (Figura Nº 1). Figura Nº 1:

Arquitectura cliente servidor

Fuente: [Cotorruelo, 2004]

Cliente: Aplicación informática que solicita un servicio de otro computador, conocido como servidor, normalmente a través de una red de telecomunicaciones. 6 Servidor: Es un equipo informático que provee servicios a otros equipos ó aplicaciones llamadas cliente a través de una red de telecomunicaciones. 7 Canal de comunicación: Medio de transmisión por el que viajan las señales portadoras de la información entre emisor y receptor. Es frecuente referenciarlo también como canal de datos. 8 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.

3 de 243

Todos los clientes están conectados al servidor, en el que se centralizan los diversos recursos y aplicaciones con que se cuenta; y que los pone a disposición de los clientes cada vez que estos son solicitados, esto significa que todas las gestiones que se realizan se concentran en el servidor. Bajo esta arquitectura se puede estructurar el enlace en línea que permite la intermediación financiera y requiere 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. (Orfali, 2002)



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. (Orfali, 2002)



Canal de comunicaciones: Es el medio por el cuál 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)

Las instituciones educativas como parte interesada determinan con que modalidad de servicio se puede trabajar, por lo cual las entidades financieras acorde a normativas existentes, brindan información respecto a los requerimientos operativos, técnicos y de seguridad, así como el costo del servicio para que la intermediación financiera se pueda efectuar con la institución interesada, mediante un acuerdo entre ambas partes. Para más información sobre las normativas (Ver Anexo A: Circular SB/466/2004 Requisitos mínimos de seguridad informática) y (Ver Anexo B:

4 de 243

Sección 10.9.2 del estándar NB-ISO/IEC 17799: Gestión de seguridad de la información). El desarrollo del proyecto pretende brindar un medio que permita la inscripción de estudiantes y el pago por este concepto con un módulo facturación mediante intermediación financiera aplicando un enlace en línea, al instituto Ing Data Comp. Solucionando así los problemas que se tienen en el proceso de inscripción y facturación.

1.2 ANTECEDENTES. La intermediación financiera es una actividad muy común en nuestro medio, empresas como Elfec, Comteco, Semapa y varios colegios, permiten que sus clientes puedan pagar el servicio correspondiente en las agencias de las entidades financieras con las cuales tienen un acuerdo. Actualmente se cobran estos servicios mediante el uso de sistemas informáticos, tales como el SFI (Sistema Financiero Integrado) desarrollado por la empresa AXON u otros. De manera que cuando el cliente efectúe el pago correspondiente permitan registrar y enviar esta transacción de la entidad financiera a la empresa respectiva, actualizando inmediatamente el estado de pagos del cliente; es decir que se cancelan las deudas pendientes. Así mismo el funcionario de caja emite una factura respectiva (la cuál es por cuenta de la empresa) que respalda la prestación del servicio y da cumplimiento a las formalidades establecidas por la administración tributaria. El instituto Ing Data Comp es una institución privada que brinda servicios educativos desde hace 18 años. Fue fundado el 19 de junio de 1994 y actualmente cuenta con 376 estudiantes en las diferentes carreras a nivel técnico superior, técnico medio y 142 estudiantes en cursos acelerados. (Ver Anexo C: Carreras y cursos Ing data Comp, Obtenido en entrevista) en la ciudad de Cochabamba. En su infraestructura dispone de 25 aulas, un laboratorio de ensamblaje de computadoras y 5 laboratorios de computación. En el área administrativa el instituto cuenta con una oficina de información, secretaría y una oficina de dirección académica.

5 de 243

Cuando una persona desea cursar alguna carrera o curso en esta institución, debe solicitar la información necesaria de la carrera o curso de su interés, luego llenar un formulario para después cancelar el monto correspondiente por inscripción (matricula y primera mensualidad) en la misma institución. Finalmente se emite una factura como comprobante del pago consumado. Para tener más claro el procedimiento manual que existe para la inscripción y facturación, se describirá en tres partes: proceso de inscripción9, proceso de pago de matrículas y/ó mensualidades y proceso de facturación. a) Proceso de inscripción: De acuerdo al instituto Ing Data Comp es el registro de datos de la persona de forma manual mediante un formulario a una planilla impresa. Este proceso se realiza solo una vez  La persona interesada se aproxima a la oficina de información del instituto, ahí el encargado le proporciona un folleto referente al contenido, costo y fecha de inicio de las carreras y cursos disponibles (Ver Anexo C: Carreras y cursos Ing data Comp, Obtenido en entrevista)  Una vez que la persona decide inscribirse, la secretaria le proporciona un formulario impreso donde el interesado debe llenar sus propios datos manualmente, los cuales son: CI, apellido paterno, materno, nombres, teléfono/celular y carrera/curso (Ver Anexo D: Formulario de datos del estudiante, Obtenido en entrevista).  El estudiante entrega el formulario completado a la secretaria, la cual manuscribe los datos a una planilla denominada: Registro de alumnos inscritos Ing Data Comp. (Ver Anexo E: Registro de alumnos inscritos Ing Data Comp) El motivo por el cuál se usa el formulario de datos es para que la secretaria evite cometer errores de transcripción.  Una vez completada la inscripción la secretaria le entrega una hoja que describe la documentación necesaria para crear el folder personal del estudiante, utilizado para tramitar la titulación del mismo.

Inscripción: Registro de una persona para pasar a formar parte de algo.

6 de 243

b) Proceso de pago: Es el pago del estudiante por concepto de inscripción al curso o carrera de su elección ó el pago de mensualidades de estudiantes ya inscritos. Este es un proceso es necesario para realizar la facturación.  El estudiante cancela en efectivo la matrícula y la primera mensualidad de la carrera ó curso elegido en secretaría, en la cuál se guarda el dinero recibido en una gaveta y registra el detalle de la transacción manualmente en un libro denominado: Reporte diario de ingresos.  La secretaria manuscribe los datos del estudiante, en este caso a otra planilla denominada: Registro de pagos Ing Data Comp. (Ver Anexo F: Registro de pagos Ing Data Comp) Ahí el pago es marcado en una casilla disponible para el monto cancelado por el estudiante de acuerdo a la carrera y semestre respectivo.  Para el pago de las siguientes mensualidades, el estudiante se aproxima al escritorio de la secretaria y le dicta sus apellidos y/ó nombres, entonces la secretaria busca al estudiante mediante los datos mencionados en la planilla respectiva de acuerdo a la carrera y semestre correspondiente. Una vez identificado paga la mensualidad en efectivo y la transacción es registrada en el libro: reporte diario de ingresos y también el pago es registrado en la planilla correspondiente. c) Proceso de facturación: De acuerdo al instituto Ing Data Comp es la emisión de factura por concepto de pago de matrículas y mensualidades, la cuál habilita al estudiante pasar clases, esto sucede en dos situaciones:  Al finalizar la inscripción: Una vez que el estudiante realiza el pago por inscripción, la secretaria mediante el formulario de datos que el estudiante entregó, obtiene el CI y los apellidos con los que emite una factura de forma manual (en talonario) (Ver Anexo G: Factura de talonario del instituto Ing Data Comp, Obtenido en entrevista) Es importante mencionar que el único lugar de pago y facturación, es el escritorio de la secretaria. Finalmente la secretaria le entrega una tarjeta que contiene las fechas de pago de las siguientes

mensualidades

(Ver

Anexo

Tarjeta

pago

mensualidades, Obtenido en entrevista) y archiva la copia de la factura

7 de 243

(que incluyendo a la planilla mencionada. es el único respaldo de pago) en el folder respectivo del estudiante.  Al finalizar el pago de mensualidades: Cuando el estudiante ya está inscrito, solo paga las mensualidades correspondientes, luego que el estudiante es identificado en la planilla de Registro de pagos Ing Data Comp. es emitida la factura (de talonario) de forma manual. Usualmente el proceso de inscripción y facturación demora demasiado tiempo, debido a que la secretaria tiene otras tareas como: Solicitud de permisos para faltas, entrega de documentación, información respecto a las notas de los estudiantes y entrega de copias del Registro de pagos Ing Data Comp para que los docentes puedan verificar que estudiantes pagaron sus mensualidades. Cuando un estudiante es observado como deudor debe salir de clases y aproximarse a consultar el estado de sus pagos en secretaría. El proceso de inscripción, pago y facturación es centralizado en el escritorio de la secretaria donde también cobra las matriculas ó mensualidades de los estudiantes y además realiza otras tareas (mencionadas anteriormente), por lo que existen largas filas de estudiantes que esperan ser atendidos. El instituto Ing Data Comp requiere de una herramienta que permita inscribir alumnos de una manera ágil y cobrar mensualidades y matriculas desde más puntos asegurando que la información (mediante el registro de datos) no se pierda y sea correctamente procesada.

1.3 PLANTEAMIENTO DEL PROBLEMA. A continuación se mencionarán los siguientes puntos para poder determinar el problema de manera clara.

1.3.1.1 Identificación del problema. 1.3.1.2 Identificación de la situación problemática. 

El proceso de inscripción es ineficiente debido a que toma demasiado tiempo que el estudiante llene el formulario de datos manualmente y la secretaria transcriba esos datos en la planilla “Registro de alumnos inscritos Ing Data

8 de 243

Comp” también de forma manual, la cuál es usada para el registro del estudiante. 

El cobro de mensualidades y matriculas es centralizado. Así mismo la facturación manual, lo cual aumenta el tiempo invertido en este proceso, además de ser un trabajo moroso para la secretaria.



La secretaria manuscribe los datos del estudiantes en dos planillas; Registro de alumnos inscritos Ing Data Comp y Registro de pagos Ing Data Comp, esto genera información redundante en el registro de los estudiantes.



Existen largas filas de estudiantes que esperan ser atendidos debido a que la secretaria atiende varias solicitudes como el pago de matrículas y mensualidades, inscripción de estudiantes, solicitud de permisos para faltas, entrega de documentación e información respecto a las notas de los estudiantes.



Como la verificación de pagos es realizada por la secretaria mediante la planilla denominada: Registro de pagos Ing Data Comp por algún motivo (descuido, falta de tiempo por sobredemanda de tareas) olvida marcar la casilla de pago ó marca la casilla equivocada, ocasionando varios problemas como ser que; el estudiante es observado como deudor y debe salir de clases ó el estudiante pueda no pagar alguna mensualidad porque su casilla de pago ya estará marcada.



Durante el proceso de inscripción el formulario de datos de los estudiantes puede ser extraviado ó mezclado entre otros papeles de la secretaria por lo que se busca al estudiante para llenar nuevamente este formulario.

1.3.1.3 Identificación de las causas. Las causas identificadas son: 

Inscripción, facturación y cobro de mensualidades y matriculas es centralizado en un único escritorio de atención por la secretaria.



Proceso manual ineficiente de inscripción el cual requiere el formulario de datos del estudiante que es llenado manualmente.



Proceso manual de emisión de factura (de talonario).

9 de 243



Información redundante en el registro manual de datos de estudiantes en dos planillas.



Múltiples solicitudes en el escritorio atendido por la secretaria.



Registro manuscrito de pagos en planillas.

1.3.2 Formulación del problema. Los ineficientes procedimientos manuales en el registro de estudiantes mediante un formulario, emisión de factura, registro de pagos manuscrito en planillas, y el cobro centralizado de matrículas y mensualidades, provocan perdida de información, tiempo excesivo en el proceso de inscripción y facturación dando lugar a largas filas de estudiantes que no siempre son atendidos.

1.3.3 Análisis causa-efecto. El análisis causa efecto se muestra a continuación: Causa: Los ineficientes procedimientos manuales en el registro de estudiantes mediante un formulario, emisión de factura, registro de pagos manuscrito en planillas, y el cobro centralizado de matrículas y mensualidades. Efecto: Perdida de información, tiempo excesivo en el proceso de inscripción y facturación dando lugar a largas filas de estudiantes que no siempre son atendidos.

1.4 OBJETIVOS Y ACCIONES. Esta sección abarca la descripción de los objetivos y acciones identificadas.

1.4.1 Objetivo general. Desarrollar un sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea, para reducir las filas de estudiantes incrementando puntos de cobro de matrículas y mensualidades, obtener información consistente respecto a la verificación del cobro de los mismos y disminuir el tiempo en el proceso inscripción y facturación en el instituto Ing Data Comp.

10 de 243

1.4.2 Objetivos específicos y acciones. 

Determinar información respecto al proceso actual de inscripción y facturación.



Identificar requerimientos en entidades financieras respecto a la intermediación financiera y requerimientos de entidades reguladoras respecto a la facturación mediante sistemas informáticos.



Desarrollar el módulo de inscripción para el registro de datos del estudiante a la carrera o curso de su interés.



Desarrollar el módulo de facturación con enlace en línea mediante intermediación financiera para el cobro de matrículas y mensualidades una vez que los estudiantes estén inscritos.



Realizar pruebas finales al sistema de inscripción y al módulo de facturación. Tabla Nº 1: Objetivos específicos y acciones. OBJETIVOS ESPECÍFICOS

ACCIONES 

Recopilar

información

mediante

entrevistas a personal indicado para obtener información sobre proceso

Determinar información respecto al proceso

actual

inscripción

actual de inscripción y facturación.

facturación.



Establecer modelo actual de negocio.



Establecer

modelo

negocio

alternativo.  Identificar

requerimientos

entidades

entidades financieras respecto a la intermediación

financiera

requerimientos

entidades

reguladoras respecto a la facturación mediante sistemas informáticos.

Determinar

requerimientos financieras

para

las

otorgar

intermediación financiera 

Determinar requerimientos de emisión de

factura

para

módulo

facturación, de acuerdo a normativas del servicio de impuestos nacionales.

11 de 243



Identificar y seleccionar metodología de desarrollo que se adecue al sistema propuesto.



Aplicar las etapas de la metodología elegida al módulo de inscripción



Realizar el análisis de requerimientos del módulo de inscripción.



Diseñar la interfaz de acceso al módulo de inscripción y de registro de datos del estudiante.

Desarrollar el módulo de inscripción del



Diseñar la base de datos del sistema.

estudiante a la carrera o curso de su



Identificar y seleccionar el servidor de

para

registro

datos

interés.

aplicaciones y de base de datos adecuado para el sistema. 

Configurar el servidor de aplicaciones y de base de datos elegido.



Implementar la interfaz de acceso al módulo y de registro de datos del estudiante

servidor

aplicaciones. 

Realizar

pruebas

módulo

inscripción. Desarrollar el módulo de facturación con

enlace

intermediación

línea

financiera



elegida al módulo de facturación.

aplicando para



cobro de matrículas y mensualidades una vez que los estudiantes estén inscritos.

Aplicar las etapas de la metodología

Realizar el análisis de requerimientos del módulo de facturación.



Diseñar las interfaces de acceso al módulo y emisión de factura según

12 de 243

normativas del SIN. 

Diseñar módulo de conexión (enlace en

línea)

entre

módulo

facturación (cliente) y el servidor de Base de Datos. 

Implementar las interfaces de acceso al módulo y emisión de factura de acuerdo a la metodología de desarrollo elegida.



Implementar módulo de conexión entre el módulo de facturación (cliente) y el servidor de Base de Datos.



Identificar

aplicar

medidas

seguridad a los elementos del enlace en línea (cliente, servidor y canal de comunicación). 

Realizar

pruebas

módulo

facturación. Realizar pruebas finales al sistema de

inscripción



pruebas

adecuadas

realizar.

módulo

facturación.

Identificar



Aplicar pruebas elegidas.

Fuente: [Elaboración propia]

1.5 JUSTIFICACIÓN. Esta sección describe las diferentes justificaciones del tema.

1.5.1 Justificación Técnica. Una vez terminada la propuesta, el beneficio obtenido será contar con un sistema de inscripción de estudiantes a carreras y cursos. Adicionalmente el módulo de facturación mediante la intermediación financiera, permitirá a los estudiantes inscritos

13 de 243

pagar el monto de las matrículas y mensualidades en las distintas sucursales de la entidad financiera y finalmente emitir la factura correspondiente dando lugar a la intermediación financiera, reduciendo el tiempo en ambos procesos y proporcionando información consistente y determinada respecto a la inscripción de alumnos y el estado de pagos de los mismos.

1.5.2 Justificación Económica El beneficio del sistema seria la disminución en el gasto de planillas impresas que son usadas para el registro de estudiantes, registro de pagos y el libro de reporte diario de ingresos. Así mismo los formularios de datos que son llenados manualmente por los estudiantes ya no serán necesarios, por lo que el instituto podrá utilizar ese capital para otros fines.

1.5.3 Justificación Social Los estudiantes del instituto se beneficiaran con la facilidad de inscribirse en un periodo corto de tiempo, además de la flexibilidad de pagar sus matrículas o mensualidades en distintos puntos de cobro autorizados de la entidad financiera con la que se tendrá el convenio.

1.6 ALCANCE. Esta sección describe las diferentes Alcances del tema.

1.6.1 Alcance temático. El área en la que se ubica el presente trabajo es el área de Programación orientada a Web, Ingeniería de Software, UML, Metodologías de diseño,

Intermediación

financiera, Arquitecturas cliente servidor

1.6.2 Alcance temporal. El desarrollo de esta herramienta asumirá una duración de nueve meses en la presente gestión 2013.

1.6.3 Alcance institucional. El sistema será de beneficio para el área de inscripción y facturación en el instituto Ing Data Comp en la ciudad de Cochabamba. 14 de 243

1.7 HIPOTESIS. El sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea, permitirá reducir las filas de estudiantes incrementando puntos de cobro de matrículas y mensualidades, obtener información consistente respecto a la verificación del cobro de los mismos y disminuir el tiempo en el proceso inscripción y facturación en el instituto Ing Data Comp.

1.7.1 Análisis de variables. Variable independiente. El sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea. Variable dependiente. 

Filas de estudiantes incrementando puntos de cobro de matrículas y mensualidades.



Información consistente respecto a la verificación del cobro de los mismos.



Tiempo en el proceso inscripción y facturación en el instituto Ing Data Comp.

1.7.2 Definición conceptual. Variable independiente. El sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea, permitirá registrar alumnos a carreras y cursos de su interés, emitir facturas impresas directamente en la entidad financiera, descentraliza el cobro de mensualidades a varios puntos autorizados, disminuye el tiempo en el proceso de inscripción y facturación. Así mismo proporciona información consistente respecto a la verificación del cobro de mensualidades. Variable dependiente.  Filas de

estudiantes incrementando

puntos de

cobro

matrículas

mensualidades. Involucra extender la cantidad de puntos de cobro de mensualidades en la entidad financiera.

15 de 243

 Información consistente respecto a la verificación del cobro de los mismos Involucra que la información está completa, es decir que es íntegra, donde los datos se mantengan idénticos durante cualquier operación, como transferencia (envío y recepción), almacenamiento y recuperación.  Tiempo en el proceso inscripción y facturación Involucra el tiempo que se toma registrar los datos del estudiante e inscribirlo en el curso o carrera de su interés y cobrar la mensualidad y/o matricula registrando los datos del cobro para emitir la factura correspondiente.

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

Dimensión

Indicador

Variable independiente. El sistema de inscripción con módulo de facturación mediante

intermediación

Inscripción vía web y Facturación (en

Sistema implementado.

entidades financieras)

financiera aplicando enlace en línea. Variable dependiente. Filas

estudiantes

incrementando cobro

puntos

matrículas

de y

Puntos de cobro

Cantidad de puntos de cobro disponibles

mensualidades.

Información

consistente

respecto a la verificación de cobro de los mismos.

Integridad de información

16 de 243

Pruebas de integridad

Tiempo en el proceso de inscripci贸n y facturaci贸n.

Tiempo

Fuente: [Elaboraci贸n propia]

17 de 243

Horas

1.8 MATRIZ DE CONSISTENCIA. Figura Nº 2: PROBLEMA

Matriz de consistencia. OBJETIVOS

HIPÓTESIS

DESARROLLAR UN SISTEMA DE INSCRIPCIÓN CON MÓDULO DE FACTURACIÓN MEDIANTE INTERMEDIACIÓN FINANCIERA APLICANDO ENLACE EN LÍNEA, PARA REDUCIR LAS FILAS DE ESTUDIANTES INCREMENTANDO PUNTOS DE COBRO DE MATRICULAS Y MENSUALIDADES, OBTENER INFORMACIÓN CONSISTENTE RESPECTO A LA VERIFICACIÓN DEL COBRO DE LOS MISMOS Y DISMINUIR EL TIEMPO EN EL PROCESO INSCRIPCIÓN Y FACTURACIÓN EN EL INSTITUTO ING DATA COMP.

Los ineficientes procedimientos manuales en el registro de estudiantes mediante un formulario, emisión de factura, registro de pagos manuscrito en planillas, y el cobro centralizado de matrículas y mensualidades.

PROVOCA Perdida de información, tiempo excesivo en el proceso de inscripción y facturación dando lugar a largas filas de estudiantes que no siempre son atendidos.

Desarrollar un sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea

La aplicación del sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea

PARA

PERMITIRÁ Reducir las filas de estudiantes incrementando puntos de cobro de matrículas y mensualidades, obtener información consistente respecto a la verificación del cobro de los mismos y disminuir el tiempo en el proceso inscripción y facturación

Fuente: [Elaboración propia]

18 de 243

Reducir las filas de estudiantes incrementando puntos de cobro de matrículas y mensualidades, obtener información consistente respecto a la verificación del cobro de los mismos y disminuir el tiempo en el proceso inscripción y facturación

2 MARCO TEORICO 2.1 MÉTODOS Y TECNICAS DE RECOLECCIÓN DE DATOS En este apartado se describen métodos y técnicas que serán utilizados con el fin de recopilar datos sobre la situación existente en el Instituto Ing Data Comp. Los métodos de recolección de datos indican la forma de obtención de los datos, es decir el modo de obtenerlos (escrito, verbal, etc). A su vez existen técnicas que son reglas que mediante el empleo de instrumentos, permiten obtener los datos sobre el objeto de estudio adoptando un método. Las técnicas de recolección de datos que se emplean con más frecuencia son: 

Observación



Entrevistas (Yuni, 2006)

2.1.1 Observación Consiste en observar un fenómeno de interés para obtener y registrar la información deseada. Las formas de observación que generalmente se emplean se fundamentan en sus procedimientos, por este motivo se dividen en: 

Observación simple y observación experimental



Observación discreta y observación abierta



Observación estructurada y observación no estructurada



Observación participante y observación no participante

a) Observación simple: Se realiza en un ambiente natural, anotando los hechos de interés; por ejemplo, observar el comportamiento en un establecimiento comercial, para saber si hay una relación entre el tiempo de su permanencia y la probabilidad de que adquiera cierta cantidad de mercancía. b) Observación experimental: Se realiza en una situación artificial controlada, sobre la cuál se disponen condiciones para descubrir ciertas relaciones; por ejemplo realizar una serie de ensayos en un laboratorio para confirmar una teoría.

19 de 243

c) Observación discreta: Se realiza de modo que los individuos no saben que están siendo observados. Este procedimiento se efectúa por medio de la observación personal o el empleo de aparatos mecánicos tales como la cámara fotográfica y un micrófono escondido. d) Observación abierta: Se realiza de modo que los individuos saben que están siendo investigados. e) Observación estructurada: Se realiza al conocer de antemano los hechos y las características que se van a identificar y registrar; por tanto es una técnica utilizada con frecuencia en estudios sistemáticos. Para este procedimiento la situación y el problema tienen que estar relativamente bien especificados; y como se tiene conocimiento de lo que se desea analizar; se observan los aspectos precisos sobre los objetos de estudio. f) Observación no estructurada: Consiste en anotar las actividades y las características que se estimen más convenientes, en el lugar y tiempo de ocurrencia, sin tener que acudir a técnicas especiales. g) Observación participante: El investigador se mezcla con la situación observada y coopera con las actividades al detectar los aspectos que le interesan. h) Observación no participante: El investigador entra en contacto con el fenómeno, pero observa y toma notas de los aspectos de interés sin mezclarse ni penetrar en el hecho o situación a estudiar. (Landeau, 2007)

2.1.2 Entrevistas Permiten al investigador obtener información más detallada, mediante una serie de preguntas formuladas (en el contexto de la investigación) que se hacen a las personas implicadas con el objeto de estudio con el propósito de obtener datos sobre los elementos a estudiar. En esta técnica, se da una participación de ambas partes. La persona entrevistada se convierte en un sujeto informante sobre las necesidades de información que son indagadas por el investigador mediante la aplicación de la técnica.

20 de 243

La entrevista puede ser aplicada de las siguientes formas: 

De manera personal, donde las preguntas se formulan y se responden directamente, el entrevistador y el entrevistado está presente.



Por teléfono, donde el dialogo se realiza a través del mismo.

La entrevista adopta el empleo de un instrumento denominado cuestionario que permite la obtención de datos y será descrita en el siguiente apartado. (Landeau, 2007)

2.1.3 Cuestionarios Es el método que utiliza un instrumento o formulario impreso, que consta de preguntas escritas destinado a obtener repuestas sobre el problema en estudio sin intervención del investigador. El cuestionario puede aplicarse a grupos o individuos estando presente el investigador o el responsable del recoger la información, o puede enviarse por correo a los destinatarios seleccionados en la muestra de una población dada. Debido a su administración se puede presentar problema relacionados con la cantidad y calidad de datos que pretende obtener para el estudio, es importante que el cuestionario tenga las siguientes cualidades fundamentales: confiabilidad y validez. El diseño de un cuestionario es una labor que se debe realizar al considerar sus objetivos fundamentales que son: 

Motivar al entrevistado.



Obtener respuestas claras acorde con la información deseada.

Las etapas para el desarrollo de un cuestionario son las siguientes: 

Establecer la naturaleza de la información que se requiere.



Precisar las características de la población estudiada.



Determinar cómo se aplicará el cuestionario.



Especificar el tipo de preguntas adecuadas.



Determinar el contenido de las preguntas.

Las preguntas son los elementos básicos de un cuestionario; por lo tanto, para que proporcionen la información deseada es necesario que se formulen de acuerdo a los objetivos para las cuales son apropiadas, según su finalidad y en función del 21 de 243

entrevistado. Básicamente, se recurre a dos tipos de preguntas, las abiertas y las cerradas. 

La pregunta abierta: Contiene una interrogación que el individuo contesta de acuerdo a sus ideas y con sus propias palabras, sin tener que limitarse a respuestas prefijadas. Esta modalidad de pregunta es adecuada cuando el tema es complejo y cuando no se conocen con precisión sus elementos relevantes.



La pregunta cerrada: Contiene una interrogación y un conjunto de alternativas fijas de respuesta, definidas con anticipación por el investigador para que el entrevistado seleccione la que corresponda a su respuesta. Este tipo de preguntas ofrece dos o más opciones, de las cuales, dependiendo de lo que se pretenda abordar, se hace la elección.

Cuando el cuestionario se haya elaborado en su totalidad, es importante hacer una revisión de las preguntas, para comprobar la calidad del instrumento, medir el grado de su comprensión y determinar si es competente y adecuada a las características del estudio que se está realizando. (Landeau, 2007)

2.2 INTERMEDIACIÓN FINANCIERA 2.2.1 Generalidades 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. La Autoridad de Supervisión del Sistema Financiero (ASFI) otorga la autorización a estas entidades para proporcionar servicios financieros. De manera que estas entidades autorizadas son denominadas: Entidades de intermediación financiera. La intermediación financiera es efectuada mediante la adquisición de un servicio financiero con un contrato expreso, el cual define una relación entre la entidad financiera y el solicitante del servicio (institución o empresa).

22 de 243

El tipo de servicio puede ser: 

Servicio de pago: Incluye Administración de instrumentos de pago, procesamiento de órdenes de pago, Cambio de divisas, servicios de remesa, etc (Ley Nº 1488, 1993)

2.2.1.1 Servicios de remesa A su vez una entidad de intermediación financiera puede ser una empresa remesadora, la cual tiene las siguientes funciones: 

Envío y pago de remesas al interior y exterior del país



Envío y pago de giros a nivel nacional



Envío y pago de giros al exterior



Compra y/o venta de moneda extranjera derivada de la prestación del servicio de remesas y/o giros.



Cobro de servicios básicos.

Las instituciones, empresas, etc; pueden solicitar este servicio a una entidad de intermediación financiera mediante un contrato expreso con el objeto de que esta última realice operaciones financieras por cuenta de la institución. (Ley Nº 1488, 1993)

2.2.2 Entidades de intermediación financiera En el sistema financiero10 del país existen dos grandes grupos de intermediarios financieros: las entidades financieras bancarias y las entidades financieras no bancarias. 

Las entidades financieras bancarias: 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.

Sistema financiero: Es el conjunto de Instituciones bancarias, financieras y demás empresas e instituciones de derecho público o privado, debidamente autorizadas por la Autoridad de Supervisión del Sistema Financiero, que operan en la intermediación financiera.

23 de 243



Las entidades financieras no bancarias: Son el resto de entidades que intermedian en el mercado financiero, estas 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 ó mutual de ahorro y préstamo.

Las entidades mencionadas actúan como intermediarios financieros desempeñando un papel importante dentro del sistema financiero, pues ponen en conexión a los prestatarios y a los prestamistas, permitiendo adecuar las necesidades entre ambas partes. (Ley Nº 1488, 1993) De acuerdo a la autorización de la ASFI (Figura Nº 3) las entidades de intermediación financiera que pueden ofrecer servicios financieros son:



Banco



Fondo financiero privado



Cooperativa de ahorro y crédito



Mutual de ahorro y préstamo

Banco: Entidad financiera autorizada, de origen nacional o extranjero, dedicada habitualmente a realizar operaciones de intermediación y a prestar servicios financieros al público. Es la entidad más importante dentro del sector financiero con relación a los fondos que moviliza, ya que la captación de pasivo y la inversión crediticia es la principal actividad de los bancos.



Fondo financiero privado: Es una sociedad anónima cuyo objeto principal es la canalización de recursos a pequeños y micro prestatarios cuyas actividades se localizan tanto en áreas urbanas como rurales.



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.

24 de 243



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.

Figura Nº 3:

Entidades de intermediación financiera

Fuente: [Autoridad de Supervisión del Sistema Financiero, 2005]

Las empresas auxiliares de servicios financieros tienen el objetivo de la intermediación de recursos, en favor de entidades de intermediación financiera y de asociaciones o fundaciones de carácter financiero, pero no brindan el mismo tipo de servicios financieros al público. (Ley Nº 1488, 1993) Las entidades financieras son las que proveen el servicio de remesa a instituciones para así efectuar la intermediación financiera.

25 de 243

2.2.3 Empresa Es la institución que solicita el servicio de remesa a la entidad de intermediación financiera. Esta institución puede ser: 

Institución de servicios básicos (Telefonía, Luz, Agua, Gas)



Institución de servicios educativos (nivel primaria, secundaria, superior)



Institución de otro tipo de servicios (Cine, Cosméticos, Cable, Telefonía inalámbrica)

2.2.3.1 Institución educativa Una institución educativa es un centro organizado cuya la finalidad de formar de manera global o más específica, a las personas de distintas edades que acuden a él. De acuerdo a la estructura general del sistema educativo, estas instituciones esta divididas en niveles, los cuales son: 

Educación prescolar: Constituye el primer nivel de educación, el cual es preparatorio para en nivel primario.



Educación primaria: Se orienta al aprendizaje de lectura, escritura, entorno social, razonamiento y el desarrollo del lenguaje.



Educación secundaria: Orientado al logro de habilidades y conocimientos técnicos y aprendizaje científico-humanístico.



Educación superior: Formación técnico profesional, tecnológica, humanísticoartística y la científica, incluyendo la capacitación y la especialización.

El instituto Ing Data Comp (Ingeniería de datos y computación) es una institución privada que brinda servicios educativos a nivel superior desde hace 18 años. Fue fundado el 19 de junio de 1994 y actualmente cuenta con 376 estudiantes en las diferentes carreras a nivel técnico superior, técnico medio y 142 estudiantes en cursos acelerados. (Ver Anexo C: Carreras y cursos Ing data Comp, Obtenido en entrevista) en la ciudad de Cochabamba. En su infraestructura dispone de 25 aulas, un laboratorio de ensamblaje de computadoras y 5 laboratorios de computación.

26 de 243

2.2.3.2 Procedimientos de habilitación de estudiantes a carreras y cursos Cuando una persona desea cursar alguna carrera o curso debe cumplir ciertos requisitos para luego realizar una serie de pasos que le permitan ser habilitado en el instituto como estudiante y pueda pasar clases. Las carreras a nivel técnico medio y superior solo pueden ser cursadas personas que al menos tengan bachillerato en cambio los cursos técnicos no tienen esta restricción. Por este motivo el instituto tiene requisitos que permiten crear el folder de identificación cada estudiante y estos son los siguientes: Requisitos para carreras a nivel técnico medio o superior: Estos son: 

Una fotocopia de carnet de identidad



Una fotocopia de título de bachiller



Cuatro fotografías, tamaño 3x4 fondo rojo (traje oscuro c/corbata)



Un folder amarillo



Un acofaster y/o nepaco



Una fotocopia de certificado de nacimiento

Requisitos para cursos: Estos son: 

Todos los anteriores excepto a fotocopia de título de bachiller

Una vez que se cumplen los requisitos mencionados, se efectúan una serie de pasos, los cuales se refieren a los siguientes procesos: a) Proceso de inscripción b) Proceso de pago c) Proceso de facturación a) Proceso de inscripción: De acuerdo al instituto Ing Data Comp, es el registro de los datos de la persona al curso o carrera de su elección, para que luego pueda proseguir con los siguientes procesos y esté habilitado para pasar clases en el instituto.

27 de 243

b) Proceso de pago: El pago es un modo de extinguir11 las obligaciones existentes, que consiste en el cumplimiento efectivo de la prestación debida (no solo se refiere a la entrega de una cantidad de dinero o de una cosa), también se refiere al cumplimiento del contenido del objeto de una prestación. El estudiante debe cancelar el monto respectivo en dos situaciones: -

Cuando ya está inscrito el estudiante, efectúa el pago de la matrícula y la primera mensualidad.

Cuando el estudiante cancela el resto de sus mensualidades.

c) Proceso de facturación: Es la emisión de factura que acredita la prestación de un servicio (pago por inscripción ó pago de mensualidad). Una vez concretado este último proceso el estudiante es habilitado para pasar clases en el curso o carrera en el que se inscribió. (RND Nº 10-0016-07, 2007) Dentro de la intermediación financiera el instituto es el solicitante del servicio de remesa, el cual una vez adquirido mediante un contrato expreso permite que la entidad financiera cobre los servicios educativos a nombre del instituto.

2.2.4 Arquitectura del enlace en línea La intermediación financiera requiere de una estructura que permita el envío de transacciones (operaciones financieras) de la entidad financiera hacia la institución con la que se ha realizado el previo acuerdo, dando resultado a la arquitectura cliente/servidor, la cuál es un tipo de enlace o red que permite relacionar tres partes fundamentales (Un medio de registro de transacciones, un medio de almacenamiento de tales transacciones y un medio de comunicación que relacione las dos partes anteriores). Esta arquitectura es un modelo de aplicación distribuida12 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). (Blake, 2005)

Extinguir: Son los hechos en virtud de los cuales la obligación deja de existir. 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. 12

28 de 243

La arquitectura cliente/servidor tiene ciertas 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; el cliente los consume. 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 diálogo al solicitar un servidor, 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 escalamiento vertical significa migrar a una máquina servidor más grande y rápida o distribuir la carga de procesamiento entre varios servidores. (Ley 1488, 1993)

La arquitectura cliente/servidor posee tres elementos, estos son cliente, servidor y canal

comunicación

(descritos

más

adelante).

Estos

elementos

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

29 de 243

está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) (Orfali, 2002)

2.2.4.1 Cliente Permite al usuario enviar solicitudes o peticiones al servidor mediante una interfaz gráfica de usuario, espera y recibe las respuestas del servidor. La interacción cliente servidor, se puede ver claramente en la (Figura Nº 4) (Rob, 2004) Figura Nº 4:

Envío de solicitudes del cliente al servidor

Fuente: [Ian Sommerville, 2005]

El cliente como solicitante de servicios a un servidor siempre iniciara la conversación con el servidor. El cliente requiere los siguientes componentes para su funcionamiento: 

Hardware: El cliente requiere recursos de hardware, estos deberán estar estacionados en una computadora con suficiente poder de procesamiento. El cliente también requiere de espacio de disco duro y memoria física.



Sistema operativo: El cliente debe tener acceso a un sistema operativo que tenga capacidad multitarea para manejar las solicitudes realizadas. Así mismo debe ser posible que el sistema operativo pueda conectarse y comunicarse con otros sistemas operativos instalados en otras computadoras en un ambiente de red. Por consiguiente, la combinación de hardware y sistema operativo también deben permitir una conectividad adecuada con múltiples sistemas operativos de red (NOS) debido a que los servicios pueden estar localizados en redes diferentes. 30 de 243

๏ ท

Interfaz de usuario grรกfica: El cliente funciona por encima del sistema operativo y se conecta con el middleware de comunicaciones para acceder a los servicios disponibles en la red. Esto es posible por una interfaz de usuario que oculta al usuario la complejidad del componente. La (Figura Nยบ 5), ilustra los componentes bรกsicos del cliente. (Rob, 2004) Figura Nยบ 5:

Componentes de cliente Software

Aplicaciรณn Frontal Interfaz de software de red

Los componentes de la capa de comunicaciรณnes proporcionan acceso a la red y a los servicios

Sistema operativo

Hardware

Memoria (RAM) Disco duro

CPU Tarjeta de red Tarjeta de video

Cable de red

Fuente: [Rob, 2004]

El cliente debe estar situado en la entidad financiera, mediante el cual podrรก enviar las transacciones correspondientes a la instituciรณn que tendrรก un servidor.

2.2.4.2 Servidor El servidor proporciona servicios a procesos cliente. Es reactivo porque siempre espera las solicitudes del cliente. El servidor dispone de componentes de hardware y software los componentes de hardware incluyen una computadora, esta aloja el servidor y deberรก tener una capacidad mรกs alta de procesamiento que la que almacena el cliente, porque el servidor debe ser capaz de manejar solicitudes concurrente de varios clientes. En la (Figura Nยบ 6), se muestran los componentes del servidor.

31 de 243

El servidor no requiere Interfaz de usuario, este interactúa con el sistema operativo de red y constantemente espera las solicitudes del cliente. Una vez que recibe una solicitud el servidor la procesa localmente y luego de que la solicitud es atendida, la respuesta es enviada de regreso al cliente a través del middleware de comunicaciones. Figura Nº 6:

Componentes del servidor

Software

Servidor Frontal Interfaz de software de red

NOS

Sistema operativo

Los componentes de la capa de comunicaciónes proporcionan acceso a la red y las solicitudes y respuestas viajan a través de la red

Hardware

Memoria (RAM) Disco duro

CPU Tarjeta de red Tarjeta de video

Cable de red

Fuente: [Rob, 2004]

Para la implementación del enlace en línea, se requiere de dos servidores; servidor de base de datos que permita almacenar la información de las transacciones comerciales y un servidor de aplicaciones que tenga la lógica de la aplicación que es usada por el cliente. (Rob, 2004) 

Servidores

base

datos:

Proporciona

servicios

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). (Figura Nº 7) Los servidores de bases de datos son utilizados para manejar grandes y complejos volúmenes de datos, los cuales son compartidos con un conjunto de clientes. 32 de 243

Figura Nº 7:

Cliente/servidor con servidor de base de datos

Fuente: [Orfali, 2002]

En la intermediación financiera el servidor de base de datos es donde se almacena las transacciones correspondientes registradas mediante el cliente. Este servidor debe estar situado en la institución. 

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. De esta manera centraliza y disminuye la complejidad en el desarrollo de aplicaciones. Este servidor gestiona los servicios de la aplicación cliente (que está en la entidad financiera) y así mismo la parte funcional de la aplicación en general. La (Figura Nº 8) muestra un ejemplo de servidor de aplicaciones. Figura Nº 8:

Cliente/servidor con servidor de aplicaciones

Fuente: [Orfali, 2002]

33 de 243

La arquitectura cliente/servidor clásica está dividida en 2 capas, pero también existen de más capas que son utilizadas de acuerdo a los requerimientos que se tengan: 

Sistemas cliente/servidor de dos capas: La lógica de la aplicación está en el cliente o dentro de la base de datos en el servidor (o en los dos lugares).



Sistemas cliente/servidor de tres capas: La lógica de la aplicación (o del proceso) reside en la capa intermedia y está separada de la información y de la interfaz de usuario.

En la (Figura Nº 9) se puede diferenciar los sistemas cliente/servidor de dos y tres capas. Figura Nº 9:

Arquitecturas cliente/servidor: comparación entre de dos y tres capas DBMS, administradores de recursos heredados y de otros tipos

GUI y aplicaciones SQL, Archivos de E/S HTTP

Primera capa

Segunda capa

CLIENTE SERVIDOR DE DOS CAPAS DBMS, Administradores de recursos heredados y otros tipos

Servidor de aplicaciones RPC ORB MOM HTTP

Primera capa

Acceso a la información mediante SQL

Segunda capa

Tercera capa

CLIENTE SERVIDOR DE TRES CAPAS

Fuente: [Orfali, 2002]

En teoría los sistemas c/s de tres capas son escalables, robustos y flexibles. Además pueden integrar datos provenientes de varias fuentes; a la vez, es más fácil administrar y distribuir aplicaciones de tres capas en la red; casi todo el código se ejecuta en los servidores. Así mismo, las aplicaciones de tres capas reducen los intercambios de red al crear planos de servicio abstractos. (Orfali, 2002)

34 de 243

2.2.4.3 Canal de comunicación En el contexto de la intermediación financiera es 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 middleware13 de comunicaciones que proporciona los medios mediante los cuales los clientes y servidores se comunican para realizar funciones específicas. En la (Figura Nº 10), se puede ver un ejemplo de interacción entre los componentes del cliente y servidor Figura Nº 10: Interacción entre los componentes del cliente y servidor de BD Cliente envia solicitud SQL a traves de middleware SQL Cliente

Datos

Middleware envia solicitud SQL a servidor de BD Red de middleware de comunicaciónes

Servidor de BD recibe solicitud la valida y ejecuta. SQL

Servidor de base de datos Datos

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. (Rob, 2004) En la (Figura Nº 11) se puede visualizar el middleware en una infraestructura cliente/servidor.

Middleware: software de conectividad que ofrece un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas.

35 de 243

Figura Nº 11: Infraestructura del software cliente/servidor

Cliente

M ODBC FxRPC Correo

Navegador

GUI/ODU

ORB

Servidor

HTTP

DSM CMIP

SNMP

NOS DSM

e ar w e dl id

Directorio

Seguridad

RPC

Impresion

Tivoe/ORB Achiv os distribuidos Igual a igual

Objetos Web Groupware OLTP DBMS

Pila de transporte NetBios

TCP/IP

IPX/SPX

DSM

SNA

Fuente: [Orfali, 2002]

Los canales de comunicación ofrecen servicios de comunicación entre componentes (o entre aplicaciones). Estos canales dividen al middleware en: 

Canales generales



Canales de servicio específico

Canales generales: Brindan el sustrato para casi todas las interacciones entre cliente y servidor. Incluyen las pilas de comunicación, los directorios distribuidos, los servicios de autenticación, hora de red, llamadas a procedimientos remotos y los servicios de encolado. Esta categoría también comprende las extensiones del NOS, como los archivos distribuidos y los servicios de impresión.

En esta categoría

pertenecen los firewalls, servidores certificados (SSL, DCE, MS-RPC), los canales con nombre (TCP/IP, APPC, IPX/SPX). Canales de servicios específicos: Desempeñan un tipo de servicio cliente/servidor específico entre ellos se cuentan: 

Middleware específico para bases de datos como ODBC, JDBC, SQLJ, OLE DB, etc.



Middleware específico para OLTP14 como ATML, RPC, OTS, DTC.



Middleware específico para groupware como MAPI, SMTP, POP3, IMAP.



Middleware específico para objetos como CORBA/IIOP, COM+ y RMI.

OLTP (Online Transaction Procesing): Procesamiento de transacciones en línea.

36 de 243



Middleware específico para internet como HTTP, CCI, XML y SET. (Orfali, 2002)

El tipo de middleware que es requerido en el enlace en línea es principalmente el de base de datos, donde se almacenan las transacciones financieras. Los componentes de este middleware se pueden visualizar en la (Figura Nº 12) y estos son: 

Interface de programación de aplicaciones (API): El cual permite que el cliente sea independiente del servidor de base de datos. Tal independencia significa que el servidor puede ser cambiado sin que se tengan que volver a escribir en su totalidad las aplicaciones cliente.



Traductor de base de datos: Traduce las solicitudes SQL en la sintaxis del servidor de base de datos específica. La capa traductora de la base de datos acepta la solicitud SQL genérica y la proyecta en el protocolo SQL del servidor de base de datos.

 Traductor de red: Maneja los protocolos de comunicación de red entre los protocolos que se utilicen. Figura Nº 12: Componentes del middleware de base de datos

Cliente

API

Traductor de Traductor base de datos de red

Protocolo de red

Middleware de base de datos Fuente: [Rob, 2004]

Cada módulo maneja los detalles de cada protocolo de comunicaciones de red. La capa traductora de la red se encarga de utilizar el protocolo de red correcto para acceder a cada base de datos. Cuando los datos de la consulta son regresados, se presentan en un formato común a la aplicación cliente. La (Figura Nº 13) muestra la interacción entre el cliente y los componentes middleware de la base de datos.

37 de 243

Figura Nº 13: Interacción entre los componentes middleware cliente/servidor Cliente

La aplicación frontal hace interface con la aplicación middleware

Servidor de base de datos

Middleware

El programa hace solicitudes SQL genéricas que son trasladadas al servidor de BD por la capa middleware

Middleware

Protocolo de red

El middleware envía entonces las solicitudes SQL al servidor a traves de la red

Base de datos

Protocolo de red

Fuente: [Rob, 2004]

Los protocolos de red son un conjunto de reglas que determinan cómo se envían, interpretan y procesan los mensajes en las computadoras. Así mismo, permiten que las computadoras interactúen en una red. Respecto a los protocolos que el servidor puede utilizar, se pude mencionar a los siguientes: 

Protocolo de control de transmisión/Protocolo de internet (TCP/IP): Es el protocolo de comunicaciones soportado por la mayoría de los sistemas operativos. TCP/IP provee conectividad de extremo a extremo especificando cómo los datos deberían ser formateados, direccionados, transmitidos, enrutados y recibidos por el destinatario.



Intercambio de paquetes entre redes/Intercambio de paquetes en secuencia (IPX/SPX): Es un protocolo de datagramas rápido orientado a comunicaciones sin conexión que se encarga de transmitir datos a través de la red, incluyendo en cada paquete la dirección de destino.

Cuando se realiza la infraestructura de red, se debe tomar en cuenta que es necesario seleccionar una topología de red y seleccionar un protocolo, este afecta directamente el software que puede utilizarse. La mayoría de los servidores de base de datos utilizan TCP/IP como protocolo de red. (Rob, 2004)

38 de 243

2.2.5 Seguridad en la intermediación financiera Son mecanismos de seguridad que garantizan la protección y el envío seguro de datos desde el cliente hasta el servidor. Esto es efectuado mediante la aplicación de protocolos que aseguran la integridad de datos, la autenticación de identidad de clientes con el servidor y el control de tráfico de red para determinar quién puede acceder o la misma. Estos mecanismos están categorizados en: 

Protocolos de seguridad



Filtros de red (Orfali, 2002)

2.2.5.1 Protocolos de seguridad Aseguran canales seguros de comunicación y autenticación, estos pueden ser: 

SSL: Es una capa de conexiones seguras de sóckets asegurada. Es la norma para la autenticación y encriptación entre navegadores y servidores web. SSL también verifica que el contenido del mensaje no haya sufrido alteraciones. SSL implementa una versión de sóckets con seguridad mejorada que da protección a las transacciones en el nivel de transporte. SSL brinda un enlace seguro de comunicación que comprende las aplicaciones que lo llaman; 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. Este protocolo permite al cliente y al servidor autenticarse entre sí y negociar el algoritmo de cifrado (encriptación). 39 de 243

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

SSL y S-HTTP pueden coexistir sin problemas de un modo muy complementario. (Figura Nº 14). En consecuencia, es posible obtener mucha mejor seguridad de la que brindaría cualquier enfoque por sí solo. Figura Nº 14: S-HTTP sobre SSL Navegador

Mensajes de HTTP

Sello de S-HTTP

Web segura Puerto 443

Servidor

Fuente: [Orfali, 2002]

40 de 243

En resumen S-HTTP da muchos servicios de seguridad como encriptación, autenticación, integridad de mensajes y no rechazo. (Orfali, 2002)

2.2.5.2 Filtros de red Firewall: Un firewall es una parte de un sistema de red que cuida las puertas que separan Internet de una red privada. Sirve para proteger la red privada 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 (Figura Nº 15). Figura Nº 15: Firewalls: La patrulla fronteriza de la red.

Fuente: [Orfali, 2002]

Los firewalls ofrecen un solo punto de entrada en el que es posible imponer controles de acceso, además de monitorear el tránsito de la red. Así mismo controlan las comunicaciones mediante políticas de seguridad, permitiendo o prohibiendo las mismas (Orfali, 2002) Cuando se efectúa la intermediación financiera, la institución educativa conforma parte de una red con la entidad financiera (para el envío de transacciones), por lo que el firewall controla la comunicación entre ambas partes.

2.2.5.3 Normativas de seguridad Actualmente existe el estándar NB-ISO/IEC 17799 de gestión de seguridad de la información, el cual indica todos los aspectos de seguridad que se deben considerar en las instituciones de acuerdo a secciones específicas. La sección que corresponde 41 de 243

a la intermediación financiera es la de transacciones en línea y se puede ver en (Anexo B: Sección 10.9.2 del estándar NB-ISO/IEC 17799: Gestión de seguridad de la información). Así mismo este estándar menciona que las transacciones en línea pueden necesitar cumplir leyes, reglas y regulaciones, por lo que la Autoridad de Supervisión del Sistema Financiero (ASFI) mediante la circular SB/433/2003 indica los requisitos técnicos y de seguridad que la entidad financiera debe cumplir cuando emplea sistemas informáticos en sus instalación y la circular SB/466/2004 la cual indica los requisitos de seguridad informática a proveedores de tecnologías de información (que en este caso corresponde al instituto). La información a detalle se puede ver en (Anexo A: Circular SB/466/2004: Requisitos mínimos de seguridad informática).

2.3 SISTEMAS DE FACTURACIÓN Los sistemas de facturación, conforman parte de los sistemas de información, estos permiten la emisión impresa de facturas y facilitan la administración tributaria. El objetivo de los sistemas de facturación es permitir que las empresas que los utilizan puedan reducir sus costes operativos, por las funcionalidades que los sistemas ofrecen, tal como eliminación de las facturas en papel, automatización de envío de facturas y establecimiento de aplicaciones a las que se puede conectar los proveedores y las empresas asociadas. Los sistemas de facturación permiten la emisión de facturas de manera impresa ó de forma digital, de acuerdo a las normativas dispuestas por la ley, esta facturación es efectuada mediante sistemas informáticos, se explica con más detalle en el siguiente apartado. (Benet, 2003)

2.3.1 Facturación La facturación o emisión de la factura es el acto a través del cual el sujeto pasivo o tercero responsable extiende la factura, nota fiscal o documento equivalente 15 al comprador, cumpliendo con las formalidades establecidas por la Administración Tributaria, al haberse perfeccionado el hecho generador del IVA16 15

Documento equivalente: Documento, que si bien no se constituye en una factura o nota fiscal propiamente dicha, su emisión implica la realización de una operación gravada por el IVA (Ej. Boletos aéreos) 16 IVA: Impuesto al valor agregado

42 de 243

Esta factura, es el documento autorizado por la Administración tributaria, cuya emisión acredita la realización de la venta de bienes, contratos de obras o la prestación de servicios u otras prestaciones gravadas por el IVA. Para que una institución pueda facturar es necesaria la autorización de una entidad reguladora, esta entidad es denominada: Administración Tributaria, que también se le conoce como Servicio de Impuestos Nacionales (SIN). La resolución normativa de directorio Nº 10-0016-07 de 18 de mayo de 2007 de acuerdo al artículo 13 de la ley Nº 843 (Ley de reforma tributaria) faculta a la Administración tributaria normar y reglamentar la forma de emisión de facturas, notas fiscales o documentos equivalentes, además de los registros que deben llevar los sujetos pasivos o terceros responsables del impuesto. De acuerdo a esta normativa, existen dos pasos para que los sujetos pasivos puedan realizar la facturación: 

Dosificación: Es el procedimiento mediante el cual el sujeto pasivo o tercero responsable, solicita al SIN la habilitación de facturas, para su posterior activación y emisión. La dosificación puede ser por tiempo (aplicada a facturación computarizada) o por cantidad (aplicada a facturación manual y máquina registradora).



Activación: Es el procedimiento a través del cual la Administración Tributaria autoriza la emisión de las facturas que fueron previamente dosificadas.

Posteriormente el sujeto pasivo puede realizar la facturación para acreditar la realización de la venta de bienes o la prestación de servicios, a este proceso se denomina Emisión de factura; Es el acto a través del cual es sujeto pasivo o tercero responsable extiende la factura, nota fiscal o documento equivalente al comprador, cumpliendo con las formalidades establecidas por la Administración Tributaria. Una vez emitida la factura el original del documento debe ser entregado al comprador por el sujeto pasivo o tercero responsable. Así mismo el sujeto pasivo en función a la modalidad de facturación que opta, debe realizar las copias respectivas de la factura, esto será descrito en el siguiente apartado,

43 de 243

El término de sujeto pasivo se refiere a estas personas: 

En forma habitual se dediquen a la venta de bienes muebles;



Realicen obras o presten servicios o efectúen prestaciones de cualquier naturaleza



Realicen operaciones de arrendamiento financiero con bienes muebles.

El sujeto pasivo efectúa el proceso de facturación a través de un Autoimpresor; este un medio mediante el cual se emiten las facturas o notas fiscales, previo registro y autorización ante el SIN y comprende a las máquinas registradoras, puntos de venta Da Vinci o Sistemas de facturación computarizados. Es importante mencionar que la factura tiene una fecha límite de emisión, que es el plazo máximo otorgado por el SIN. (RND Nº 10-0016-07, 2007)

2.3.2 Modalidades de facturación De acuerdo a normativas del SIN, existen las siguientes modalidades de facturación:

2.3.2.1 Facturación electrónica En esta modalidad los sistemas informáticos de los sujetos pasivos o terceros responsables, deberán interactuar directamente con los Sistemas informáticos del SIN, a efectos de solicitar la generación de facturas o notas fiscales por las transacciones comerciales que se realicen por medios electrónicos, individualizadas con un código de control generado y asignado por la Administración tributaria. Esta modalidad de facturación está orientada para aquellos sujetos pasivos o terceros responsables que efectúen transacciones comerciales electrónicas. En esta modalidad no es necesaria la impresión de copias físicas (salvo requerimiento del sujeto pasivo), pero si una copia magnética a momento de realizarse la transacción comercial.

44 de 243

2.3.2.2 Facturación en línea Esta modalidad de facturación se realizara a partir del portal tributario del SIN, permitiendo la emisión de facturas en línea (via internet), individualizadas con un código de control generado y asignado por la Administración Tributaria. Esta modalidad está orientada a aquellos sujetos pasivos o terceros responsables de baja cantidad de facturas emitidas. En esta modalidad la facturación no requiere la impresión de copias físicas de respaldo (salvo requerimiento del sujeto pasivo) pero sí copias magnéticas para fines contables internos, a partir del portal tributario de la administración tributaria.

2.3.2.3 Facturación computarizada Esta modalidad de facturación se realizara a partir del sistema informático desarrollado o adquirido por el propio sujeto pasivo o tercero responsable permitiendo la emisión de facturas o notas fiscales individualizadas con un código de control generado a partir de determinados datos de la transacción comercial, datos de la dosificación y la llave (dato alfanumérico) entregada a tiempo de recabar la dosificación correspondiente. Estos sistemas deben adecuarse, agregando un módulo informático denominado Generador de códigos de control, el mismo que será desarrollado por cuenta del propio sujeto pasivo o tercero responsable, en base a las especificaciones técnicas que estarán disponibles en la página Web o en las dependencias operativas del SIN. Una vez adecuado el sistema, se deberá registrarlo como Autoimpresor ante el SIN. Esta modalidad está orientada a todo tipo de actividades sin restricción alguna. Las facturas o notas fiscales de esta modalidad pueden prescindir de las copias físicas de respaldo, en la medida que los sujetos pasivos o terceros responsables generen copias magnéticas, que sean registradas y archivadas en medios electrónicos asegurando el cumplimiento de las siguientes condiciones: permitir la identificación del emisor, garantizar la integridad, completitud y consistencia de la información y datos en ellos contenidos. Caso contrario los sujetos pasivos responsables deberán generar copias físicas. (RND Nº 10-0016-07, 2007)

45 de 243

2.3.3 Aspectos técnicos de la factura La factura debe seguir un formato normado por la administración tributaria, el cuál se menciona a continuación (esta especificación es para la modalidad de facturación computarizada): Formato de la factura 1. Datos básicos del sujeto pasivo (parte superior izquierda): 

Razón social en el caso de personas jurídicas o nombre en el caso de personas naturales.



Domicilio tributario (casa matriz), número(s) telefónico(s) y la alcaldía a la que pertenece.



Número de sucursal, domicilio, número(s) telefónico(s) y la alcaldía a la que pertenece (excepto en espectáculos públicos eventuales); sólo en el caso que la nota fiscal sea emitida en una sucursal.



Tipo de autoimpresor y número del autoimpresor asignado por el SIN, para las facturas o notas fiscales de las modalidades de facturación computarizada.

2. Datos de dosificación (parte superior derecha) 

Número de identificación tributaria (NIT) del sujeto pasivo.



Número de correlativo de factura, nota fiscal o documento equivalente.



Número de autorización



El término “ORIGINAL” O “COPIA”, según corresponda.

3. Título y subtítulos (parte superior central) 

“FACTURA”

“FACTURA

POR

TERCEROS”

“FACTURA

CONJUNTA”, según corresponda. 4. Datos de la transacción comercial (parte central) 

Lugar y fecha de emisión, en el siguiente orden: LUGAR, DIA, MES AÑO.



Nombre o razón social del comprador.



Número de identificación tributaria o número de documento de identificación del comprador.



Detalle: cantidad, concepto, precio unitario y total. 46 de 243



Tipo de cambio oficial de venta correspondiente a la fecha de la transacción, cuando la operación sea en moneda extranjera.



Total en general en Bolivianos (numeral y literal)

5. Datos finales (parte inferior) 

Código de control, cuando corresponda (izquierda)



Fecha límite de emisión (a la derecha y en negrillas)



En negrillas y legible la leyenda: “ La reproducción total o parcial y/o el uso no autorizado de esta Nota Fiscal, constituye un delito a ser sancionado conforme a la Ley” (Central)

Tamaño de la factura: Las facturas o notas fiscales del sistema de facturación, tanto originales como copias, deben aplicar los límites mínimos y máximos según la especificación: General: Mínimo (1/4 oficio) y máximo (Oficio) Colores y materiales: Las facturas o notas fiscales deberán contener información personalizada del sujeto pasivo, es decir el Logo (si corresponde, pudiendo mantener sus colores originales) y Nombre o razón social del sujeto pasivo, el cualquier color distinto de negro, el resto de la información puede ser impresa en cualquier color. Como regla general, los materiales y colores utilizados para la elaboración de los originales y copias físicas de las facturas o notas fiscales, deben permitir preimprimir, imprimir o consignar de forma nítida, legible, precisa y permanente, la información establecida al efecto. Código de control: Es un dato alfanumérico que debe ser generado por el sistema de facturación computarizado a tiempo de emitir una nota fiscal. El Código de Control tiene el objetivo de individualizar cada nota fiscal emitida y se construye con los siguientes datos: 

Número de autorización.



Número de factura o nota fiscal.



NIT o número de documento de identificación del comprador.



Fecha de transacción



Monto de la transacción (Monto efectivamente debitado en el IVA menos tasas, otros impuestos y demás conceptos no gravados) En caso que el monto

47 de 243

de la transacción contenga decimales, se deberá realizar el redondeo sin decimales. (RND Nº 10-0016-07, 2007) La generación del código de control es realizado mediante el uso de algoritmos de criptografía, los cuales pueden ser: 

Algoritmo Alleged RC4: Algoritmo de criptografía simétrica, basado en cifrado de flujo (stream cipher). (ver Anexo I: Generación del código de control).



Algoritmo Verhoeff: Algoritmo de dígito verificador que trabaja con cadenas de dígitos decimales de cualquier tamaño. Además de detectar una amplia gama de errores en datos numéricos, este algoritmo también detecta casos de transposición de dígitos adyacentes. Para más detalle (ver Anexo I: Generación del código de control).



Algoritmo de Base 64: Algoritmo que convierte cifras en base 10 a base 64, utilizando divisiones sucesivas además de un diccionario de 64 caracteres. (ver Anexo I: Generación del código de control). (RND Nº 10-0016-07, 2007)

2.4 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. En esta definición, existen dos frases clave: 1. Disciplina de la ingeniería: Los ingenieros aplican teorías, métodos y herramientas donde sean convenientes, pero las utilizan de forma selectiva y siempre tratando de descubrir las soluciones a los problemas, aún 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 de software comprende los procesos técnicos del desarrollo de software y también con 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. 48 de 243

La ingeniería de software tiene como objetivo construir una solución de software eficiente que satisfaga las necesidades requeridas por un cliente, mediante la aplicación de: 

Proveer los estándares y los modelos que faciliten la comunicación, tanto para clientes como para especialistas en la elaboración de un proyecto de software.



Proveer los métodos, herramientas y procedimientos para la “construcción” eficiente del software.



Proveer parámetros y criterios de evaluación de la calidad del software.

La ingeniería de software cuenta con modelos de desarrollo de software los cuales muestran una estructura que indica los pasos a seguir dentro de un ciclo de vida. Así mismo existen metodologías de desarrollo de software que definen patrones aplicados a las etapas del ciclo de vida. (Rob, 2004)

2.4.1 Modelos de desarrollo de software Los modelos indican un ciclo de vida que indica los pasos a seguir en la construcción de software. De acuerdo a las características iterativas de estos modelos, se mencionarán los siguientes: 

Modelo incremental



Modelo espiral



Modelo DRA

2.4.1.1 Modelo Incremental El modelo incremental es aplicado en forma iterativa donde en cada iteración tiene una serie de fases secuenciales. Como se muestra en la (Figura Nº 16), Las fases son aplicadas de manera escalonada. Cada secuencia lineal produce “incrementos” del software.

49 de 243

Figura Nº 16: El modelo incremental

Comunicación Planeación

FUNCIONALIDAD

Modelado

n. Incremento

Construcción Despliegue

Configuraciónes 2do. Incremento

Funciones más complejas 1er. Incremento

Funciones básicas, es un producto escencial TIEMPO

Fuente: [Pressman, 2004]

El primer incremento da resultado a un producto esencial. Es decir, se incorporan los requisitos básicos. El producto esencial queda en manos del cliente (o se somete a una evaluación detallada). Como resultado de la evaluación se desarrolla un plan para el incremento siguiente. El plan afronta la modificación del producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la entrega de características y funcionalidades adicionales. Este proceso se repite después de la entrega de cada incremento mientras no se haya elaborado el producto completo. El desarrollo incremental es útil sobre todo cuando el personal necesario para una implementación completa no está disponible. Si el producto esencial es bien recibido se agrega (si se requiera) más personal para implementar el incremento siguiente. Además los incrementos se pueden planear para manejar los riesgos técnicos. (Pressman, 2004)

50 de 243

2.4.1.2 Modelo espiral Es un modelo de desarrollo de software evolutivo que conjuga la naturaleza iterativa y la construcción secuencial. Proporciona el material para el desarrollo rápido de versiones incrementales del software. El software se desarrolla en una serie de entregas evolutivas (lo que le diferencia del modelo iterativo). Durante las primeras iteraciones, la entrega puede ser un documento del modelo o un prototipo. Durante las últimas iteraciones se producen versiones cada vez más complejas del sistema desarrollado. Un proceso en espiral se divide en un conjunto de actividades del marco de trabajo que define el equipo de desarrollo. En la (Figura Nº 17) cada una de las actividades del marco de trabajo representa un segmento de la ruta en espiral. Figura Nº 17: Modelo en espiral típico

Fuente: [Pressman, 2004]

El modelo espiral tiene una dirección en el sentido del movimiento de las manecillas del reloj y se inicia desde el centro, para lo cual el equipo de software realiza actividades en un circuito alrededor de la espiral. Los puntos de fijación (combinación de productos de trabajo y condiciones incluidas a lo largo de la ruta de la espiral) se consideran para cada paso evolutivo. 51 de 243

El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software, Por lo tanto, el primer circuito alrededor de la espiral podría representar un “proyecto de desarrollo del concepto”, el cual se inicia en el centro de la espiral y continua por múltiples iteraciones hasta que el desarrollo del concepto este completo. El modelo en espiral es un enfoque realista para el desarrollo de software y de sistemas a gran escala. Como el software evoluciona conforme avanza el proceso, el desarrollador y el cliente entienden y reaccionan de mejor manera ante los riesgos en cada etapa evolutiva. (Pressman, 2004)

2.4.1.3 Modelo DRA El modelo rápido de aplicaciones (DRA) es un modelo incremental que resalta el ciclo de desarrollo corto. Es una adaptación de “alta velocidad” del modelo en cascada y está basado en componentes. Usualmente el periodo promedio de desarrollo es corto (60 a 90 días). El modelo DRA cumple las actividades genéricas de un modelo incremental. La comunicación trabaja para entender el problema de negocios y las características de información que se incluye en el software. En la planeación los equipos de software trabajan en paralelo sobre diferentes funciones del sistema. El modelado incluye tres grandes fases: Modelado de negocios, modelado de datos y modelado de proceso. Estos establecen representaciones del diseño utilizados como base para la construcción y el despliegue, el cuál establece una base de iteraciones necesarias para completar el sistema. El modelo DRA se puede visualizar en la (Figura Nº 18). Las restricciones de tiempo impuestas exigen un ámbito de escalas. SI la aplicación se puede modular de forma que cada función pueda completarse en menos de tres meses, ésta es una candidata para DRA. (Pressman, 2004)

52 de 243

Figura Nº 18: Modelo DRA Equipo # n Modelado modelado de negocio modelado de datos modelado del proceso Construcción reutilización de componentes generacion de código automatico pruebas

Equipo # 2 Modelado modelado de negocio modelado de datos modelado del proceso

Comunicación

Planeación

Construcción reutilización de componentes generacion de código automatico pruebas

Equipo # 1 Modelado modelado de negocio modelado de datos modelado del proceso

Despliegue integración entrega retroalimentación

Construcción reutilización de componentes generacion de código automatico pruebas

60 - 90 Días

Fuente: [Pressman, 2004]

2.4.2 Metodologías de desarrollo de software Las metodologías de desarrollo de software definen patrones aplicados a las etapas del modelo de desarrollo de software elegido, las metodologías aplicadas a los modelos descritos anteriormente, pueden ser las siguientes: 

Proceso unificado (UP)



Programación Extrema (XP)



Scrum (Sommerville, 2005)

2.4.2.1 Proceso unificado El PU es un proceso de software que implementa muchos de los mejores principios del desarrollo ágil de software. Así mismo reconoce la importancia de la comunicación con el cliente y los métodos encaminados a describir el punto de vista del cliente con respecto a un sistema (por ejemplo, el caso de uso17).

Caso de uso: Contexto narrativo o plantilla que describe una característica o función del sistema desde el punto de vista del usuario. El caso de uso lo escribe el usuario y sirve como base para la creación de un modelo de análisis más completo.

53 de 243

El PU enfatiza el importante papel de la arquitectura de software, el entendimiento, el ajuste a los cambios futuros y la reutilización. Sugiere un flujo de proceso iterativo e incremental y que proporciona el sentido evolutivo esencial en el desarrollo de software moderno. Ciclo de vida del proceso unificado: El ciclo de vida en el PU define las fases en el desarrollo del sistema. Cada ciclo concluye con una versión del producto. Como se muestra en la (Figura Nº 19). Figura Nº 19: Ciclo de vida del proceso unificado.

Fuente: [Jacobson, 2000]

Cada ciclo consta de cuatro fases: inicio, elaboración, construcción y transición (que serán descritas más adelante). Cada fase se subdivide a su vez en iteraciones, la (Figura Nº 20) ilustras de forma más clara las iteraciones de cada fase. Cada ciclo produce una nueva versión del sistema y cada versión, es un producto preparado para su entrega.

54 de 243

Figura Nº 20: Ciclo con fases e iteraciones del proceso unificado.

Fuente: [Jacobson, 2000]

Es probable que mientras se realizan las fases de construcción, transición y producción ya se hayan iniciado los trabajos para el siguiente incremento del software. Esto significa que las cinco fases del PU no suceden en una secuencia, sino en una concurrencia por etapas. Fases del proceso unificado: PU posee cinco actividades genéricas del marco de trabajo y se aplican para describir cualquier modelo de proceso del software. En la (Figura Nº 21) se muestran las fases del proceso unificado. Figura Nº 21: El proceso unificado

Fuente: [Pressman, 2004]

55 de 243



Inicio: Fase inicial que abarca la comunicación con el cliente y las actividades de planeación. Al colaborar con los clientes y usuarios finales se identifican los requisitos de negocios para el software, se propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza iterativa e incremental del sistema subsiguiente. Los requisitos fundamentales de negocios se describen a través de casos de uso que describen cuáles características y funciones son deseables para cada clase importante de usuarios. La arquitectura es un esquema tentativo de los subsistemas más importantes y de las funciones y características que los forman. Después la arquitectura se refinará y expandirá en un conjunto de modelos que representarán visiones diferentes del sistema.



Elaboración: Esta fase abarca la comunicación con el cliente y las actividades de modelado del modelo genérico del proceso. La elaboración refina y expande los casos de uso preliminares que se desarrollaron como una parte de la fase de inicio; además, expande la representación arquitectónica para incluir cinco visiones diferentes del software: el modelo de casos de uso, el modelo de análisis, el modelo de diseño, el modelo de implementación y el modelo de despliegue. La arquitectura demuestra la viabilidad de la arquitectura, pero no proporciona todas las características y funciones necesarias para utilizar el sistema. Además, el plan se revisa de manera cuidadosa al término de la fase de elaboración para asegurar que el ámbito, los riesgos y los datos entregados aún son razonables.



Construcción: Si se utiliza el modelo arquitectónico como entrada, la fase de construcción desarrolla o adquiere los componentes del software que harán que cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere que los modelos de análisis y diseño iniciados durante la fase de elaboración se complementen para reflejar la versión final del incremento del software.



Transición: Abarca las últimas etapas de la actividad genérica de construcción y la primera parte de la actividad genérica de despliegue. El

56 de 243

software se entrega a los usuarios finales para realizar pruebas beta y la retroalimentación del usuario reporta tanto defectos como cambios necesarios. Además, el equipo de software crea la información de soporte necesaria (manuales de usuario, guías de resolución de problemas, procedimientos de instalación) para el lanzamiento. Al final de la fase de transición, el incremento de software se convierte en un lanzamiento de software utilizable. (Rumbaugh, Jacobson y Booch, 2000). PU posee aspectos que definen el proceso unificado en tres aspectos clave: Dirigido por casos de uso, centrado en la arquitectura e iterativo e incremental. Características del PU: UP tiene las siguientes características: 

El proceso unificado está dirigido por casos de uso: Quiere decir que el proceso de desarrollo sigue un hilo y avanza a través de una serie de flujos de trabajo que parten de los casos de uso. Los casos de uso se especifican, se diseñan y los casos de uso finales son la fuente a partir de la cual los ingenieros de prueba construyen sus casos de prueba. Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los requisitos funcionales y guían el diseño, implementación y prueba.



El proceso unificado está 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 del sistema, plataforma en la que tiene que funcionar el software, arquitectura hardware, sistema operativo, sistema de gestión de base de datos, protocolos para comunicarse en red, los bloques de construcción

reutilizables

que

disponen

consideraciones

implantación, sistemas heredados y requisitos no funcionales. Debe haber interacción entre los casos de uso y la arquitectura. En realidad, tanto la arquitectura, como los casos de uso deben evolucionar en paralelo. La arquitectura es la que se diseña para permitir que el sistema evolucione, no solo en su desarrollo inicial, sino también a lo largo de las futuras generaciones.

57 de 243



El proceso unificado es iterativo e incremental: El desarrollo de software se divide en partes más pequeñas, cada parte es una iteración que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo y los incrementos, al crecimiento del producto. En cada iteración los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, implementan

diseño

mediante

componentes

verifican

que

los

componentes satisfaces los casos de uso. La iteración trata un grupo de casos de uso que juntos amplían la utilidad del producto desarrollado hasta ahora y también trata los riesgos más importantes. Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron a través del trabajo de desarrollo subsiguiente (análisis, diseño, implementación y prueba) que termina convirtiendo en código ejecutable los casos de uso que se desarrollaron en la iteración. 

Proceso integrado: El proceso unificado está basado en componentes. Utiliza el estándar de modelado visual; el Lenguaje Unificado de Modelado (UML), y se sostiene sobre los tres aspectos básicos ya mencionadas.( (Rumbaugh et al., 2000)

Cuando el objetivo está más claro, los requisitos pueden cambiar, los desarrolladores al final afrontan un nuevo ciclo, así que para llevar a cabo el siguiente ciclo de manera eficiente, los desarrolladores necesitan todas las representaciones del producto software, esto se refleja en la (Figura Nº 22)

58 de 243

Figura Nº 22: Modelo del proceso unificado.

Fuente: [Jacobson, 2000]



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

correspondencia

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.



Finalmente la representación de la arquitectura. 59 de 243

Todos estos modelos están relacionados, juntos representan al sistema como un todo. Los elementos de un modelo poseen dependencias hacia atrás y hacia delante, mediante enlaces hacia otros modelos. Flujo de trabajo dentro del ciclo de vida: Se mencionó que el ciclo de vida posee cuatro fases. A su vez dentro de cada fase se puede descomponer el trabajo en iteraciones con sus incrementos resultantes, donde cada fase termina con un hito. La (Figura Nº 23) 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. (Rumbaugh et al., 2000) Figura Nº 23: Los cinco flujos de trabajo.

Fuente: [Jacobson, 2000]

2.4.2.2 Programación extrema (XP) Extreme programing ó programación extrema, es una metodología ágil de desarrollo de software, utiliza un enfoque orientado a objetos. XP abarca un conjunto de reglas y prácticas que ocurren en el contexto de cuatro actividades en el marco de trabajo, estas son: planeación, diseño, codificación y pruebas.

60 de 243

La programación extrema se basa en valores, principios: 

Valores: -

Comunicación: Para la resolución rápida de problemas y fortalecimiento del equipo a través de la interacción mutua.

Simplicidad: Desarrollo debe ser lo más simple debido al factor tiempo.

Retroalimentación: Resultado de las pruebas funcionales de las historias de usuario realizadas por el cliente.

Audacia: Nivel de confianza que debe existir entre los miembros del equipo de desarrolla para responder a los problemas que surjan de la mejor manera posible y lograr los objetivos.



Principios: -

Proporcionar retroalimentación rápida: Retroalimentación debe darse en un intervalo de tiempo razonablemente corto.

Adoptar la sencillez: Se basa en la premisa de que al menos el 90% de los problemas se puedan resolver con absoluta sencillez.

Cambiar progresivamente: Se requiere cambios constantes que resulten en una diferencia del esfuerzo de desarrollo.

Aceptar el cambio: Se debe mantener abiertas todas las opciones de resolver un obstáculo en el desarrollo.

Alentar el trabajo de calidad: Todos los miembros del equipo deben hacer un trabajo eficiente. (Benet, 2003)

XP posee un proceso que se adopta durante el desarrollo de software, este se visualizar en la (Figura Nº 24).

61 de 243

Figura Nº 24: El proceso de la programación extrema

Fuente: [Pressman, 2004]

Fases del proceso de XP: Son cuatro y están descritas a continuación: 

Planeación: Esta actividad comienza creando una serie de historias de usuario, que describen las características y la funcionalidad requeridas para el software que se construirá. El cliente le asigna un valor o prioridad a la historia basándose en valores generales del negocio respecto a la función. Los miembros del equipo XP evalúan cada historia y le asignan un costo (semanas de desarrollo). Los clientes y el equipo trabajan juntos para decidir cómo agrupar las historias hacia el próximo incremento. Conforme avanza el trabajo de desarrollo el cliente puede agregar historias, cambiar el valor de la historia existente, dividir historias o eliminarlas entonces el equipo modifica sus planes de acuerdo a tales historias.



Diseño: El diseño en XP es simple, ofrece una guía de implementación para una historia de usuario. El diseño se considera como un artefacto que puede y debe modificarse de manera continua a medida que prosigue la construcción.

62 de 243



Codificación: Después de realizar las historias y realizar el diseño, el equipo aún no se mueve hacia la codificación, sino se realiza antes pruebas de unidad que ejercitan las historias que se incluirán en el incremento. Una vez realizada la prueba de unidad, se realiza la codificación y esa unidad se prueba inmediatamente para proporcionar una retroalimentación en el desarrollo. Una actividad clave que se adopta es la programación en pareja, donde dos personas trabajan juntas en una estación de trabajo para crear el código de la historia, esta actividad tiene como objetivo el asesoramiento de la calidad y resolución de problemas en tiempo real. Cuando los programadores completan su trabajo el código que desarrollaron se integra con el trabajo de otros



Pruebas: Es un elemento clave en XP, las pruebas de unidad que se crean deben implementarse de manera que se puedan automatizarlas (ejecución fácil y repetida). Cuando las unidades individuales de prueba se organizan en un conjunto, las pruebas de integración y validación pueden realizarse a diario. Existen también pruebas de aceptación o pruebas del cliente, estas son especificadas por el cliente y se enfocan en las características generales y la funcionalidad del sistema, elementos visibles y revisables por el cliente. Están son derivadas de las historias de usuario implementadas. (Benet, 2003)

Características de XP: XP tiene las siguientes características: 

Planificación incremental: Los requerimientos se registran en historias de usuario, que son divididas luego en tareas de desarrollo.



Entregas

pequeñas:

Las

entregas

del

sistema

son

frecuentes

incrementalmente añaden funcionalidad a la primera entrega. 

Diseño sencillo: Solo se lleva a cabo el diseño necesario para cumplir los requerimientos actuales.



Desarrollo previamente probado: Se utiliza pruebas de unidad para escribir pruebas para nuevas funcionalidades antes de que éstas se implementen.



Refactorización: Refactorización de código en el proceso de desarrollo.



Programación en parejas: Los desarrolladores trabajan en parejas, verificando uno el trabajo del otro, para realizar un buen trabajo. 63 de 243



Integración continua: Cuando se acaba el trabajo en una tarea, se integra en el sistema entero. Después de la integración, se deben pasar al sistema todas las pruebas de unidad.



Cliente presente: Debe estar disponible al equipo de XP, un representante de los usuarios finales del sistema a tiempo completo. En un proceso de la programación extrema, el cliente es miembro del equipo de desarrollo y responsable de formular al equipo los requerimientos del sistema para su implementación.

2.4.2.3 Scrum Es una metodología ágil de desarrollo, se caracteriza por su simplicidad, requerimiento de trabajo duro, porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto. Scrum se compone de una serie de iteraciones las cuales se denominan Sprint, las cuales tienen por objetivo obtener entregables al finalizar cada iteración. En la (Figura Nº 25) se puede visualizar el proceso Scrum. Figura Nº 25: El proceso de desarrollo de software en Scrum

Fuente: [Chalco, 2013]

64 de 243

Características de Scrum: Scrum posee las siguientes características: 

A los individuos (respeto, responsabilidad, coraje) por encima de los procesos y herramientas.



Al software que funciona, por encima de la documentación exhaustiva.



A la colaboración con el cliente, por encima de la negociación contractual.



A la respuesta al cambio, por encima del seguimiento de un plan.



La transparencia y visibilidad del proyecto

Dentro de cada iteración o Sprint, existen tres elementos importantes (actores, actividades y productos) los cuales son descritos a continuación: 

Actores: Son participantes del Sprint, de los cuales existen los siguientes: -

Product owner (Propietario del producto): Dueño del proyecto, define requerimientos y prioridades.

Scrum master: Encargado de realizar el seguimiento del proyecto en base a las actividades que proporciona scrum



Team member: Miembro del equipo de desarrollo

Stakeholder: Persona que participa en el desarrollo del producto

Scrum project manager: Líder de los equipos SCRUM.

Actividades: Durante el desarrollo de un Sprint, se definen una serie de actividades que dan resultado a un entregable, estas actividades son las siguientes: -

Reunión de planificación de Sprint: Es una reunión en la cual se define requerimientos, entregables y sus respectivas priorizaciones.

Reunión diaria: Esta tiene por objetivo relacionar y sincronizar los procesos de desarrollo a cada Team Member.

Revisión de pares: Actividades que tiene por objetivo hacer una revisión rápida de métricas y estándares.

Revisión de Sprint: Presentación de entregables terminados por equipos SCRUM ó el Team member, tiene por objetivo realizar una revisión deacuerdo a la funcionalidad del producto.



Productos: Cada Sprint al concretarse da como resultado un entregable que genera dos documentos: 65 de 243

Retrospectiva de sprint: Es el documento que indica el estado del Sprint finalizado; tiene por objetivo verificar que cumple con su función y si se puede mejorar.

Sprint burndown: Indicador de avance que permite evaluar los recursos asignados a las etapas determinadas dentro del Sprint

Finalmente se tienen a los componentes de Scrum: 

Pila del producto: Es una relación de requisitos no detallados excesivamente y que tienen prioridad.



Pila de Sprint: Son los requisitos comprometidos por el equipo para concretar el Sprint y son suficientemente detallados para su ejecución.



Incremento: Iteración realizada que es una parte del software en general desarrollada en un Sprint y está en condiciones de ser usada (pruebas, documentación).

Ciclo de trabajo: Scrum a diferencia de otras metodologías posee un ciclo de trabajo que especifica las tareas a realizar para construir el software, para un mejor entendimiento se puede dividir en cuatro partes: 

Obtención de requisitos al cliente: Para cada requisito principal se crea un bloque de trabajo, llamado historia de usuario.



Priorización de historias de usuario: El cliente ordena las historias de trabajo en una pila de producto (producto backlog) según su prioridad de entrega.



Codificación: El equipo de trabajo toma un grupo de historias, con el que trabajan durante una iteración o sprint (entre 15 y 30 días).



Pruebas: Una vez finalizado un sprint entregan al cliente el resultado del trabajo. Se vuelve a la priorización de historias de usuario, hasta terminar la pila de producto.

Finalmente se puede concluir que SCRUM es de carácter adaptable más que predictivo y está orientado a las personas más que a los procesos. (Benet, 2003)

66 de 243

2.4.3 Lenguajes de modelado de software El modelado de software permite entender la complejidad del software de manera visual. Además estos pueden ser utilizados como instrumento para la comunicación con el cliente. Para expresar los modelos existen lenguajes de modelado de software como UML, este será descrito a continuación.

2.4.3.1 UML El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual que se usa para especificar, visualizar, 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á pensado para usarse con todos los métodos de desarrollo, etapas del ciclo de vida, dominios de aplicación y medios. UML como lenguaje ayuda a interpretar grandes sistemas mediante una representación gráfica, obteniendo modelos explícitos que ayudan a la comunicación durante el desarrollo, los modelos pueden ser interpretados por personas que no participaron en su diseño (e incluso por herramientas) sin ninguna ambigüedad. El lenguaje Unificado de modelado tiene varios propósitos: 

Captar y enumerar exhaustivamente los requisitos y el dominio de conocimiento: Los diversos modelos de un sistema de software pueden capturar requisitos sobre su dominio de aplicación, las formas en que los usuarios lo utilizaran, su división en módulos, los patrones comunes usados en su construcción y otras cosas.



Pensar del diseño de un sistema: Un modelo de un sistema software ayuda a los desarrolladores a explorar varias arquitecturas y soluciones de diseño fácilmente, antes de escribir el código. Un buen lenguaje de modelado permite que el diseñador consiga la arquitectura correcta antes de que comience el diseño detallado.



Captar decisiones del diseño en una forma mutable a partir de los requisitos: Un modelo de un sistema software puede capturar el comportamiento externo de un sistema y la información del dominio del 67 de 243

mundo, real representado por el sistema. Otro modelo muestra las clases y las operaciones internas, que implementan el comportamiento; el modelo final de diseño muestra un acercamiento que el diseñador cree correcto. 

Generar productos aprovechables para el trabajo: Un modelo de un sistema software se puede utilizar para generar las declaraciones de clase, los cuerpos de procedimiento, las interfaces de usuario, las bases de datos, los escenarios de uso validos o los guiones de configuración.



Explorar económicamente múltiples soluciones: Los modelos de un sistema de software grande permiten que se proponga y comparen varios diseños. Modelar permite considerar varios diseños, con un coste pequeño al implementar cualquiera de ellos.



Entender los sistemas complejos: Un modelo de un sistema software grande permite ocuparse de la complejidad que es demasiado difícil de tratar directamente. Un modelo se puede abstraer a un niel que sea comprensible a los seres humanos sin perderse en detalles. (Jacobson, Booch y Rumbaugh, 200)

Vistas y diagramas: UML utiliza vistas que representan un aspecto de un sistema. Una o dos clases de diagramas proporcionan una notación visual para los conceptos de cada vista. Así mismo

posee diagramas que se utilizan para representar

visualmente diferentes perspectivas de un sistema de forma que un diagrama es una proyección del mismo. Estos son utilizados para representar la arquitectura del sistema. Las vistas se pueden dividir en tres áreas: clasificación estructural, comportamiento dinámico y gestión del modelo. 

La clasificación estructural: Describe los elementos del sistema y sus relaciones con otros elementos.



El comportamiento dinámico: Describe el comportamiento de un sistema en el tiempo.



La gestión del modelo: Describe la organización de los propios modelos en unidades jerárquicas.

68 de 243

La Tabla Nº 3 muestra la división de las vistas y los diagramas que pertenecen a cada vista. (Jacobson, 2000) Tabla Nº 3: Vistas y diagramas UML Vista

Área

Diagramas Diagrama de

Vista estática

clases

Conceptos principales Clase, generalización,

dependencia,

realización, interfaz Caso

Estructural

asociación,

Vista de casos

Diagrama de

asociación,

de uso

casos de uso

inclusión,

uso,

actor,

extensión, generalización

casos de uso Vista de

Diagrama de

Componente,

implementación

componentes

dependencia, realización

Vista

de Diagrama de

despliegue Dinámica

dependencia, localización

Diagrama de

Estado,

estados

acción

Vista de

Diagrama de

Estado, actividad, transición,

actividad

actividades

de terminación, división, unión

Vista

máquinas

Diagrama

interacción

Diagrama

transición,

activación de Colaboración, interacción, rol

colaboración del Vista de gestión Diagrama del modelo clases

evento,

de Interacción, objeto, mensaje,

de secuencias

Vista

modelo

componente,

despliegue

estado

Gestión

Nodo,

interfaz,

de colaboración, mensaje Paquete, subsistema, modelo

Fuente: [Jacobson, 2000]

Clasificación estructural: Dentro de esta categoría describen las siguientes vistas: 

Vista estática: Modela los conceptos del dominio de la aplicación, así como los conceptos internos inventados como parte de la implementación de la

69 de 243

aplicación. Los componentes principales de esta vista son las clases 18 y sus relaciones: asociación, generalización y varias clases de dependencia, tales como realización y uso. Se representa mediante diagramas de clases, muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. 

Vista de los casos de uso: Modela la funcionalidad del sistema según lo perciben los usuarios externos, llamados actores. El propósito de esta es enumerar a los actores y los casos de uso, y demostrar qué actores participan en cada caso de uso. Esta vista se representa mediante diagramas de casos de uso.



Vista de implementación: Modela los componentes de un sistema, así como las dependencias entre los componentes, para poder determinar el impacto de un cambio propuesto. También modela la asignación de clases y de otros elementos del modelo a los componentes. La vista de implementación se representa en diagramas componentes y también 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.



Vista de despliegue: Representa la disposición de las instancias de componentes de ejecución en instancias de nodos. Un nodo es un recurso de ejecución, tal como una computadora, un dispositivo o memoria. Esta vista permite determinar las consecuencias de la distribución y de la asignación de recursos. La vista de despliegue se representa en diagramas de despliegue.

El comportamiento dinámico: Dentro de esta categoría se describen las siguientes vistas: 

Vista de la máquina de estados: Una máquina de estados permite modelar las posibles historias de un objeto de una clase. Contiene los estados conectados por transiciones. Cada estado modela un periodo de tiempo, durante la vida de un objeto, en el que satisface ciertas condiciones. Las maquinas de estado se pueden utilizar para describir interfaces de usuarios, controladores de dispositivo y otros subsistemas reactivos. También pueden

Clase: Una clase es la descripción de un concepto del dominio de la aplicación o de la solución de la

aplicación.

70 de 243

usarse para describir los objetos pasivos que pasan por varias fases cualitativas distintas, durante su tiempo de vida, cada una de las cuales tienen su propio comportamiento especial. Las maquinas de estados se muestran como diagramas de estados 

Vista de actividades: Es una variante de una máquina de estados que muestra las actividades de computación implicadas en la ejecución de un cálculo. Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel de la ejecución de un sistema, sin profundizar en los detalles internos de los mensajes, lo que requeriría un diagrama de colaboración.



Vista de interacción: La vista de interacción describe secuencias de intercambios de mensajes entre los roles que implementan el comportamiento de un sistema. Esta división proporciona una vista integral del comportamiento de un sistema. Es decir, muestra el flujo de control a través de muchos objetos. La vista de interacción se expresa en dos diagramas centrados en distintos aspectos: diagramas de secuencia y diagramas de colaboración. 

Diagrama de secuencia: Muestra un conjunto de mensajes, en una secuencia temporal. Cada rol en la secuencia se muestra como una línea de vida, es decir una línea vertical que representa el rol durante cierto plazo de tiempo, con la interacción completa.



Diagrama de colaboración: Muestra los roles en la interacción en una disposición geométrica. La colaboración muestra la interacción entre objetos para encontrar la base de datos de la presentación deseada en el conjunto de todas las representaciones.

Gestión del modelo: Dentro de esta categoría se describen la siguiente vista: 

Vista de gestión del modelo: Modela la organización del modelo en sí mismo. Mediante un conjunto de paquetes. Los paquetes pueden contener otros paquetes; por lo tanto un modelo parte de un paquete raíz, que contiene indirectamente todo el contenido del modelo.

71 de 243

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. (Jacobson, 2000)

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

El primer objetivo conduce a las pruebas de validación, en las que se espera que el sistema funcione correctamente usando un conjunto determinado de casos de prueba que reflejan el uso esperado de aquel. El segundo objetivo conduce a las pruebas de defectos en los que los casos de prueba se diseñan para exponer los defectos. Un ejemplo básico de las fases de pruebas se muestra en la (Figura Nº 26). (Sommerville, 2005) Figura Nº 26: Fases de pruebas Pruebas del componente

Pruebas del componente

Desarrollador de software

Equipo de pruebas independiente

Fuente: [Ian Sommerville, 2005]

72 de 243

Las pruebas no pueden demostrar que el software está libre de defectos o que se comportará en todo momento como está especificado. Siempre es posible que una prueba que se haya pasado por alto pueda descubrir problemas adicionales con el sistema. Un modelo general del proceso de pruebas se muestra en la (Figura Nº 27). 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. Figura Nº 27: Modelo general del proceso de pruebas de software

Casos de prueba

Diseñar casos de prueba

Datos de prueba

Preparar datos de prueba

Resultados de la prueba

Ejecutar el programa con los datos de prueba

Informe de la prueba

Comparar resultados con los datos de prueba

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. Para la mayoría de los sistemas, existen tres fases distintas de pruebas del sistema: 

Pruebas de integración



Pruebas de Funcionales



Pruebas de rendimiento (Sommerville, 2005)

2.4.4.1 Pruebas unitarias Las pruebas unitarias se concentran en la verificación de la unidad más pequeña del diseño del software: El módulo de software. Se prueban importantes caminos de control para descubrir errores dentro de los límites del módulo.

73 de 243

Las pruebas de unidad se concentran en la lógica del procesamiento interno y en las estructuras de datos dentro los límites de un componente. Este tipo de prueba se puede aplicar en paralelo a varios componentes. Mediante la siguiente figura, se puede observar las pruebas que se realizan mediante el uso de un caso de prueba. Figura Nº 28: Pruebas unitarias

Módulo ---------------------------------------------------

Condiciones límite Estructuras de datos locales Manejo de errores Rutas independientes

Casos de prueba

Fuente: [Pressman, 2004]

Se deben diseñar casos de prueba para descubrir errores debidos a cálculos incorrectos, comparaciones erróneas o flujos de control inapropiados. Entre los errores más comunes en los cálculos se pueden encontrar: Aplicación incorrecta de la precedencia aritmética, operaciones de modo mezcladas, falta de precisión, representación simbólica incorrecta ante una expresión, comparación incorrecta de variables, etc. La prueba de unidad suele considerarse adyacente al paso de la codificación. El diseño de las pruebas de unidad puede realizarse antes de que empiece la codificación o después de que se ha generado el código fuente. Una revisión de la información del diseño proporciona una guía para establecer los casos de prueba que probablemente descubrirán errores en cada una de las categorías analizadas. Cada caso de prueba debe relacionarse con un conjunto de resultados esperados. (Pressman, 2004)

74 de 243

2.4.4.2 Pruebas funcionales Consiste en probar el funcionamiento correcto de los diferentes componentes software del sistema o aplicación. Básicamente se comprueba el cumplimiento de las funciones específicas para los cuales han sido creados. A este tipo de pruebas se les denomina también pruebas de comportamiento o pruebas de caja negra, ya que no enfocan su atención a como se generan las respuestas del sistema, sino en el análisis de los datos de entrada y en los de salida, esto generalmente se define en los casos de prueba preparados antes del inicio de las pruebas. Al realizar pruebas funcionales lo que se pretende en ponerse en los pies del usuario, usar el sistema como él lo usaría sin embargo se debe ir más allá que cualquier usuario, generalmente se requiere apoyo de los usuarios finales ya que ellos aportan en el desarrollo de casos de prueba complejos, enfocados básicamente al negocio, proporcionando posibles particularidades que no se hayan contemplado adecuadamente en el diseño funcional. La (Figura Nº 29) muestra ilustra el modela 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. Figura Nº 29: Pruebas de caja negra.

Entrada de datos de prueba

Entrada que provocan comportamiento anómalo

Sistema

Resultados de las pruebas

Salidas que revelan la presencia de defectos

Fuente: [Ian Sommerville, 2005]

75 de 243

Si las salidas no son las esperadas (es decir, si las salidas pertenecen al conjunto ), entonces la prueba ha detectado un problema con el software. Cuando realizan las pruebas, debería intentarse “romper” el software eligiendo casos de prueba que pertenecen al conjunto

en la (Figura Nº 35), es decir el objetivo

debería ser seleccionar entradas que tienen una alta probabilidad de generar fallos de ejecución del sistema (salidas del conjunto

). Se utiliza la experiencia previa de

cuáles son las pruebas de defectos que probablemente tendrán éxito y las guías de pruebas ayudarán a elegir la adecuada. 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.

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. Si se han utilizado casos de uso para describir los requerimientos del sistema, estos casos de uso y los diagramas de secuencia asociados pueden ser una base para las pruebas

del sistema. Los casos de uso y los diagramas de secuencia pueden

emplearse ambos durante la integración y pruebas de entregas. (Sommerville, 2005)

2.4.4.3 Pruebas de carga Una vez que el 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

76 de 243

pruebas en las que la carga se va incrementando regularmente hasta que el rendimiento del sistema se hace inaceptable. Para probar si los requerimientos de rendimiento son alcanzados, se debe construir un perfil operacional, este es un conjunto de pruebas que reflejan la combinación real de trabajo que debería ser manejada por el sistema. Las pruebas 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: 

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 perdidos inesperadas de servicios de los usuarios.



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. (Sommerville, 2005)

2.5 HERRAMIENTAS DE DESARROLLO DE SOFTWARE Las herramientas de desarrollo de software, permitirán facilitar y agilizar el proceso de desarrollo, en el aspecto de la organización de cada versión del sistema, la productividad durante la fase de construcción, el diseño, etc. Estos pueden ser lenguajes de programación, bases de datos y arquitecturas de desarrollo de software. (Pressman, 2004)

2.5.1 Gestión de la configuración Uno de los principales problemas en todos los proyectos de desarrollo de software es el “versionaje”.

77 de 243

El versionaje nos permite llevar un control de los cambios en nuestro código, quien y cuando lo hizo, porque lo hizo, que cambio a razón de que. Existe muchas alternativas libres en el mercado que unidos a otros productos permiten tener incluso hasta los historiales, hacer comparaciones, manejar tickets, llevar métricas, etc. Casi todas las opciones cuentan con soporte de GUI para administración y/o soporte Web lo que hace mucho mas cómodo trabajar en equipos de desarrollo distribuidos en varios lugares. Son herramientas son software de apoyo al desarrollo, mantenimiento y documentación informatizados de software. (Sommerville, 2005)

2.5.2 Arquitecturas de desarrollo de software Es la descripción de los subsistemas y componentes de un software y las relaciones entre ellos. La arquitectura de software viene determinada por las diferentes instancias de cada tipo de componentes y conectores que la componen y por una serie de enlaces específicos que definen la unión de todas ellas formando una estructura.

2.5.2.1 Arquitectura cliente/servidor Esta arquitectura es un modelo de sistema en el que dicho sistema se organiza como un conjunto de servicios y servidores asociados, más unos clientes que acceden y usan los servicios. Los principales componentes de este modelo son: 

Un conjunto de servidores que ofrecen servicios a otros subsistemas.



Un conjunto de clientes que llaman a los servicios ofrecidos por los servidores de manera concurrente



Una red que permite a los clientes acceder a estos servicios. Esto no es estrictamente necesario ya que los clientes y los servidores podrían ejecutarse sobre una única máquina. En la práctica, sin embargo, la mayoría de los sistemas cliente-servidor se implementan como sistemas distribuidos.

Los clientes acceden a los servicios proporcionados por un servidor a través de llamadas a procedimientos remotos usando un protocolo de petición-respuesta tal como el protocolo http usado en la WWW. Básicamente, un cliente realiza una petición a un servidor y espera hasta que recibe una respuesta. La (Figura Nº 30), muestra un ejemplo de un sistema basado en el modelo cliente-servidor. Éste es un 78 de 243

sistema multiusuario basado en web para proporcionar una biblioteca de películas y fotografías. (Sommerville, 2005) Figura Nº 30: Arquitectura de un sistema de biblioteca de películas y fotografías Cliente 1

Cliente 2

Cliente 3

Cliente 4

Servidor de imagenes --------------Fotografias digitalizadas

Servidor web --------------información de videos y peliculas

Internet

Servidor de catálogos --------------Catálogo

Servidor de videos --------------Archivos de video

Fuente: [Sommerville, 2005]

En este sistema varios servidores gestionan y visualizan diferentes tipos de dispositivos. Las secuencias de video necesitan ser transmitidas rápidamente y en sincronía, pero con una resolución relativamente baja. La arquitectura cliente-servidor es una arquitectura distribuida. Se puede hacer un uso efectivo de los sistemas de red con muchos procesadores distribuidos. Es fácil añadir un nuevo servidor e integrarlo con el resto del sistema o actualizar los servidores de forma transparente sin afectar al resto del sistema. Sin embargo, puede ser necesario realizar cambios a los clientes y servidores existentes para obtener los mayores beneficios de la integración de un nuevo servidor. Puede no haber un modelo de datos compartidos entre los servidores y los subsistemas pueden organizar sus datos de formas diferentes. (Rob, 2004)

2.5.2.2 Arquitectura de n-capas Es una evolución de la arquitectura cliente servidor básica, la separación por capas permite descomponer la aplicación de manera que cada parte sea gestionada por uno o varios servidores especializados. El cliente hace una solicitud al servidor de la capa inmediata que está preparado para recibir y gestionar solicitudes de clientes. El servidor de esta capa a su vez, actúa como cliente y hace una solicitud a otro servidor, por ejemplo, para conseguir información de una base de datos. Finalmente,

79 de 243

el servidor de la última capa devuelve un resultado que en sentido inverso a las solicitudes cruza y es tratado en cada capa hasta llegar de vuelta al usuario. Para entender la evolución de esta arquitectura respecto a las tradicionales se explicara a más detalle a continuación. Básicamente la arquitectura de n-capas es en realidad un estilo de programación donde el objetivo principal es separar los diferentes aspectos del desarrollo, tales como las cuestiones de presentación, lógica de negocio, mecanismos de almacenamiento, etc. (Tentor, 2008) La necesidad de contar con porciones de la aplicación que se puedan "intercambiar" sin tener que modificar el resto de la aplicación es lo que impulsa el desarrollo en capas (Figura Nº 31) Figura Nº 31: Diagrama básico de la división según n-capas.

Fuente: [Tentor, 2008]

Se tiene primeramente 2 niveles y en el primero existen 2 capas, de esta manera La capa de presentación interactúa con la capa de lógica de negocio; Esto significa que la capa de lógica de negocios presenta una interfaz para brindar servicios a la

80 de 243

capa de presentación, también existe otro nivel donde se encuentra una capa encargada de los datos. Esta se trata de un motor de base de datos que puede o no ejecutarse en el mismo equipo. Esta capa también presenta una "interfaz" para brindar sus servicios a la capa que está por encima. Las capas inferiores brindan servicios a las capas superiores (independientemente del nivel en que se encuentren). Si se agrega nuevo código, se puede intercambiar la capa de presentación sin afectar el resto de la aplicación. El problema se presenta cuando se requiere intercambiar la Capa / Nivel de Datos, esto significa que es necesario utilizar otro motor de base de datos. Lo que inevitablemente incorporará en la Capa de Lógica de Negocios código que no es compatible con otros motores de base de datos. En consecuencia, cambiar la capa de datos significa corregir la capa de lógica de negocios. (Figura Nº 32) Figura Nº 32: Diagrama de 2 niveles

Fuente: [Tentor, 2008]

81 de 243

Se puede ver ahora las 3 capas. La nueva capa, se denomina Capa de Acceso a Datos (Capa de Persistencia) que no es lo mismo que Capa de Datos. La capa de acceso a datos es una porción de código que realiza el acceso a los datos. De esta manera cuando es necesario cambiar el motor de base de datos, solamente se requiere modificar esa capa. Mientras que la capa de datos (en el nivel de datos) es donde están los datos y corresponde directamente con la definición de esquemas, tablas, vistas, procedimientos almacenados y todo lo que se pueda o deba poner en un motor de base de datos. En este modelo los desarrolladores tienen un problema. Resulta que los componentes de la capa de lógica de negocios necesitan referenciar a instancias de las clases del dominio (las que representan las entidades del negocio) y los componentes de la capa de acceso a datos también tienen que referenciarlas con los datos que obtienen de las capas inferiores. La solución que satisface a los arquitectos y a los desarrolladores, es la siguiente (Figura Nº 33) Figura Nº 33: Modelo de 2 niveles, con una capa de dominio de aplicación

Fuente: [Tentor, 2008]

82 de 243

Ahora se añade una nueva capa que corresponde al dominio de la aplicación. En esta capa se encuentra la declaración de las entidades de la aplicación, de manera que se pueden referenciar desde otras capas sin entrar en ciclos recursivos de compilación. La arquitectura de n-capas posee una división de capas y niveles. Las Capas se ocupan de la división lógica de componentes y funcionalidad, y no tienen en cuenta la localización física de componentes en diferentes servidores o en diferentes lugares. Por el contrario, los Niveles se ocupan de la distribución física de componentes y funcionalidad en servidores separados, teniendo en cuenta topología de redes y localizaciones remotas. Tanto las capas como niveles usan conjuntos similares de nombres (presentación, servicios, negocio y datos), En la (Figura Nº 34) se puede visualizar un esquema de 3 niveles y n-capas. (Tentor, 2008) Figura Nº 34: Esquema de 3 niveles y n-capas

Capa de infraestructura Transversal (Seguridad, operaciónes, etc)

Capa de presentación

Capa de negocio

Capa de acceso a datos

Servicios Fuentes externos de datos n-capas (lógico)

3-niveles (físico)

Fuente: [Tentor, 2008]

83 de 243

2.5.3 Lenguajes de programación Los lenguajes de programación serán utilizados para construir parte por parte el sistema que esta propuesto en este trabajo. Estos lenguajes son idiomas artificiales diseñados para expresar procesos que pueden ser llevadas a cabo por máquinas como las computadoras. Pueden usarse para crear programas que controlen el comportamiento físico y lógico de una máquina, para expresar algoritmos con precisión, o como modo de comunicación humana.

2.5.3.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. Este lenguaje puede ser utilizado mediante un framework denominado ASP.NET. 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. Características de c sharp 

Lenguaje de programación orientado a objetos simple, moderno y de propósito general.

84 de 243



Inclusión de principios de ingeniería de software tales como revisión estricta de los tipos de datos, revisión de límites de vectores, detección de intentos de usar variables no inicializadas, y recolección de basura automática.



Capacidad para desarrollar componentes de software que se puedan usar en ambientes distribuidos.



Portabilidad del código fuente



Fácil migración del programador al nuevo lenguaje, especialmente para programadores familiarizados con C y C++.



Adecuación para escribir aplicaciones de cualquier tamaño: desde las más grandes y sofisticadas como sistemas operativos hasta las más pequeñas funciones.



Aplicaciones económicas en cuanto a memoria y procesado. (Sharp, 2009)

2.5.3.2 Java Java es un lenguaje de programación orientado a objetos, desarrollado por Sun Microsystems a principios de los años 90. El lenguaje en sí mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de objetos más simple y elimina herramientas de bajo nivel, que suelen inducir a muchos errores, como la manipulación directa de punteros o memoria. Características de Java Es un lenguaje de programación que ofrece la potencia del diseño orientado a objetos con una sintaxis fácilmente accesible y un entorno robusto. Proporciona un conjunto de clases potente y flexible, además es: 

Orientación a Objetos



Riqueza Semántica.



Robusto



Modelo de Objeto Rico



Multiplataforma



Interactivo y orientado a Red (Rodríguez, 2006).

85 de 243

2.5.3.3 PHP Es un lenguaje interpretado del lado del servidor que se caracteriza por su potencia, versatilidad, robustez y modularidad. Los programas escritos en php son embebidos directamente en el código HTML y ejecutados por el servidor web a través de un intérprete antes de transferir al cliente que lo ha solicitado un resultado en forma de código HTML puro. 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.



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

Si bien PHP no obliga a quien lo usa a seguir una determinada metodología a la hora de programar, aún haciéndolo, el programador puede aplicar en su trabajo cualquier técnica de programación o de desarrollo que le permita escribir código ordenado, estructurado y manejable. (Tentor, 2008)

2.5.4 Sistemas gestores de base de datos Es un conjunto de información almacenada en memoria auxiliar que permite acceso directo y un conjunto de programas que manipulan esos datos. Base de Datos es un conjunto

exhaustivo

redundante

datos

estructurados

organizados

independientemente de su utilización y su implementación en máquina accesibles en tiempo real y compatibles con usuarios concurrentes con necesidad de información diferente y no predicable en tiempo. 86 de 243

En la actualidad, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital (electrónico), que ofrece un amplio rango de soluciones al problema de almacenar datos. (Casillas, 2005).

2.5.4.1 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 ayuda a obtener más rendimiento de los datos, poniendo a disposición una amplia gama de servicios integrados como son consultas, búsquedas, sincronizaciones, informes y análisis. Los datos pueden almacenarse y recuperarse desde servidores potentes en un Data Center hasta los desktops y dispositivos móviles, permitiendo tener un mayor control sobre la información sin importar dónde se almacena físicamente. (Rob, 2004) 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. (Rob, 2004)

87 de 243

2.5.4.2 MySql Es un sistema de administración relacional de bases de datos. Una base de datos relacional 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 software de fuente abierta, es decir que es posible para cualquier persona usarlo y modificarlo. Cualquier persona puede descargar el código fuente de MySQL y usarlo sin pagar. MySQL usa el GPL (GNU General Public License) para definir qué puede hacer y que no puede hacer con el software en diferentes situaciones. Características de MySql Amplio subconjunto del lenguaje SQL. Algunas extensiones son incluidas igualmente. 

Disponibilidad en gran cantidad de plataformas y sistemas.



Diferentes opciones de almacenamiento según si se desea velocidad en las operaciones o el mayor número de operaciones disponibles.



Transacciones y claves foráneas.



Conectividad segura.



Replicación (Casillas, 2005).

2.5.4.3 PostgreSql Es un sistema de gestión de bases de datos objeto-relacional, distribuido bajo licencia BSD y con su código fuente disponible libremente. 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. Características de PostgreSql 

Alta concurrencia

88 de 243



Amplia variedad de tipos nativos: PostgreSql provee nativamente soporte para (Números de precisión arbitraria., Texto de largo ilimitado, Direcciones IP (IPv4 e IPv6), Arrays.)



Claves ajenas: Llaves ajenas o Claves Foráneas (foreign keys).



Permite el uso de disparadores (triggers):



Soporte para transacciones distribuidas



Funciones ejecutadas en bloques de código que se ejecutan en el servidor. (Casillas, 2005).

2.5.4.4 Replicación de base de datos Se refiere al almacenamiento de copias de datos en sitios múltiples servidores por una red de computadoras. Pueden guardarse copias de fragmentos en varios sitios para satisfacer requerimientos de información específicos. 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º 35), el fragmento A1 se guarda en los sitios S1 y S2, mientras que A2 guarda en los sitios S2 y S3. Figura Nº 35: Replicación de datos Sitio S1

Sitio S2

Sitio S3

Fuente: [Rob, 2004]

Los datos replicados se someten a la regla de consistencia mutua. Esta regla requiere que todas las copias de fragmentos de datos sean idénticas.

89 de 243

La replicación es utilizada para: 

Incrementar la disponibilidad de los datos esto implica que el sistema sigue funcionando aún en el caso de la caída de alguno de los nodos (BD).



Aumentar el paralelismo de los nodos, los cuales pueden realizar consultas en paralelo sobre una misma tabla. Cuando más replicas existan, mayor será la posibilidad de que el dato buscado se encuentre en el nodo desde el que se realiza la consulta, minimizando el tráfico de datos entre nodos.

Existen aspectos que se consideran al realizar una réplica, estos definen procesos que el DBMS debe realizar para utilizar la base de datos: 

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



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.



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 dos escenarios de replicación; una base de datos puede ser totalmente replicada o parcialmente replicada, como se explica a continuación: 

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, estos son claves cuando se requiere acceder a información específica de una base de datos y no su totalidad, esto implica un tráfico de datos más rápido. Existen fragmentos verticales, horizontales y mixtos. 90 de 243

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.



Modificación de los datos replicados: Se refiere a realizar pruebas de modificación a los datos de la replicación



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 replica (esclava).

Cuando la frecuencia de uso de datos remotamente localizados es elevada y la base de datos es grande, la replicación de los datos reduce el costo de las solicitudes de datos. La información sobre la replicación de los datos se guarda en el catálogo de datos distribuidos, cuyo contenido es utilizado por el procesador de transacciones para decidir que copia de un fragmento de bases de datos acceder. La replicación de datos permite recuperar los datos perdidos. (Rob, 2004)

91 de 243

3 MARCO PRÁCTICO 3.1 DETERMINACIÓN DEL PROCESO ACTUAL DE INSCRIPCIÓN Y FACTURACIÓN En esta sección se aplican técnicas de recopilación de datos para obtener, la información necesaria que servirá en la construcción del modelo de negocio actual y de acuerdo este modelo realizar un modelo de negocio alternativo

3.1.1 Resultado de entrevista respecto al proceso actual de inscripción y facturación De acuerdo a una entrevista realizada al personal administrativo del instituto Ing Data Comp mediante cuestionarios, se obtuvo información respecto al proceso actual de inscripción y facturación. (Ver Anexo J: Cuestionarios de recolección de datos). Los resultados de la entrevista se muestran a continuación: 

El proceso de inscripción es manual ya que los datos del estudiante primeramente se manuscriben en un formulario y luego en una planilla de alumnos inscritos.



El pago realizado por concepto de inscripción o pago de mensualidades es registrado en una planilla y en un libro diario de ingresos de forma manual.



La facturación es efectuada de forma manual dentro la institución. La factura original es entregada al estudiante y la copia es archivada en el folder del estudiante.



Como los tres procesos mencionados son manuales ocasionan demora en la habilitación de un estudiante a carreras o cursos.



Existe información redundante en el registro de datos de estudiantes ya que se utilizan dos planillas.



Se han dado situaciones en las que el formulario de datos del estudiante es extraviado por lo que el estudiante debe llenar este formulario nuevamente.

92 de 243

3.1.2 Modelo de negocio actual El modelo de negocio actual permite representar de manera grรกfica la informaciรณn adquirida mediante las tรฉcnicas de recolecciรณn de datos. Esta representaciรณn es dividida en dos partes; Una representaciรณn por niveles que divide al instituto en tres niveles (Objetivos, procesos, sistemas) para facilitar la alineaciรณn de los sistemas a los objetivos y proceso y una representaciรณn de actividades del instituto. Las representaciones se muestran en el siguiente apartado:

3.1.2.1 Modelo de negocio en tres niveles Figura Nยบ 36: Modelado de negocio actual en tres niveles Inscripciรณn de estudiantes a carreras y cursos mediante el uso de planillas

Ing Data Comp Registro de pago de inscripciรณnes y mensualidades en planillas y emisiรณn de factura manual (de talonario) Factura de talonario

NIVEL DE OBJETIVOS

NIVEL DE PROCESO DE NEGOCIO ACTUAL

Persona se aproxima a secretaria donde se inscribe a la carrera o curso de su interes

Persona solicita informaciรณn de carreras o cursos para inscribirse

Su pago es registrado y se emite la factura correspondiente (de talonario)

Persona cancela el monto por inscripciรณn รณ mensualidad (dependiendo el caso)

Si ya estรก inscrita puede solicitar pagar su mensualidad

Inscripciรณn y facturaciรณn en planillas (manual)

NIVEL DE SISTEMA DE INFORMACIร N Planillas archivadas

Planillas

Fuente: [Elaboraciรณn propia]

93 de 243

Estantes de documentos (datos estudiante)

3.1.2.2 Modelado de negocio actual Figura N潞 37: Modelado de negocio actual

Fuente: [Elaboraci贸n propia]

94 de 243

3.1.2.3 Deficiencias en el proceso actual de inscripción y facturación 

Existe tiempo excesivo en el proceso de inscripción y facturación debido a que estos procesos son manuales.



La centralización de pago de mensualidades y de inscripción en secretaría genera largas filas de estudiantes que esperan ser atendidos.



El uso de dos planillas para el registro de inscripción de estudiantes y pagos respectivamente genera redundancia de datos

3.1.3 Modelo de negocio alternativo Este modelo surge como una propuesta que permita solucionar las deficiencias encontradas en el modelado de negocio actual y se muestra a continuación:

3.1.3.1Modelo de negocio en tres niveles Figura Nº 38: Modelado de negocio alternativo en tres niveles

Inscripción de estudiantes a carreras y cursos mediante sistema w eb

Ing Data Comp

Registro de pago de inscripciónes, mensualidades y emisión de factura (impresa) mediante sistema de facturación en entidad financiera

NIVEL DE OBJETIVOS

Factura impresa

Funcionario de caja ingresa al Sistema de facturación y consulta cuanto debe pagar la persona

2 Persona se aproxima a la entidad financiera y solicita pagar su inscripción o mensualidad con su CI

NIVEL DE PROCESO DE NEGOCIO ALTERNATIVO 1

Persona cancelal el monto, su pago es registrado y es emitida la factura correspondiente

Persona ingresa a sistema de inscripción donde Si ya está inscrita puede ver su se inscribe con sus datos (ci,nombre,etc) a un estado de pagos para ver los curso o carrera de su interes pagos realizados y pendientes

Sistema de inscripción y facturación

Servidor BD (Sql server)

Servidor aplicaciónes (IIS) Red de entidad financiera

NIVEL DE SISTEMA DE INFORMACIÓN

BD replica Sistema

Fuente: [Elaboración propia]

95 de 243

Base de datos instituto

3.1.3.2 Modelado de negocio alternativo Figura Nยบ 39: Modelado de negocio alternativo

96 de 243

3.2 REQUERIMIENTOS EN ENTIDADES FINANCIERAS RESPECTO A LA INTERMEDIACIÓN FINANCIERA Y REQUERIMIENTOS EN ENTIDADES REGULADORAS RESPECTO A LA FACTURACIÓN MEDIANTE SISTEMAS INFORMÁTICOS Las entidades financieras proporcionan una serie de requerimientos necesarios para poder efectuar la intermediación financiera mediante los servicios que otorgan. Estos requerimientos son normados por un ente regulador denominado Autoridad de Supervisión del Sistema Financiero (ASFI). La intermediación financiera permite que la entidad financiera cobre los servicios educativos (matriculas/mensualidades) a nombre del instituto. Esta actividad implica la realización de operaciones financieras, por lo que existen normativas que establecen aspectos técnicos y de seguridad en estas operaciones. La circular SB/443/2003 indica los requisitos técnicos y de seguridad que la entidad financiera debe cumplir cuando emplea sistemas informáticos en sus instalaciones. Así mismo existe otra circular: SB/466/2004 de REQUISITOS MÍNIMOS DE SEGURIDAD INFORMÁTICA, mediante la cual ASFI regula los mismos aspectos a las instituciones que proveen tecnologías de información. El instituto como proveedor del módulo de facturación a la entidad financiera, debe cumplir estos requisitos y son descritos a continuación.

3.2.1 Aspectos de técnicos en la intermediación financiera según la circular SB/466/2004 Se han considerado los siguientes aspectos: -

Programas Fuente: Al término de finalización del módulo de facturación, la entidad financiera tendrá acceso el acceso oportuno al código fuente, para la verificación del funcionamiento correcto del mismo.

Propiedad intelectual: La propiedad intelectual del de desarrollo del módulo de facturación dependerá de lo que se acuerde entre el instituto y la entidad financiera, mediante el contrato expreso.

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

El servidor del instituto Ing Data Comp está en Windows Server 2008.

El sistema operativo utilizado es Windows Server 2008

El lenguaje utilizado para el desarrollo del sistema es C Sharp

El motor de base datos del sistema es SQL Server 2008.

Formalización de Recursos Humanos: El personal autorizado para el uso del módulo debe estar descrito en el contrato entre entidad financiera e instituto. El instituto debe proveer de personal de soporte técnico en caso de haber problemas con el sistema. Así mismo el instituto debe prever la capacitación al personal de la entidad financiera (Administrador y funcionarios de caja) para el uso del módulo de facturación antes de su implantación.

Cronograma y plan de trabajo: El plan y cronograma de trabajo está documentado en la primera parte de generalidades de este trabajo.

Acceso remoto: El acceso al servidor del instituto por parte de la entidad financiera es remoto, Las normas de seguridad de esta conexión son descritas en el siguiente apartado.

3.2.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: Deben ser consideradas por el instituto y entidad financiera



Desarrollo de sistemas de información y programas: Efectuado por personal del instituto siguiendo el cronograma de plan de trabajo establecido.



Mantenimiento de sistemas y programas: Efectuado por personal del instituto cada vez que sea requerido.



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



Respaldos y recuperación de información: Se ha dispuesto de una base de datos replica situada en el servidor del instituto.

98 de 243



Respaldo y recuperación de bases de datos: Se ha dispuesto de una base de datos replica situada en el servidor del instituto.



Administración de licencias de software y programas: El instituto prevé adquirir las licencias de software que será otorgada 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: El acceso al servidor del instituto debe ser por el personal autorizado (Administrador de instituto). Así mismo el acceso al módulo de facturación en la entidad financiera debe ser por el personal autorizado (Administrador de entidad financiera y funcionarios de caja).

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. Así mismo los puntos que se desean tomar en cuenta y que no están descritos anteriormente, por parte del instituto o la entidad financiera, deben ser acordados mediante el contrato expreso de ambas partes. Para mayor información. (Ver Anexo A: Circular SB/466/2004: Requisitos mínimos de seguridad informática).

3.2.3 Análisis y selección de entidad financiera La aplicación de entrevistas a entidades financieras (Ver Anexo J: Cuestionarios de recolección de datos) dio resultado al siguiente análisis, que servirá en la selección de la entidad financiera la cuál proporcionara el servicio financiero (de intermediación financiera) al instituto Ing Data Comp. Tabla Nº 4: Selección de entidad financiera Criterio de

Banco unión

Fondo Financiero Fassil

Se requiere la creación de al

selección

Cuenta bancaria

menos

una

cuenta

instituto en el banco. Requerimientos legales

 Constitución legal.

de la entidad financiera

 Personería jurídica.

99 de 243

del

menos una cuenta del instituto en Fassil.

 Registro de comercio.  Registro de inscripción al padrón de contribuyentes.  Documento de identificación del representante legal del instituto (Fotocopia) La cuenta del instituto debe Requerimientos

poseer un promedio de al

económicos

menos 70 mil dólares mensualmente

Costo por transacción realizada

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

No hay restricción respecto al monto mínimo en la cuenta del instituto mensualmente

Costo por transacción es de 1 bs

Fuente: [Elaboración propia]

El análisis de la tabla muestra que la opción más adecuada para el instituto tomando como referencia el costo por transacción realizada y los requerimientos económicos es el Fondo Financiero Fassil.

3.2.4 Requerimientos de solicitud de intermediación financiera para cobro de servicios (Fondo Financiero Privado Fassil) De acuerdo al instructivo I007 del Fondo Financiero Privado Fassil se denomina a este tipo de servicio “Sistema de recepción de pagos”. Para la adquisición de este el instituto Ing Data Comp debe entregar la siguiente documentación a Fassil: 

Constitución legal (Documento con las normas del instituto Ing Data Comp).



Personería (Documento que posee el registro y reglamentación de las funciones y actividades del instituto, otorgando el derecho de poder trabajar de manera legal en las actividades inherentes a su campo de acción)



Registro de comercio (Documento que acredita el registro del instituto ante la organización FundeEmpresa)



Certificado de inscripción al padrón nacional de contribuyentes (Documento que acredita el registro del instituto 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 del instituto) 100 de 243



Fotocopia de carnet de identidad del representante legal del instituto

3.2.4.1 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 inscripción y de mensualidades por cuenta del instituto Ing Data Comp. La modalidad de pago para los estudiantes del instituto es la de pago en ventanilla debido a la cantidad de puntos de cobros que tiene la entidad financiera. En esta modalidad de pago el estudiante se aproxima al funcionario de caja e indica el CI del mismo de esta manera el funcionario consultará al sistema de facturación para indicar los pagos pendientes del estudiante. Una vez realizado el pago le entregará la factura correspondiente y el estado de pagos será actualizado.

3.2.5 Requerimientos para la emisión de factura La normativa de directorio Nº 10-0016-07 del artículo 13 de Ley Nº 843 (Ley de bancos y entidades financieras) describe los requerimientos para la emisión de factura en sistemas computarizados. La factura que será otorgada por concepto de pago por inscripción o pago de mensualidades, cumpliendo con los requerimientos de la ley se describe a continuación:

3.2.5.1 Formato de la factura 1. Datos básicos (parte superior izquierda): Sujeto pasivo (Instituto) 

Ing Data Comp



Casa Matriz: Av. Heroínas 233 Zona central



Teléfono: 4501210 – 4501217



Alcaldia: Cochabamba – Bolivia



Nº de SFC

Tercero emisor (Instituto) 

Nombre de entidad financiera

101 de 243

2. Datos de dosificación (parte superior derecha) 

NIT: 2795266019



Número de correlativo de factura: Nº XXXXXX



Número de autorización: Nº 3001002259472



ORIGINAL – CLIENTE

3. Título y subtítulos (parte superior central) 

FACTURA

4. Datos de la transacción comercial (parte central) 

Cochabamba, día mes año de emisión de factura



Señores: Nombre de estudiante



NIT de estudiante



Detalle: cantidad, concepto, precio unitario y total. (pago por inscripción o de mensualidades)



Total en general en Bolivianos (numeral y literal)

5. Datos finales (parte inferior) 

Código de control: (Ej: 51-E8-FD-0B)



Fecha límite de emisión



La reproducción total o parcial y/o el uso no autorizado de esta Nota Fiscal, constituye un delito a ser sancionado conforme a la Ley”

Tamaño de la factura: El tamaño de la factura será (1/2 Carta). Colores y materiales: El color de la información de la factura será azul y en hojas de papel bond. Código de control: Este código será implementado en un módulo dentro del sistema de facturación y será construido con los siguientes datos: 

Número de autorización.



Número de factura o nota fiscal.



NIT



Fecha de transacción.



Monto de la transacción o importe



Llave de dosificación (otorgada en cada dosificación por el SIN al instituto)

102 de 243

3.2.5.2 Dosificación El tipo de dosificación para el sistema de facturación es por tiempo. El cuál tiene validez de seis meses. Una vez concluido el plazo no se deben emitir facturas. Se debe solicitar una nueva dosificación dos semanas antes de la fecha de límite de emisión. El SIN denomina al sujeto pasivo (instituto) que adopte el tipo de facturación computarizada, como contribuyente newton, por este motivo el procedimiento de dosificación debe ser realizado a través del portal tributario del SIN. Una vez efectuada la solicitud, el portal indica el tiempo de vigencia de la dosificación y así mismo proporciona una llave que será utilizada para generar el código de control en el sistema de facturación. En cada dosificación el SIN, proporcionará al instituto los siguientes datos, los cuales serán ingresados en el sistema de facturación, para poder emitir facturas: 

Número de autorización



Fecha de vigencia de la dosificación



Llave de dosificación (para la generación del código de control)



Fecha límite de emisión

Además es importante mencionar que como el sistema de facturación es de red, solo es necesario realizar una dosificación para el sistema (cada 6 meses) la misma que será utilizada en las agencias de la entidad financiera, en la que se efectuará la facturación.

3.2.5.3 Registro de AutoImpresor Se identifica la casa matriz o sucursal donde se encuentra instalado el Sistema de Facturación Computarizada (SFC), consignando la siguiente información: 

Tipo: SFC de red, el cuál puede operar con la misma dosificación de la casa matriz (Instituto), correspondiendo certificar y registrar solamente al sistema empleado



Denominación del SFC: SFIngDataComp

103 de 243

3.2.5.4 Facturación por terceros La entidad financiera permite facturar a nombre del instituto en las diferentes agencias en las que cuenta, por este motivo el tipo de emisión efectuada se denomina: facturación por terceros. Es importante mencionar que en este tipo de facturación el sujeto pasivo titular (Instituto) es responsable ante el Fisco por el pago de tributos, dosificación y demás obligaciones tributarias mientras que el tercero emisor (Entidad financiera) es responsable ante el Fisco, por el cumplimiento de las obligaciones formales relativas a la emisión de facturas por terceros, sin perjuicio del cumplimiento de las obligaciones tributarias propias. La entidad financiera debe ser registrada y acreditada por el instituto ante la Administración tributaria para poder emitir este tipo de facturas, tomando en cuenta los siguientes datos: 

Nombre o razón social la entidad financiera



NIT de la entidad financiera



Certificación del SFC

Una vez obtenida la autorización por la Administración Tributaria podrá dar curso a las solicitudes de dosificación.

3.2.5.5 Prototipo de factura Danto cumplimiento a la normativa que indica el formato de la factura acorde a los elementos mencionados anteriormente, el prototipo de factura que será utilizado en el sistema de facturación se muestra a continuación:

104 de 243

Figura Nº 40: Prototipo de factura instituto Ing Data Comp

Fuente: [Elaboración propia]

3.3 DESARROLLO DEL MODULO DE INSCRIPCIÓN 3.3.1 Identificación y selección de metodología de desarrollo A continuación se muestra una tabla con ventajas y desventajas de las tres metodologías de desarrollo elegidas en el marco teórico, con el objetivo de seleccionar la metodología adecuada para el desarrollo de este trabajo.

105 de 243

Tabla Nº 5: Selección de metodología de desarrollo Metod. de

Características

desarrollo

Criterio de valoración

 Implementa las mejores prácticas de la ingeniería de software

 El flujo de trabajo indica de

 Genera software de alta calidad.  Se reducen riesgos y se obtiene UP (Proceso Unificado)

versiones operativas en etapas tempranas.

forma clara los pasos a seguir en el desarrollo del software.  El uso de UML facilita el

 Está dirigido por casos de uso.

entendimiento

 Está centrado en la arquitectura

arquitectura y el diseño del

 Es iterativo e incremental

sistema a desarrollar.

 Utiliza el lenguaje de modelado unificado  La programación es organizada.  Existe flexibilidad y adaptación a los cambios

 Necesita solo miembros de

 Productividad y calidad. SCRUM

equipo experimentados.

 Recomendable para proyectos de corto plazo.

 Las historias de usuario no describen detalladamente lo

 Los miembros del equipo pueden

que se va a desarrollar

dejar trabajo pendiente debido a la fecha límite de entrega de cada versión.  Adaptable

desarrollo

proyectos pequeños/grandes. XP (Programación extrema)

 Optimiza el desarrollo mediante la programación en parejas

 Requiere que el cliente sea parte

del

equipo

proporcionar

para

requisitos

 Menor taza de errores.

evaluar

 Es recomendable emplearlo solo

operativas lo cual no siempre

en proyectos a corto plazo.  Altas comisiones en caso de fallar. Fuente: [Elaboración propia]

106 de 243

sucede

las

versiones

Proceso de selección: De acuerdo al flujo de trabajo claro en las fases de desarrollo, el uso de un lenguaje de modelamiento que facilita el diseño, la generación de software de alta calidad y el uso de arquitecturas se ha seleccionado como metodología de desarrollo a UP (Proceso unificado)

3.3.2 Análisis de selección del modelo de desarrollo En la siguiente tabla se muestran las ventajas y desventajas de los modelos de desarrollo elegidos en el marco teórico, con el objetivo de seleccionar el modelo adecuado para el desarrollo de este trabajo. Tabla Nº 6: Selección de modelo de desarrollo Modelo de

Características

desarrollo

Criterio de valoración

 Permite entregar de manera rápida la versión operativa del sistema.  Apropiado para proyectos de larga duración. Incremental

 Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.  Aplica lineal

del

forma

modelo

escalonada

mientras se desarrolla el software.  No requiere la definición completa de los requisitos para empezar el desarrollo.  El riesgo es menor debido a las Espiral

iteraciones.  Validación sencilla de requisitos a partir de la primera iteración  Genera

reduce

tiempo

desarrollo inicial, ya que se implementa la funcionalidad parcial.  Proporciona ventajas

del

todas

las

modelo

cascada en cada incremento.  Al finalizar cada incremento

secuencias de

 Se

mucho

tiempo

obtiene

producto

funcional con documentación detallada del mismo.  La evaluación de los riesgos involucrados en el proyecto pueden elevar el costo y puede ser mayor que el costo de

construcción

del

sistema.  Está orientado al desarrollo

desarrollo del sistema.  El costo es elevado.

107 de 243

de grandes sistemas de gran complejidad.

 Permite trabajar a varias personas  Requiere

en el proyecto.  El ciclo de desarrollo es de menos

comunicación

la entre

desarrolladores y el cliente

fases.

DRA

que

 Menor taza de errores.

sea constante para aclarar los

 Requiere de gran cantidad de

requerimientos caso contrario el proyecto puede fallar.

recursos humanos para crear el número correcto de equipos. Fuente: [Elaboración propia]

Proceso de selección: De acuerdo la sencillez de los cambios en cada iteración, la entrega rápida de versiones operativas del sistema y la ventaja de ser apropiado para proyectos de larga duración, se ha seleccionado como adecuado para este trabajo al modelo de desarrollo incremental.

3.3.3 Análisis de selección del lenguaje de programación El lenguaje de programación como herramienta permitirá construir el sistema, por este motivo es importante seleccionar el adecuado. La siguiente tabla describe las ventajas y desventajas de los lenguajes con el objetivo de seleccionar el lenguaje para este trabajo. Tabla Nº 7: Selección de lenguaje de programación Lenguaje de programación

Características  Trabaja sobre la plataforma .NET.

Criterio de valoración  Es de fácil aprendizaje.

 Combina las mejores ideas de  Como es de propósito general es adaptable a las Lenguajes como C, C++ y Java con las mejoras de productividad C sharp

del Framework .Net de Microsoft.  Es sencillo debido a que eliminar complementos innecesarios que otros lenguajes incluyen.

necesidades.  Desarrollo ágil por la facilidad del entorno de desarrollo que posee (Visual studio)  Fácil

instalación

 Gestión automática de memoria.

configuración del servidor de

 Es orientado a objetos

aplicaciones (IIS)

108 de 243

 Permite el manejo de excepciones

 Como es orientado a objetos cumple con los principios de encapsulación,

herencia

polimorfismo.  Lenguaje es Multiplataforma, así

 El entorno de trabajo posee

mismo trabaja sobre la plataforma

varios

java.

código de forma paralela.  Permite

desarrollo

configuración y no permite un

 Puede procesar múltiples hilos de Java

problemas

desarrollo ágil  Es necesario para trabajar de

web

una manera óptima que se

dinámicas.

encuentre instalado el JDK

 Es de código abierto, interpretado

de Java.

y compilado a la vez.  El código es embebido con HTML lo

cual

resultado

 Cada

invisibilidad de este código en el

desarrollar

navegador. PHP

 Fácil de aprender

se cero,

debe su

entorno de trabajo no es de

 Es un lenguaje multiplataforma.  Es de código abierto

aplicación

mucha ayuda.  Los errores son difíciles de encontrar.

 Permite desarrollar de manera estructurada y manejable Fuente: [Elaboración propia]

Proceso de selección: De acuerdo a la facilidad de aprendizaje, adaptabilidad a las múltiples necesidades requeridas en los sistemas a desarrollar, gestión automática de memoria y el desarrollo ágil mediante el entorno de trabajo, se ha seleccionado a C Sharp como lenguaje de programación.

109 de 243

3.3.4 Aplicar las etapas de la metodología elegida al módulo de inscripción 3.3.4.1 Identificación de fases y flujo de trabajo de UP Según la Figura Nº 23 de la sección 2.4.2.1 del marco practico de este trabajo se puede ver que las fases del ciclo de vida de UP son las siguientes: 

Inicio: Requisitos importantes, modelado de primeros casos de uso.



Elaboración: Mayoría de casos de uso, arquitectura del sistema (modelado en su totalidad)



Construcción: Últimos detalles en el modelado, implementación en base a la arquitectura y las pruebas básicas.



Transición: Se obtiene una versión beta del producto a la cual se realiza las pruebas finales.

Cada una de estas fases se descompone en iteraciones, las cuales poseen un flujo de trabajo, el cuál se puede ver en la siguiente figura. Figura Nº 41: Flujo de trabajo de UP

Requisitos

Modelo de casos de uso

Análisis

Modelo de análisis Diseño

Modelo de diseño Implementación

Modelo de implementación Prueba

Modelo de prueba

Fuente: [Elaboración propia]

110 de 243

La cantidad de iteraciones dependen de la complejidad del proyecto.

3.3.4.2 Fase de inicio Primera iteración: Cuentas de usuario e inicio de sesión Análisis de requerimientos 

Requerimientos funcionales -



Creación y gestión de cuentas de usuario.

Requerimientos no funcionales -

Debe estar orientado a la web

Utilizar arquitectura cliente servidor de 3 capas para estructurar el incremento.

Modelo de casos de uso Describe la funcionalidad del sistema propuesto mediante actores y casos de uso. 



Identificación de actores: Los actores que participan en este incremento son: -

Administrador de instituto

Usuario estudiante

Descripción de actores: Los actores se describen a continuación: 

Administrador de instituto: Generalmente es el director académico del Instituto Ing Data Comp. En este incremento tiene las siguientes funciones en el sistema de inscripción: -



Gestión de cuentas de usuario.

Usuario estudiante: Es la persona que puede acceder al sistema mediante una cuenta de usuario. Así mismo puede gestionar su cuenta de usuario (Editar y cancelar la cuenta)



Diagramas de caso de uso: Los casos de uso muestran las funcionalidades, actividades y tareas que tiene el sistema. En este incremento se ha realizado el diagrama de casos de uso de la gestión de usuario, el cual se muestra a continuación.

111 de 243



Caso de uso: Crear cuenta usuario Figura Nº 42: Diagrama de caso de uso: Crear cuenta usuario

Crear cuenta de usuario Administrador de instituto

<<exclude>>

Gestionar cuenta de usuario

Usuario estudiante

Fuente: [Elaboración propia]



Escenario de caso de uso: A continuación se muestra una especificación del caso de uso crear cuenta usuario de acuerdo a su función y actores. Tabla Nº 8: Escenario: Crear cuenta usuario

Nombre de caso de uso:

Crear cuenta usuario

Actor:

Administrador, Usuario estudiante

Función:

Permitir crear cuentas de usuario para el acceso al sistema de inscripción

Descripción:

Administrador: Permitirá el registro de cuentas de usuario con los privilegios que el decida y la gestión de los mismos (editar, desactivar). Usuario estudiante: Permitirá la creación y gestión de la cuenta de usuario para ingresar al sistema. Fuente: [Elaboración propia]

112 de 243

Modelo de análisis Permite establecer la base para el diseño del sistema y la realización de los casos de uso 

Diagramas de colaboración: Muestran la interacción entre objetos que forman parte de la interacción y los enlaces entre los mismos a través de mensajes con un orden establecido para describir el comportamiento de la estructura estática y dinámica del sistema. 

Caso de uso: Crear cuenta de usuario Figura Nº 43: Diagrama de colaboración: Crear cuenta de usuario

1. Enviar datos nueva cuenta lec Se 5.

4. Enviar msj respuesta

r na c io

I.U. Crear cuenta de usuario

s to da

ón ci op

3 Enviar msj respuesta

Gestor cuenta 8 Enviar msj respuesta de de usuario opción

n c ió op

9. En re v iar sp m ue en st sa a je

Seleccionar opción

Administrador de instituto Usuario estudiante

7. Conectar con BD y enviar datos de opción 2. Conectar con BD y enviar datos

r ia nv E 6.

cuenta de usuario

I.U. Gestionar cuenta de usuario

Fuente: [Elaboración propia]

Modelo de diseño Describe la realización física de los casos de uso y crea una base al modelo de implementación. 

Diagramas de secuencia: Muestran la interacción de mensajes entre objetos en una secuencia temporal. Este diagrama se muestran a continuación:

113 de 243



Caso de uso: Crear cuenta de usuario Figura Nº 44: Diagrama de secuencia: Crear cuenta de usuario :IU Crear cuenta de usuario

:IU Gestionar cuenta de usuario

:Gestor cuenta de usuario

:Cuenta de usuario

Seleccionar opción Enviar datos nueva cuenta

Administrador de instituto Usuario estudiante

Conectar con la BD central y enviar datos Enviar mensaje de respuesta

Enviar mensaje de respuesta

Seleccionar opción Enviar datos opción

Enviar mensaje de respuesta

Enviar datos opción Enviar mensaje de respuesta

Fuente: [Elaboración propia]



Diagrama de clases del sistema: Permite ver las relaciones entre entidades de manera general, considerando la cardinalidad entre las mismas, el diagrama de base de datos se construirá el diagrama en diagrama aplicando reglas de normalización Figura Nº 45:

Diagrama de clases: Cuenta de usuario Cuenta de usuario nombre_usuario Password correo_electronico pregunta_de_seguridad respuesta_de_seguridad Tipo_usuario Estado Registrar_cuenta_usuario Buscar_cuenta_usuario Modificar/Eliminar

Fuente: [Elaboración propia]

114 de 243

base a este

En este único caso, para este incremento no existe relación de esta entidad con otra. 

Diseño de interfaces: La aplicación del modelo de diseño da resultado a las siguientes interfaces: Figura Nº 46: Diseño de interfaz: Crear cuenta de usuario

Fuente: [Elaboración propia]

Figura Nº 47: Diseño de interfaz: Gestionar cuenta de usuario

Fuente: [Elaboración propia]

115 de 243

Modelo de implementación Describe los elementos del modelo de diseño que se implementan en términos de componentes.  Diagrama de componentes: Representa los componentes del sistema, así como las dependencias entre los componentes de manera física. Figura Nº 48: Diagrama componentes: Cuenta de usuario Registro de cuenta de usuario Cuenta de usuario

Gestión de cuenta de usuario

Fuente: [Elaboración propia]

Pruebas Según la metodología UP en esta fase no se efectúan las pruebas.

3.3.4.3 Fase de elaboración Segunda iteración: Carreras y cursos Análisis de requerimientos 



Requerimientos funcionales -

Registro de carreras, cursos del instituto.

Asignación de descuentos por pago adelantado de semestre (carrera)

Asignación de pago por arrastre de materias (carrera)

Requerimientos no funcionales -

Debe estar orientado a la web

Utilizar arquitectura cliente servidor de 3 capas para la estructuración del incremento

116 de 243

Modelo de casos de uso A continuación se la funcionalidad del sistema según los actores y diagramas de caso de uso. 



Identificación de actores: Los actores que participan en este incremento son: -

Administrador de instituto

Usuario estudiante

Descripción de actores: Los actores se describen a continuación: 

Administrador de instituto: Tiene las siguientes funciones en este incremento: -

Creación y gestión de carreras o cursos del instituto e información referente a las mismas.



Usuario estudiante: Puede visualizar la información de las diferentes carreas y cursos del instituto para poder inscribirse a alguna de estas.



Diagramas de caso de uso: En este incremento se ha realizado el diagrama de casos de uso de la creación

de carreras y cursos, el cual se muestra a

continuación. 

Caso de uso: Crear carrera/curso Figura Nº 49: Diagrama de caso de uso: Crear carrera/curso

Crear carrera/curso Administrador

<<include>>

Visualizar carrera/curso

<<ex tend> >

<<include>>

Registrar plan académico

Gestionar carrera/curso

Fuente: [Elaboración propia]

117 de 243

Usuario Estudiante



Escenario de caso de uso: A continuación se muestra una especificación del caso de uso crear carrera/curso de acuerdo a su función y actores. Tabla Nº 9: Escenario: Crear carrera/curso

Nombre de caso de uso:

Crear carrera/curso

Actor:

Administrador de instituto, Usuario estudiante

Función:

Administrar carreras y cursos existentes en el instituto

Descripción:

Administrador de instituto: Permitirá añadir carreras, cursos con los semestres o meses respectivamente, las materias que corresponden a los mismos. Así mismo permite la asignación de descuentos y pago por arrastre de materias en las carreras. Finalmente permitirá la gestión de los mismos (Edición, eliminación) Usuario estudiante: Permitirá visualizar la información respecto a las carreras y cursos que cuenta el instituto para su próxima inscripción. Fuente: [Elaboración propia]

Modelo de análisis Dentro de este incremento, incluye los diagramas de colaboración. 

118 de 243



Caso de uso: Crear carrera/curso Figura Nº 50: Diagrama de colaboración: Crear carrera/curso

ion ar op c ió n 5. Se lec c

1. Enviar datos nueva carrera/curso c ele .S 10

4. Enviar msj respuesta

r na c io

I.U. Crear carrera/curso

7,12 Conectar con BD y enviar datos de opción 2. Conectar con BD y enviar datos

Gestor carrera/curso

n c ió op

11 .E nv iar 14 da .E to s nv op re ia c ió sp r m ue en n st sa a je

Seleccionar opción

Administrador de instituto Usuario estudiante

ión pc so ato rd je v ia sa En en 6. r m op v ia eta En u 9. res p

I.U. Registrar plan académ ico

3 Enviar msj respuesta 8,13 Enviar msj respuesta de opción

Carrera/curso

I.U. Gestionar carrera/curso

Fuente: [Elaboración propia]

Modelo de diseño Permite una realización física de los casos de uso en base al modelo de implementación. 

Diagramas de secuencia: Muestran la interacción de mensajes entre objetos en una secuencia temporal. Este diagrama se muestras a continuación:

119 de 243



Caso de uso: Crear carrera/curso Figura Nº 51: Diagrama de secuencia: Crear carrera/curso :IU Crear carrera/curso

:IU Registrar plan académico

:IU Gestionar carrera/curso

:Gestor carrera/curso

:Carrera/curso

Seleccionar opción Enviar datos nueva carrera/curso

Conectar con la BD central y enviar datos

Administrador de instituto Usuario estudiante Enviar mensaje de respuesta

Enviar mensaje de respuesta

Seleccionar opción

Enviar datos opción

Enviar mensaje respuesta de opción

Seleccionar opción

Enviar datos opción

Enviar mensaje de respuesta

Fuente: [Elaboración propia]

120 de 243

Conectar con la BD central y enviar datos de opción Enviar mensaje de respuesta



Diagrama de clases del sistema: La relación entre entidades que describe este diagrama considerando la cardinalidad entre las mismas, se muestra a continuación:

Figura Nº 52: Diagrama de clases: carrera/curso 1 Curso

1 *

Cod_curso Nombre Nivel Duración Detalle_duracion Turno Descripción Fecha_inicio Disponible Costo_matricula Costo_mensualidad

Registrar_curso Buscar_curso Modificar/Eliminar

Carrera

Cod_carrera Nombre Nivel Duración Detalle_duracion Turno Descripción Fecha_inicio Disponible Costo_matricula Costo_mensualidad Registrar_carrera Buscar_carrera Modificar/Eliminar

Turno

Mes

Codigo_turno tipo_turno estado_turno

Cod_mes Nombre_mes

Registrar_turno Buscar_turno Modificar/Eliminar

Registrar_mes Buscar_mes Modificar/Eliminar

Semestre

Cod_semestre año Nombre_semestre Registrar_semestre Buscar_semestre Modificar/Eliminar

Materia

Cod_materia Nombre_materia Registrar_materia Buscar_materia Modificar/Eliminar

Fuente: [Elaboración propia]

121 de 243



Diseño de interfaces: La aplicación del modelo de diseño da resultado a las siguientes interfaces Figura Nº 53: Diseño de interfaz: Gestionar carrera/curso

Fuente: [Elaboración propia]

122 de 243

Carrera/curso

Registro de carrera/curso

Gestión de carrera/curso Registro de plan académico

Fuente: [Elaboración propia]

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.3.4.4 Fase de construcción Tercera iteración: Inscripción de estudiantes a carreras y cursos e integración de módulos respectivos Análisis de requerimientos 



Requerimientos funcionales -

Integrar el resto de los módulos realizados al módulo de inscripción

Permitir la inscripción de estudiantes a las carreras o cursos.

Conocer el estado de pagos de estudiantes inscritos a carreras o cursos

Requerimientos no funcionales -

Debe ser orientado a la web

Utilizar arquitectura cliente servidor de 3 capas para estructurar el sistema.

123 de 243

Modelo de casos de uso A continuación se la funcionalidad del sistema según los actores y diagramas de caso de uso. 

Identificación de actores: Los actores que participan en el sistema inscripción de son:



Administrador de instituto

Usuario estudiante

Descripción de actores: Los actores se describen a continuación: 

Administrador de instituto: Tiene las siguientes funciones en este incremento: -

Gestión de cuentas de usuario.

Creación y gestión de carreras y cursos del instituto e información referente a los mismos

Visualizar reporte de los alumnos inscritos y su estado de pagos en las diferentes carreras y cursos en el instituto. Así mismo visualizar los estudiantes con deudas pendientes.



Usuario estudiante: Es la persona que puede ver la información respecto a la oferta académica del instituto, e inscribirse, tiene las siguientes funciones: -

Visualizar la información respecto a las carreras y cursos del instituto

Crear y gestionar su cuenta de usuario (Editar y cancelar la cuenta)

Puede inscribirse a alguna carrera o curso y gestionar su inscripción (Editar datos de inscripción y cancelar la misma)

En el caso de tener arrastre puede inscribirse solo a las materias que lo correspondan cursar.

Una vez que la persona se inscribe puede:  

Visualizar el estado de pagos (mensualidades pagadas y pendientes)

Diagramas de caso de uso: En este incremento se ha realizado el diagrama de casos de uso de la inscripción y el diagrama de casos de uso general del sistema; el resto de diagramas se incluye en los anteriores incrementos. Este diagrama se muestra a continuación.

124 de 243



Caso de uso: Realizar inscripción Figura Nº 55: Diagrama de caso de uso: Realizar inscripción Realizar inscripción <<include>> << inc Seleccionar lud e> > carrera/curso

> lude> <<inc

>> nd te ex <<

Reportes de inscripción

<<include>>

Registrar estudiante

Gestionar inscripción

Administrador de instituto

Usuario estudiante

Visualizar estado de pagos

Fuente: [Elaboración propia]



Escenario de caso de uso: A continuación se muestra una especificación del caso de uso realizar inscripción de acuerdo a su función y actores. Realizar inscripción. Tabla Nº 10: Escenario: Realizar inscripción

Nombre de caso de Realizar inscripción uso: Actor:

Administrador, Usuario estudiante

Función:

Inscribir estudiantes a carreras o cursos y obtener información de las inscripciones realizadas

Descripción:

Administrador: Permitirá ver los reportes de alumnos inscritos a las carreras y cursos del instituto con los datos del estudiante y el estado de pagos de los estudiantes. Usuario estudiante: Permitirá inscribirse a alguna carrera o curso o materias separadas (caso de arrastre) del instituto con el registro de datos del estudiante, así mismo editar los detalles de la inscripción y cancelarla. Una vez inscrito podrá ver su estado de pagos. Fuente: [Elaboración propia]

125 de 243



Diagrama de casos de uso general (Sistema de inscripción): Describe las funcionalidades del sistema desde el punto de vista del usuario. En este diagrama se muestra la integración de los anteriores incrementos al módulo de inscripción: Figura Nº 56: Diagrama de caso de uso general: Sistema de inscripción Ingresar al sistema

Crear cuenta de usuario <<extend>>

> i>

> e> lud inc < <

Administrador de instituto

<< inc lud e> >

Crear carrera/curso

<< ex ten d> >

Registrar plan académico

Gestionar carrera/curso

Realizar inscripción > lude> <<inc

ini <<

Usuario estudiante

<<include>> Seleccionar

carrera/curso <<inc lude> > Registrar << ex estudiante te nd >>

> e> lud inc <<

Reportes de inscripción

Visualizar carrera/curso

<< in

in <<

ini <<

i> >

Gestionar cuenta de usuario

Gestionar inscripción

Visualizar estado de pagos

Fuente: [Elaboración propia]

Modelo de análisis En este incremento se establece la base para el diseño mediante los diagramas de colaboración.

126 de 243



Diagramas de colaboración: Muestran la interacción entre objetos que forman parte de la interacción y los enlaces entre los mismos a través de mensajes con un orden establecido. 

Caso de uso: Realizar inscripción Figura Nº 57: Diagrama de colaboración: Realizar inscripción

I.U. Visualizar estado de pagos

3. En v v e iar d rif ic ato ac s d ión e 6. E res nv ia pu r es ta

26. S elec c ionar opc ió 1. Se n lec c io na r

n c ió s op ato ta tos rd es da ia pu nv iar E es . nv rr .E aje 2 v ia 27 ns En me op 7. e iar nv s ta d .E 30 s pue re

15. Enviar mensaje respuesta

ar on ci on ci op

cc ele .S 21

os at rd ia v En

ón ci op

n c ió op ar ion

22 .E nv iar 2 da tos re 0. En 25 op s pu v iar .E c ión es ta ms res nv ia de j pu r m op es en ta s de aje op

ec el .S 16

I.U. Realizar inscripción

. 17

I.U. Gestionar inscripción

Carrera/curso

18, 23, 28. Conectar con la BD y enviar datos opción

13. Conectar con BD y enviar datos

8. Enviar datos nueva inscripción

Seleccionar opción

Administrador de instituto Usuario estudiante

Seleccionar carrera/curso

4. Verificar datos 5. Enviar respuesta Gestor carrera/curso

Gestor 14. Enviar msj respuesta inscripción 19, 24, 29. Enviar msj respuesta de opción Inscripción 9. En v e v ia c o 12. rif r d nf En ic at irm v i ac os ac ar ió n de ió n 10. Verificar datos

11. Enviar confirmación Gestor cuenta Cuenta de de usuario usuario

I.U Reportes de inscripción

Fuente: [Elaboración propia]

Modelo de diseño Permite una realización física de los casos de uso en base al modelo de implementación. 

Diagramas de secuencia: Muestran la interacción de mensajes entre objetos en una secuencia temporal. Este diagrama se muestras a continuación:

127 de 243



Caso de uso: Realizar inscripción Figura Nº 58: Diagrama de secuencia: Realizar inscripción :IU Realizar inscripción

:IU Gestionar inscripción

:IU Reportes de inscripción

:Seleccionar carrera/curso

:IU Ver estado de pagos

:Gestor inscripción

:Gestor carrera/curso

:Carrera/curso

:Gestor cuenta de usuario

:Cuenta de usuario

:Inscripción

Seleccionar opción

Administrador de instituto Usuario estudiante

Enviar datos de selección

Enviar datos de verificación

Enviar datos de selección

Verificar datos Enviar respuesta

Enviar respuesta Enviar respuesta de disponibilidad

Enviar datos nueva inscripción (datos estudiante)

Enviar datos de inscripción

Verificar datos Enviar confirmación Enviar confirmación

Conectar con la BD central y enviar datos Enviar mensaje respuesta

Enviar mensaje respuesta

Seleccionar opción Enviar datos opción Enviar mensaje respuesta de opción

Seleccionar opción

Enviar datos opción Enviar mensaje respuesta de op.

Seleccionar opción

Enviar datos opción

Conectar con la BD central y enviar datos opción

Enviar mensaje respuesta de op.

Fuente: [Elaboración propia]

128 de 243

Enviar msj respuesta de opción



Diagrama de clases del sistema: Permite ver las relaciones entre entidades de manera general, considerando la cardinalidad entre las mismas, el diagrama de base de datos se construirá en base a este diagrama. Figura Nº 59: Diagrama de clases del sistema de inscripción * *

Estado de pagos pendientes

Codigo_estado_pagos_efectuados monto_pagado detalle_monto año semestre mes

Codigo_estado_pagos_pendientes monto_pendiente detalle_monto año semestre mes

* 1

Cod_curso Nombre Nivel Duración Detalle_duracion Turno Descripción Fecha_inicio Disponible Costo_matricula Costo_mensualidad Registrar_curso Buscar_curso Modificar/Eliminar

1 Cuenta de usuario nombre_usuario Password correo_electronico pregunta_de_seguridad respuesta_de_seguridad Tipo_usuario Estado Registrar_cuenta_usuario Buscar_cuenta_usuario Modificar/Eliminar

Registrar_estado_pagos Ver_estado_pagos

Curso

Estado de pagos efectuados

1 Inscripción CI Apellido_paterno Apellido_materno Nombres Telefono_celular Dirección Estado

Registrar_inscripción Buscar_inscripción Modificar/Cancelar Visualizar_inscripción

1 1

Carrera Cod_carrera Nombre Nivel Duración Detalle_duracion Turno Descripción Fecha_inicio Disponible Costo_matricula Costo_mensualidad Registrar_carrera Buscar_carrera Modificar/Eliminar

Semestre

Materia

Cod_semestre año Nombre_semestre

Cod_materia Nombre_materia

Registrar_semestre Buscar_semestre Modificar/Eliminar

Registrar_materia Buscar_materia Modificar/Eliminar

Mes

Cod_mes Nombre_mes Registrar_mes Buscar_mes Modificar/Eliminar

1 1

Turno Codigo_turno tipo_turno estado_turno Registrar_turno Buscar_turno Modificar/Eliminar

Fuente: [Elaboración propia]

129 de 243



Diseño de base de datos del sistema de inscripción Figura Nº 60: Diagrama de base de datos del sistema de inscripción

Fuente: [Elaboración propia]

130 de 243



Diseño de interfaces: La aplicación del modelo de diseño da resultado a las siguientes interfaces

Figura Nº 61: Diseño de interfaz: Interfaz principal del sistema de inscripción

Fuente: [Elaboración propia]

Figura Nº 62: Diseño de interfaz: Iniciar sesión

Fuente: [Elaboración propia]

131 de 243

Figura N潞 63: Dise帽o de interfaz: Efectuar inscripci贸n

Fuente: [Elaboraci贸n propia]

132 de 243

Modelo de implementación Describe los elementos del modelo de diseño que se implementan en términos de componentes.  Diagrama de componentes: Representa los componentes del sistema, así como las dependencias entre los componentes de manera física. Figura Nº 64: Diagrama componentes: Sistema de inscripción Registro de cuenta de usuario

Seleccion de usuario

Gestor de inscripción

Realizar inscripción

Reporte de inscripción

Registro de estudiante

Selección de carrera/curso

Carrera/curso

Registro de carrera/curso

Cuenta de usuario

Gestion de cuenta de usuario

Estudiante

Gestion de carrera/curso Registro de plan académico

Fuente: [Elaboración propia]

Implementación del sistema de inscripción: La implementación ha sido efectuado en base a todo el diseño realizado en las anteriores iteraciones. 

Interfaz principal: La siguiente interfaz implementada es la página principal del sistema de inscripción mediante la cuál se puede acceder al mismo.

133 de 243

Figura Nº 65: Interfaz principal del sistema

Fuente: [Elaboración propia]



Acceso al sistema de inscripción: Esta interfaz permite a los usuarios el acceso al sistema para la visualización de opciones de acuerdo a su tipo de usuario y también permite el registro de nuevas cuentas de usuario. La interfaz de acceso se muestra a continuación: Figura Nº 66: Interfaz de inicio de sesión

Fuente: [Elaboración propia]



Gestión de cuentas de usuario: Esta interfaz permite editar y eliminar las cuentas de usuario existentes en el sistema de inscripción, como se puede ver a continuación:

134 de 243

Figura Nº 67: Interfaz de gestión de cuentas de usuario

Fuente: [Elaboración propia]



Creación de carrera/curso: Permite registrar carreras o cursos en el instituto del estudiante mediante un formulario de registro, como se muestra a continuación:

135 de 243

Figura Nº 68: Interfaz de creación de carrera/curso

Fuente: [Elaboración propia]



Creación de plan académico: Permite registrar materias respectivas a cada semestre (en el caso de una carrera) y mes (en el caso de un curso), así mismo permite la generación las fechas de pago de una carrera o curso determinado, también permite la asignación de descuentos por pago de la totalidad de un semestre y montos específicos para los arrastres de materias, como se puede ver en la siguiente figura:

136 de 243

Figura Nº 69: Interfaz: Registrar plan académico

Fuente: [Elaboración propia]



Gestión de carreras o cursos: Permite realizar búsquedas de las carreras o cursos registrados mediante diferentes opciones. Así mismo permite editarlas (mediante una interfaz auxiliar) y eliminarlas. También permite la gestión de las materias de cada carrera o curso (pensum), turnos, descuentos, arrastres y fechas de pago, como se muestra a continuación: Figura Nº 70: Interfaz: Gestionar carrera/curso

137 de 243

Fuente: [Elaboraci贸n propia]

138 de 243



Inscripción de estudiantes: Permite registrar los datos del estudiante cuando se realiza una inscripción a algún curso o carrera mediante un formulario, como se muestra a continuación: Figura Nº 71: Interfaz de registro de datos de estudiante

Fuente: [Elaboración propia]

139 de 243



Gestionar inscripción: Permite visualizar el detalle de la inscripción efectuada, mediante distintos criterios de búsqueda. Así mismo permite cancelar la misma. La implementación se muestra en la siguiente figura. Figura Nº 72: Gestionar inscripción

Fuente: [Elaboración propia]

140 de 243

Pruebas 

Pruebas unitarias: Las pruebas unitarias, implican se pueda comprobar el correcto procesamiento en la lógica de cada módulo que conforma el sistema en general. Estas pruebas se han efectuado mediante de casos de prueba.

Se ha creado casos de prueba utilizando el Framework NUnit (Ver Anexo K: Pruebas del sistema) mediante los cuales se han efectuado las pruebas unitarias a cada componente del sistema de inscripción. Así mismo este NUnit posee una interfaz visual mediante la cuál realizar las pruebas. Los resultados se muestran en la siguiente figura: Figura Nº 73: Pruebas unitarias: Sistema de inscripción

Fuente: [Elaboración propia]

Las pruebas realizadas a cada componente del sistema de inscripción se han efectuado sin errores.

141 de 243

3.3.4.5 Fase de transición Cuarta iteración: Pruebas al sistema de inscripción Análisis de requerimientos En esta fase a no se describen nuevos requerimientos, más al contrario ya deben cumplirse los requerimientos establecidos. Modelo de casos de uso Ya no se realiza ningún caso de uso en esta fase y los actores ya están establecidos en las anteriores fases. Modelo de análisis Según la metodología UP el análisis concluye en la anterior fase del ciclo de vida. Modelo de diseño Según la metodología UP el diseño concluye en la anterior fase del ciclo de vida. Modelo de implementación La implementación ya se ha efectuado en la fase de construcción Pruebas Las pruebas efectuadas al sistema de inscripción son las siguientes: 

Pruebas funcionales: Permiten probar el funcionamiento correcto de los componentes de este incremento mediante la siguiente tabla: Tabla Nº 11: Pruebas funcionales: Sistema de inscripción

Caso de

Datos de Entrada

uso

Resultado

Resultado Esperado

Obtenido

El usuario debe ingresar  El sistema despliega la página de inicial de acuerdo en un formulario de inicio Ingresar al Sistema

sesión

sus

datos

al tipo de usuario que ha

(login/password) para ser

iniciado

autenticado

sistema.

presiona

botón “Iniciar sesión”.

142 de 243

sesión

Satisfactorio

 En caso de que el usuario no es autenticado el sistema retorna

mensaje

Satisfactorio

datos de usuario incorrecto  Crear

cuenta

usuario:

Administrador de instituto ingresa

los

datos

 La cuenta de usuario es creada

muestra

Satisfactorio

mensaje de confirmación

mediante el formulario de registro.  Los datos de la cuenta de

Crear cuentas de

 Gestionar

Usuario

usuario:

cuenta

usuario son modificados y

administrador de instituto gestiona

las

muestra

mensaje

Satisfactorio

confirmación

cuentas  En caso de deshabilitar la

existentes

(editar,

cuenta,

esta

cambia

deshabilitar) ingresando

estado en de la base de

un criterio de búsqueda.

datos y se muestra mensaje

Satisfactorio

de confirmación  Crear carrera/curso: El de

 La carrera/curso es creada

instituto crea la carrera o

y se muestra mensaje de

curso en el formulario de

confirmación.

Administrador

Satisfactorio

registro.  Registrar

plan

Crear

académico:

carrera/curso

administrador

instituto selecciona una carrera/curso e ingresa las

materias

correspondientes,

 El plan académico de la carrera/curso

creado

como también el registro de las fechas de pago. Los descuentos y arrastres son registrados correctamente y se muestra mensaje de

también puede generar

confirmación

las fechas de pagos de

143 de 243

Satisfactorio

carrera

seleccionado,

curso asignar

descuentos por pago de semestre

arrastre

pago

materias

para las carreras.  La carrera/curso es editada

 Gestionar carrera/curso:

administrador

instituto

ingresa

criterio de búsqueda y luego

gestiona

las

carreras/cursos existentes

correctamente y se muestra

Satisfactorio

mensaje de confirmación

 La

carrera/curso

eliminada y se muestra

Satisfactorio

mensaje de confirmación (editar,

eliminar).  Realizar inscripción: El estudiante

 La inscripción es registrada

selecciona una carrera o

y se muestra mensaje de

curso,

materias

confirmación en el que se

separadas (arrastre) a

incluye la fecha límite de

continuación ingresa sus

pago

datos en el formulario de

puntos donde se puede

registro (si se inscribe

realizar los pagos.

usuario

Realizar inscripción

los

Satisfactorio

diferentes

por primera vez)  Gestionar inscripción: El usuario ingresa su ci, para

 La inscripción es editada o

alguna

cancelada y se muestra

visualizar

inscripción

carrera o curso y poder

Satisfactorio

mensaje de confirmación.

gestionarla(editar datos y cancelar inscripción)  Reportes inscripción:

 De acuerdo a la selección de El

del reporte específico, se visualizan los reportes.

144 de 243

Satisfactorio

administrador

instituto selecciona un reporte.  Visualizar pagos:

estado El

usuario

estudiante ingresa su ci, para visualizar el estado de

pagos

 El estado de pagos es visualizado ingresado

una el

vez

del

Satisfactorio

estudiante.

carrera/curso en la que esté inscrito. Fuente: [Elaboración propia]

3.3.5 Identificación y selección de servidor de aplicaciones y servidor de base de datos 3.3.5.1 Análisis de selección de servidor de aplicaciones La tabla que se muestra a continuación muestra una comparación de características importantes para la selección del servidor de aplicaciones (web) de acuerdo a la compatibilidad con los lenguajes de programación seleccionados en el marco teórico. Tabla Nº 12: Selección de servidor de aplicaciones IIS

Tomcat

Apache

Es open source

Posee interfaz de

No posee interfaz de

administración sencilla de

administración sencilla

administración, se debe

utilizar para el usuario

de utilizar

descargar aparte

Es privativo y requiere licencia

Fácil instalación y sin problemas

Instalación puede tener problemas. Requiere el JDK de Java

145 de 243

Instalación puede tener problemas

Soporte a middleware de

base de datos (ODBC y

base de datos (ODBC)

JDBC)

Requiere instalación por separado de middleware Administración de

Administración de servicios

Administración es más

es sencilla mediante la

compleja y a veces

interfaz de IIS

presenta errores

Soporte de páginas Asp.net

Soporte a páginas JSP

Es compatible con tomcat y

Es compatible con IIS y

apache

Apache

Tomcat

servicios es más compleja usualmente existen problemas Soporte de lenguajes perl, python y php

Fuente: [Elaboración propia]

Proceso de selección: De acuerdo a la descripción de características de los servidores de aplicaciones en la anterior tabla, por la facilidad de instalación, presencia de interfaz de usuario y administración sencilla, se ha seleccionado a IIS como servidor de aplicaciones para este trabajo.

3.3.5.2 Análisis de selección de servidor de base de datos El servidor de base de datos permitirá gestionar la información almacenada en la base de datos del instituto, por este motivo es importante la elección del servidor adecuado. La tabla que se muestra continuación describe las ventajas y desventajas así como el criterio personal de selección de los gestores de base de datos elegidos en el marco teórico. Tabla Nº 13: Selección de gestor de base de datos Gestor de base de datos

Características  Escalabilidad,

Sql Server

seguridad.

Criterio de valoración

estabilidad,  Administración motor y la

 Posee entorno gráfico para la administración del motor de BD

146 de 243

mediante que posee.

las

sencilla

del

configuración herramientas

 Permite administrar otras bases  Permite de datos, previa configuración.

BD y gestión de seguridad mediante

Microsoft Windows. conectarse

gestores

bases

administración de réplicas de

 Requiere de un sistema operativo  Permite

creación

con

otros

datos

manejador

gráfico

mediante middleware específicos.  Sencillez de uso, es gratuito.  Multiplataforma. Alto rendimiento

 Alto nivel

Soporte a las transacciones

en sistemas UNIX. PostgreSQL

 Permite

de seguridad,

es estable, la administración

programación

funciones.

réplica

suele

tener

problemas y es necesario

 Requiere la instalación de un

instalar

middleware para acceder a la BD

parches

para

subsanar este problema.

por lenguajes de programación  Bajo costo en requerimientos de

 El soporte a las transacciones

hardware.

en varias ocasiones falla.

 Multiplataforma MySQL

 Requiere

 La interfaz de administración

middleware

para

acceso a la BD por lenguajes de

no es intuitiva  El nivel de seguridad no es

programación  Bajo costos en requerimientos.

medio.

Fuente: [Elaboración propia]

Proceso de selección: De acuerdo a la escalabilidad, estabilidad, alta seguridad, soporte de transacción y replica de base de datos asi como también facilidad de administración mediante el gestor gráfico, es seleccionado SQL server como gestor de base de datos.

147 de 243

3.4 DESARROLLO DEL MÓDULO DE FACTURACIÓN CON ENLACE EN LÍNEA APLICANDO INTERMEDIACIÓN FINANCIERA 3.4.1 Aplicar las etapas de la metodología elegida al módulo de facturación Tomando en cuenta la identificación de fases y flujos de trabajo visto en la sección 3.3.4.1 se ha desarrollado el módulo de facturación cumpliendo la metodología UP.

3.4.1.1 Fase de inicio Primera iteración: Creación de entidades financieras Análisis de requerimientos 

Requerimientos funcionales -

Registro de entidades financieras y sus agencias.

La conexión debe ser efectuada hacia la base de datos replica situada en el instituto.

Requerimientos no funcionales -

Utilizar arquitectura cliente servidor de 3 capas para estructurar el sistema.

Modelo de casos de uso 

Identificación de actores: Los actores que participan en el sistema de facturación son: -



Administrador de entidad financiera

Descripción de actores: Los actores se describen a continuación: 

Administrador de instituto: En este incremento tiene las siguientes funciones: -



Creación y gestión de entidades financieras y sus agencias.

Diagramas de casos de uso: Los casos de uso por actor muestran las funcionalidades, actividades y tareas que tiene cada actor en el sistema.

148 de 243



Caso de uso: Crear entidad financiera Figura Nº 74: Diagrama de caso de uso: Crear entidad financiera

Crear entidad financiera Administrador de instituto

<<extend>>

Gestionar entidad financiera

Fuente: [Elaboración propia]



Escenario de caso de uso: Crear entidad financiera Tabla Nº 14: Escenario: Crear entidad financiera

Nombre de caso de uso:

Crear entidad financiera

Actor:

Administrador de instituto

Función:

Permitir crear entidades financieras y sus agencias

Descripción:

Administrador de instituto: Permite el registro de entidades financieras y sus respectivas agencias para su posterior asignación a las credenciales de usuarios que se van a crear. Así mismo permite la gestión de las mismas (editar, eliminar). Fuente: [Elaboración propia]

Modelo de análisis Permite establecer la base para el diseño del sistema y la realización de los casos de uso. 

Diagramas de colaboración: Los diagramas que pertenecen a este modelo se muestran a continuación:

149 de 243



Caso de uso: Crear entidad financiera Figura Nº 75: Diagrama de colaboración: Crear entidad financiera 7. Conectar con BD y enviar datos de opción 2. Conectar con BD y enviar datos

1. Enviar datos nueva entidad financiera

ar on ci

6. En vi ar da to s

4. Enviar msj respuesta

c le Se 5.

I.U. Crear entidad financiera

op ci ón

Seleccionar opción

Gestor entidad e j s a financiera

3 Enviar msj respuesta 8 Enviar msj respuesta de opción

Entidad financiera

ón ci op

en m ta ar ues i v p En es 9. r

I.U. Gestionar entidad financiera

Fuente: [Elaboración propia]

Modelo de diseño Describe la realización física de los casos de uso y crea una base al modelo de implementación. 

Diagramas de secuencia: Muestran la interacción de mensajes entre objetos en una secuencia temporal. Estos diagramas se muestran a continuación:  Caso de uso: Crear entidad financiera Figura Nº 76: Diagrama de secuencia: Crear entidad financiera :IU Crear entidad financiera

:IU Gestionar entidad financiera

:Gestor entidad financiera

:Entidad financiera

Seleccionar opción Enviar datos nueva entidad financiera

Administrador de entidad financiera

Conectar con la BD replica y enviar datos

Enviar mensaje de respuesta

Seleccionar opción Enviar datos opción

Enviar mensaje de respuesta

Fuente: [Elaboración propia]

150 de 243

Conectar con la BD replica y enviar datos Enviar mensaje de respuesta



Diagrama de clases del sistema: El diagrama de clases permite ver las relaciones entre entidades de manera general, considerando la cardinalidad entre las mismas. El diagrama de base de datos será construido en base a este diagrama. En este incremento las entidades que corresponden al diagrama se muestran en la siguiente figura: Figura Nº 77: Diagrama de clases: Entidad financiera

Fuente: [Elaboración propia]



Diseño de interfaces: La aplicación del modelo de diseño da resultado a las siguientes interfaces: Figura Nº 78: Diseño de interfaz: Crear entidad financiera y agencia

Fuente: [Elaboración propia]

151 de 243

Entidad financiera

Selección de entidad financiera y agencia

Fuente: [Elaboración propia]

Pruebas Según la metodología UP en esta fase no se efectúan las pruebas.

3.4.1.2 Fase de elaboración Segunda iteración: Creación de credenciales de usuario y registro de datos de dosificación. Análisis de requerimientos 

Requerimientos funcionales -

Registro de credenciales de usuario que permitan el acceso al módulo de facturación y estén asociados a una agencia de una entidad financiera.

Registro de datos de dosificación, para la emisión de las facturas.

La conexión debe ser efectuada hacia la base de datos replica situada en el instituto.

Requerimientos no funcionales -

Utilizar arquitectura cliente servidor de 3 capas para estructurar el sistema.

152 de 243

Modelo de casos de uso 

Identificación de actores: Los actores que participan en el sistema de facturación son:



Administrador de entidad financiera

Administrador de instituto

Descripción de actores: Los actores se describen a continuación: 

Administrador de instituto: En este incremento tiene las siguientes funciones: -

Creación y gestión de credenciales de usuario para el Administrador de la entidad financiera y funcionarios de caja.

Registro y gestión de datos de dosificación en el sistema cada vez que se requiera.



Administrador de entidad financiera: Es el jefe de sistemas o equivalente de la entidad financiera, el cual tiene las siguientes funciones dentro del sistema: 

Gestión de credenciales de usuario de los funcionarios de caja (Desactivación y cambio de contraseñas).



Diagramas de casos de uso: Los casos de uso por actor muestran las funcionalidades, actividades y tareas que tiene cada actor en el sistema. 

Caso de uso: Crear cuenta de usuario Figura Nº 80: Diagrama de caso de uso: Crear credencial de usuario

Crear credencial de usuario Administrador de instituto

<<extend>>

Gestionar credencial de usuario

Administrador de entidad financiera Fuente: [Elaboración propia]

153 de 243



Escenario de caso de uso: Crear credencial de usuario Tabla Nº 15: Escenario: Crear credencial de usuario

Nombre de caso de uso:

Crear credencial de usuario

Actor:

Administrador de instituto, Administrador de entidad financiera

Función:

Permitir crear credenciales de usuario para el acceso al sistema de facturación

Descripción:

Administrador de instituto: Permite el registro de cuentas de usuario y la gestión de los mismos (editar, deshabilitar). Administrador de entidad financiera: Permite la gestión de las credenciales de usuario de los funcionarios de caja. Fuente: [Elaboración propia]



Caso de uso: Registrar datos de dosificación.

Figura Nº 81: Diagrama de caso de uso: Registrar datos de dosificación

Registrar datos de dosificación Administrador de instituto

<<extend>>

Gestionar datos de dosificación

Fuente: [Elaboración propia]

154 de 243



Escenario de caso de uso: Registrar datos de dosificación Tabla Nº 16: Escenario: Registrar datos de dosificación

Nombre de caso de uso:

Registrar datos de dosificación

Actor:

Administrador de instituto

Función:

Permitir registrar los datos de dosificación cada vez que se requiera en el sistema.

Descripción:

Administrador de instituto: Permitirá el registro de datos de dosificación (Nro autorización, llave para el código de control, etc) así mismo gestionar estos datos. Fuente: [Elaboración propia]

Modelo de análisis Permite establecer la base para el diseño del sistema y la realización de los casos de uso. Diagramas de colaboración: Los diagramas que pertenecen a este modelo se muestran a continuación: 

Caso de uso: Crear credencial de usuario

Figura Nº 82: Diagrama de colaboración: Crear credencial de usuario

3 Enviar msj respuesta

4. Enviar msj respuesta

r na c io

I.U. Crear credencial de usuario

lec Se 5.

Adm. de instituto y entidad financiera

7. Conectar con BD y enviar datos de opción 2. Conectar con BD y enviar datos

1. Enviar datos nueva credencial

Seleccionar opción

n c ió op

6. En v ia rd 9. at os En v op re iar c ió sp m n ue en st sa a je



8 Enviar msj respuesta de Credencial de Gestor usuario opción credencial de usuario

I.U. Gestionar credencial de usuario

Fuente: [Elaboración propia]

155 de 243



Caso de uso: Registrar datos de dosificación

Figura Nº 83: Diagrama de colaboración: Registrar datos de dosificación

Seleccionar opción

3 Enviar msj respuesta

4. Enviar msj respuesta

ón Gestor datos 8 Enviar msj respuesta de Datos de ci de dosificación op opción dosificación s je to sa da en a ar i v r m st En ia ue 6. nv s p E e 9. r

r na c io

I.U. Registrar datos de dosificación

lec Se 5.

Adm. de instituto y entidad financiera

7. Conectar con BD replica y enviar datos de opción 2. Conectar con BD y enviar datos

1. Enviar datos nuevos datos de dosificación

n c ió op

I.U. Gestionar datos de dosificación

Fuente: [Elaboración propia]

Modelo de diseño Describe la realización física de los casos de uso y crea una base al modelo de implementación. 

Diagramas de secuencia: Muestran la interacción de mensajes entre objetos en una secuencia temporal. Estos diagramas se muestran a continuación:  Caso de uso: Crear credencial de usuario Figura Nº 84: Diagrama de secuencia: Crear credencial de usuario :IU Crear credencial de usuarrio

:IU Gestionar credencial de usuarrio

:Gestor credencial de usuarrio

:Credencial de usuarrio

Seleccionar opción Enviar datos nuevo credencial

Administrador de instituto Administrador de entidad financiera

Conectar con la BD réplica y enviar datos Enviar mensaje de respuesta

Enviar mensaje de respuesta

Seleccionar opción Enviar datos opción

Enviar mensaje de respuesta

Fuente: [Elaboración propia]

156 de 243

Conectar con la BD réplica y enviar datos Enviar mensaje de respuesta

 Caso de uso: Registrar datos de dosificación Figura Nº 85: Diagrama de secuencia: Registrar datos de dosificación :IU Gestionar datos de dosificación

:IU Registrar datos de dosificación

:Gestor datos de dosificación

:Datos de dosificación

Seleccionar opción

Administrador de entidad financiera

Enviar datos nueva dosificación Conectar con la BD replica y enviar datos Enviar mensaje de respuesta

Enviar mensaje de respuesta

Seleccionar opción Enviar datos opción

Enviar mensaje de respuesta

Conectar con la BD replica y enviar datos Enviar mensaje de respuesta

Fuente: [Elaboración propia]



157 de 243

Figura N潞 86:

Diagrama de clases: Entidad financiera, credencial de usuario y datos de dosificaci贸n

Fuente: [Elaboraci贸n propia]

158 de 243



Diseño de interfaces: La aplicación del modelo de diseño da resultado a las siguientes interfaces: Figura Nº 87: Diseño de interfaz: Crear credencial de usuario

Fuente: [Elaboración propia]

Figura Nº 88: Diseño de interfaz: Registrar datos de dosificación

Fuente: [Elaboración propia]

159 de 243

Diagrama componentes: Entidad financiera, credencial de usuario y datos de dosificación

Entidad financiera

Datos de dosificación Dosificación vigente

Selección de entidad financiera y agencia

Registro de credencial de usuario

Credencial de usuario

Gestión de de credencial de usuario

Fuente: [Elaboración propia]

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.

160 de 243

3.4.1.3 Fase de construcción Tercera iteración: Realizar pagos e integración del módulo de facturación Análisis de requerimientos 

Requerimientos funcionales -

Integración de los módulos realizados en el anterior incremento al módulo de facturación

Permitir consultar los datos de inscripción de estudiantes en el sistema de inscripción.

Cumplir con las normativas de facturación mediante sistemas informáticos.

Registro de pagos por inscripción o por mensualidades

Registro de pagos por materias separadas (si existe arrastre de materias)

Permitir la emisión de facturas impresa por concepto de los pagos mencionados.

Visualizar los pagos realizados en la entidad financiera referente a los pagos mencionados mediante reportes

El módulo debe estar conectado a una Base de datos replica situada en el instituto.



Requerimientos no funcionales -

Utilizar arquitectura cliente servidor de 3 capas para estructurar el incremento.

Modelo de casos de uso A continuación se la funcionalidad del sistema según los actores y diagramas de caso de uso. 

Identificación de actores: Los actores que participan en el módulo de facturación son: -

Administrador de instituto

Administrador de entidad financiera

Funcionario de caja

161 de 243



Descripción de actores: Los actores se describen a continuación: 

Administrador de instituto: Es la persona encargada de administrar en su totalidad el módulo de facturación. Es el encargado de sistemas del instituto y tiene las siguientes funciones: -

Creación y gestión de entidades financieras y sus agencias.

Creación y gestión de credenciales de usuario para el Administrador de la entidad financiera y funcionarios de caja.

Registro y gestión de datos de dosificación en el sistema cada vez que se requiera.

Visualizar los pagos efectuados en las agencias de la entidad financiera mediante reportes.



Administrador de entidad financiera: Es el jefe de sistemas o equivalente de la entidad financiera, el cual tiene las siguientes funciones dentro del sistema: 

Gestión de credenciales de usuario de los funcionarios de caja (Desactivación y cambio de contraseñas)



Visualizar los pagos efectuados en las diferentes agencias de la entidad financiera mediante reportes.



Funcionario de caja: Es la persona encargada de recibir dinero del pago de matrículas o mensualidades en un punto de pago. En el sistema de facturación puede: 

Consultar el detalle de inscripciones de estudiantes del instituto.



Registrar el pago de matrículas y mensualidades.



Emitir la factura impresa por concepto de pagos realizados.



Ver el reporte de los pagos registrados por el funcionario de caja en el sistema de facturación.



Diagramas de casos de uso: Los casos de uso por actor muestran las funcionalidades, actividades y tareas que tiene cada actor en el sistema.

162 de 243



Caso de uso: Realizar pago Figura Nº 90: Diagrama de caso de uso: Registrar pago

Registrar pago > lude> <<inc

Consultar inscripción

<< inc lud e> >

<<extend>>

Reporte de Pagos

Administrador de instituto

Funcionario de caja

Emitir factura

Administrador de entidad financiera

Fuente: [Elaboración propia]



Escenario de caso de uso: Registrar pago Tabla Nº 17: Escenario: Registrar pago

Nombre de caso de uso:

Registrar pago

Actor:

Administrador de instituto, Administrador de entidad financiera Funcionario de caja

Función:

Permitir registrar el pago por inscripción o pago de mensualidades y emitir la factura correspondiente

Descripción:

Administrador de instituto y de entidad financiera: Permitirá la visualización los pagos registrados en las agencias de la entidad financiera. Funcionario

caja:

Permitirá

consultar

las

inscripciones existentes para registrar el pago por concepto de inscripción o pago de mensualidades (también visualizar pagos realizados) y finalmente permitirá la emisión de factura impresa por el correspondiente pago registrado. Fuente: [Elaboración propia]

163 de 243



Diagrama de casos de uso general (Módulo de facturación): Describe las funcionalidades del sistema desde el punto de vista del usuario. Este diagrama se muestra la integración de los anteriores incrementos al módulo de facturación: Figura Nº 91: Diagrama de casos de uso general: Sistema de facturación Ingresar al sistema

Crear entidad financiera <<extend>>

in <<

i > <in i> <

i>> <<in

Gestionar entidad financiera Crear credencial de usuario <<extend>>

Registrar datos de dosificación <<extend>>

Administrador de entidad financiera

i> >

Gestionar credencial de usuario

<< in

Administrador de instituto

Funcionario de caja

Gestionar datos de dosificación Registrar pago <<include>>

Consultar inscripción

<<include>>

Emitir factura

<<include>>

Reporte de pagos

Fuente: Elaboración propia]

Modelo de análisis En este incremento se establece la base para el diseño mediante los diagramas de colaboración.

164 de 243



Diagramas de colaboración: Muestran la interacción entre objetos que forman parte de la interacción y los enlaces entre los mismos a través de mensajes con un orden establecido. 

Caso de uso: Ingresar al sistema Figura Nº 92: Diagrama de colaboración: Ingresar al sistema 1. Enviar usuario y contraseña

2. Verifficar datos de autenticación

3. Redireccionar a página principal ó recibir mensaje Gestor I.U. Ingresar al

3. Enviar respuesta

Credencial de usuario

credencial de usuario

sistema

Adm. de instituto y entidad financiera Funcionario de caja

Fuente: [Elaboración propia]



Caso de uso: Registrar pago Figura Nº 93: Diagrama de colaboración: Registrar pago 3. Conectar con la BD y enviar datos consulta

4. Enviar respuesta Gestor Inscripción

2. c o Env i ns a ulta r da ins tos c ri de pc ión 5. E n res v ia pu r es ta

9. Se lec c

ion ar op c ió n

n c ió op tos da iar aje nv ns .E me ión 10 c iar nv ta op .E 13 s pue re

I.U. Reporte de pagos

op c ió n

6.Visualizar datos inscripción 8. Enviar mensaje respuesta

7. Enviar msj respuesta Gestor pago

r na c io n c ió op

je sa en n ó m i ar c v i ma En nf ir . o 18 c

15 .E nv iar da to s

c ele .S 14

Adm. de instituto y entidad financiera Funcionario de caja

6 Conectar con BD y enviar datos nuevo pago

1. Enviar datos de consulta inscripción

I.U. Registrar pago

I.U. Em itir factura

Fuente: [Elaboración propia]

165 de 243

16. Imprimir factura

11. Conectar con la BD y enviar datos opción

7.Enviar datos de pago Seleccionar opción

Inscripción

17. Enviar msj confirmación

Pago

Modelo de diseño Permite una realización física de los casos de uso en base al modelo de implementación. 

Diagramas de secuencia: Muestran la interacción de mensajes entre objetos en una secuencia temporal. Este diagrama se muestras a continuación: 

Caso de uso: Ingresar al sistema Figura Nº 94: Diagrama de secuencia: Ingresar al sistema :IU Ingresar al sistema

:Gestor credencial de usuario

:Credencial de usuario

Seleccionar opción Enviar usuario y contraseña

Administrador de instituto Administrador de entidad financiera

Conectar a BD replica y verificar datos de autenticación

Enviar espuesta Redireccionar a pagina principal ó recibir mensaje

Fuente: [Elaboración propia]

166 de 243

 Caso de uso: Registrar pago Figura Nº 95: Diagrama de secuencia: Registrar pago :IU Registrar pago

:IU Reporte de pagos

:IU Emitir Factura

:Gestor pago

:Gestor inscripción

:Inscripción

:Pago

Seleccionar opción Ingresar datos de consulta inscripción

Funcionario de caja Administrador de instituto Administrador de entidad financiera

Enviar datos de consulta inscripción

Visualizar datos inscripción

Seleccionar y enviar datos de pago

Conectar con la BD réplica y enviar datos consulta Enviar respuesta

Enviar respuesta

Conectar con BD réplica y enviar datos nuevo pago

Enviar mensaje respuesta

Seleccionar opción Enviar datos opción

Conectar con la BD réplica y enviar datos opción

Enviar mensaje confirmación

Enviar mensaje respueta opción

Seleccionar opción Enviar datos opción

Imprimir factura

Enviar mensaje confirmación

Fuente: [Elaboración propia]



Diagrama de clases del sistema: Permite ver las relaciones entre entidades de manera general, considerando la cardinalidad entre las mismas, el diagrama de base de datos se construirá en base a este diagrama. Se ha integrado el módulo de inscripción y facturación en este diagrama el cuál se muestra a continuación:

167 de 243

Figura Nº 96: Diagrama de clases del sistema de inscripción y facturación *

Codigo_estado_pagos_efectuados monto_pagado detalle_monto año semestre mes

Codigo_estado_pagos_pendientes monto_pendiente detalle_monto año 1 semestre mes

Registrar_estado_pagos Ver_estado_pagos

1 *

Cuenta de usuario

1 Curso Cod_curso Nombre Nivel Duración Detalle_duracion Turno Descripción Fecha_inicio Disponible Costo_matricula Costo_mensualidad Registrar_curso Buscar_curso Modificar/Eliminar

nombre_usuario Password correo_electronico pregunta_de_seguridad respuesta_de_seguridad Tipo_usuario Entidad_financiera Agencia Registrar_credencial_usuario Buscar_credencial_usuario Modificar/Eliminar

codigo_entidad_financiera nombre_entidad_financiera Telefono Dirección Agencias

Registrar_entidad_financiera Buscar_entidad_financiera Modificar/Eliminar

1 1

Pago

* NroFactura Nro_correlativo_interno NroAutorización NIT Lugar Fecha Nombre Cantidad Concepto Precio_unitario Total Total_general Fecha_limite_emisión Codigo_control Numero_SFC Datos_dosificacion Credencial_Usuario Registrar_pago Buscar_pago Visualizar_pagos

Registrar_inscripción Buscar_inscripción Modificar/Cancelar Visualizar_inscripción

Entidad financiera

1 Inscripción

* CI Apellido_paterno Apellido_materno Nombres Telefono_celular Dirección Estado

nombre_usuario Password correo_electronico pregunta_de_seguridad respuesta_de_seguridad Tipo_usuario Estado Registrar_cuenta_usuario Buscar_cuenta_usuario Modificar/Eliminar

Credencial de usuario

Estado de pagos efectuados

Estado de pagos pendientes

Carrera Cod_carrera Nombre Nivel Duración Detalle_duracion Turno Descripción Fecha_inicio Disponible Costo_matricula Costo_mensualidad Registrar_carrera Buscar_carrera Modificar/Eliminar

1 Datos dosificación codigo_dosificacion numero_autorizacion llave_dosificacion fecha_ingreso fecha_limite_emision NIT_Instituto Estado_dosificación Entidad_financiera Registrar_entidad_financiera Buscar_entidad_financiera Modificar/Eliminar

Fuente: [Elaboración propia]

168 de 243

Semestre

Materia

Cod_semestre año Nombre_semestre

Cod_materia Nombre_materia

Registrar_semestre Buscar_semestre Modificar/Eliminar

Registrar_materia Buscar_materia Modificar/Eliminar

Mes

Cod_mes Nombre_mes Registrar_mes Buscar_mes Modificar/Eliminar

1 1

Turno Codigo_turno mañana tarde noche Registrar_mes Buscar_mes Modificar/Eliminar



Diseño de la base de datos del sistema (Inscripción y facturación)

Figura Nº 97:

Diagrama de base de datos: Sistema de inscripción y facturación

Fuente: [Elaboración propia]

169 de 243



Diseño de interfaces: La aplicación del modelo de diseño da resultado a las siguientes interfaces: Figura Nº 98: Diseño de interfaz: Crear entidad financiera y agencia

Fuente: [Elaboración propia]

Figura Nº 99: Diseño de interfaz: Registrar pago (Paso I)

Fuente: [Elaboración propia]

170 de 243

Figura Nº 100: Diseño de interfaz: Registrar pago (Paso II)

Fuente: [Elaboración propia]

Figura Nº 101: Diseño de interfaz: Reporte de pagos

Fuente: [Elaboración propia]

171 de 243

Modelo de implementación Describe los elementos del modelo de diseño que se implementan en términos de componentes.  Diagrama de componentes: Representa los componentes del sistema, así como las dependencias entre los componentes de manera física. En el siguiente diagrama se puede ver las relaciones entre componentes del módulo de inscripción y facturación Figura Nº 102: Diagrama componentes: Sistema de inscripción y facturación Datos de dosificación Dosificación vigente

Reporte de pagos

Emisión de factura

Factura

Entidad financiera

Registro de pago Seleccion de entidad financiera y agencia Seleccionar usuario

Credencial de usuario

Registrar pago Estado de pagos

Gestion de de credencial de usuario

Consultar inscripción

Registro de cuenta de usuario

Seleccion de usuario

Gestor de inscripción

Realizar inscripción

Reporte de inscripción

Carrera/curso

Registro de carrera/curso

Cuenta de usuario

Registro de estudiante

Selección de carrera/curso

Registro de credencial de usuario

Estudiante

Gestion de carrera/curso Registro de plan académico

Fuente: [Elaboración propia]

172 de 243

Gestion de cuenta de usuario

Implementación del módulo de facturación: La implementación ha sido efectuado en base a todo el diseño realizado en las anteriores iteraciones. 

Acceso al módulo de facturación: De acuerdo a la arquitectura de 3 capas, el acceso al módulo se realiza de la siguiente manera: Figura Nº 103: Secuencia de acceso al módulo de facturación Presentación: Se ingresan los datos mediante la interfaz de usuario

Lógica de negocio: Se reciben los datos, se validan y se realizan operaciónes auxiliares

Acceso a datos: Se reciben datos validados, se envian/reciben estos datos a la base de datos.

Inicio de sesion Capa de presentación

Capa de lógica logica de negocio

<<Interfaz>> Principal.xaml (Inicio de sesion)

Capa de acceso a datos

<<Clase>> CredencialUsuarioLN

<<Clase>> CredencialUsuarioAD Base de datos

La capa de presentacción accede a la capa de logica de negocio

La capa de logica de negocio accede a la capa de acceso a datos

Fuente: [Elaboración propia]



Inicio de sesión: El acceso al módulo se efectúa mediante una interfaz de inicio de sesión con un nombre de usuario y password. La implementación se muestra en la siguiente figura. Figura Nº 104: Acceso al sistema de facturación

Fuente: [Elaboración propia]

173 de 243



Consultar inscripción: Permite consultar inscripciones de estudiantes, para que luego el funcionario de caja pueda efectuar el pago. Esta interfaz se puede visualizar en la siguiente figura. Figura Nº 105: Consulta de inscripción

Fuente: [Elaboración propia]



Registro de pago (Paso I): Permite obtener el detalle de las inscripciones de estudiantes y seleccionar los pagos a registrar. Figura Nº 106: Registro de pago: Paso I

Fuente: [Elaboración propia]

174 de 243



Registro

pago

(Paso

II):

Permite

visualizar

detalle

mensualidades/matriculas a pagar seleccionadas y permite registrar el pago. Como se puede ver en la siguiente figura: Figura Nº 107: Registro de pago: Paso II

Fuente: [Elaboración propia]



Visualización de factura: Permite obtener una vista previa de la factura antes de registrar el pago y emitir la factura correspondiente. Esta vista se muestra en la siguiente figura.

175 de 243

Figura Nº 108: Visualización de factura

Fuente: [Elaboración propia]



Reportes de pago: Permite visualizar reportes de pagos efectuados de acuerdo a un criterio de búsqueda previo. Este criterio puede ser una vista general de los pagos efectuados en una fecha en específico o en un rango de fechas, según un funcionario de caja, una agencia o un mes determinado. En todos los casos se puede generar un reporte general o un reporte detallado. Este criterio de búsqueda es ingresado mediante la interfaz de reportes que se muestra en la siguiente figura.

176 de 243

Figura Nº 109: Interfaz de generación de reporte de pagos

Fuente: [Elaboración propia]

Una que vez ingresado el criterio de búsqueda se genera el reporte específico para cada consulta como el que se puede visualizar a continuación Figura Nº 110: Reporte general de pagos: Funcionarios de caja

Fuente: [Elaboración propia]

También se puede generar un reporte más específico, como el detalle de un pago en particular. Este reporte se muestra a continuación

177 de 243

Figura N潞 111: Reporte detalle de pagos: Funcionarios de caja

Fuente: [Elaboraci贸n propia]

178 de 243

En la siguiente figura se puede observar otro tipo de reporte, mediante la selecci贸n de mes como un criterio de b煤squeda. Figura N潞 112: Reporte mensual de pagos

Fuente: [Elaboraci贸n propia]

179 de 243

Es posible obtener reportes de las deudas de los estudiantes mediante diferentes criterios de búsqueda generando reportes con el que se puede ver a continuación: Figura Nº 113: Reporte de deudas de estudiantes

Fuente: [Elaboración propia]



Implementación del código de control: En cumplimiento a la normativa indicada por el Servicio de Impuestos Nacionales, se ha implementado el código de control utilizando los siguientes datos de entrada: -

Número de autorización.

Número de factura o nota fiscal.

NIT

Fecha de transacción.

Monto de la transacción o importe

Llave de dosificación (otorgada en cada dosificación por el SIN al instituto) Los algoritmos utilizados en la implementación del código de control son: Algoritmo Alleged RC4, Verhoeff y de base 64. El detalle de la implementación se puede visualizar en (Anexo I: Generación del código de control). 180 de 243



Implementación de la conexión entre el módulo de facturación y el servidor de base de datos: La conexión ha sido efectuada mediante los siguientes parámetros que dan el acceso a la base de datos al módulo de facturación: -

Data Source = 192.168.56.2 (IP del servidor)

Inicial Catalog = BDIngDataComp (Base de datos)

User ID = Virtual; Password = virtual (cuenta de acceso a la base de datos)

Encrypt = true (encriptación activada  requiere de certificado SSL descrito en el siguiente punto)



Medidas de seguridad al sistema de inscripción Mediante el uso de certificados SSL se habilitado la encriptación SSL y https. El detalle de la implementación se puede visualizar en: (Anexo L: Aplicación de medidas de seguridad) y el resultado se muestra en la siguiente figura: Figura Nº 114: Habilitación de SSL y Https al sistema de inscripción

Fuente: [Elaboración propia]

181 de 243



Medidas de seguridad a los elementos del enlace en línea Se han aplicado las medidas que indica la circular SB/466/2004 (acorde a los detalles que se describen en el punto 3.2.2 de este trabajo) que indica la ASFI y a la sección 10.9.2 del estándar internacional NB-ISO/IEC 1799, referente a transacciones en línea, de manera que permitan efectuar la intermediación financiera. (Ver Anexo J: Sección 10.9.2 del estándar NB-ISO/IEC 17799: Gestión de seguridad de la información). Considerando ambas normativas se ha considerado lo siguiente: 

Las políticas, normas y procedimientos de seguridad informática: Se ha considerado lo siguiente: -

Se han considerado políticas en la creación de cuentas de usuario y contraseñas. El detalle se puede visualizar en (Anexo L: Aplicación de medidas de seguridad)

La contraseña está encriptada en la base de datos. El detalle de su implementación se puede ver en (Anexo L: Aplicación de medidas de seguridad)

Roles de usuarios existentes que permitan categorizar el acceso al módulo de facturación (La descripción se puede ver en la sección siguiente)

Las políticas, normas y procedimientos de seguridad que deben cumplir la entidad financiera están establecidos en la circular SB/443/2003.

El Administrador del instituto tiene el acceso a una interfaz en el módulo de facturación mediante la cuál puede realizar consultas hacia los logs de la base de datos (pistas de auditoria). Esta interfaz se puede visualizar en la siguiente figura:

182 de 243

Figura Nº 115: Interfaz de logs de la base de datos

Fuente: [Elaboración propia]

El uso del firewall y las reglas que debe considerar tanto la entidad financiera. El firewall que adquiera el instituto puede ser de tipo 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 instituto son las siguientes: 

Permitir acceso a las IP entrantes de la entidad financiera hacia el servidor del instituto



Permitir las solicitudes entrantes de la entidad financiera de tipo TCP en los puertos 1433, 1434, 1954 y de tipo UDP en el puerto 1434. Estos puertos permiten el acceso a la base de datos del instituto.

En la entidad financiera se deben aplicar reglas de salida tomando en cuenta las mismas reglas mencionadas anteriormente.



Se ha considerado los siguientes aspectos de seguridad según el estándar NB-ISO/IEC 17799: -

Uso de certificados digitales para autenticar la identidad del instituto. (Ver Anexo L: Aplicación de medidas de seguridad)

Validez de credenciales de usuario (Habilitadas por el administrador de instituto). (Ver Anexo L: Aplicación de medidas de seguridad) 183 de 243

Las transacciones efectuadas son confidenciales (solo realizadas por el personal autorizado: Funcionario de caja) y la privacidad con todas las partes involucradas es conservada.

Canal

comunicaciones

entre

las

partes

involucradas

(cliente/servidor) es encriptado. (Ver Anexo L: Aplicación de medidas de seguridad) -

Protocolos de comunicación entre las partes involucradas es seguro.

Almacenaje de datos localizados fuera de cualquier ambiente público accesible.



Políticas de usuarios Tomando en cuenta la circular SG/466/2004 se ha considerado esta política, donde el acceso al módulo de facturación para el uso de sus diferentes funcionalidades depende del tipo de usuario, el cuál posee privilegios diferentes. Los usuarios existentes son: 

Administrador de Instituto: Encargado de sistemas del instituto. Tiene acceso a las funcionalidades de: -

Creación y gestión de entidades financieras y sus agencias respectivas



Creación y gestión de credenciales de usuario.

Registro y gestión de datos de dosificación.

Reportes de pagos efectuados en entidad financiera especifica

Administrador de Entidad financiera: Encargado de sistemas de la entidad financiera. Tiene acceso a las siguientes funcionalidades: -

Gestión de credenciales de usuario creadas por el administrador de instituto (Desactivación y cambio de contraseñas)

Reporte de pagos efectuados la entidad financiera a la que pertenece.



Funcionario de caja: Encargado de registrar los pagos en las agencias de la entidad financiera. Tiene acceso a las siguientes funciones: -

Consultar detalle de inscripciones de estudiantes.

184 de 243

Registrar el pago de matrículas y mensualidades

Emitir factura impresa por concepto de pagos efectuados

Reporte de pagos efectuados del funcionario de caja

Pruebas 

Fuente: [Elaboración propia]

Las pruebas realizadas a cada clase del sistema se han efectuado a cabo de manera satisfactoria, utilizando valores estáticos en cada módulo de manera que se abarquen todas las funcionalidades en el sistema de facturación

185 de 243

3.4.1.4 Fase de transición Cuarta iteración: Pruebas al módulo de facturación Análisis de requerimientos En esta fase a no se describen nuevos requerimientos, más al contrario ya deben cumplirse los requerimientos establecidos. Modelo de casos de uso Ya no se realiza ningún caso de uso en esta fase y los actores ya están establecidos en las anteriores fases. Modelo de análisis Según la metodología UP el análisis concluye en la anterior fase del ciclo de vida. Modelo de diseño Según la metodología UP el diseño concluye en la anterior fase del ciclo de vida. Modelo de implementación La implementación ya se ha efectuado en la fase de construcción Pruebas 

Pruebas funcionales: Permiten probar el funcionamiento correcto de los componentes del sistema, se han realizado las pruebas a los módulos de este incremento mediante la siguiente tabla: Tabla Nº 18: Pruebas funcionales: Módulo de facturación

Caso de

Datos de Entrada

uso

Resultado

Resultado Esperado

Obtenido

 El sistema despliega la

Ingresar al Sistema

El usuario debe ingresar en un

interfaz

principal

formulario de inicio de sesión

acuerdo

sus datos (login/password) para

usuario que ha iniciado Satisfactorio

ser

sesión en el sistema.

autenticado

presiona

botón “Iniciar sesión”.

tipo

 En caso de que el usuario

186 de 243

autenticado el sistema retorna un mensaje de datos

usuario

incorrecto  Crear entidad financiera: El Administrador

instituto

ingresa los datos de creación de

entidad

agencias mediante

financiera

de el

 La entidad financiera o agencias

registrados

misma,

formulario

son

muestra

mensaje

se Satisfactorio de

confirmación

registro.

 Los datos de la entidad financiera o agencias

Crear

son modificados y se Satisfactorio muestra mensaje de

entidad financiera

 Gestionar

entidad

financiera: El administrador

confirmación  En caso de eliminar la

de instituto gestiona las la

entidad financiera, se

entidad financiera o agencias

elimina

de la misma (editar, eliminar) ingresando

criterio

esta

sus

agencias. Si es solo una

agencia no afecta a la Satisfactorio entidad financiera,

búsqueda.

finalmente se muestra mensaje

confirmación credencial de  Crear credencial de usuario:  La usuario es creada y se El Administrador de instituto Crear credencial de Usuario

ingresa los datos mediante el

muestra

formulario de registro.

confirmación

 Gestionar

 Los credencial

usuario: El administrador de instituto gestiona las cuentas

187 de 243

mensaje

datos

Satisfactorio

credencial de usuario son modificados y se muestra

mensaje

Satisfactorio

existentes (editar, deshabilitar) ingresando

criterio

confirmación.

búsqueda. El administrador de  En caso de deshabilitar entidad financiera también la credencial de usuario, tiene acceso a esta función. ésta ya no tendrá

Satisfactorio

acceso al módulo de facturación  La

dosificación

registrada y se muestra mensaje

 Registrar

datos

confirmación.

dosificación: El Administrador

Además

solo una puede estar

de instituto registra los datos de dosificación mediante el formulario de registro.

vigente

existen

nuevas

dosificaciones

Satisfactorio

deben estar pendientes

Registrar

hasta

datos de

fecha

vigencia.

dosificación

 La

dosificación

editada correctamente y

dosificación: El administrador

se muestra mensaje de

de instituto ingresa un criterio

confirmación.

 Gestionar

datos

dosificación es de búsqueda el cuál le permite  La eliminada y se muestra editar y eliminar datos de mensaje

dosificación.

Satisfactorio

confirmación.  Registrar

pago:

 Se

una inscripción mediante un criterio pago

búsqueda.

inscripción y sus montos Satisfactorio pendientes (si existen).

funcionario de caja, consulta

Registrar

muestra

 El pago es registrado y

Selecciona la inscripción y los

se muestra mensaje de Satisfactorio confirmación.

pagos a registrar mediante la interfaz de pago.  Emitir factura: El funcionario de

caja

selecciona

 La Factura es emitida

esta

188 de 243

de manera impresa.

Satisfactorio

opción y envía la factura a la cola de impresión  De

acuerdo

selección

del

reporte

 Reportes de inscripción: El

específico, se visualizan

administrador de instituto o el

los reportes. Además se

administrador

puede

visualizar

pagos

realizados

financiera

entidad

selecciona

los Satisfactorio en

cada agencia de una

reporte.

entidad

financiera

determinada. Fuente: [Elaboración propia]

3.4.2 Diseño del enlace en línea El diseño de la conexión es basada en la arquitectura cliente/servidor la cual es un tipo de enlace en línea. Esta conexión es descrita a continuación por las partes que la conforman.

3.4.2.1 Cliente Es el módulo de facturación y está situado en las terminales (computadoras) de los funcionarios de caja en las diferentes agencias de la entidad financiera. El módulo se conecta a través de la red de comunicaciones de la entidad financiera hacia la base de datos replica gestionada por el servidor de Base de datos en el instituto.

3.4.2.2 Servidor El servidor que permite la administración de la base de datos principal está situado en el instituto. Este recibe las solicitudes enviadas por el modulo cliente 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.

3.4.2.3 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

189 de 243

las transacciones enviadas de la entidad financiera a la institución. El protocolo usado en el canal de datos es TCP/IP.

3.4.2.4 Diseño de arquitectura del enlace en línea Permite conocer la estructura de los elementos del enlace (módulo cliente, servidor y canal de comunicaciones), mediante la cual se va a construir el sistema. La arquitectura del módulo cliente (facturación) ha sido estructurada en tres capas: 

Capa de acceso a datos: Contiene las funciones de conexión hacia la base de datos réplica mediante consultas SQL.



Capa de lógica de negocio: La cual contiene el procesamiento del módulo (llamada a funciones de procesamiento, validaciones, mensajes de retorno) recibe las peticiones del usuario (funcionario de caja/Administradores) y envía las respuestas de estas solicitudes.



Capa de presentación: Esta capa permite utilizar las funciones del módulo por el funcionario de caja y administradores mediante una interfaz gráfica. De acuerdo al tipo de acceso que poseen.

La arquitectura es expresada mediante el diagrama de despliegue y se muestra a continuación:

190 de 243

Figura Nº 117: Diagrama de despliegue: Arquitectura del enlace en línea Cliente (Sistema de facturación)

Capa de presentación <<Interfaz>> Registro y reporte de pagos

<<Interfaz>> Gestor de usuario

Servidor

Gestor de base de datos

Capa de logica de negocio

<<Clase>> Pagos

Protocolo TCP/IP

Solicitud SQL (nivel de base de datos) <<Clase>> CredencialUsuario

Middleware de base de datos (SQL.Data.Client)

Base de datos replica

Capa de acceso a datos <<Clase>> Conexion SQL de CredencialUsuario <<Clase>> Conexion SQL de Pagos

Fuente: [Elaboración propia]

El servidor posee un middleware de base de datos (SQL.Data.Client), el cual permite traducir o comunicar las solicitudes recibidas por el modulo cliente hacia la base de datos replica. El canal de comunicación es de fibra óptica y es la vía mediante la cual las transacciones (solicitudes SQL) se envían del módulo cliente al servidor utilizando el protocolo TCP/IP.

3.4.2.5 Esquema conexión entre entidad financiera e instituto Para tener una idea más clara del enlace en línea que permite la intermediación financiera a un nivel técnico, a continuación se muestra un esquema que describe esta conexión y el envío de las transacciones de la entidad financiera hacia el instituto mediante el módulo de facturación.

191 de 243

Figura Nº 118:

Esquema de diseño de enlace en línea para la intermediación financiera

Fuente: [Elaboración propia]

192 de 243

3.5 PRUEBAS FINALES DEL SISTEMA DE INSCRIPCIÓN Y EL MÓDULO DE FACTURACIÓN. Una vez que se ha implementado el sistema y comprobado el correcto funcionamiento de cada módulo en todos incrementos, se ha verificado el rendimiento y concurrencia del sistema de inscripción y el módulo de facturación.

3.5.1 Pruebas de carga y concurrencia Estas pruebas permiten verificar que el sistema pueda procesar su carga esperada de acuerdo a una cantidad de usuarios que prueban el sistema simultáneamente.

3.5.1.1 Aplicación de pruebas de carga y concurrencia al sistema de inscripción Para efectuar estas pruebas se ha utilizado la herramienta de TestProyect de visual studio. Las pruebas de concurrencia se han realizado simultáneamente con las pruebas de carga (Ver Anexo K: Pruebas del sistema). El resultado de estas pruebas es el siguiente: Tabla Nº 19: Resultados de prueba de carga: Sistema de inscripción Prueba

Parámetros 

Concurrencia de usuarios: 100



Modelación

combinación

Resultado

prueba: A partir de usuarios virtuales. Carga

(Solicitudes enviadas al sistema) 

Internet Explorer Iteraciones de la prueba: 100



Concurrencia de usuarios: 1000



Modelación

de advertencia sobrepasando uso

recomendado

procesador.

Uso

este

combinación

Pruebas

efectuadas

sin

de errores.

prueba: A partir de usuarios virtuales. infracciones 

sin

último 32.1 %



Carga

efectuadas

errores. Se obtuvo 1 infracción

Explorador: Google Chrome, Firefox,

Pruebas

obtuvo

advertencia

(Solicitudes enviadas al sistema)

sobrepasando

Explorador: Google Chrome, Firefox,

recomendado de procesador.

193 de 243

uso

Internet Explorer



Iteraciones de la prueba: 100

procesador 46.1 %



Concurrencia de usuarios: 10000

Pruebas



Modelación

combinación

críticas.

efectuadas

de errores.

prueba: A partir de usuarios virtuales. infracciones Carga  

Uso

sin

obtuvo

advertencia

(Solicitudes enviadas al sistema)

sobrepasando

Explorador: Google Chrome, Firefox,

recomendado de procesador.

Internet Explorer

Iteraciones de la prueba: 100

procesador 53.4 %

críticas.

uso

Uso

Fuente: [Elaboración propia]

Se puede ver que el sistema tiene un alto soporte a la carga sometida, y una alta concurrencia de usuarios, dando lugar a una cantidad de errores aceptables.

3.5.1.2 Aplicación de pruebas de carga y concurrencia al módulo de facturación Estas pruebas han sido efectuadas mediante la herramienta ANTS Performance Profiler. (Ver Anexo K: Pruebas del sistema). El resultado de estas pruebas es el siguiente: Tabla Nº 20: Resultados de prueba de carga: Módulo de facturación Prueba

Carga

Parámetros

Resultado



Concurrencia de usuarios: 100



% de uso de procesador



Solicitudes a base de datos (SQL)



Contador de hilos de procesador



Entrada/Salida de operaciones



Entrada/Salida de bytes



Concurrencia de usuarios: 1000

Pruebas



% de uso de procesador

errores.



Solicitudes a base de datos (SQL)

infracciones

194 de 243

Pruebas

efectuadas

sin

errores. Se obtuvo 1 infracción crítica sobrepasando el uso recomendado de procesador (132.12%)

efectuadas Se

sin

obtuvo

críticas

Carga



Contador de hilos de procesador

sobrepasando



Entrada/Salida de operaciones

recomendado de procesador



Entrada/Salida de bytes

(132.75%, 117.38%, 111.71%)



Concurrencia de usuarios: 5000



% de uso de procesador



Solicitudes a base de datos (SQL)



Contador de hilos de procesador



Entrada/Salida de operaciones



Entrada/Salida de bytes

Pruebas errores.

uso

efectuadas Se

obtuvo

infracciones sobrepasando

sin 4

críticas el

uso

recomendado de procesador (124.85%, 135.7%, 110.69%, 124.47%)

Fuente: [Elaboración propia]

Se puede ver que el módulo de facturación tiene un alto soporte a la carga sometida, y una alta concurrencia de usuarios, dando lugar a una cantidad de errores aceptables.

3.6 DEMOSTRACIÓN DE LA HIPOTESIS La hipótesis planteada es: El sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea, permitirá reducir las filas de estudiantes incrementando puntos de cobro de matrículas y mensualidades, obtener información consistente respecto a la verificación del cobro de los mismos y disminuir el tiempo en el proceso inscripción y facturación en el instituto Ing Data Comp. Las variables que conforman la hipótesis son las siguientes: Variable independiente. 

El sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea. Descripción: El sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea, permitirá registrar alumnos a carreras y cursos de su interés, emitir facturas impresas directamente en la entidad financiera, descentraliza el cobro de mensualidades a varios puntos autorizados, disminuye el tiempo en el proceso de inscripción y facturación. Así 195 de 243

mismo proporciona información consistente respecto a la verificación del cobro de mensualidades. Variable dependiente. 

Filas de estudiantes incrementando puntos de cobro de matrículas y mensualidades. Descripción: Involucra extender la cantidad de puntos de cobro de mensualidades en la entidad financiera.



Información consistente respecto a la verificación del cobro de los mismos. Descripción: Involucra que la información está completa, es decir que es íntegra, donde los datos se mantengan idénticos durante cualquier operación, como transferencia (envío y recepción), almacenamiento y recuperación.



Tiempo en el proceso inscripción y facturación en el instituto Ing Data Comp. Descripción: Involucra el tiempo que se toma registrar los datos del estudiante e inscribirlo en el curso o carrera de su interés y cobrar la mensualidad y/o matricula registrando los datos del cobro para emitir la factura correspondiente.

La medición de las variables se ha efectuado mediante la siguiente tabla: Tabla Nº 21: Operativización de variables de la hipótesis Variable

Dimensión

Indicador

Variable independiente El sistema de inscripción con módulo de facturación mediante

intermediación

financiera aplicando enlace

Inscripción vía web y Facturación (en entidades financieras)

en línea.

196 de 243

Sistema implementado.

Variable dependiente Filas

incrementando cobro

Comparación

estudiantes puntos

matrículas

de y

Puntos de cobro (Cajeros)

cantidad de puntos de cobro

(cajeros)

del

instituto con cajeros de

mensualidades. Información

la entidad financiera consistente

respecto a la verificación de cobro de los mismos. Tiempo en el proceso de inscripción y facturación.

Integridad de

Pruebas de integridad

información

Tiempo

Horas

FUENTE: [Elaboración propia]

A continuación se realizara el análisis de las variables que conforman la hipótesis

3.6.1 Demostración de la primera variable dependiente: Filas de estudiantes incrementando puntos de cobro de matrículas y mensualidades Para la demostración de esta variable se ha considerado la cantidad de puntos existentes para el cobro de matrículas o mensualidades antes y después del uso del sistema mediante la intermediación financiera. Tabla Nº 22: Puntos de cobro de matrículas y mensualidades Actividad

Puntos de cobro de matrículas y mensualidades El cobro de matrículas o mensualidades es centralizado en el escritorio de la secretaria

Sin el sistema

del instituto, por lo que hay filas de estudiantes esperando ser atendidos. 1 punto de cobro

197 de 243

El cobro de matrículas o mensualidades puede ser efectuado en las distintas agencias de la entidad financiera con la que exista la intermediación financiera. En la sección 3.2.3 Con

sistema

mediante

intermediación financiera

se seleccionó a Fassil S.A. como entidad financiera con la cual el instituto realizara el acuerdo. 17 puntos de cobro en la ciudad y 9 en provincias cercanas (Fassil)

Fuente: [Elaboración propia]

La cantidad de puntos de cobro disponibles para implantar el sistema se obtuvo mediante una entrevista (Ver Anexo M: Pruebas del sistema). Mediante el análisis efectuado mediante la anterior tabla se concluye que las filas de estudiantes van a reducir debido al incremento de puntos de cobro de matrículas y mensualidades en las distintas agencias de la entidad financiera con la cual el instituto efectué la intermediación financiera.

3.6.2 Demostración de la segunda variable dependiente: Información consistente respecto a la verificación del cobro de los mismos Para la demostración de esta variable se ha considerado la integridad en la base de datos, algoritmos de encriptación asociados con funciones hash, certificados y la comparación de la información consistente de los cobros efectuados sin el sistema y con el sistema.

3.6.2.1 Integridad en la base de datos Para garantizar la integridad de los datos, en el diseño y estructuración de la base de datos se ha considerado las siguientes categorías de integridad: 

Integridad de entidad: Define una fila como entidad única para una tabla determinada, la cual exige el uso de claves principales en las tablas (Primary Key)



Integridad de dominio: Definida por la validez de las entradas para una columna determinada. Exige la restricción de tipos de datos, longitud o 198 de 243

intérvalo de valores, también se hace uso de claves foráneas (Foreign Key), valores por defecto (Default) y definiciones Not null. 

Integridad referencial: Protege las relaciones definidas entre las tablas cuando se crean o eliminan filas. Se hacen uso de las restricciones Foreign Key y esta integridad garantiza que los valores clave sean coherentes en las distintas tablas.

En la siguiente figura, se muestra el diagrama de base de datos del sistema de inscripción y módulo de facturación considerando las categorías de integridad mencionadas: Figura Nº 119: Integridad en la base de datos

Fuente: [Elaboración propia]

199 de 243

3.6.2.2 Funciones hash Son estructuras de datos que se encuentran relacionadas con algoritmos criptográficos y la integridad de datos en general. Estas funciones convierten un mensaje de cualquier tamaño en uno de longitud constante. Lo que resulta de aplicar una función hash a un mensaje (flujo de datos, archivo, solicitud) se llama resumen criptográfico dando resultado a un número constante que se usa para identificar de forma única el flujo de datos. Las funciones hash permiten comprobar la integridad de los datos. Si se calcula el hash de un flujo de datos antes de ser enviado como también después de ser enviado y dan el mismo resultado, se puede considerar que ha mantenido su integridad. Los algoritmos utilizados tanto en el sistema de inscripción como en el módulo de facturación para calcular el hash son los siguientes: 

Algoritmo MD5 en el cifrado de contraseñas e inicio de sesión (Ver Anexo L: Aplicación de medidas de seguridad)

3.6.2.3 Certificados Un certificado consiste en la asociación entre una entidad física y una firma realizada por una entidad confiable, de manera que permita saber que los datos no han cambiado y provienen de una firma concreta, garantizada su identidad por una tercera parte confiable (Autoridad certificadora). La entidad física es el Instituto Ing Data Comp y la firma es efectuada por esta misma institución. Al visualizar los detalles del certificado se indican la validez del certificado y si la ruta de firmas culmina en una entidad de confianza (Instituto Ing Data Comp) entonces se considera que se garantiza la integridad. Los certificados utilizados que se han utilizado son los siguientes: 

Certificado SSL para en la publicación del sistema de inscripción (Ver Anexo L: Aplicación de medidas de seguridad)



Certificado SSL en la conexión en línea entre el módulo de facturación y la base de datos (Ver anexo L: Aplicación de medidas de seguridad)

200 de 243

3.6.2.4 Comparación de la integridad de la información Mediante la siguiente tabla se ha realizado la comparación de la integridad de la información sin el sistema y con el sistema. Tabla Nº 23: Integridad de la información sin el sistema y con el sistema Integridad de Actividad

Integridad de información

información sin el

con el sistema

sistema Proceso de facturación

Secretaria

alguna

vez

olvida marcar la casilla de pago o marca la casilla equivocada.

Existen

casillas para cada pago correspondiente.

Funcionario de caja al registrar el pago mediante el módulo de facturación

automáticamente el detalle de tal transacción (Año, Semestre, Mes) que corresponde a la casilla que antes se utilizaba

El formulario de datos de Cuando Pago de matrícula o mensualidad y registro del pago efectuado

registra

estudiante

estudiantes (con el cuál se inscribe a alguna carrera o registran

los

datos

del curso mediante el sistema de

estudiante en la planilla: inscripción, registra sus datos Registro

pagos

Ing personales; de manera que al

Data Comp) puede ser registrar algún pago mediante extraviado

mezclado el módulo de facturación, se

entre otros papeles de la recuperan estos datos y no se secretaria.

pierden.

Para verificar los cobros El módulo de facturación posee realizados

secretaria reportes de pagos efectuados

revisa el libro de reporte los cuales se generan mediante diario de ingresos o la criterios de búsqueda y sirven planilla: Registro de pagos para

201 de 243

verificar

los

cobros

Ing Data Comp. Los cuales realizados. se pueden extraviar. Fuente: [Elaboración propia]

3.6.3 Demostración de la tercera variable dependiente: Tiempo en el proceso inscripción y facturación en el instituto Ing Data Comp Para la demostración de esta variable se ha considerado un tiempo determinado, calculado mediante el uso de un cronómetro como instrumento de medición, de manera que permita realizar un análisis del tiempo que implica el proceso de inscripción y facturación. Tabla Nº 24: Tiempos invertidos en el proceso de inscripción y facturación Actividad

Tiempo sin el sistema

Tiempo con el sistema

Proceso de inscripción El encargado explica a la La

persona

ingresa

mediante un sistema de inscripción y Solicitud de personas persona la información selecciona la carrera o respecto a la folleto, información sobre las referente al contenido, curso de su elección para carreras y cursos de su costo de las carreras y visualizar la información interés.

cursos de su interés

correspondiente

0.5 horas (30 min) La

persona

0.25 horas (15 min)

manuscribe La persona selecciona la

sus datos personales en carrera o curso e ingresa Llenado de datos de un formulario inscripción mediante un inscripción que formulario.

de sus datos en un formulario

secretaria le proporciona 0.1333 horas (8 min)

202 de 243

la web efectuando así su inscripción 0.0333 horas (2 min)

Secretaria manuscribe los

En la anterior actividad al del datos del formulario a la efectuarse la inscripción, Registro de formulario de planilla: se almacenan esos datos alumnos inscritos Ing Data inscripción hacia una en la base de datos. Comp planilla Paso

datos

0.1667 horas (10 min)

0 horas

Proceso de facturación El estudiante cancela la El estudiante cancela en matricula o mensualidad efectivo

matricula

o en efectivo en la agencia

la de la entidad financiera,

mensualidad Pago de matrícula o mensualidad y registro del pago efectuado.

secretaria, la cual registra donde el funcionario de el detalle de la transacción caja registra la transacción en un libro denominado: mediante el módulo de Reporte diario de ingresos.

facturación en la base de datos del instituto.

0.1667 horas (10 min)

0,0833 horas (5 min) Los datos del estudiante

Secretaria

manuscribe

datos del estudiante a la Registro de datos del estudiante que efectuó el correspondiente.

pago

planilla: Registro de pagos Ing Data Comp y marca la casilla correspondiente al pago efectuado.

están

cuando

registrados realiza

inscripción y cuando se registra el pago mediante el módulo de facturación se

registra

también

detalle de tal transacción (Año, Semestre, Mes)

0.1333 horas (8 min) Emisión de factura

Una

vez

efectuado

0 horas el Una vez que el funcionario

pago, la secretaria emite de

203 de 243

caja

registra

de forma manual la factura transacción mediante el correspondiente

le módulo

entrega al estudiante

facturación

emite la factura de forma impresa

con

los

correspondientes

datos y

entrega al estudiante.

Tiempos

total

proceso

Tiempo total (Estimado)

0.0833 horas (5 min)

0.01667 horas (1 min)

Proceso de inscripción:

0.8 horas (48 min)

0.2833 horas (17 min)

Proceso de facturación:

0.3833 horas (23 min)

0.09997 horas (6 min)

1,1833 horas (71 min)

0.38327 horas (23 min

por

Fuente: [Elaboración propia]

Después de haber realizado el análisis del tiempo invertido en el proceso de inscripción y facturación mediante la anterior tabla se puede concluir que el tiempo es menor en ambos procesos con el uso del sistema a comparación de los proceso sin el sistema.

3.6.4 Demostración de la variable independiente: El sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea Para la demostración de esta variable, se realiza el análisis a través de una muestra de todos los beneficios que posee el sistema propuesto en el proceso de inscripción y facturación en relación a la forma actual de efectuar los procesos mencionados, calificando como beneficio con la palabra “Si” y rechazando el beneficio con la palabra “No” en la siguiente tabla:

204 de 243

Tabla Nº 25: Beneficios del sistema de propuesto Nro

Factores tomados en cuenta como

Factor

beneficio

Proceso

Proceso con

manual

el sistema

(Antes)

(Ahora)

Sistema de inscripción La información respecto a las carreras y 1

cursos del instituto se encuentra siempre disponible.

Permite que las personas puedan inscribirse a la carrera o curso de su interés. Permite que los estudiantes inscritos puedan

consultar su estado de cuentas (pago de matrículas y mensualidades, efectuados o pendientes).en cualquier momento. Permite el ahorro de tiempo (Antes 48 min – Ahora 17 min, aprox)

y aumenta la

disponibilidad en la inscripción ya que puede 4

realizar

este

proceso

desde

cualquier

computadora que tenga acceso a internet en cualquier momento, mediante el formulario de inscripción que le proporciona el sistema. Módulo de facturación Permite efectuar el pago de matrículas o mensualidades en las distintas agencias de 5

la entidad financiera con la cual el instituto tiene

acuerdo

intermediación

financiera. De esta manera se aumentan los puntos de cobro (Antes 1 – Ahora 17) 6

Permite el ahorro de tiempo en el proceso de

205 de 243

facturación (Antes 23 min – Ahora 6 min, aprox) Permite la emisión de la factura que acredita

y respalda el pago efectuado. Permite respecto

obtener a

información

consistente

verificación

pagos

efectuados por los estudiantes, mediante

2 (Sí)

8 (Sí)

reportes específicos. TOTAL BENEFICIOS Fuente: [Elaboración propia]

De acuerdo al análisis realizado en la anterior tabla, se concluye que los beneficios sin el sistema son 2 y con el sistema 8. Estos resultados se tomarán en cuenta en el cálculo del estadístico T para verificar la aceptación o rechazo de la hipótesis planteada.

3.6.5 Definición de la hipótesis Para definir la hipótesis se considera el análisis de aceptación y rechazo de la misma, haciendo referencia a un P que representa una probabilidad, en este caso se tiene que: 

P1 = El proceso que sigue actualmente el instituto Ing Data Comp para la inscripción y facturación.



P2 = El sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea.

Donde los factores que influyen en la operativización son: 

Hipótesis nula: Los factores de éxito de ambas muestras son iguales: H0: P1 = P2



Hipótesis alternativa: Los factores de éxito de ambas muestras son distintas: H1: P1 <> P2

206 de 243

Para el cuál se presentan dos casos: 

Los factores de éxito de la muestra anterior es mayor a la posterior: P1 > P2



Los factores de éxito de la muestra anterior es menor a la posterior: P1 < P2

Entonces se tiene que: 

H0: P1 = P2: (El proceso que sigue actualmente el instituto Ing Data Comp para la inscripción y facturación es igual al sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea).



H1: P1 <> P2: (El proceso que sigue actualmente el instituto Ing Data Comp para la inscripción y facturación es diferente al sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea). Esta hipótesis tiene dos implicaciones mutuamente excluyentes: -

P1 > P2: (El proceso que sigue actualmente el instituto Ing Data Comp para la inscripción y facturación tiene mayores beneficios que el sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea).

P1 < P2: (El proceso que sigue actualmente el instituto Ing Data Comp para la inscripción y facturación tiene menores beneficios que el sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea).

Dadas ambas hipótesis en la siguiente sección se realiza el cálculo del estadístico T para la demostración de la hipótesis planteada.

3.6.6 Cálculo del estadístico T El estadístico T permite verificar 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 utilizadas en la demostración de la hipótesis son las siguientes:   207 de 243

 √

Dónde: 

Pn = Probabilidad de ocurrencia de P1 o P2 (explicado anteriormente)



X = Número de aciertos en la muestra de la probabilidad: Pn (X1=2 y X2=8)



n = Número de muestras ( 8 beneficios analizados en la sección 3.6.4)



t = Valor estadístico para la aceptación o rechazo de la hipótesis.



Qn = Probabilidad de concurrencia (%) de P1 o P2 (explicado anteriormente)



Q/2 = Grado de error del cálculo del estadístico T (25%)



gl = grado de libertad del estadístico T

Realizando los cálculos necesarios para: n = 8   

; Entonces P1 alcanzo un 25% de los beneficios de la muestra. ; Entonces P2 alcanzo un 100% de los beneficios de la muestra. ; Por lo tanto P2 es mejor que P1

Pata el cálculo T-Student se toma en cuenta el valor de

, de acuerdo al número de

muestras que se tiene. En este caso considerando que la muestra es menor a 100, para el cálculo del grado de error el valor es de 0.05.

⁄ Los grados de libertad se calculan a continuación:

Para la obtención de los rangos de rechazo de la hipótesis, se busca 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 N: Valores críticos de la distribución T-Student)

208 de 243

Los rangos obtenidos son: -2.365 y 2.365. Es importante mencionar 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. Por lo tanto Por lo tanto Dónde: = Porcentaje de beneficios no alcanzados con el proceso que sigue actualmente el instituto Ing Data Comp para la inscripción y facturación. = Porcentaje de beneficios no alcanzados con el sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea. Sustituyendo los datos obtenidos: √

A continuación se grafican los resultados de los cálculos realizados: Figura Nº 120: Campana de Gauss para la demostración de la Hipótesis

Fuente: [Elaboración propia]

209 de 243

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 la hipótesis nula es rechazada y se acepta la alternativa (P1 < P2) concluyendo que “El proceso que sigue actualmente el instituto Ing Data Comp para la inscripción y facturación tiene menores beneficios que el sistema de inscripción con módulo de facturación mediante intermediación financiera aplicando enlace en línea”.

210 de 243

4 ANÁLISIS DE VIABILIDAD 4.1 Viabilidad técnica La viabilidad técnica es un aspecto importante debido a que en este punto se contemplan todos los requerimientos funcionales y no funcionales necesarios para la aplicación correcta del sistema propuesto, por este motivo se ha realizado el estudio acerca de la disponibilidad tecnológica, recursos materiales y requerimientos necesarios tanto para el cliente como el servidor.

4.1.1 Requerimientos del sistema Equipo servidor para el sistema de inscripción y módulo de facturación: Situado en instalaciones del instituto Ing Data Comp. Se han identificado los siguientes requerimientos en base a la consulta previa al sitio de Microsoft: “Requisitos del sistema Windows Server 2008 y SQL Server” Tabla Nº 26: Requerimientos funcionales: Equipo servidor Componente

Características

Disponibilidad

Requerimientos de hardware Mínimo: Procesador de

doble

núcleo de 1.5 Ghz Procesador Recomendado:

Procesador

doble núcleo de 3 Ghz o superior Mínimo: 2 GB de RAM Memoria RAM Recomendado: 4 GB o superior Espacio en

Mínimo: 8 GB

disco duro

Recomendado: 40 GB

Pantalla

Monitor con resolución 800x600 o superior

211 de 243

El instituto cuenta con el hardware requerido

Requerimientos de software Sistema operativo

El instituto no cuenta con el

Windows server 2008 o superior

software requerido pero es posible adquirirlo v铆a web en

Gestor de base de datos

las direcci贸nes: Sql server 2008 Standard

www.microsoft.com

www.amazon.com

El instituto no cuenta con este requerimiento pero se puede

Navegador

windows.microsoft.com/es

download-ie -

www.google.com/intl/es419/chrome/

www.mozilla.org/esES/firefox/new/

Software adicional

Microsoft Framework 4.5 Fuente: [Elaboraci贸n propia]

212 de 243

las

-es/internet-explorer/

Recomendado:Chrome ver. 29, Firefox ver.23

direcciones:

M铆nimo: Internet explorer 8, Chrome ver. 23, Firefox ver.17

adquirir

Disponible en www.microsoft.com

Equipo cliente del sistema de inscripción: Es una computadora que tenga acceso a internet mediante la cuál el estudiante pueda acceder al sistema de inscripción. Se han identificado los siguientes requerimientos: Tabla Nº 27: Requerimientos funcionales: Equipo cliente del sistema de inscripción Componente

Características

Disponibilidad

Requerimientos de hardware Mínimo: Procesador de 500 Mhz Procesador

Recomendado: Procesador de 1 Ghz o superior

Mínimo: 512 MB de RAM Memoria RAM

disponible

la mayoría de Recomendado: 1 GB o superior

Tarjeta de red o adaptador de

encuentra

los

café

internet Soporte de 100Mbps o superior

públicos

red inalámbrico. Pantalla

Monitor con resolución 800x600 o superior

Requerimientos de software Sistema operativo

Windows XP SP3 o superior Se Mínimo: Internet explorer 8, Chrome ver.

disponible

23, Firefox ver.17

la mayoría de

Recomendado: Chrome ver. 29, Firefox

los

ver.23

internet

Navegador

Conexión a internet

encuentra

públicos Conectividad superior a 56 Kbps Fuente: [Elaboración propia]

213 de 243

café

Equipo cliente del módulo de facturación: Son las computadoras mediante las cuales los funcionarios de caja en las distintas agencias de la entidad financiera, puedan utilizar el módulo de facturación. Se han identificado los siguientes requerimientos: Tabla Nº 28: Requerimientos funcionales: Equipo cliente del módulo de facturación Componente

Características

Disponibilidad

Requerimientos de hardware Mínimo: Procesador de 800 Mhz Procesador

Recomendado: Procesador de 1 Ghz o superior Las computadoras

Mínimo: 512 MB de RAM Memoria RAM

de los funcionarios

Recomendado: 1 GB o superior

de Espacio en

Mínimo: 30 MB

disco duro

Recomendado: 100 MB

entidad cuentan

financiera con

Computadoras

funcionarios

hardware

Tarjeta de red o adaptador de

caja

requerido

Soporte de 100Mbps o superior

red inalámbrico. Pantalla

Monitor

con

resolución

800x600

superior

Requerimientos de software

Sistema operativo

Windows Vista - SP2·o superior

caja cuentan con el software requerido

Software adicional

Microsoft Framework 4.5 Fuente: [Elaboración propia]

214 de 243

Disponible en www.microsoft.com

4.1.1.1 Licencias de software El sistema propuesta ha sido desarrollado mediante un software privativo, por lo que es necesario la adquisición de las respectivas licencias para el uso del sistema. El detalle de las licencias se muestra a continuación. Equipo servidor para el sistema de inscripción y módulo de facturación: Se han identificado los siguientes requerimientos en base a la consulta previa al sitio de Microsoft: “Requisitos del sistema Windows Server 2008 y Sql server 2008” Tabla Nº 29: Requerimientos no funcionales: Equipo servidor Componente

Licencia

Windows server 2008

Características

Disponibilidad El

instituto

Incluyen derechos ilimitados para la cuenta con las ejecución de entornos virtuales licencias pero es posible adquirirlas vía

Licencia SQL

de Licencia única por cada CPU que server ejecuta el cliente e incluye acceso

2008 Standard

web

dirección: www.microsoft.com

ilimitado de dispositivos cliente. www.amazon.com Fuente: [Elaboración propia]

4.1.2 Requerimientos del enlace en línea Para conectar el módulo de facturación situado en la entidad financiera con la base de datos del instituto es requerido el enlace en línea. A continuación se muestran los requerimientos de este enlace.

215 de 243

Tabla Nº 30: Requerimientos funcionales: Enlace en línea Componente

Características

Disponibilidad

Enlace que conecte el módulo Se Enlace dedicado

puede

adquirir

de facturación de las agencias enlace de transmisión de de la entidad financiera hacia datos a la base de datos del instituto.

proveedores ISP

(Comteco, Entel, Axs) El instituto no cuenta con

Permite

interconectar

el este equipo pero se puede

segmento del instituto hacia la adquirir en el mercado local Switch

entidad financiera para que en

las

tiendas

pueda ser distribuido a sus componentes diferentes agencias

electrónicos

de la calle Esteban Arce (Cochabamba).

Fuente: [Elaboración propia]

4.1.3 Requerimientos de personal Para utilizar el sistema de inscripción y el módulo de facturación se requiere de personal específico, el cual se puede ver en la siguiente tabla. Tabla Nº 31: Requerimientos de personal Sistema

Personal requerido

Sistema de



Administrador de sistemas en el instituto

inscripción



Usuario Final (Estudiante o postulante)



Administrador de sistemas en el instituto



Administrador de sistemas en la entidad financiera



Funcionario de caja de entidad financiera

Módulo de facturación

Fuente: [Elaboración propia]

216 de 243

Actualmente el instituto no cuenta con el equipo necesario para cumplir con el requerimiento mínimo para el servidor del sistema de inscripción y el módulo de facturación, pero está dispuesto a adquirir los mismos. La entidad financiera Fassil S.A. con la que el instituto va a realizar el acuerdo de intermediación financiera, está conforme y cumple con los requerimientos del módulo de facturación. Todos componentes mencionados, tanto para hardware como para software son de fácil adquisición y no requieren de gran inversión de tiempo para su capacitación por lo que se considera al trabajo de grado viable técnicamente

4.2 Viabilidad económica Para identificar los costos de los componentes hardware y software se ha tomado en cuenta los costos por componente tecnológico y costos por mano de obra.

4.2.1 Costos por componente tecnológico Se ha consultado a los sitios web oficiales de cada proveedor para identificar los costos de cada uno de los componentes tecnológicos. Los resultados se muestran a continuación. Equipo servidor para el sistema de inscripción y módulo de facturación: Los precios de los componentes son los siguientes: Tabla Nº 32: Precio de componentes: Equipo servidor Componente

Precio (Aprox)

Procesador: 3Ghz Memoria: 4 GB Disco duro 80 GB 7200 rpm Equipo servidor

dedicado

para

734$ Case Combo: Monitor resolución 1024x768, teclado, mouse y tarjeta de red. Sistema operativo: 217 de 243

1029$

Windows Server 2008 Standard Navegador: Internet explorer (Incluido con el

0.00$

sistema operativo) Sql server 2008 Standard Microsoft

Framework

(Gratuito:

700$

4.5

puede

descargar

0.00$

www.microsoft.com) Windows Server 2008 SP1 (incluida con el software) Licencias

0.00$

Sql server 2008 Standard (El

software

incluye

licencias de clientes y 1

0.00$

servidor) TOTAL

2463$

FUENTE: [Elaboraciรณn propia]

Equipo cliente del sistema de inscripciรณn: Los precios de los componentes son los siguientes: Tabla Nยบ 33: Precio de componentes: Equipo cliente del sistema de inscripciรณn Componente

Precio (Aprox)

Windows 7 (No se considera el precio Sistema operativo

debido

encuentra computadoras

que

en mediante

se las las

cuales los estudiantes acceden al sistema de inscripciรณn)

218 de 243

0.00$

Incluido como componente del

Navegador

sistema operativo TOTAL

0.00$ 0.00$

Fuente: [Elaboración propia]

Equipo cliente del módulo de facturación: Los precios de los componentes son los siguientes: Tabla Nº 34: Precio de componentes: Equipo cliente del módulo de facturación Precio

Componente

(Aprox)

Procesador: 800Mhz Memoria: 1 GB Disco duro 80 GB 7200 rpm Equipo

para

módulo

facturación

300$

Case Combo: Monitor resolución 1024x768, teclado, mouse y tarjeta de red. Sistema operativo: Windows 7 Home Basic TOTAL

60$ 360$

Fuente: [Elaboración propia]

Enlace en línea: El precio para el enlace de transmisión de datos se muestra a continuación: Tabla Nº 35: Precio de enlace en línea Componente Enlace

línea

para

la Instalación (Solo se paga una

transmisión de datos del módulo vez)

219 de 243

Precio (Aprox) 99$

de facturación hacia la base de Velocidad de transferencia: datos del instituto 64kbps (Precio anual) Switch

para

instituto

interconectar

hacia

entidad

financiera

1128$

Switch hp v1410-24 (24

160$

puertos, con soporte 100Mbps) TOTAL

1387$

Fuente: [Elaboración propia]

Una vez identificados los costos de cada componente correspondiente, se muestra a continuación el costo total de los componentes tecnológicos: Tabla Nº 36: Lista de costos por componente tecnológico Componente Equipo servidor del sistema de inscripción y el módulo de facturación

Monto (Aprox)

2463$

Equipo cliente del sistema de inscripción

0.00$

Equipo cliente del módulo de facturación

360$

Enlace en línea

1387$ TOTAL

4210$

Fuente: [Elaboración propia]

4.2.2 Costos por mano de obra Para la identificación de los costos del desarrollo del sistema de inscripción y el módulo de facturación se procederá a la elaboración del modelo COCOMO II, el cuál toma en cuenta tres modelos denominados: Composición de aplicación, diseño temprano y post-arquitectura. 

Composición de aplicación: Empleado en software construido a partir de componentes pre-empaquetados. En este caso se emplean Puntos Objeto para estimar el tamaño del software acorde al nivel de información de la

220 de 243

planificaciĂłn y nivel de precisiĂłn requerido en la estimaciĂłn de este tipo de proyectos. ď&#x201A;ˇ

DiseĂąo preliminar: Usado en las etapas iniciales del proyecto por lo que se usan Puntos FunciĂłn no ajustados para la estimaciĂłn del tamaĂąo del proyecto. Utiliza 7 conductores de coste que afectan al coste del proyecto.

ď&#x201A;ˇ

Post-Arquitectura: Aplicado en la etapa de desarrollo una vez definida la arquitectura del sistema y en la etapa del mantenimiento.

El modo post-arquitectura, serĂĄ utilizado en el presente proyecto, porque es el modelo de estimaciĂłn mĂĄs detallado y se aplica cuando la arquitectura del proyecto estĂĄ completamente definido. Para ese modo post-arquitectĂłnico se utilizaran las siguientes formulas: ď&#x201A;ˇ

đ??¸đ??´đ??šđ?&#x2018;&#x20AC;

0 MultiplicaciĂłn de valores evaluados en los 17 diferentes conductores de coste

ď&#x201A;ˇ

[

â&#x2C6;&#x2018;

]

ď&#x201A;ˇ ď&#x201A;ˇ

â&#x2C6;&#x2018;

ď&#x201A;ˇ ď&#x201A;ˇ ď&#x201A;ˇ ď&#x201A;ˇ ď&#x201A;ˇ

â&#x2C6;&#x2018;

ď&#x201A;ˇ ď&#x201A;ˇ :( ď&#x201A;ˇ

â&#x2C6;&#x2018;

ď&#x201A;ˇ

221 de 243

Conductores de costos de desarrollo

  Inicialmente para poder estimar el costo del proyecto de acuerdo al modelo especificado se debe obtener la estimación del tamaño de software utilizando algunas métricas de software. Se hace uso de las siguientes técnicas: 

Puntos objeto19



Puntos Función no ajustados



Líneas de código Fuente20

Para esto a continuación se realizan los cálculos correspondientes dividiendo el sistema general en módulos: Tabla Nº 37: Módulos del sistema propuesto Número de módulo

Nombre del módulo

Abreviatura del módulo

Módulo de inscripción

Módulo de facturación

Fuente: [Elaboración propia]

Métricas orientadas a la función Módulo 1: Módulo de inscripción Se va a obtener los Puntos Función (FP) de este módulo, para más adelante obtener la cantidad de líneas de código. Primeramente se ha ponderado los Puntos Función no Ajustados mediante la siguiente tabla:

Punto objeto: Medida indirecta de software que se calcula teniendo en cuenta la cantidad de interfaces de usuario, informes y componentes necesarios construir para un sistema. 20

Líneas de código fuente: Es cada una de las líneas de un archivo de código fuente de un programa de software.

222 de 243

Tabla Nº 38: Puntos Función no Ajustados: Módulo de inscripción Factor de ponderación Parámetros de medición

Cuenta

Total Simple Medio Complejo

Número

entradas

usuario Número de salidas de usuario Número

peticiones

usuario Número de archivos Número

interfaces

externas

125

375

180

120

140

105

Total cuenta (UFP: Puntos función no ajustados)

920

Fuente: [Elaboración propia]

En la siguiente tabla se ha calculado el valor de ajuste asignando 1 a 5 a cada uno de los factores, dónde: 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.

Tabla Nº 39: Valores de factores de ajuste - LDC Factor de ajuste

Valor

Factor de ajuste

(1-5)

Comunicación de datos

Proceso distribuido

Objetivos de rendimiento

Actualizaciones en línea Liga de proceso interno compleja Reusabilidad de código

223 de 243

Valor (1-5) 4 4 4

Configuración de explotación

compartida

Conversión de instalación contemplada

Tareas de transacciones

Facilidad de operación

Entrada de datos en línea

Instalaciones múltiples

Eficiencia con el usuario final

Facilidad de cambios

4 ∑

Fuente: [Elaboración propia]

Para calcular los Puntos Función (FP) se requiere el valor del Factor de complejidad técnica (TFC). Este utiliza la tabla de valores de ajuste (Tabla Nº 39). El cálculo de TFC es el siguiente: [

∑

[

]

La sumatoria de la tabla Nº 38 muestra los Puntos Función no Ajustados (UFP):

Ahora se obtiene los Puntos Función de este módulo, los cuales equivales a las líneas de código del módulo:

Factores de costo: Se ha obtenido el valor del conductor de costo de desarrollo (EAF) para el módulo mediante la tabla de factores de costo:

224 de 243

Tabla Nº 40: Factores de costo en COCOMO II: Módulo de inscripción FACTORES DE

MUY

COSTO

BAJO

Fiabilidad

requerida

ATRIBUTOS DEL PRODUCTO

del software Tamaño de la base de datos

acorde a las diferentes etapas del ciclo de

Complejidad

del

producto

Restricciones

del

tiempo de ejecución COMPUTADOR

ALTO

MUY

EXTRA

ALTO

RELY

0.82

0.92

1.10

1.26

DATA

0.90

1.14

1.28

DOCU

0.81

0.91

1.11

1.23

CPLX

0.73

0.87

1.17

1.34

1.74

RUSE

0.95

1.07

1.15

1.24

TIME

1.11

1.29

1.63

STOR

1.05

1.17

1.46

PVOL

0.87

1.15

1.3

ACAP

1.42

1.19

0.85

0.71

AEXP

1.22

1.10

0.88

0.81

PCAP

1.34

1.15

0.88

0.76

PEXP

1.19

1.09

0.91

0.85

vida

reusabilidad

ATRIBUTOS DEL

MEDIO

Documentación

Requerimientos

Restricciones

del

almacenamiento principal Volatilidad

máquina Virtual ATRIBUTOS DEL PERSONAL

BAJO

Capacidad del analista Experiencia

aplicaciones Capacidad

los

programadores Experiencia sistema operativo

225 de 243

Experiencia

con

lenguaje

el de

LTEX

1.20

1.09

0.91

0.84

PCON

1.29

1.12

0.90

0.81

TOOL

1.17

1.09

0.90

0.78

SCED

1.43

1.14

SITE

1.22

1.09

0.93

0.86

0.80

programación Continuidad

del

ATRIBUTOS DEL PROYECTO

personal Utilización

herramientas

software Limitaciones

planificación

del

desarrollo del proyecto Desarrollo multisitio

Fuente: [Elaboración propia]

Módulo 2: Módulo de facturación Se va a obtener los Puntos Función (FP) de este módulo, para más adelante obtener la cantidad de líneas de código. Primeramente se ha ponderado los Puntos Función no Ajustados mediante la siguiente tabla: Tabla Nº 41: Puntos Función no Ajustados: Módulo de facturación Factor de ponderación Parámetros de medición

Cuenta

Total Simple Medio Complejo

Número

entradas

105

420

Número de salidas de usuario

140

Número

usuario

peticiones

226 de 243

usuario Número de archivos Número

interfaces

externas

133

125

Total cuenta (UFP: Puntos función no ajustados)

908

Fuente: [Elaboración propia]

En la siguiente tabla se ha calculado el valor de ajuste asignando 1 a 5 a cada uno de los factores, dónde: 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.

Tabla Nº 42: Valores de factores de ajuste - LDC Valor

Factor de ajuste

(1-5)

Comunicación de datos

Proceso distribuido

Objetivos de rendimiento

Configuración de explotación compartida

Actualizaciones en línea Liga de proceso interno compleja Reusabilidad de código Conversión de instalación contemplada

Valor (1-5) 5 4 4 3

Tareas de transacciones

Facilidad de operación

Entrada de datos en línea

Instalaciones múltiples

Eficiencia con el usuario final

Facilidad de cambios

4 ∑

Fuente: [Elaboración propia]

227 de 243

Para calcular los Puntos Función (FP) se requiere el valor del Factor de complejidad técnica (TFC). Este utiliza la tabla de valores de ajuste (Tabla Nº 42). El cálculo de TFC es el siguiente: [

∑

[

]

Así mismo la sumatoria de la tabla Nº 41 muestra los Puntos Función no Ajustados (UFP):

Ahora se obtiene los Puntos Función de este módulo, los cuales equivales a las líneas de código del módulo:

Factores de costo: Se ha obtenido el valor del conductor de costo de desarrollo (EAF) para el módulo mediante la tabla de factores de costo: Tabla Nº 43: Factores de costo en COCOMO II: Módulo de facturación FACTORES DE

MUY

COSTO

BAJO

Fiabilidad

requerida

ATRIBUTOS DEL PRODUCTO

del software Tamaño de la base de datos

BAJO

MEDIO

ALTO

MUY

EXTRA

ALTO

RELY

0.82

0.92

1.10

1.26

DATA

0.90

1.14

1.28

DOCU

0.81

0.91

1.11

1.23

CPLX

0.73

0.87

1.17

1.34

1.74

Documentación acorde a las diferentes etapas del ciclo de vida Complejidad producto

del

228 de 243

Requerimientos

reusabilidad del

tiempo de ejecución COMPUTADOR

ATRIBUTOS DEL

Restricciones

0.95

1.07

1.15

1.24

TIME

1.11

1.29

1.63

STOR

1.05

1.17

1.46

PVOL

0.87

1.15

1.3

ACAP

1.42

1.19

0.85

0.71

AEXP

1.22

1.10

0.88

0.81

PCAP

1.34

1.15

0.88

0.76

PEXP

1.19

1.09

0.91

0.85

LTEX

1.20

1.09

0.91

0.84

PCON

1.29

1.12

0.90

0.81

TOOL

1.17

1.09

0.90

0.78

SCED

1.43

1.14

SITE

1.22

1.09

0.93

0.86

0.80

del

almacenamiento principal Volatilidad

máquina Virtual Capacidad del analista Experiencia ATRIBUTOS DEL PERSONAL

RUSE

aplicaciones Capacidad

los

programadores Experiencia

sistema operativo Experiencia

con

lenguaje

el de

programación Continuidad

del

ATRIBUTOS DEL PROYECTO

personal Utilización

herramientas

software Limitaciones

planificación

del

desarrollo del proyecto Desarrollo multisitio

Fuente: [Elaboración propia]

229 de 243

[

]

Una vez obtenida las líneas de código de ambos módulos y los factores de costo lo siguiente es obtener el valor exponencial de escala “B” con la siguiente tabla: Tabla Nº 44: Factores de escala MUY

FACTORES DE ESCALA WJ

Precedencia

BAJO

MEDIO

ALTO

MUY ALTO

EXTRA

PREC

6.20

4.96

3.72

2.48

1.24

0.00

FLEX

5.07

4.05

3.04

2.03

1.01

0.00

RESL

7.07

5.56

4.24

2.83

1.04

0.00

Cohesión de equipo

TEAM

5.48

4.38

3.29

2.19

1.10

0.00

Madurez del proceso

PMAT

7.80

6.24

4.68

3.12

1.56

0.00

Flexibilidad

desarrollo Arquitectura/Resolución de riesgo

Fuente: [Bohem, 2000]

Con los valores seleccionados y calculados anteriormente se procede a calcular el costo del proyecto, aplicando las formulas enunciadas al principio de esta sección. El primer cálculo es el esfuerzo nominal requerido para desarrollar el sistema y se calcula de la siguiente forma:

Dónde:

∑

230 de 243

Entonces: [

]

El cálculo de la productividad se muestra a continuación:

[

]

Lo siguiente es calcular el esfuerzo nominal por módulos, según la siguiente fórmula:

Módulo 1: Módulo de inscripción [

]

[

]

Módulo 2: Módulo de facturación

Después se ha calculado el esfuerzo estimado por cada módulo, mediante la siguiente fórmula:

Módulo 1: Módulo de inscripción [

]

[

]

Módulo 2: Módulo de facturación

231 de 243

El siguiente cálculo es para hallar el esfuerzo estimado del proyecto: ∑

[

]

Así mismo es necesario calcular el tiempo de desarrollo del proyecto:

[

]

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: Módulo de inscripción [

]

[

]

Módulo 2: Módulo de facturación

Ahora se obtiene el costo estimado del proyecto, mediante la siguiente formula: ∑ [

]

Lo siguiente es obtener el costo estimado por módulo considerando las líneas de código que se obtuvieron anteriormente:

232 de 243

Módulo 1: Módulo de inscripción [

]

[

]

Módulo 2: Módulo de facturación

Se debe obtener la productividad de cada módulo:

Módulo 1: Módulo de inscripción [

]

[

]

Módulo 1: Módulo de facturación

Así mismo se obtiene la productividad del proyecto:

[

]

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:

233 de 243

Tabla Nº 45: Tabla Final de COCOMO II Costo

Costo

Produc-

estim.

Instruc.

tividad

[

Costo

Nombre

Líneas

del

módulo

código

1067.2

1.387

3.617

5.016

173.662

871.088

0.816

212.758

1098.68

1.387

3.723

5.164

173.662

896.783

0.816

212.758

1767.871

Nro. de mod.

EAF [

]

[

]

[

]

[

]

Costo

2165.88 [

10.179

]

estim. [

212.758

] Product.

29 [

7.341

]

[

]

estim.

6.995 [

30 [

295.027

]

Fuente: [Elaboración propia]

Otro cálculo importante es la cantidad de personal promedio para el desarrollo del presente proyecto, el cual se obtiene mediante la siguiente formula:

[

]

Interpretando los valores obtenidos en la tabla se concluye que: 

En el proyecto existen: 2166 líneas de código funcionales.



Existe un esfuerzo estimado de 10 personas por mes



El tiempo de desarrollo del es de 7 meses.



Se requiere de 1 programador para el desarrollo del proyecto.



El costo total del proyecto es: 1768 $us.

234 de 243

]

Finalmente en la siguiente tabla se muestra el costo de los equipos y el enlace en línea necesarios para el funcionamiento del sistema. Así mismo el costo del desarrollo del mismo. Tabla Nº 46: Tabla final de viabilidad económica Componente Equipo servidor del sistema de inscripción y el módulo de facturación

Monto (Aprox)

2463$

Equipo cliente del sistema de inscripción

0.00$

Equipo cliente del módulo de facturación

360$

Enlace en línea

1387$

Costo total del sistema

1768$

TOTAL

5978$

Fuente: [Elaboración propia]

Tomando en cuenta los costos obtenidos de los equipos y en enlace en línea necesarios para el funcionamiento del sistema, como también la disponibilidad de adquisición de los mismos y el costo del desarrollo del sistema, se considera que el trabajo de grado es viable económicamente.

4.3 Viabilidad operativa El análisis de viabilidad operativa permite saber si el sistema propuesto funcionará y será utilizado una vez que se implante de una manera eficiente y accesible, los beneficios que ofrecen el sistema de inscripción y el módulo de facturación y la conformidad del personal administrativo del instituto respecto a la propuesta. La problemática existente en el instituto está el proceso de inscripción (debido a que toma demasiado tiempo que el estudiante llene el formulario de datos manualmente y la secretaria transcriba estos datos en la planilla correspondiente) como también en el proceso de facturación (debido a que el pago de matrículas y mensualidades es manual y centralizado por lo que existen largas fila de estudiantes que desean ser atendidos lo cuál también aumenta el tiempo invertido en este proceso) por este 235 de 243

motivo se ha desarrollado el sistema propuesto el cuál pretende solucionar los problemas en ambos procesos. Mediante una entrevista realizada al director del instituto Ing Data Comp se obtuvo la opinión acerca de los beneficios y la aceptación del sistema propuesto (Ver Anexo O: Cuestionarios para viabilidad operativa). Los resultados se muestran a continuación: 

El director del instituto Ing Data Comp está conforme con la solución que otorga el sistema de inscripción y el módulo de facturación.



Los beneficios que el sistema de inscripción brindan son: Ahorro de tiempo en la inscripción de estudiantes ya que es sencilla y rápida, administración de carreras, cursos, cuentas de usuario y estado de pagos de estudiantes de fácil de manejar.



Los beneficios que el módulo de facturación brindan son: Administración sencilla de entidades financieras, agencias, datos de dosificación y credenciales de usuario. Ahorro de tiempo en el registro de pagos y emisión de factura ya que es sencillo e intuitivo. Así mismo gestor de reportes con diferentes opciones y fácil de usar.

La implantación de la propuesta requiere del siguiente personal: 

Administración de sistemas: Para la entidad financiera un Ingeniero de sistemas, licenciado informático o profesional del área relacionada, con conocimientos de redes, seguridad y capacitación para el uso del módulo de facturación. Para el instituto un Ingeniero de sistemas, licenciado informático o profesional del área relacionada, con conocimientos sobre Sql server, servidores IIS, redes, seguridad y capacitación para el uso del sistema de inscripción y el módulo de facturación.



Usuario final de módulo de facturación: Funcionario seleccionado y capacitado en procesamiento de transacciones mediante sistemas informáticos, sistemas de facturación y perteneciente a la entidad financiera.



Usuario final del sistema de inscripción: Persona que tenga experiencia en el manejo básico de navegación por internet.

236 de 243

Basรกndose en los resultados obtenidos en la entrevista y en la tabla Nยบ 25 de beneficios de la secciรณn 3.6.4, tomando en cuenta el ahorro de tiempo, disponibilidad, aumento de puntos de cobro, etc. Se puede evidenciar que el instituto Ing Data Comp sale beneficiado, por lo que se concluye que el trabajo de grado es viable operativamente.

237 de 243

5 CONCLUSIONES Y RECOMENDACIONES Una vez alcanzados el objetivo general y los objetivos específicos se tienen las siguientes conclusiones y recomendaciones.

5.1 Conclusiones 

La información respecto al proceso actual de inscripción de estudiantes a carreras o cursos y facturación de pagos de matrículas y mensualidades del instituto Ing Data Comp fue obtenida a través de entrevistas efectuadas al personal administrativo del instituto utilizando cuestionarios y aplicando observación estructurada acerca de los procesos mencionados. De esta manera se realizó el modelo de negocio actual según las especificaciones de UML y así mismo se realizó el modelo de negocio alternativo el cual fue modificado en dos ocasiones durante el desarrollo del proyecto.



Mediante la revisión de la circular SB/433/2003 y SB/466/2004 otorgadas por la ASFI (Autoridad de Supervisión del Sistema Financiero) se pudo obtener los requerimientos técnicos y de seguridad respecto a la intermediación financiera. Adicionalmente a los circulares mencionados se pudo obtener otros aspectos de seguridad respecto a transacciones en línea en la sección 10.9.2 del estándar NB-ISO/IEC 17799 considerando que el módulo de facturación será utilizado para el registro de transacciones monetarias. También fue necesario la revisión de la resolución normativa de directorio Nº 100016-07 otorgada por el SIN (Servicio de Impuestos Nacionales) mediante la cual se obtuvo los requerimientos para la emisión de facturas mediante sistemas informáticos la cual fue aplicada en el desarrollo del módulo de facturación.



Mediante un análisis de comparación y valoración se seleccionó a UP (Proceso unificado) como metodología de desarrollo, C# como lenguaje de programación y SQL Server como gestor de base de datos. Así mismo se inició desarrollo del sistema de inscripción mediante el modelo de negocio alternativo realizado, la utilización de UML en el diseño del sistema y la aplicación de la metodología seleccionada considerando sus fases correspondientes.

238 de 243

De la misma manera que en el sistema de inscripción se desarrolló el módulo de facturación en base al modelado de negocio actual y la aplicación de las fases que indica la metodología UP. Adicionalmente se aplicó las consideraciones de técnicas y de seguridad indicadas en los circulares (mencionadas previamente) y la resolución normativa para los sistemas de facturación. Un aspecto importante dentro de las medidas de seguridad fue la creación de una réplica de base de datos que permita tener un respaldo de las transacciones efectuadas (pagos realizados) y aumentar la disponibilidad de acceso a estos datos. La implementación del enlace en línea (que permitirá la intermediación financiera) entre el módulo de facturación y la base de datos del instituto requirió tomar en cuenta configuraciones de red y firewall ya que en primera instancia se tuvieron problemas de conexión impidiendo el correcto funcionamiento. Estas configuraciones se especifican en el manual del sistema. El uso de la arquitectura cliente servidor de 3 capas (Capa de presentación, lógica de negocio y acceso a datos) permitió añadir nuevas funcionalidades de manera ordenada. Así mismo la herramienta Visual Studio 2012 permitió la codificación y realización de pruebas de ambos sistemas de forma estructurada. De esta manera se concluyó el desarrollo ambos sistemas en ocho iteraciones (cuatro para cada sistema respectivamente), dando resultado a un sistema de inscripción que permite el registro de estudiantes a las diferentes carreras y cursos que cuenta el instituto Ing Data Comp y un módulo de facturación que permite registrar el pago de mensualidades y matriculas de estudiantes inscritos en las diferentes agencias de la entidad financiera. Durante el desarrollo de ambos sistemas se pudo observar que UP es muy extensa a comparación de otras metodologías como XP o Scrum debido a que en cada fase del desarrollo (Inicio, Elaboración, Construcción y Transición) se debe efectuar un flujo de trabajo (análisis, diseño, implementación, pruebas) el cual es realizado en una o más iteraciones por este motivo es generada mucha documentación

239 de 243



Para la verificación del correcto funcionamiento del sistema de inscripción y el módulo de facturación se efectuaron las primeras pruebas (unitarias y funcionales) las cuales permitieron saber si lo indicado en el diseño se contrastaba con lo codificado, de esta manera se probaron las funciones principales de cada sistema. El uso de Visual Studio 2012 como herramienta de testeo facilitó de manera ágil y sencilla la realización de las pruebas de ambos sistemas. Con esta misma herramienta se realizaron también las pruebas finales (carga y concurrencia) las cuales probaron que el sistema de inscripción y el módulo de facturación (como prioridad principal) tienen un soporte de concurrencia de 5000 usuarios con solo 4 errores. De esta manera se realizaron las pruebas correspondientes dando resultado a un sistema que cumple estos criterios de calidad.



Finalmente se concluye que se lograron alcanzar los objetivos establecidos con el desarrollo del sistema propuesto, logrando reducir filas de estudiantes incrementando puntos de cobro de matrículas y mensualidades (mediante la aplicación de la intermediación financiera con la implantación del módulo de facturación), obtener información consistente respecto a la verificación del cobro de los mismos y disminuir el tiempo en el proceso de inscripción y facturación, con lo cual se da solución al problema identificado en el instituto Ing Data Comp.

5.2 Recomendaciones 5.2.1 Recomendaciones para el sistema de inscripción: Una vez que el sistema de inscripción sea implantado, se tienen las siguientes recomendaciones de uso: 

Utilizar de preferencia el navegador Google chrome o Firefox.



En la parte del servidor, verificar que ningún programa utilice el puerto 443 el cual es de gran importancia para el correcto funcionamiento del sistema de inscripción.

240 de 243

Las posibles mejoras se describen en las siguientes recomendaciones: 

Agregar un módulo que permita gestionar descuentos para los cursos ya que actualmente solo es posible para las carreras (según información proporcionada por el instituto).



Añadir un módulo que permita a los usuarios estudiantes recuperar sus contraseñas (en caso de que se olviden) mediante el correo electrónico asociado a su cuenta de usuario.



En la creación de cuentas de usuario, añadir la posibilidad de que el estudiante pueda subir su foto al sistema de manera que permita una mejor identificación más del mismo.



Añadir el código necesario para que sistema de inscripción no presente problemas de diseño en las interfaces, en las últimas versiones de los navegadores (Ej. Internet Explorer 10).



Añadir el código necesario en el sistema para que pueda ser utilizado en Smartphones y tablets de manera que los estudiantes puedan inscribirse a las carreras o cursos del instituto Ing Data Comp a través de estos dispositivos.



Añadir el código necesario para que el sistema de inscripción cumpla los principios de usabilidad web, de manera que incremente la facilidad de uso a los usuarios.

5.2.2 Recomendación para el módulo de facturación Una vez que el módulo de facturación sea implantado, se tienen las siguientes recomendaciones de uso: 

Verificar si el Framework .NET 4.5 está instalado en las computadoras de los funcionarios de caja ya que es fundamental para que el módulo de facturación funcione correctamente.



Realizar las configuraciones de red (descritas en el manual de instalación) necesarias para que el módulo pueda enviar las transacciones (pagos realizados) hacia la base de datos del instituto.



Registrar cada 6 meses (según indica el SIN) una nueva dosificación en el módulo para que la facturación pueda efectuarse.

241 de 243



Cambiar

las

Administradores

contraseñas de

Entidad

las

credenciales

Financiera

Funcionarios

Administrador

caja,

instituto

periódicamente de manera que incrementen la seguridad de acceso al módulo de facturación. Actualmente las contraseñas no tienen periodo de caducidad. Las posibles mejoras se describen en las siguientes recomendaciones: 

Añadir reportes de según las nuevas necesidades que aparezcan, de manera que permitan obtener la información requerida respecto a los pagos efectuados



Añadir un módulo el cuál permita bloquear los intentos fallidos de acceso al módulo de facturación mejorando la seguridad del mismo. Actualmente el módulo no cuenta con esta restricción.



Añadir criterios de búsquedas de logs más específicos de manera que permita obtener la información requerida según las necesidades existentes.



Aplicar más secciones del estándar NB-ISO/IEC 17799 de modo que permitan incrementar la seguridad en el módulo de facturación.

242 de 243

BIBLIOGRAFÍA 

Benet, C. (2003). Ingeniería de software. Barcelona: UOC.



Blake, R. (2005). Sistemas electrónicos de comunicaciones. España: Paraninfo.



Casillas, L. (2005). Software libre: BASE DE DATOS. México: Software libre.



Circular ASFI 150/2012. (2012). Reglamento para la constitución, adecuación, funcionamiento, disolución y clausura de las empresas remesadoras. Bolivia



Jacobson, I., Booch, G., y Rumbaugh, J. (2000). El lenguaje unificado de modelado. Madrid, Pearson Education.



Landeau, R. (2007). Elaboración de trabajos de investigación. Venezuela: Alfa.



Ley Nº 1488 (1993). Ley de bancos y entidades financieras. Bolivia



Ley Nº 843. (2004). Ley de reforma tributaria. Bolivia



Orfali, R. (2002) Cliente/Servidor y Objetos. Inglaterra: Oxford University Press



Pita, J. (2011). Productos y servicios en Banca. España: Lulu



Pressman, R. (2004). Ingeniería del software. México: McGraw-Hill Science.



Resolución normativa de directorio Nº 10-0016-07. (2007), Nuevo sistema de facturación (NSF-07). Bolivia.



Rob, P. (2004). Sistemas de bases de datos, Diseño implementación y administración. México: Thomson.



Rodríguez, R. (2006). Manual de java. España: Rodríguez.



Rumbaugh, J., Jacobson, I., y Booch, G. (2000). El proceso unificado de desarrollo de software. Madrid: Addison Wesley.



Sharp, J. (2009). Microsoft; Visual C# Paso a paso. España: Anaya Multimedia.



Sommerville, I. (2005). Ingeniería de software. Madrid: Pearson.



Tentor, J. (2008). Software y aplicaciones Web. Argentina: Tentor.



Yuni, J. (2006). Recursos metodológicos para la preparación de proyectos de investigación. Argentina: Brujas 243 de 243

ANEXOS ANEXO A: Circular SB/466/2004: Requisitos mínimos de seguridad informática ANEXO B: Sección 10.9.2 del estándar NB-ISO/IEC 17799: Gestión de seguridad de la información ANEXO C: Carreras y cursos disponibles Ing. Data Comp ANEXO D: Formulario de datos del estudiante ANEXO E: Registro de alumnos inscritos Ing Data Comp ANEXO F: Registro de pagos Ing Data Comp. ANEXO G: Factura de talonario del instituto Ing Data Comp ANEXO H: Tarjeta de pago de mensualidades ANEXO I: Generación del código de control ANEXO J: Cuestionarios de recolección de datos ANEXO K: Pruebas del sistema ANEXO L: Aplicación de medidas de seguridad ANEXO M: Cuestionarios para la demostración de las variables de la hipótesis ANEXO N: Valores críticos de la distribución T-Student ANEXO O: Cuestionarios de viabilidad operativa

244 de 243

ANEXO “A”: Circular SB/466/2004: Requisitos mínimos de seguridad informática

ANEXO “B”: Sección 10.9.2 del estándar NBISO/IEC 17799: Gestión de seguridad de la información

10.9.2 Transacciones en línea Control La Información involucrada en transacciones en línea debe ser protegidos para prevenir la transmisión incompleta, el error de encaminamiento, la alteración de mensajes no autorizada, el descubrimiento no autorizado, la duplicación de mensaje no autorizado o la repetición. Guía de implementación Las consideraciones de seguridad para 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, p. ej. asegurar que: 1) las credenciales de usuario de todas las partes son válidas y verificadas; 2) la transacción permanece confidencial; y 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, p.ej. sobre una plataforma de almacenaje que existe en la organización de Intranet, no conservada y expuesta en un medio de almacenaje directamente accesible desde Internet; 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 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.

Información adicional La magnitud de los controles adoptados necesitará ser correspondiente con el nivel de riesgo asociado con cada forma de transacción en línea. Las transacciones pueden necesitar cumplir con leyes, reglas y regulaciones en la jurisdicción en la cual la transacción es generada, vía de procesamiento, completada en y/o almacenada. Existen muchos formularios de transacciones que pueden ser realizados en línea p.ej. contractuales, financieras etc.

ANEXO “C” Carreras y cursos disponibles Ing. Data Comp

Carreras a nivel técnico superior: 

Analista de sistemas.



Administración de empresas.



Contador general.



Diseño gráfico.



Electrónica digital y computación.



Construcciones civiles.



Instalaciones eléctricas.



Secretariado ejecutivo.



Telecomunicaciones y redes.



Marketing y publicidad.



Topografía y geodesia.

Carreras a nivel técnico medio: 

Mantenimiento y reparación de computadoras, monitores e impresoras.



Auxiliar contable.

Cursos de capacitación: 

Operador profesional de computadoras.



Operador en diseño de páginas web.



Operador profesional avanzado de computadoras



Operador en arquitectura digital.



Operador en diseño grafico publicitario.

ANEXO “D” Formulario de datos del estudiante

ANEXO “E”: Registro de alumnos inscritos Ing Data Comp

ANEXO “F”: Registro de pagos Ing Data Comp.

ANEXO “G”: Factura de talonario del instituto Ing Data Comp

ANEXO “H”: Tarjeta de pago de mensualidades

ANEXO “I”: Generación del código de control

Los algoritmos que se utilizan para la implementación del código de control son los siguientes:

ALGORITMO ALLEGED RC4: Algoritmo de criptografía simétrica, basado en cifrado de flujo (stream cipher), muy utilizado por su rendimiento y simplicidad. Para efectos de la implementación del código de control, la llave se conformará a partir de caracteres del siguiente diccionario:

ALGORITMO VERHOEFF: Algoritmo de digito verificador que trabajo con cadenas de dígitos decimales de cualquier tamaño. Además de detectar una amplia gama de errores de datos numéricos, este algoritmo también detecta casos de transposición de dígitos adyacentes.

ALGORITMO DE BASE 64: El algoritmo de Base 64, se trata sencillamente de pasar un número en base 10 a base 64, manteniendo una relación de equivalencia entre número y carácter por ejemplo A=10, B=11,…./=63 Base 64 equivale a hacer la conversión de números a palabras. Para lograrlo se basa en el método de visiones sucesivas hasta llegar a un cociente 0, los restos en orden inverso, expresados como caracteres, dan la palabra resultante.

Implementación del código de control: La generación del código de control se describe a continuación mediante un ejemplo: 

Se requieren de datos iniciales que se muestran en la siguiente figura.



Se obtienen 2 dígitos Verhoeff mediante concatenación al final de los datos: Número Factura, NIT / CI del Cliente, Fecha de la Transacción y Monto de la Transacción. Luego se halla la sumatoria de los datos obtenidos y sobre este resultado se ha generado consecutivamente 5 dígitos Verhoeff. Los resultados hallados son:



Tomando cada uno de los 5 dígitos Verhoeff obtenidos, se ingresa la llave de dosificación de dosificación (solo 5 cadenas adyacentes), cada una con un largo definido por el dígito Verhoeff correspondiente más 1. A continuación se concatena la primera cadena obtenida al final del dato relacionado al Número de Autorización; la segunda al Número de factura; la tercera al NIT / CI del Cliente; la cuarta a la Fecha de la Transacción y la quinta al Monto de la Transacción. Los resultados hallados son los siguientes:



A continuación se aplica el algoritmo AllegedRC4 a la cadena conformada por la concatenación de todos los datos anteriores, utilizando como llave la concatenación de la Llave de Dosificación y los 5 dígitos Verhoeff generados previamente, los resultados son:



A continuación se obtiene la sumatoria total de los valores ASCII de todos los caracteres de la cadena resultante del paso anterior, además, se calcula 5 sumatorias parciales de los ASCII de ciertos caracteres de la misma cadena, de acuerdo al siguiente criterio: La primera sumatoria parcial toma las posiciones 1, 6, 11, 16, 21, etc.; la segunda 2, 7, 12, 17, 22, etc.; la tercera 3, 8, 13, 18, 23, etc.; la cuarta 4, 9, 14, 19, 24,etc. y la quinta 5, 10, 15, 20, 25, etc. El resultado de la operación es el siguiente:



Se obtienen las multiplicaciones entre la sumatoria total y cada una de las sumatorias parciales. Luego se dividen cada uno de los resultados obtenidos entre el dígito Verhoeff correspondiente más 1, el resultado deberá ser truncado. Finalmente se obtiene la sumatoria de todos los resultados y se aplica el algoritmo Base64, dando resultado a:



Se aplica AllegedRC4 a la anterior expresión obtenida, utilizando como llave la concatenación de la Llave de Dosificación y los 5 dígitos Verhoeff generados anteriormente.



La información resultante del proceso de cifrado, expresada en formato hexadecimal separada en pares por guiones (-), da resultado al código de control, el resultado se muestra a continuación:

La información resultante del proceso de cifrado, expresada en formato hexadecimal separada en pares por guiones (-), dando resultado al código de control: 6A-DC-53-05-14.

ANEXO “J”: Cuestionarios de recolección de datos

ANEXO “K”: Pruebas del sistema

Pruebas unitarias: Sistema de inscripci贸n Casos de prueba: Haciendo el uso del framework NUnit se han creado los casos de prueba en Visual Studio para realizar las pruebas, como se muestra a continuaci贸n. Casos de prueba del sistema de inscripci贸n

La descripción de cada caso de prueba se muestra en la siguiente tabla: Caso de prueba

PruebaUnitariaRegistrar Carrera

PruebaUnitariaRegistrar Curso

PruebaUnitariaRegistrar Usuario

PruebaUnitariaRegistrar Inscripcion

Descripción Permite realizar la prueba unitaria referente a todos los elementos en la creación de carreras y sus relaciones existentes Permite realizar la prueba unitaria referente a todos los elementos en la creación de cursos y sus relaciones existentes Permite realizar la prueba unitaria referente a todos los elementos en la creación de cuentas de usuario y sus relaciones existentes Permite realizar la prueba unitaria referente a todos los elementos en el registro de una inscripción y sus relaciones existentes

Pruebas unitarias: Mรณdulo de facturaciรณn Casos de prueba: Haciendo el uso del framework NUnit se han creado los casos de prueba en Visual Studio para realizar las pruebas, como se muestra a continuaciรณn. Casos de prueba del mรณdulo de facturaciรณn

La descripciรณn de cada caso de prueba se muestra en la siguiente tabla: Caso de prueba

Descripciรณn

PruebaUnitariaRegistrar

Permite realizar la prueba unitaria referente a todos los

EntidadFinanciera

elementos en entidades financieras Permite realizar la prueba unitaria referente a todos los

PruebaUnitariaRegistrar Agencia

elementos en la creaciรณn de agencias de entidades financieras Permite realizar la prueba unitaria referente a todos los

PruebaUnitariaRegistrar CredencialUsuario

elementos en la creaciรณn de credenciales de usuario y sus relaciones existentes

PruebaUnitariaObtener

Permite realizar la prueba unitaria referente a la

PagoPendiente

obtenciรณn de pagos pendientes de estudiantes Permite realizar la prueba unitaria referente a todos los

PruebaUnitariaRegistrar Transaccion

elementos en el registro de un pago y sus relaciones existentes

Pruebas de carga: Sistema de inscripción Se añadió una prueba de rendimiento en el proyecto de prueba de visual studio, mediante el cuál se prueba las funcionalidades del sistema de manera que se cree una secuencia de uso habitual del sistema. Esta secuencia posee parámetros dinámicos (solicitudes realizadas al sistema) mediante los cuales se realiza la prueba. El detalle se muestra a continuación Prueba de rendimiento: Sistema de inscripción

En la anterior figura se puede observar el rendimiento de cada solicitud enviada hacia el sistema, mediante parámetros como el estado, tiempo total de envío de solicitud y bytes enviados. Primera prueba Utilizando la secuencia anterior de solicitudes se ha creado una primera prueba de carga con los siguientes parámetros: 

Cantidad de usuarios: 100



Modelación de combinación de prueba: A partir de usuarios virtuales. (Solicitudes enviadas al sistema a partir de los parámetros dinámicos de la prueba de rendimiento)



Explorador: Google Chrome, Firefox, Internet Explorer



Iteraciones de la prueba: 50

Los resultados de esta prueba se pueden visualizar en la siguiente figura.

Con 100 usuarios, las pruebas se han efectuado sin errores. Se utilizó 32,1 % de uso de procesador y hubo 1 infracción. La cual se puede ver en la siguiente figura:

De 100 usuarios que utilizan el sistema de manera concurrente, se puede ver que se da una advertencia de que 1 excede el uso recomendado de procesador (transacciones muy lentas) Segunda prueba: Se aumentó la cantidad de usuarios que pueda soportar el sistema, como se muestra a continuación: 

Cantidad de usuarios: 1000



Modelación de combinación de prueba: A partir de usuarios virtuales. (Solicitudes enviadas al sistema a partir de los parámetros dinámicos de la prueba de rendimiento)



Explorador: Google Chrome, Firefox, Internet Explorer



Iteraciones de la prueba: 100

Esta prueba ha dado los siguientes resultados:

Las prueban se han ejecutado sin errores. Se utilizĂł un 46.1 % de tiempo de procesador y se obtuvo 6 infracciones, como se puede ver en la siguiente imagen

La prueba dio resultado a 4 infracciones de advertencias y 2 crĂticas. Es decir que de los mil usuarios que usan el sistema de manera simultĂĄnea, 2 se cuelgan o no funcionan de manera correcta y 4 exceden el uso recomendado de procesador, es decir que las transacciones pueden ser muy lentas.

Tercera prueba: Se aumentó la cantidad de usuarios que pueda soportar el sistema, como se muestra a continuación: 

Cantidad de usuarios: 10000



Modelación de combinación de prueba: A partir de usuarios virtuales. (Solicitudes enviadas al sistema a partir de los parámetros dinámicos de la prueba de rendimiento)



Explorador: Google Chrome, Firefox, Internet Explorer



Iteraciones de la prueba: 100

Esta prueba ha dado los siguientes resultados:

Las prueban se han ejecutado sin errores. Se utilizó un 56.4 % de tiempo de procesador y se obtuvo 14 infracciones, como se puede ver en la siguiente imagen

La prueba dio resultado a 9 infracciones de advertencias y 5 crĂticas. Es decir que de los 10 mil usuarios que usan el sistema de manera simultĂĄnea, 5 se cuelgan o no funcionan de manera correcta y 9 exceden el uso recomendado de procesador, es decir que las transacciones pueden ser muy lentas.

Pruebas de carga: Módulo de facturación ANTS Performance profiler, permite configurar parámetros para la ejecución de pruebas de carga.

Como el módulo de facturación es una aplicación cliente de

escritorio, se han enfocado las pruebas a solicitudes sql, ya que carece de solicitudes http (como el sistema de inscripción). Primera prueba Los parámetros tomados en cuenta son los siguientes: 

Cantidad de usuarios: 100



% de uso de procesador



Solicitudes a base de datos (SQL)



Contador de hilos de procesador



Entrada/Salida de operaciones



Entrada/Salida de bytes

Los resultados de la prueba realizada se muestran a continuación:

En esta figura se puede observar las solicitudes SQL realizadas por el módulo de facturación, donde el tiempo más largo es de 24 segundos. En la siguiente figura se puede también observar el uso de procesador.

En la anterior figura se puede observar que solo en una ocasión el porcentaje de uso de procesador excede el límite recomendado (132.12%) lo cual puede dar lugar a

mal funcionamiento o lentitud en el sistema. Estas pruebas han sido efectuadas sin errores. Segunda prueba Los parámetros tomados en cuenta son los siguientes: 

Cantidad de usuarios: 1000



% de uso de procesador



Solicitudes a base de datos (SQL)



Contador de hilos de procesador



Entrada/Salida de operaciones



Entrada/Salida de bytes

Los resultados de la prueba realizada se muestran a continuación:

En esta figura se puede observar las solicitudes SQL realizadas por el módulo de facturación, donde el tiempo más largo es de 92,57 segundos. En la siguiente figura se puede también observar el uso de procesador.

Se puede observar que de 1000 usuarios solo en tres ocasiones el porcentaje de uso de procesador excede el límite recomendado (132.75%, 117.38%, 111.71%) lo cual puede dar lugar a mal funcionamiento o lentitud en el sistema. Estas pruebas han sido efectuadas sin errores.

Tercera prueba Los parámetros tomados en cuenta son los siguientes: 

Cantidad de usuarios: 5000



% de uso de procesador



Solicitudes a base de datos (SQL)



Contador de hilos de procesador



Entrada/Salida de operaciones



Entrada/Salida de bytes

Los resultados de la prueba realizada se muestran a continuación:

En esta figura se puede observar las solicitudes SQL realizadas por el módulo de facturación, donde el tiempo más largo es de 145 segundos. En la siguiente figura se puede también observar el uso de procesador.

Se puede observar que de 5000 usuarios solo en cuatro ocasiones el porcentaje de uso de procesador excede el límite recomendado (124.85%, 135.7%, 110.69%, 124.47%) lo cual puede dar lugar a mal funcionamiento o lentitud en el sistema. Estas pruebas han sido efectuadas sin errores.

ANEXO “L”: Aplicación de medidas de seguridad

Aplicación de medidas de seguridad al sistema de inscripción: El servidor IIS se ha configurado con los siguientes pasos: 

En el panel de control de Windows, se selecciona la opción que muestra la ilustración:



Se tickea la opción de Internet Información Services y click en Aceptar, como se puede ver en la siguiente figura:



El servidor se activa. Para acceder a la interfaz de administración del mismo se presiona el botón Inicio de Windows, en la casilla de búsqueda se ingresa “IIS” y se selecciona: “Administrador de Internet Información Services (IIS)”.



Con esto el servidor de aplicaciones está activado y configurado para la publicación del sistema de inscripción una vez que este implementado.

Configuración de seguridad en el servidor de aplicaciones: Se ha activado la capa de conexiones seguras (SSL) que permite intercambios encriptados entre cliente y servidor mediante un certificado firmado por una entidad certificadora (Ing Data Comp). Para la creación de entidad certificadora y el certificado firmado por la entidad se ha utilizado la herramienta makecert en la consola de Windows (CMD) que viene instalado en el SDK de este sistema operativo. En la siguiente figura se puede observar la creación de ambos certificados.

La especificación de los parámetros usados para la creación de ambos certificados se muestra a continuación: 

-pe: Clave privada de certificado exportable



-sr: Ubicación del almacén de certificados del sujeto (localmachine)



-ss: Nombre del almacén de certificados que almacena el certificado de salida



-n “CN=nombre”: Nombre de certificado



-cy: Especifica el tipo de certificado, donde Authority es para el tipo de entidad emisora de certificados.



-a: Especifica el algoritmo de la firma (md5 o sha1)



-sky: Especifica el tipo de clave, donde Exchange indica que la clave se usa para el cifrado e intercambio de claves.



-b: Especifica el principio del periodo de validez del certificado



-e: Especifica el final del periodo de validez del certificado.



-sv: Especifica el archivo de la clave privada .pvk del sujeto.



-r: Crea el certificado con firma automática



-eku: Inserta en el certificado identificadores de objetos (OID), donde el oid: 1.3.6.1.5.5.7.3.1 permite la autenticación del servidor



-sp: Especifica el proveedor CryptoAPI del sujeto



-sy: Especifica el tipo de proveedor CryptoAPU del sujeto



-ic: Especifica el archivo de certificado del emisor



-iv: Especifica el archivo de clave privada .pvk del emisor

Una vez creados los certificados correspondientes se instaló el certificado Raiz (Ing Data Comp) en la ruta de Entidades de certificación intermedias y se utilizó la herramienta pvk2pfx mediante la consola de Windows para la exportación del certificado creado para el sistema de inscripción, esta exportación se puede ver en la siguiente imagen.

Es importante mencionar que se debe aumentar las siguientes líneas en el archivo host de Windows: 

127.0.0.1



127.0.0.1

www.ingdatacomp.com 443

www.ingdatacomp.com

Estas líneas permiten que se cree un host virtual con la previa configuración del sistema de inscripción en el servidor IIS, también se debe agregar al navegador el certificado raíz creado para que este reconocido como entidad certificadora de confianza. En el administrador de IIS, en la opción de Certificados de servidor se importó el certificado buscando el archivo .pfx creado previamente. Luego se procedió a la publicación del sistema mediante el mismo administrador, añadiendo el certificado importado y activando al mismo tiempo https (http seguro) con el puerto 443. Esta configuración se puede visualizar a continuación:

Si se observa en la anterior figura se puede ver que se activ贸 https (http seguro) al sistema de inscripci贸n mediante un certificado SSL. Los detalles de este certificado se pueden visualizar en la siguiente figura.

De esta manera el sistema de inscripci贸n queda publicado y configurado correctamente.

Creación de cuentas de usuario y contraseñas 

Las políticas, normas y procedimientos de seguridad informática: Se ha considerado lo siguiente: -

Se utilizará la siguiente política en la creación de usuarios y contraseñas para el acceso al módulo de facturación: 

Tamaño mínimo: 8 caracteres



Uso de al menos 1 carácter especial y 1 número en el usuario y contraseña



El nombre de usuario debe empezar con una letra ya sea mayúscula o minúscula.



Uso de al menos una letra en mayúscula.



No debe existir espacios en el nombre de usuario o contraseña



La contraseña no debe ser igual al nombre de usuario y se debe evitar secuencias básicas de teclado (Ej: qwerty, 123, asd, etc)



La contraseña está encriptada en la base de datos. Su implementación se encuentra en el siguiente punto.

Cifrado en creación de contraseñas e inicio de sesión: Se aplicó el algoritmo de encriptación MD5, para el cifrado de la contraseña en la base de datos y para el inicio de sesión al módulo de facturación. A continuación se muestra la implementación del algoritmo.

Cifrado en la conexión en línea entre cliente (módulo de facturación) y servidor (base de datos): Se configuró y activó las conexiones entrantes al servidor mediante un certificado SSL de SQL server mediante la herramienta de Windows makecert de la misma manera en la que se creó el certificado el sistema de inscripción. El detalle del certificado creado para SQL server se muestra en la siguiente figura:

El certificado que se muestra en la anterior figura permite que las conexiones del mรณdulo de facturaciรณn hacia la base de datos del instituto estรฉn cifradas. Se procediรณ la instalaciรณn del certificado (previa exportaciรณn) en el servidor, mediante el asistente de importaciรณn de certificados (en los certificados de confianza) de la consola Raiz de Windows.

Finalmente se exportรณ el certificado instalado en la herramienta de administraciรณn de configuraciรณn de SQL server (Propiedades de protocolos de MSSQLSERVER) se seleccionรณ el certificado y se activรณ la conexiรณn cifrada, como se puede ver en la siguiente imagen.

Con esta configuraci贸n el servidor solo puede recibir conexiones cifradas del m贸dulo de facturaci贸n, permitiendo una conexi贸n segura.

Consideraciones de seguridad según estándar NB-ISO/IEC 17799 de la ASFI 

El detalle de las consideración de seguridad es el siguiente: -

Certificados digitales: Se ha creado una entidad certificadora (Instituto) que firma certificados digitales para autenticar la identidad de la misma. El certificado se puede ver en la encriptación SSL del sistema de inscripción (descrita en el punto 3.3.7.1 del marco práctico) y la conexión del módulo de facturación en el presente anexo.

Valide de credenciales de usuario: Las credenciales de usuario son válidas si son habilitadas por el Administrador del instituto.

Conexión cifrada y protocolos seguros: La conexión en línea entre el módulo de facturación situado en la entidad financiera y la base de datos situado en el instituto está cifrada. El detalle de su implementación se puede ver en la anterior sección.

Sistema solo accesible en ambiente seguro: Como se ha diseñado e implementado el enlace en línea (Ver punto 3.4.3.5 del marco práctico) la conexión entre entidad financiera e instituto es efectuada mediante una línea dedicada, dando lugar a una red privada. Así mismo se ha recomendado el uso de un firewall con las reglas de entrada y salida que limitan el acceso a solo a protocolos y puertos específicos de manera que impiden la exposición a redes externas (acceso por internet). Estas reglas se describirán más adelante.

ANEXO “M”: Cuestionarios para la demostración de las variables de la hipótesis

ANEXO “N”: Valores críticos de la distribución T-Student

ANEXO “O”: Cuestionarios de viabilidad operativa